Skip to main content

7 reasons I switched back to PHP after 2 years on Rails

SUMMARY: I spent two years trying to make Rails do something it wasn’t meant to do, then realized my old abandoned language (PHP, in my case) would do just fine if approached with my new Rails-gained wisdom.
INTRO / BACKGROUND:
Back in January 2005, I announced on the O’Reilly blog that I was going to completely scrap over 100,000 lines of messy PHP code in my existing CD Baby (cdbaby.com) website, and rewrite the entire thing in Rails, from scratch.
I hired one of the best Rails programmers in the world (Jeremy Kemper aka bitsweat), and we set off on this huge task with intensity. The first few months showed good progress, and Jeremy could not have been more amazing, 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. (Like trying to turn a train into a boat. It’s do-able with a lot of glue. But it’s damn hard. And certainly makes you ask why you’re really doing this.)
Two years (!) later, after various setbacks, we were less than halfway done.* (To be fair to Jeremy’s mad skillz: many setbacks were because of tech emergencies that pulled our attention to other internal projects that were not the rewrite itself.) The entire music distribution world had changed, and we were still working on the same goddamn rewrite. I said fuckit, and we abandoned the Rails rewrite. Jeremy took a job with 37 Signals, and that was that.
I didn’t abandon the rewrite IDEA, though. I just asked myself one important question:
“Is there anything Rails can do, that PHP CAN’T do?”
The answer is no.
I threw away 2 years of Rails code, and opened a new empty Subversion respository.
Then in a mere TWO MONTHS, by myself, not even telling anyone I was doing this, using nothing but vi, and no frameworks, I rewrote CD Baby from scratch in PHP. Done! Launched! And it works amazingly well.
It’s the most beautiful PHP I’ve ever written, all wonderfully MVC and DRY, and and I owe it all to Rails.
Inspired by Rails:
*- all logic is coming from the models, one per database table, like Martin Fowler’s Active Record pattern.
*- no requires or includes needed, thanks to __autoload.
*- real MVC separation: controllers have no HTML or business-logic, and only use REST-approved HTTP. (GET is only get. Any destructive actions require POST.)
*- all HTML coming from a cute and powerful templating system I whipped up in 80 lines, all multi-lingual and caching and everything
*- … and much more. In only 12,000 lines of code, including HTML templates. (Down from 90,000, before.)
Though I’m not saying other people should do what I’ve done, I thought I should share my reasons and lessons-learned, here:
SEVEN REASONS I SWITCHED BACK TO PHP AFTER 2 YEARS ON RAILS:
#1 - “IS THERE ANYTHING RAILS/RUBY CAN DO THAT PHP CAN’T DO? … (thinking)… NO.”

For 2 years, I thought Rails is genius, PHP is shit. Rails is powerful, PHP is crap.
I was nearly killing my company in the name of blindly insisting Rails was the answer to all questions, timeframes be damned.
But when I took a real emotionless non-prejudiced look at it, I realized the language didn’t matter that much.
Ruby is prettier. Rails has nice shortcuts. But no big shortcuts I can’t code-up myself in a day if needed.
Looked at from a real practical point of view, I could do anything in PHP, and there were many business reasons to do so.
#2 - OUR ENTIRE COMPANY’S STUFF WAS IN PHP: DON’T UNDERESTIMATE INTEGRATION
By the old plan (ditching all PHP and doing it all in Rails), there was going to be this One Big Day, where our entire Intranet, Storefront, Members’ Login Area, and dozens of cron shell scripts were ALL going to have to change. 85 employees re-trained. All customers and clients calling up furious that One Big Day, with questions about the new system.
Instead, I was able to slowly gut the ugly PHP and replace it with beautiful PHP. Launch in stages. No big re-training.
#3 - DON’T WANT WHAT I DON’T NEED
I admire the hell out of the Rails core gang that actually understand every line inside Rails itself. But I don’t. And I’m sure I will never use 90% of it.
With my little self-made system, every line is only what’s absolutely necessary. That makes me extremely happy and comfortable.
#4 - IT’S SMALL AND FAST
One little 2U LAMP server is serving up a ton of cdbaby.com traffic damn fast with hardly any load.
#5 - IT’S BUILT TO MY TASTES
I don’t need to adapt my ways to Rails. I tell PHP exactly what I want to do, the way I want to do it, and it doesn’t complain.
I was having to hack-up Rails with all kinds of plugins and mods to get it to be the multi-lingual integration to our existing 95-table database.
My new code was made just for me. The most efficient possible code to work with our exact needs.
#6 - I LOVE SQL
Speaking of tastes: tiny but important thing : I love SQL. I dream in queries. I think in tables.
I was always fighting against Rails and its migrations hiding my beloved SQL from me.
#7 - PROGRAMMING LANGUAGES ARE LIKE GIRLFRIENDS: THE NEW ONE IS BETTER BECAUSE *YOU* ARE BETTER
Rails was an amazing teacher. I loved it’s “do exactly as I say” paint-by-numbers framework that taught me some great guidelines.
I love Ruby for making me really understand OOP. God, Ruby is so beautiful. I love you, Ruby.
But the main reason that any programmer learning any new language thinks the new language is SO much better than the old one is because he’s a better programmer now! You look back at your old ugly PHP code, compared to your new beautiful Ruby code, and think, “God that PHP is ugly!” But don’t forget you wrote that PHP years ago and are unfairly discriminating against it now.

