C# 3.0 is Right Around the Corner (in the Microsoft sense of the word…), and it brings to bear a lot of interesting features. Most of them come together in the technology called LINQ (Language INtegrated Queries). Even though I doubt I will use C#, I think there is a lot that can be learned from this preview release. Let’s take a look at an example Query:

var contacts =
    from cust in customers
    where cust.State == "PA"
    select new { cust.Name, cust.Email };

If the syntax looks familiar, that’s not strange. It’s modeled after SQL-syntax. As a matter of fact, if “customers” is a database table mapped with DLinq, the result will be a SQL call directly in the database! However, if customer is a collection or an XML file, LINQ will do The Right Thing. How can this work? In a word: Mechanics. The syntax as you see it is merely syntactic sugar for the following:

var contacts =
    customers
    .Where(cust => cust.State == "PA")
    .Select(cust => new { Name = cust.Name, Email = cust.Email });

This is still pretty magical, but if we look at a few other new features, it will all be clear. First: “x => x.State == “PA” is a lambda expression with “x” as the lambda variable. As customer can be a generic collection, the compiler can presumably resolve the type of x statically. “new { Name = cust.Name, Email = cust.Email }” creates an anonymous class with two variables Name and Email. Last, “var” is a dynamically (or quasi-dynamically) typed variable. Presumably, it will be statically typed when the compiler can guess the type. In this case, it will be a collection of the anonymous class created by the select statements. These “implicitly typed” variables are essensial for dealing with anonymous classes. How else would you be able to say result[0].Name?

So much for the mechanical part. This first level of LINQ-translation is just syntactic sugar, and when you look at the resulting statement, it doesn’t even add all that much sweetness! I would instinctively prefer the later syntax. Of course, this syntax has an essential feature that is presently lacking from both C# and Java: lambdas. Now for the magic part:

I have been assured that these expression (“table.Where(row => row.Column1 == “Test”).Select(row => new { row.Column2, row.Column2 }”) will be translated into SQL when executed to the database. Presumably something like “SELECT column2, column3 FROM table WHERE column1 = ‘Test’”. Now here is what I want to know: Short of decompiling the lambda “row => row.Column1 == “Test”", how is that even possible!?

In conclusion: Integrating queries into the language is something that I don’t particuarly think is a good idea. It seems to be cluttering up the language a lot. Integrating lambda expressions and a good set of collection libraries that take advantage of them is, on the other hand, an obvious improvement. If I could just figure out how they translate those lambdas into SQL… Hmm… good stuff to think about.

For the most part I think Ruby on Rails is pretty much the best thing since sliced bread. Of course, like everything else, there are some issues I’m uncomfortable with. Mostly, it has to do with deployment, and especially security during deployment.

• SwitchTower deploy.rb configuration file contains source repository password. This is a consequence of the fact that the application servers check out code from the repository.
• When using SwitchTower the source repository must be available from the application servers. Ideally, the source repository should be very deep behind corporate firewalls, whereas the application server is of course in the DMZ. Requiring a communication path between these is not a good thing.
• Rails production database password in database.yml in the source repository. This is a biggie. I don’t think developers in general should be trusted with the production server passwords. Is this a common theme with LAMP applications?
• Rails supports no obvious ways of using different databases for different production servers (e.g. rolling out applications to several customers). The production server in database.yml will be the same for all roll-outs. In particular, I would like to have the same application rolled out to two different directories on the same web server using different databases.
• There seems to be no way to run a Rails application in Apache both on Windows and Unix without modifying the shebang line in the dispatch.* scripts manually during the installation.
• Per default, Rails expects administrative privileges for Apache to turn on production mode. This is not practical for hosted solutions.
• No support for different developers of the same application having different development and test databases (unless these are local).

These are not issues that are perfectly solved by any competing architecture. Neither are they issues that can’t be solved with a little bit of hard work. However: Rails has the potensial of solving them better than most:

• Switchtower should pack and upload during deployment instead of checking out from the production server. That way, neither the communication path from app server to source repository or the source repository password would be an issue. It will also lessen the dependencies on installed software on the server
• Applications should be partitioned so the .htaccess and the database.yml configurations could remain on the server and differ between servers. database.yml should probably be fragmented so only test and development databases should be stored in the source repository. The goal is to separate the application code from the local configuration during deployment.

The second point may not be as straightforward to implement as the first, but there might be LAMP architecture patterns to solve this kind of problem. The solution is left as an exercise for you, gentle reader.

Everyone is talking about SwitchTower these days, so I just had to check it out. When I got it to work, I was quite pleased with how it works, but there were quite a few issues along the road.

First of: What is SwitchTower? Basically, it is a tool for automating deployment of applications, focused around Ruby on Rails. With SwitchTower in place, I am able to write stuff like “rake deploy” and “rake rollback“. rake deploy will: check in my code locally, check out the latest version on the server, and update a symbolic link to point to it. On the best of days, it is “one click deployment”.

However, it took me quite a bit of effort to get it to work. Much of the reason for this, was that I am running my development on Windows with a local CVSROOT and deploying to Linux. This introduced some hitches.

First off: rake deploy will not run on Windows out of the box. The reason: it is defined as system "switchtower -vvvv -r config/deploy -a deploy". On Windows, this should be system "switchtower.cmd -vvvv -r config/deploy -a deploy". In addition, I am saddened by the fact that rake does a system call out to execute switchtower, instead of directly invoking Ruby code.

Source repository location: I had major problems with the version control. The documentation is not explicit about this, so I wasn’t sure, but SwitchTower does a checkout from the server, instead of checking out at the client, packing the code, and shipping it. If you CVS server is behind a firewall that can’t be reached from the server, this won’t work, quite simply. Instead of using CVS I decided to switch to hosting SVN on the same server as the application.

Subversion on Windows: Getting SVN to work on Windows was not straightforward, either. Basically, I had to edit the rather obscure “C:\documents and settings\username\Application Data\Subversion\config” file to set the correct ssh-client. I also had to use svn+ssh, which means I had to specify the password in the SwitchTower deploy.rb-file (ouch!). I also had to patch up switchtower/lib/scm/subversion.rb: It uses the regexp “/^Password.*:/” to check if the server prompts for password. But my server says: “user@host's password:“.

Unix and Windows incompabilities: Getting it to work on the server. I have encountered a number of problems with getting it to work, none of which are caused (or solved) by SwitchTower. First: Make sure the shebang (“#!…/ruby”) line in dispatch.rb, dispatch.cgi and dispatch.fcgi is correct. Since I don’t deploy on Apache on Windows, I have left all these as #!/usr/local/bin/ruby. Second: File format. This is extremely important: .htaccess and dispatch.* should have Unix line endings (many Unices come with “dos2unix” for fixing this). Luckily, Ruby is quite lenient about line endings, so these four files are the only ones where file format is critical. Third: The production server in database.yml has to be set correctly. All these issues are best fixed by making changes to the files in your repository.

Last, dispatch.* should be executable. I am not sure if this is even possible in CVS, but in SVN, you just set the “svn:executable” property, and Bob’s your uncle. I do wish that SwitchTower could’ve set the executable bit, though.

With all these gotchas, I finally got SwitchTower to work. So far, once I have gotten it to work, it is a thing of beauty. My second deployment worked on the first try! Check it out, but bring a good guide (like this document) and some patience – SwitchTower still have quite sharp edges.