Enterprise Etc Adventures and Insights of a .Net Developer

For the past few weeks I've been kicking the tires on the Ruby language and the Rails framework.  This post is not meant to be a review of either, but I thought I'd note some of my impressions for other .Net developers that have been hearing the buzz and have not had the time to take a look.

First of all, I'm not planning to make a jump from ASP.Net to rails anytime soon.  However, I think there is always benefit in exploring other technologies, approaches and points of view and my look at these things was primarily motivated by curiosity.

The Ruby Language
I love this language.  Scott Hanselman has commented on how easily intent can be expressed in Ruby and Wilco Bauwer likes its rhythm.  Writing logic in it feels really natural, to me, and it seems that whenever I need a particular piece of functionality, it's available and easy to invoke without having to jump through hoops.  Without casting a vote for either dynamic languages or statically typed ones as the be-all-and-end-all, I have to say that if I were to be tasked with creating a domain specific language I'd certainly go for Ruby as my language of choice to implement it in.  It lends itself well to that type of exercise.  After all, to an extent Rails is a DSL for the web application space.  Some day to day tasks would lend themselves well to being implemented in Ruby.  Command line tasks, in particular, could be easily handled in Ruby.  The language (as implemented for Windows) supports calling into the win32 API and COM.  It does not contain any support for building windows UI, though you can do that by calling the windows API (if you're nuts) or by making use of one of the many Ruby .Net bridges that are freely available.  Just don't expect the performance of the bridge to blow you away.

Another thing that impressed me was the number of dynamic language features that are making their way into .Net languages.  Anonymous methods, continuations and extension methods all seem to have their roots in dynamic languages such as Ruby. 

Ruby is easy to learn and the code is easy to read.

Rails Framework
As one who appreciates the value of convention and likes having a process in place to grease the wheels of progress, I find Rails to be a very comfortable approach to use for web development.  As stated on many Rails-Centric sites, Rails is about "Convention over configuration"  and "DRY" or "Don't Repeat Yourself" meaning don't duplicate code.  Typical frameworks offer abstractions to make the most commonly required functionality easier and faster to use.  Rails does this well, but adds code generation and a type of adaptability that could only be achieved by using dynamic language such as Ruby.  There is also a substantial number of tools to aid the developer with ancillary tasks such as deployment and testing.  In general, Rails forces the developer to use the Model-View-Controller pattern to build their web application.  Few would argue with this approach.  ActiveRecord, which is an ORM library, is used for database access.  ActiveRecord is the stated inspiration for the Subsonic library written in .Net and greatly simplifies database access.

Many proponents of Rails claim extraordinary gains in productivity can be achieved.  I can see how productivity can be increased greatly for an experienced Rails developer, but be warned that there is a lot to remember and new Rails developers may find they are spending a great amount of time in the Rails documentation. 

There are a few IDE's out there that support Rails development.  I preferred RadRails and have been using it for the past few weeks with good success.  I found that Rails, as many have claimed, brought some fun back to the development of web pages. 

The one area I found to be a significant pain was in the deployment story.  Rails is not thread safe.  This means that each web request cannot be handled by only a new thread, but a new process.  I searched, for some time, and found some solutions using FastCgi which basically spins up several instances of a web server and feeds requests to them.  There seem to be some better solutions on the horizon , but I was not able to find what I would consider to be a "clean" solution to use immediately.

I've gained a number of insights, so far, from this exercise.  I don't see myself building my next business application in Rails (but, who knows) or even being gainfully employed as a Rails developer, but the lessons learned will continue to open my mind and make me a better developer.

As I mentioned in a previous post, I'm relatively new to using SubSonic.  I'm working on a web application and the lure of not having to write a ton of boiler plate database access code lead me to use this technology.  Recently, I encountered a problem with it, however, and though I'd pass on what happened and the solutions I found.

I had been happily using subsonic within the workflow of the normal Asp.Net page lifecycle.  I've even been using some callbacks from pages with no problems at all.  It was when I started adding some Asp.Net Ajax functionality to the site that I encountered problems.  I set up a call to a webservice from the browser.  Within this web service method, I was using SubSonic to populate one of the Active record classes it built and was, then, passing that class back as the return value.  When I executed the code, I received an error message saying that an instance of the class I was returning could not be created because one of its properties was inaccessible. 

After some investigation, I discovered that the problem was occurring when the object I was returning was being serialized to be passed back to my page.  When SubSonic generates the active record classes for you, it generates a property for each column on the table that the class corresponds to.  If that column is nullable, the property's type is set as a nullable type, as well.  This makes perfect sense to me.  However, the XmlSerializer cannot serialize nullable types.  This means that if your table has nullable columns in it, the class generated by SubSonic cannot be serialized.

So, I modified my table such that none of the columns were nullable, regenerated my classes and tried to execute the code, again...same error - different property.  This time, it seems, the offending property was one that is defined in the AbstractRecord class from which my generated class derives.  The "get" was marked as protected and, as such, could not be read by the serializer.  I had found some posts in the forums on the SubSonic site that pointed out the problem and the recommendation was to modify the class in the SubSonic source code, recompile the project and then regenerate your classes.  Thankfully, though, the problem had already been addressed by the latest version (2.0.1a) of the project and this change is not necessary if you upgrade.

It was a scary moment for me, but now that I understand the limitations of the XmlSerializer in regard to nullable types I can code around the issue and not encounter this problem again.