software solutions / project leadership / agile coaching and training

My first foray into Ruby on Rails

Posted on October 6, 2009

I finally broke down, set aside some time, and learned Ruby on Rails. My previous experience had been the Ruby Koans, random discussions with people, and a couple quick demos. So basically I knew Ruby, but not Rails.

I started by reading through Rails For .NET Developers, which was an excellent book. Normally I don’t read a lot of tech books (I’m more of a blog guy), but when I’m learning something new, I like having something that will walk me through it. This book did an excellent job of it.

So I had a basic web site with a couple pages and I started building it. I used RSpec for my testing framework and I wrote my tests first, of course.

I was surprised at how similar Rails development is to ASP.NET MVC. Certainly the language is different, but you’re using the same MVC pattern, you’re writing tests for the same things, and you’re creating views in pretty much the same way. I knew that the .NET community had borrowed a lot from Rails, but I got a first hand view of it. I was glad to know that my world wasn’t going to be turned upside down.

The main thing that I noticed is that with Ruby on Rails, it’s really easy to hit the ground running. You have most of what you need out of the box with Rails, and you can easily install more gems to provide extra functionality. It’s all so easy and there is very little friction.

I’ve been doing .NET for awhile now, and I feel that I have a pretty good understanding of it. I’ve learned a lot of tricks and I use a lot of open source projects and other Microsoft libraries to add functionality to .NET, similar to how you add gems in Rails. I written code myself that does database migrations (like rake db:migrate) and code that runs builds (like rake… I’ve even used rake in .NET). But there several significant differences — first, I had to know about the open source projects (and I suspect that many people don’t know about some of them, or worse, aren’t allowed to use them). Second, I have to download them and set them up myself (and know how to do it). Third, I had to write some of the code from scratch.

I think the point I’m trying to make in that last paragraph is that someone who is new to .NET could not grab ASP.NET MVC and have everything they need to create a really good, frictionless, ASP.NET MVC app. When I did my Rails app, I already had my ORM, database migrations, build runner, and my project structure was set up with a lot of code generated for me.

The other benefit to this is that most Rails developers will most likely be doing things the same way. If you do Rails, you’re going to be using an MVC framework, you’re going to use ActiveRecord as your ORM, you’re going to use rake, you’re going to have the same project structure, and on and on. In the .NET world, there are so many different solutions out there. Not that they are all bad, but consistency makes it easier to find someone else who does things your way. In the .NET world, a large majority of developers are still using stored procedures to do all of their data access, and if you are using an ORM, there are many different ones that you might be using. Again, this isn’t necessarily a bad thing (although I would argue that hand rolled data access layers using stored procs are a bad thing), but I feel like there is value in consistency.

I feel that Rails development is very tempting to many developers in the .NET community. This isn’t all because of the language, it’s also because ideas and practices like TDD, the MVC pattern, and good design practices are much more widely accepted in the Ruby community. There is a lot of good in the .NET community, and I still think that .NET is a great platform for building all kinds of applications. But I feel like things like TDD, ORMs, the SOLID principles, etc. are used by less then half of .NET developers out there. Once you start using things like ORMs and TDD, it’s really difficult to join a project that doesn’t use these things and be productive.

So the moral of the story is to use whatever tool you can find to best do the job. Ruby on Rails is something I wouldn’t mind having in my toolbox.


  1. Dear Jon,
    we have competing practices of RoR and .Net in our company in Ann Arbor and your concluding statement is what I have always believed in while countering blows to .Net or RoR from the other practice.
    Thank you!

    Vishal Sibal — October 7, 2009 @ 7:29 pm

  2. “although I would argue that hand rolled data access layers using stored procs are a bad thing”

    I would like to hear more of thoughts about this.

    mgroves — October 13, 2009 @ 8:45 am

  3. more of *your* thoughts is what I meant to type.

    mgroves — October 13, 2009 @ 8:45 am

  4. My first foray into Ruby on Rails…

    You’ve been kicked (a good thing) – Trackback from… — October 13, 2009 @ 9:22 am

  5. [...] My first foray into Ruby on Rails [...]

    Jon Kruger’s Blog » Why I don’t like hand rolled data access layers — October 13, 2009 @ 10:32 pm

  6. Hello from Russia!
    Can I quote a post in your blog with the link to you?

    Polprav — October 23, 2009 @ 12:35 am

Leave a comment

I have over 10 years of software development experience on several different platforms (mostly Ruby and .NET). I recognize that software is expensive, so I'm always trying to find ways to speed up the software development process, but at the same time remembering that high quality is essential to building software that stands the test of time.
I have experience leading and architecting large Agile software projects and coordinating all aspects of a project's lifecycle. Whether you're looking for technical expertise or someone to lead all aspects of an Agile project, I have proven experience from multiple projects in different environments that can help make your project a success.
I believe that Agile processes and tools should be applied with common sense. I've spent the last 6 years working on Agile projects as a consultant in many different environments, both in leadership roles and as a practitioner doing the work. I can help you find out how Agile can work best in your organization, not just apply a prescriptive process.
TDD Boot Camp is a hands-on, three day, comprehensive training course that will teach you all of the skills, tools, frameworks that you will need to use test-driven development to develop real world .NET applications. If you're not looking for something that intensive, check out the the half-day version.
Have any questions? Contact me for more information.
The Business of You: 10 Steps For Running Your Career Like a Business
From CONDG 2012, Stir Trek 2014
From Stir Trek 2013, DogFoodCon 2013
From Stir Trek 2012, QA or the Highway 2014
(presented with Brandon Childers, Chris Hoover, Laurel Odronic, and Lan Bloch from IGS Energy) from Path to Agility 2012
(presented with Paul Bahler and Kevin Chivington from IGS Energy)
From CodeMash 2011
An idea of how to make JavaScript testable, presented at Stir Trek 2011. The world of JavaScript frameworks has changed greatly since then, but I still agree with the concepts.
A description of how test-driven development works along with some hands-on examples.
From CodeMash 2010
From CodeMash 2010