It’s not the language (entirely). It’s you, dude. You’re better now. Give yourself some credit.
Ok. All that being said, I’m looking forward to using Rails some day when I start a brand new project from scratch, with Rails in mind from the beginning.
But I hope that this reaches someone somewhere thinking, “God our old code is ugly. If we only threw it all away and did it all over in Rails, it’d be so much easier!”

Find the original article here.

Comments

Popular posts from this blog

Survey says: PHP passes Microsoft Active Server Pages

By JT Smith on June 11, 2002 (8:00:00 AM) With a faltering economy forcing companies to cut spending whenever possible, less expensive and freely available Open Source software solutions may be gaining in popularity. Those wanting proof can look no further to PHP taking the top server-side scripting spot in a recent Internet host survey. In April 2002, Netcraft's monthly Web server survey revealed that 24 percent, or around 9 million of the 37 million sites it surveyed, were using Hypertext Preprocessor (PHP) for a server side scripting language. For the first time, an Open Source scripting solution had passed Microsoft's proprietary Active Server Pages scripting to claim the top spot on the Netcraft survey. For both the April and May Netcraft surveys, PHP and ASP were almost too close to call, with Microsoft's product offering coming in just a hair under 24 percent of all hosts running a server-side script

PHP Code Review Guidelines

General  The code works  The code is easy to understand  Follows coding conventions  Names are simple and if possible short  Names are spelt correctly  Names contain units where applicable  There are no usages of magic numbers  No hard coded constants that could possibly change in the future  All variables are in the smallest scope possible  There is no commented out code  There is no dead code (inaccessible at Runtime)  No code that can be replaced with library functions  Variables are not accidentally used with null values  Variables are immutable where possible  Code is not repeated or duplicated  There is an else block for every if clause even if it is empty  No complex/long boolean expressions  No negatively named boolean variables  No empty blocks of code  Ideal data structures are used  Constructors do not accept null/none values  Catch clauses are fine grained and catch specific exceptions  Exceptions are not eaten if caught, unless explicitly documente

Security: Password Hashing

In this article I'm going to cover password hashing, a subject which is often poorly understood by newer developers. Recently I've been asked to look at several web applications which all had the same security issue - user profiles stored in a database with plain text passwords. Password hashing is a way of encrypting a password before it's stored so that if your database gets into the wrong hands, the damage is limited. Hashing is nothing new - it's been in use in Unix system password files since long before my time, and quite probably in other systems long before that. In this article I'll explain what a hash is, why you want to use them instead of storing real passwords in your applications, and give you some examples of how to implement password hashing in PHP and MySQL. Foreword As you read on you'll see that I advocate the use of a hashing algorithm called Secure Hashing Algorithm 1 (or SHA-1). Since I wrote this article, a team of researcher