Monday, 8 March 2010

Rails - Day 1 - The RubyGems Love Story

What ASP.NET (MVC) Developers Can Learn from Rails)

Rails  - Day 1 - The RubyGem Love Story
Rails -  Day 10 - Testing Rails Controllers
Rails -  Day 13 -ActiveRecord Relationships Part II
Rails - Day 15 - Rails Forms Part II
This post marks the start of a series of posts I am going to pen in order to prepare for my upcoming talk at DDD Scotland in May.

My talk goes by the somewhat sterile working title of What ASP.NET (MVC) Developers Can Learn from Rails).

One thing I am not going to touch heavily on in these posts is the Ruby language itself.  These posts are to illustrate the magic of Rails and just what a web framework should be.

When I first started delving into rails, I wanted to see what all the fuss was about.  I held in my conflicted head the analogical image of a ruby on rails developer as that of a corduroy trouser wearing, bearded and long haired yahoo who was just a little bit too “peace and love” for somebody with my angst riddled views.  The last thing I expected was to become one of the dreary voices that I had less than affectionately called rails bores who endlessly drone on about how things are done in rails.

As you might have guessed, I am now a rails bore who prattles on about what we are missing in .NET which is still sadly how I still earn most of my income.  Is the grass always greener and am I just hankering for the new and shiny?  Possibly and probably but I am moved to discuss rails in some capacity at least.

The goal of these posts is to turn you the reader, into another YARB (Yet Another Rails Bore).

So first things first, if you have not installed ruby then you can find the one click installer here. 

Now we are ready to install the rails bits themselves.  This brings us nicely onto one of the most frictionless package managers you are ever likely to use at this time of writing anyway.  I speak (in hushed and gushing tones) namely of the package manager of ruby known as RubyGems.  RubyGems is a package manager for ruby that provides a standard format for distributing Ruby programs and their libraries.  These libraries form self-contained units called gems
.  Not only does it provide a standard format that anyone wanting to create gems must adhere to, but it also provides a server for distributing them.  The notion of a standard format is a theme we will see repeating itself in Ruby on Rails time and time again.  It is this standard approach that allows so many of the convention over configuration paradigms to just flow through Rails.  

Anybody familiar with me will know of my crude attempts at providing a mechanism similar to this in .NET land with the horn project. In horn’s defence, we are fighting with the .NET assembly model and compiled binary code files.  Ruby is only dealing with code files but it does this pretty damn elegantly in my estimation.

Put simply, if I want a shared library (for example rails) I do NOT do the following which I might end up doing in .NET:

  1. I do not google for the home page of the OSS project in question.
  2. I do not have to download the source using svn, git or now God help us Mercurial.
  3. I do not have to install versions 23.2093.20329 of Nant or go near powerbuilder, psake or God knows what other builder is currently du jour in .NET OSS land in order just to build the damn thing.
  4. I do not have to then recompile all my other dependencies that might use the shared library 


I have already saved myself a lot of time and pain by NOT using .NET.  I have a standard delivery mechanism for the multitude of shared libraries out there.  

I recently got myself into a right pickle by not being able to update my development stack that includes castle, nhibernate and rhino to use ASP.NET MVC 2.0.  I gave up after half a day of pain.  The bits would just not fit together.  If I am guilty, I am guilty of using too much open source.  Never did I think such a statement was possible.

So with RubyGems at my disposal, I simply open a command prompt and type gem install rails --include-dependencies and sit back and watch the gem package manager seamlessly deliver on its promise.



As you can see, ruby has not only transparently downloaded the source code and installed rails and its dependencies but also retrieved the documentation.  RubyGems sets down standards and models like a consistent folder structure for anybody wanting to create their own gems to adhere to.  This consistency allows us to guarantee where things are and thus provide a more frictionless development environment I find seriously lacking in .NET.  It is this consistency and similarity that makes great things possible and is what I want to convey in these posts.

If I could get a fraction of what is possible with RubyGems into horn then I would consider the job more than adequately done.  The very fact that I can update my library with one command is mind blowing.  No hacking about with git, forking the code or whatever else I might currently have to do in .NET is beautiful.

For example, if I want to update RSpec, then I simply issue the command gem update rspec.  If I do this then I am greeted with the following:


RubyGems allows:
  • Easy Installation and Removal of RubyGems and their dependents
  • Management and control of local packages
  • Package dependency management (worth the admission price alone)
  • Query, search and list local and remote packages
  • web-based interface to view the documentation for your installed gems
  • Easy to use interface for building gem packages
  • Simple server for distributing your own gem packages

Benefits include:
  • download and install Ruby libraries easily
  • not worry about library A and B depending on different versions of library C.  You might want to reread this point, it is true!!

Having a delivery mechanism likes this means I can simply use all the OSS I want and have a standard interface to browse, install, update and uninstall my packages.

I am trying to find the words to express how important I think a delivery mechanism like this is but I cannot.  My involvement with horn is how serious I think this is.

I am wary of making these blog posts too long, so I will leave things here.

It seems short blog posts are this season's black.

I implore you to install Ruby and play with RubyGems.  

Truly remarkable in my estimation.

As stated earlier, this is worth the admission price alone.

In the next post, we will start to touch on convention over configuration a.k.a. the death of Xml configuration files!!


Posted by Paul Cowan at 05:16

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)