|«« Risky Business? My Take on Early Alphas||Tags Hierarchies »»|
I'm Ryan Lowe, a Software Engineering graduate living in Ottawa, Canada. I like agile software development and Ruby on Rails.
I write this blog in Canadian English and don't use a spell checker. Typos happen.
» Full-time Ruby on Rails freelancer
» Full-time with Rails since May 2005
» Former committer for RadRails (now Aptana)
» I also have a few Rails side-projects in development:
1. wheretogoinTO.com Toronto nightlife
2. Hey Heads Up! TODO list and sharing
3. Layered Genealogy family history research
4. foos for foosball scoring
5. fanconcert for music fans (on hold)
Hiring Rails developers? I can telecommute by the hour from Ottawa, Canada
»» Email: rails AT ryanlowe DOT ca
Now hosted on Hey! Heads Up -- check it out!
Derek Lowe's (Ryan's older brother) words at Ryan's funeral
[email protected] no more
Forging Email Headers: Good, Bad or Ugly?
Sarcastic Dictionary (Part 1 of Many)
Twisting Rails is Risky Business
Risky Business? My Take on Early Alphas
Whoa, it's August 2007
A Postscript to "Growth at the grassroots"
»» All Blog Posts
David Heinemeier Hansson
James Duncan Davidson
Signal vs. Noise
Amy Hoy: (24)slash7
Luis de la Rosa
Twisting Rails is Risky Business
I normally don't jump into the PHP vs Ruby/Rails debates but this time I can't help myself. Found via Darcy Whyte, Derek Sivers' provocatively titled article 7 reasons I switched back to PHP after 2 years on Rails deserves a reply from the Rails community.
Let's start with his quote: "...twisting the deep inner guts of Rails to make it do things it was never intended to do. But at every step, it seemed our needs clashed with Rails’ preferences."
Derek switched his project from PHP to Rails, didn't do things "The Rails Way" and wonders why it was difficult. The project failed and he rewrote the new version in PHP in two months, creating a smaller and custom framework inspired by Rails in the process.
The Rails framework helps developers if they follow the conventions and can hurt them if they deviate too far from them. Jeremy Kemper (bitsweat) knows this -- as do all good Ruby on Rails developers. From his description of his project, it sounds like Derek used Rails improperly.
Maybe Jeremy should have been more assertive about how Rails is meant to do things and explained The Rails Way better. When you're a Rails expert that's part of your job because people are still getting used to Rails' new approach and how it can help them. A Rails expert needs to explain to his boss the impact and risk of deviating too far from The Rails Way.
Of course PHP is a better solution than Rails for writing a custom framework, it's a programming language. He would have been just as successful writing his custom framework in Ruby. Trying to "twist" a framework like Rails into a custom framework is just asking for trouble. Use a hammer for nails, don't blame a wrench for not working well.
Sure, Rails has "The Rails Way" conventions for developers but that doesn't mean it's too templated and all Rails applications end up looking the same to users. There's a lot of UI flexibility available and copying existing "web 2.0" look and feel is a design decision. From the outside Rails applications can look like applications from any other framework or programming language.
Quote: "Is there anything Rails/Ruby can do that PHP can't do?"
No, there probably isn't. Is there anything PHP can do that Ruby/Rails can't? From the end-user perspective, probably not. So we're in a dead heat -- but that argument is a red herring.
If you follow The Rails Way, development can be *faster* than PHP because a lot of things are done for you, like object persistence with ActiveRecord. The tools need to be used as they were intended.
The moral for Rails projects is this: Learn about The Rails Way before you start. Don't go off the rails and override a lot of the default behaviour if you can't handle the business risk of doing so. Pun intended.Posted at September 27, 2007 at 09:52 AM EST
Last updated September 27, 2007 at 09:52 AM EST