I’ve spent much of my free time over the last few weeks learning Ruby on Rails and thought I would record a few first impressions for anyone else who is thinking of dipping their toes in the RoR waters any time soon.
- Curiosity – I’ve made a few snide remarks about Ruby over the past year in response to what I felt was the overuse of hyperbolic and cultish language by prominent Rubyists. After a while, I decided the only way to know for certain whether the buzz was more hype or more reality was to experience it for myself.
- Project - I promised my wife I’d get a simple PayPal integration e-commerce site up and running for her soon. Since my hosting site only supports PHP or RoR and I’ve already played with PHP enough through WordPress tweaks for my blog, I decided to go the Rails route. This gives me a vested interest in giving it a fair shot because if I can’t get it to work, then the wife won’t be happy. Everyone knows that if the wife ain’t happy, then nobody’s happy.
Learning Curve Milestone
- Over the Motivation Hump: In the beginning, I languished for several weeks in a state of motivational limbo. The pure Ruby language stuff wasn’t that interesting to me and I hadn’t quite invested enough time in Rails to understand what was going on yet. The “Aha” moments finally came once I got all the CRUD operations working for one of the pages of my eCommerce app (sample apps only get you so far) and then got it deployed to my hosting site. Every since getting past that hurdle, I’ve noticed that the time I’ve spent reading my Ruby book has increased dramatically along with my reading speed because I am suddenly much more interested in it now that I am starting to grok the potential.
Concepts I’m Sold On
- Convention Over Configuration – As a .NET developer, I’ve written my share of data access code and SQL over the years and feel perfectly comfortable with it. But I have to admit that it was a nice feeling to have ActiveRecord (the ORM package for Rails) be able to glean the table structure based on my naming conventions and dynamically generate the SQL and plumbing code behind the scenes for me. I didn’t even have to look at a bunch of ugly generated code in a code-behind page. It just worked. I haven’t had any experience with Hibernate\NHibernate mapping XML files, but I imagine that it is still much more laborious than the Rails approach.
- MVC structure - When I first tried debugging into CruiseControl.NET, which uses its own home-grown MVC style architecture, I was discombobulated because the url didn’t directly map to a code file. It seemed like an unnecessarily complex way to structure a web site. However, after experiencing how the url maps to a Controller/Action/Parameter in Rails, Django, and the .NET MVC framework, I am finally becoming a fan of this approach. Once I got used to where to look for everything, code suddenly seemed like it was much more organized and manageable than before.
- Having Development Lifecycle Built Into Project Structure - The fact that Rails creats a Dev\Test\Prod folder and configuration files, thus embedding the natural development lifecycle into the project structure from the very start, is such an obvious improvement that I’m surprised that not everybody does this.
What I’m Excited To Try
- Migrations – I’ve heard about this for a while, but only read about its full capabilities today. Managing database schemas and data across environments is one of the biggest pain points where I currently work. Having a tool that can manage incremental changes to databases and then automatically roll versions back sounds too good to be true.
- RAKE – This is the Ruby version of Nant/MsBuild but it uses code syntax instead of XML. I’m not as much of an XML-hater as some people, but if given a choice I always prefer code because it usually means much better debugger support.
- RSpec – This is the testing tool that encourages Behavior Driven Development by enforcing certain naming standards and the transforming executable tests into human readable documentation. I saw the .NET port of this last fall at the ALT.NET conference in Houston and finally saw this demonstrated at the last KC Ruby User Group Meeting. I’m still not convinced that it can simply be handed to users in lieu of documentation as many claim, but it is still the best effort to merge the world of tech specs and executable tests that I’ve seen yet.
What I Haven’t Made up my Mind on Yet
- Documentation: I’ve read several complaints that the English documentation for Ruby, which originated in Japan, is lacking when compared to other languages like Perl or Python. As a beginner, this hasn’t been an issue for me yet because there are plenty of books and web-based tutorials available, but this is something I’ll watch out for down the road.
- Complex data models: I’m curious how ActiveRecord will handle the traditional problem of impedance mismatch that all ORM systems face when trying to reconcile conceptual differences between how information is represented in a relational database versus an object model (it’s what prompted Ted Neward to call ORM the Vietnam of Computer Science). So far I have been impressed with Active Record, but the approach in all the Rails tutorials so far has been to start with the database tables, which seems to be the opposite approach of what noted architecture gurus like Rockford Lhotka have been recommending for years. I also saw a few references to things like composite keys not being supported by ActiveRecord, which makes me wonder how it will handle large, complex data models from legacy systems. Once again, I’ll just have to wait and see how this turns out.
- Ruby & Rails vs Django & Python – I’ve seen some excellent debates, like the ones in this Bitwise article or this blog post, on which of these two popular web frameworks is better. Both frameworks rely on the MVC pattern, dynamic languages, and ORM magic to reduce boiler plate data access code. Django boasts faster speed, a more popular and widely applicable language, a more plugable architecture, and some extra administrative interfaces that help out for content management sites. However, since my hosting site doesn’t currently support Django, I’m going to have to wait and do a comparison for myself later this year.
- Speed & Scalability - I don’t even want to open up the can of worms that Rob Conery did by suggesting Ruby is slow and has scalability issues. However, the general consensus is that Ruby is indeed slower than Python and both are much slower than most static languages like Java or C#. Rubyists contend that Rails is fast enough for most scenarios and that you can always drop down to C when performance is needed. I agree that performance isn’t something that most apps need to worry about these days, but I am more skeptical about the viability and ROI of dropping down to C for most development shops when performance is an issue. On the other hand, Rails is still pretty young, so I can only assume that future versions will improve in this respect.
- Tools – The general consensus seems to be that tool support for Rails is lagging behind the powerhouse IDEs used in the Java and .NET worlds. Although I do think that Visual Studio is a bit bloated these days, I see Intellisense and visual debuggers as major productivity boosters and see it as a significant downside to doing development in Ruby. So far the attitude I’ve run into from Rubyists has been the equivalent of “real programmers don’t use tools”, which I’ve never agreed with. I did see an article about Ruby In Steel that has both intellisense and a visual debugger, so I plan to try that out. For the time being, Notepad2 will work.
- Beauty? – Call me a cynic, but I’m afraid I side with Jeff Atwood here when I say that I just don’t feel comfortable using the word beautiful in reference to code syntax. I definitely have aesthetic preferences when it comes to code, but they seem a little too subjective to be able to definitively say that one language clearly reigns supreme over all others in this respect. To be honest, from what I’ve seen so far, I like about half of the syntax in Ruby better than C# and half of it worse. For example, all those end keywords that litter Ruby code give me nasty VB.NET flashbacks, so I’m not partial to them. I am willing to believe that my sense of aesthetics will change over time and that I might suddenly find Ruby syntax more appealing a year from now. However, I am also suspicious that there is an emperor’s new clothes phenomena at play here. This means that a few smart and influential people proclaiming that they see beauty can suddenly cause everyone to convince themselves that they also see beauty, not because it is really there, but because they don’t want to look stupid or feel left out.
Please remember that I am very new to Ruby on Rails, so I welcome any corrections or helpful insights that readers who have more experience in this area can offer.
As for the rest of you, I wisely chose to clip my section on “Tips for People Just Starting Out” because this post was so long, so tune in next time for some tips on how to avoid stumbling blocks early on in the Ruby learning path.
Popularity: 19% [?]