One Week with Rails

Published 31 January 05 by Justin French, 8 comments

Performance

When I first had a play with Rails a few months back, I was disappointed with the performance on my G4 using mod_ruby. Page refreshes would take 1–2 seconds, which was obviously a whole lot slower than I was used to with PHP. This performance issue most definitely resulted in a negative first impression. I knew it wasn’t exactly a problem with Rails, but hey, it was related.

So my priority when I picked Rails up this time was to boost the performance with FastCGI. So I followed the information on the Rails wiki, and I’m pleased to say that performance is a lot better.

The Language

Learning Ruby (the language) the same time as I’m learning Rails (the framework) is interesting to say the least. I come from a background in purely procedural PHP. Moving to a purely object-oriented language with a very different syntax like Ruby was definitely a shock to the system. After being an “expert” in PHP it’s quite humbling to be a complete newbie again.

Without a doubt, the biggest stumbling block has been the “where do I put this thing?” question, but I’m getting a grip on it all thanks to the wonderful guys and gals in the IRC channel.

I still remember exactly how I learnt PHP way back in the late 90’s – by reading everything. I read tutorials, I read the PHP manual, I read other peoples source code and I read every single email on the php-gen mailing list for a least a year. The fastest way I know how to learn (not coming from an IT education) is by totally surrounding myself in the language… and that’s exactly what I’m doing here with Rails.

Having so many open source applications under way using Rails has been a great way to learn. You can browse the source for Epilog (an upcoming blog application), Hieraki and many more Rails applications to see how others have approached a particular problem.

Without a doubt, I’m starting really enjoy both the Ruby language and Rails’ implementation of it. You really can read a Rails application’s source code in sentences and phrases. Here’s some random one-line examples:

• validates_presence_of :title, :body, :publish_on
• validates_length_of :body, :minimum => 5
• @news_items = NewsItem.find_all
• self.title = self.title.capitalize_most_words

I do however have a few gripes…

Immediacy

I’m missing the immediacy of PHP’s built-in functions – especially for string manipulation and things like that. But the good news is that it’s quite easy to extend Ruby’s String class, and I plan to offer my extensions as a patch to Rails or something down the road. As a side note, I’m not missing PHP’s awful (lack of) naming conventions for functions!

The Name Space

In my PHP code, things were very “flat” (but still well organised), which I’ve become very used to. Whilst I can clearly see why the Model shouldn’t have access to (or be aware of) variables in the Controller’s name space, it certainly has caused me some grief along the way – especially when doing something that Rails isn’t instantly geared up to do “for free”.

Clients

There are some definite barriers in convincing clients to trust Ruby and Rails right now. A client of mine (who I love working with, and who generally trusts me implicitly) was very concerned about the lack of developers and support for Ruby code, and considered it a form of “lock-in” to choose a language and framework which has been around for such a short time. You can show them the videos and tell them it’ll help you write better code in less time, but until Rails is considered to have some kind of widespread adoption, I think I’ll be having this conversation quite often.

In the end, I made my case by reminding them that there is a certain degree of lock-in when choosing any language or framework – just because I “know PHP” doesn’t mean I could pick-up the source for WordPress or Textpattern and become the new lead developer over night. This is where Rails applications actually start to feel like the smarter choice.

A “Rails Developer” should be able to open up any application and instantly have a decent idea of what’s going on. Sure, they won’t know the code intimately, but the fact that the separation of Models, Views, Controllers, Layouts, Partials & Helpers is somewhat forced upon us means we can borrow from our existing knowledge of the framework, and just focus on what is unique to this particular application.

I also think that a Rails developer is inherently a “better” programmer by force. PHP makes it very easy for anyone (myself included) to slap together some poorly planned procedural code and claim the title of “PHP Web Application Developer”. Rails on the other hand at least tries to make us better programmers by default.

Three cheers for David Heinemeier Hansson!