3 ms·

Somewhat related... Derek Sivers attempted to port CD Baby to Ruby on Rails, but ended up abandoning the port effort after 2 years and switched back to PHP. See

by theoj 16y ago

Somewhat related... Derek Sivers attempted to port CD Baby to Ruby on Rails, but ended up abandoning the port effort after 2 years and switched back to PHP. See his post on why he came back to PHP and what he learned from Rails (from 2007): http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_swit...

cageface 16y ago
That article is four years old now, but I'd still advise against porting a large, complex legacy PHP app to Rails. Starting from scratch with PHP in 2011 seems like a much more questionable move though. Rails works well if you start with its conventions in mind.
wikyd 16y ago
Holy lord is that a lot of risk to accumulate doing a full rewrite and deploying it all at once. I think the hardest part about rewriting an app is knowing about all the edge cases, kludges, etc. that accumulate over the years. It makes sense that the person who knows the most about the product and its dirty secrets would be much more capable of rewriting the app quickly than a newly hired employee. As a counterpoint, last year I joined a startup as the first technical member. I migrated a PHP application written by an inept contractor (terrible DB layout, SQL queries in the views, most features buggy and incomplete, etc.) to Rails piece-meal. I had very little experience with Rails or PHP prior to this, but was able to rewrite the app in the course of a few months, while adding new features and continuing product development. I simply placed nginx in front of both the PHP and Rails app servers and rewrote the auth system for both apps so that cookies/credentials could be shared. Then it was a matter of migrating sections of the app over one-by-one. There was some hairiness in how the Rails side linked to non-Rails pages, but that code was gradually replaced as the rewrite progressed. Even despite the abominable DB schema from the original PHP app (which, in fairness, had nothing to do with PHP), Rails was flexible enough to allow me to override its conventions and map tables to models with joins, etc. Overall, it was much simpler than I thought it would be and after the rewrite was complete, it was pretty simple to write migrations to start organizing the DB schema into something coherent.
gabebw 16y ago
He actually switched back to Rails again. From the foreword to the Rails Tutorial [1]: > My former company (CD Baby) was one of the first to loudly switch to Ruby on Rails, and then even more loudly switch back to PHP (Google me to read about the drama). This book by Michael Hartl came so highly recommended that I had to try it, and Ruby on Rails Tutorial is what I used to switch back to Rails again. [1] http://ruby.railstutorial.org/ruby-on-rails-tutorial-book#foreword http://ruby.railstutorial.org/ruby-on-rails-tutorial-book#fo...

by theoj 16y ago

cageface 16y ago

That article is four years old now, but I'd still advise against porting a large, complex legacy PHP app to Rails. Starting from scratch with PHP in 2011 seems like a much more questionable move though. Rails works well if you start with its conventions in mind.

wikyd 16y ago

Holy lord is that a lot of risk to accumulate doing a full rewrite and deploying it all at once. I think the hardest part about rewriting an app is knowing about all the edge cases, kludges, etc. that accumulate over the years. It makes sense that the person who knows the most about the product and its dirty secrets would be much more capable of rewriting the app quickly than a newly hired employee. As a counterpoint, last year I joined a startup as the first technical member. I migrated a PHP application written by an inept contractor (terrible DB layout, SQL queries in the views, most features buggy and incomplete, etc.) to Rails piece-meal. I had very little experience with Rails or PHP prior to this, but was able to rewrite the app in the course of a few months, while adding new features and continuing product development. I simply placed nginx in front of both the PHP and Rails app servers and rewrote the auth system for both apps so that cookies/credentials could be shared. Then it was a matter of migrating sections of the app over one-by-one. There was some hairiness in how the Rails side linked to non-Rails pages, but that code was gradually replaced as the rewrite progressed. Even despite the abominable DB schema from the original PHP app (which, in fairness, had nothing to do with PHP), Rails was flexible enough to allow me to override its conventions and map tables to models with joins, etc. Overall, it was much simpler than I thought it would be and after the rewrite was complete, it was pretty simple to write migrations to start organizing the DB schema into something coherent.

gabebw 16y ago

He actually switched back to Rails again. From the foreword to the Rails Tutorial [1]: > My former company (CD Baby) was one of the first to loudly switch to Ruby on Rails, and then even more loudly switch back to PHP (Google me to read about the drama). This book by Michael Hartl came so highly recommended that I had to try it, and Ruby on Rails Tutorial is what I used to switch back to Rails again. [1] http://ruby.railstutorial.org/ruby-on-rails-tutorial-book#foreword http://ruby.railstutorial.org/ruby-on-rails-tutorial-book#fo...