hn-classics/_stories/2007/1052337.md

created_at	title	url	author	points	story_text	comment_text	num_comments	story_id	story_title	story_url	parent_id	created_at_i	_tags	objectID	year
2010-01-14T10:58:36.000Z	Why I switched back to PHP after 2 years on Rails (2007)	http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html	niyazpk	62			50					1263466716	story author_niyazpk story_1052337	1052337	2007

Source

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

| ----- | |

Your Account

Shopping Cart

|
|

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

by Derek Sivers

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!"

---

502 Comments

| Joseph
2007-09-22 17:58:20 | Unintentionally hilarious? |
| Danno
2007-09-22 17:59:56 | So, uhhh, is your rewrite done? | | | William Pietri
2007-09-22 18:44:38 | Good for you for sticking with what suits you. We sure have different tastes, but I'm glad you ultimately judged things by real-world metrics rather than religious convictions.

In my view, your love of SQL and your focus on your existing tables were the big barriers here. Writing a procedural system in an object-oriented framework is a poor match. Treating the database as the main focus, rather than an implementation detail is, from the Rails perspective, the wrong approach. And Rails is very opinionated software; it does its thing well, but if you want it to do something else, it's not a good match.

And I'd note that integration is only a problem if you're integrating components via the database. In effect, you've duplicated the schema everywhere, making it impossible to change. Integrate via APIs rather than your database, and integration isn't nearly as big a deal. |
| jason
2007-09-22 18:54:21 | Your last comments seem to re-affirm the old cliche that PHP becomes ugly.

Doing something from scratch, in a one man team, after circling around the issues for two years, is a little different to working in a team with a new problem and needing a clean framework with (omg) Opinionated methodologies. |
| ****
2007-09-22 19:11:01 | Your website looks like a spam site. |
| she
2007-09-22 19:26:04 | When i read "php is better than ruby", I had to laugh...

I wrote a lot of php code as well, and after 3 years, soon 4 years with ruby, I am 100% sure that ruby is a LOT better than php in EVERY aspect (i dont consider rails to be a part OF ruby), and I think your conclusion is WRONG in any way that PHP sucked because you "became a better programmer".

I will tell you the truth:
PHP as a language sucks.

I agree on one point... the domain language of php, the world wide web, should be solved BY ruby. All what is possible in php, should be possible with ruby as well. I hope matz decides to adopt this, because I am 100% sure that people will use ruby instead of php IF they can use ruby just the way they can use php (which means, no stupid mod_ruby errors for example)

I actually agree on one more point - hype is never good, what really matters is IF you work BETTER with these tools or not.

People, trust me - PHP is ugly, and will ALWAYS stay ugly. I have long ago jumped away from PHP. Only because rails doesnt fit your needs, doesnt mean Ruby as a language does not fit you! |
| she
2007-09-22 19:29:29 | Oh by the way, my comment was a little too aggressive.

I think I can agree that this should make the rails developers THINK about these issue and attempt to SOLVE (or easen) them, too. Because it seems like a rather legit reason and the arguments within it can be well voiced to improve rails...

It is also true that ruby can grow very complex, but it really matters on the programmer. Whenever possible, one should strive to pick the shortest, cleanest, easiest-on-the-brain solution instead of a "magical solution" (unless it is a very clean and clear human readable and nice to maintain DSL of course ;> ) |
| Michael Daines
2007-09-22 19:37:08 | It seems like starting from scratch in PHP is kind of similar to starting from scratch with Ruby and erb, which is what DDH did, right? |
| Richard Hertz
2007-09-22 20:03:29 | Useless post without a concrete illustration.

Show us an example of:

1. What you tried to accomplish.
2. How you tried to implement it in rails.
3. The rails code that "didn't work."
4. The "beautiful" PHP code you created instead. |
   | Rabbit
   2007-09-22 20:52:28 | I enjoyed the article, but now I'm sad I can no longer say "CDBaby does!" when someone asks me if anyone big is using Rails.

William Pietri:
In my view, your love of SQL and your focus on
your existing tables were the big barriers here.

Bingo. Objects, their responsibilities and relationships first, database second (in Rails).

I loved the part about the database as an "implementation detail." That sings to me.

Taking an extreme stance to breaking down the problem domain yields the best results for me. Who keeps track of my appointments? My first answer was "me." Then I stood up and paced around the house for a bit. Upon sitting back down I wrote...

./script/generate model AppointmentBook

Break it down. Down. Down. |
| Nick D
2007-09-22 21:17:36 | Looks like you among many out there had a poor team. Poor development environment where you were working on several projects at once and putting priorities in wrong order among several projects. I will have to say being stuck in one mental framework can be hard to overcome, especially when learning to code in a new and cleaner manner as per Ruby on Rails. But you actually could have coded so much more faster had you stuck to your guns and not given up, or not, since you prioritized among so many projects.

Know this: straight out the gate, even with little MySQL/SQL knowledge I know college grads that know and love Ruby on Rails that can code entire websites and admins in manner of weeks not to mention localization and advanced features like cacheing and advanced logging systems.

One important thing to learn from these guys and gals out there: they write tests alongside their code and think in that manner. All their code and program design fit together and they develop better code and projects because of that.

You are stating pure opinion without discussion anything substantial. |
| gnufied
2007-09-22 21:30:25 | I agree with author, but i honestly see the point of posting it here. Take it elsewhere if you can. |
| ****
2007-09-22 21:44:28 | This is a problem with any web framework. The idea of a framework is to make decisions for you, and if that doesn't work for you then it's the wrong framework. It's not a hit against Ruby in this case, just a hit against Rails. |
| Bob
2007-09-22 22:06:58 | coding entire websites that do nothing is exactly what rails is great at. Having been involved in framework development that had OOP inheritance layers 25 children deep and also in heavy utility development with few objects, there is no comparison.

Dont fault the author for liking SQL and its relative if not portable efficiency. The fact is it works and its way better than some pretend ORM like rails (ooh look johnny a WHERE clause builder!) which says well you cant do any joins that are meaningful to your application unless you pull it all back and iterate the old fashion way.

SQL allows you to let the database do the work. But as far as alot of RAILS or other ORM users are concerned, pulling back rows from individual tables and "joining" them in memory in a very inefficient way is somehow beneficial. Because they dont know how to leverage existing technology.

And thats what I liked about this article. Because it is true. Rails and ruby may cover for you for a while, but in the end you will have to do heavy lifting.

So your little login and your "oh I coded a website" and I dont know SQL and how databases work. Is a bunch of bullshit.

ORM and especially active record is fools gold for people who will never learn what it takes to actually get the job done.

But it is a good learning tool for people in a hurry.
Learning how to fail. |
| David
2007-09-22 22:07:15 | she: "When i read "php is better than ruby", I had to laugh..."

If you read that here, I think you need to adjust your browser. |
| Bob
2007-09-22 22:12:51 | And specifically to nick:
I know college grads...bla bla bla

Which is why we are outsourcing software development.
Because they dont know SQUAT. |
| Paul
2007-09-22 23:11:48 | Do you use memcache at all for any of the sql requests? |
| Jono
2007-09-22 23:20:26 | Yes Derek. I had quite the same experience. Tried rewriting a web app (PHP->Rails) for about 2 weeks. I gave up and started back in PHP, but the new code was a whole lot more methodical. |
| Aaron
2007-09-22 23:22:27 | Why didn't you hire a Rails core member? Who is Jeremy Kemper? I have been programming in Ruby for 4 years now and I have never heard of him. I think you need to reconsider who you hire next time to do things the Rails way. |
| Nazgum
2007-09-22 23:36:33 | well personally it just sounded like you picked the wrong project; rails is opinionated and expects things to work certain ways, as you noted, and if your project is written entirely different then this - guess what, rails might not be the best choice. In your case it sounds like php definitely was the better choice.

It would be interesting to see, if you pick rails for a future new project if things would be different, and, two years down the road after many enhancements and changes, which codebase is more manageable, and should you have to recruit others for help, which they find easier to work with. |
| Friedrich
2007-09-22 23:41:40 | Just few things Rails != Ruby. Ruby was there long before Rails, and it was and still is one of the easier scripting languages. Howerver PHP means currently having a broader base. And a lot of experiences. I just can tell that the PHP pages I had were relatively messed up. If one really likes to know I can check the old pages (there we have used PHP, HTML (of cource;-) Apache and Mysql. I do not like MySQL for whatever reason and so I replaces it with PostgreSQL. We are also usign a Ruby based wiki but are still using PHPBB. It works has just one really big drawback. It get's spammed with subscriptions. So it seems because it is that popular the captcha was somehow cracked. This makes me angry. I would like to fix that but the code from PHPBB is not for the faint of heart. Howerver I'm not keen on check my braveness on it...

But some other things to consider:
Webprogramming does not stop with PHP or Ruby. There are so many alternatives. You have choosen what you knew. But what would happen if you had tried something else? Here are some ideas:

1. OpenACS http://openacs.org/
2. Seaside http://www.seaside.st/
3. Some lisp based stuff AllegroServe, Hutchentoot etc
4. Some scheme based stuff
5. Erlang stuff
6. Objective-C
7. Java
8. Perl
9. Python
   and so on .....

I've tried so long:
php stuff (serious)
lisp stuff (very serious but with very less success)
openacs (just had a look)
rails (has saved me from spending another few months on the lisp stuff)

I for my part are quite happy about rails. Maybe it's it's model that suits me that good...

Regards
Friedrich |
| Robert Aganauskas
2007-09-22 23:55:42 | Judging from the article what you tried to do was to rewrite your old PHP code to Ruby on Rails 1 to 1.
This is the wrong way to go. Rails (and any framework in general) has some constrains you have to adopt to, and you break those only if you are absolutely sure there is no way to accomplish what you want within those constrains, which more often that not means that you have to change your perception of the problem - not the code. |
| Cornelius
2007-09-23 00:09:54 | Now, this is some experience I would really like to buy a book of. The language of my company is PHP and it's very unlikely that there will be a switch. I don't see a very compelling reason as well.
But I have been looking for a book of somebody with a 'puristic' mind that has found a way of working with PHP. I found none, perhaps I was not looking good enough but the books were either 'PHP 101' or 'let's create a big ball of mud'.
I hope you will write more about that experience you have. |
| Cornelius
2007-09-23 00:19:28 | I was thinking... before you have the book written ;) could you post some code examples of all coding rules you imposed upon yourself? |
| Mike Zillion
2007-09-23 01:36:24 | Gee, I'd like to see those rule examples Cornelius asked about as well.... |
| No
2007-09-23 01:46:05 | Haha at the Rail Kiddies... |
| wellwisher
2007-09-23 01:47:47 | I'm a little reluctant to add to the wasteland that is this post and these comments, but here goes.

I'm familiar with the situation here. The deal was this: Derek was not a programmer; he was a musician. He learned some PHP and cobbled together the old CDBaby site by himself. It was good.

Then, he heard about Rails, and became infatuated with it. He proceeded to attempt a rolling rewrite of CDBaby's frontend and backend both (the backend is large, because of inter-label and digital distribution stuff) in Rails.

At this time, Derek had no experience with the following things:

• any language other than PHP
• systems integration and interoperability
• Rails
• object-orientation
• the MVC pattern
• managing a development team

Project fails. All right. As he has learned in #2, legacy compatibility trumps everything. Also, ship early and often.

As you can see in Derek's post about MySQL encodings, he's not always the clearest thinker. Even above he says that REST means POST-only destruction, which misses the point entirely.

His team was fine (mostly just Jeremy, until another developer was hired in the last months). Rails was fine. But there were a lot of things wrong with the project plan ("rewrite everything, eventually") and with the project leader, who was convinced he had found a silver bullet.

No framework saves you from your own inexperience.

Out.
|
| Derek Sivers
2007-09-23 02:17:07 | Thanks for the funny comments.

To Richard Hertz and Cornelius, and others asking for more concrete examples: maybe some day.

I finished the rewrite a month ago, and it's taken me a month to find the two hours it took to write this post, which I did for the benefit of an invisible someone someday.

To show in examples what I love about my new PHP code would take hours and hours more, and I might do it some day, but I've got years' worth of things that are more important for me to do, first. Maybe some day I'll just put it all up on a public svn server, but I'm not ready for that yet.

Also, when considering it, I thought my specific code that made me happy probably wouldn't make you happy. I just designed a little system for my tastes, and that's the point. |
| sandofsky
2007-09-23 02:21:26 | I came on toward the end of the project, so I can't too much credit, but yellowpages.com was rewritten in Rails in four months. That's four months from the first subversion commit to deployment in production. That was with a team of five or so, learning as they went along, with the typical business-person meddling of a mega-corporation. That includes writing a service layer that interfaces with a brand new ruby FAST library. That includes load testing and realizing you need to use mongrel handlers in a few key places.

Bob, Rails is not just ActiveRecord. Our heavy lifting is done on a service layer. Rest assured, it blasts SQL away. Bob, how many millions of hits a day does your site get? |
| noob
2007-09-23 02:26:21 | Well in a way you are right. Trying to make Rails work the way they are not supposed to is really a hard task to accomplish. Its crazy to even go that way. Really crazy.

Saying that it is better to use bare PHP and custom made templating system (isnt PHP a "clever template" after all?) is better than starting with Ruby and ERB is pure nonsence to me. Ruby is much better language (pure OOP in Ruby vs hacked in OOP in PHP) but has some downsides in deployment. Integration is not an issue when using REST and Webservices, but i guess that would be too hard to implement in PHP ;-) |
| Christoph
2007-09-23 02:40:37 | Reading your reason #6, I see that you totally don't get what rails is.
And thats pretty sad as a resumee after 2 years. |
| dalsgaard
2007-09-23 04:13:41 | PHP is a better PHP than Ruby (and Rails) ;-) |
| sapporo
2007-09-23 04:22:45 | I saw it coming when you wrote "Jeremy ... twisting the deep inner guts of Rails to make it do things it was never intended to do".

|
| Not a Rails Fanatic
2007-09-23 04:57:03 | Good post Derek. Don't let the Insane Rails Posse get you down. Your approach is refreshing. Actually build exactly what you need instead of buying into that whole Rovian "it's opinionated and only works if you kiss its ass approach and if it's not working because you're doing it wrong" talking points brief.

Look, if something was really good you all wouldn't have to work so hard to defend it. It just might be possible to develop software using something else. |
| Not a Rails Fanatic
2007-09-23 04:59:50 | > yellowpages.com

Wow, you and your posse made a site with links that lets you search. And you did that in 4 months with 5 people? Respect. I just can't imagine doing that so fast any other way. |
| Joh
2007-09-23 05:02:45 | The problems with PHP run much deeper than just your cosing style.

• PHP handles integers wrong on 64-bit platforms.
• Its namespace is polluted to a point that makes working with libraries a major pain.
• Its identity and type coaxing system makes it easy to produce security flaws.
• Its OO-model doesn't allow inspection which makes working with ORM like Propel or eZPublish's PersistentObject a real problem of XML/YML configuration or lots of custom coding

A problem that both have is that their Unicode-handling sucks big time (which is why I would have argued in favor of Django/Python, they're at least getting there)

Maintenance-wise you'll almost always be much better off with Django, Tapestry or Rails. Especially since your maintenance-phase will almost always be about 4-10 times as long as your development-phase.

And as both Ruby and PHP are Turing-complete there's nothing that can't be done with each of them (except implementing 64-bit integer handling in less than 80 lines of code in PHP), including implementing each other.

cheers |
| Pratik
2007-09-23 05:17:53 | I agree with most of the things you said about PHP not being good. But, as far as your project is concerned, it failed because of your lack of planning and vision. Hell, anyone could have re-written that site in JSP/mod_perl/whatever in 15 months.

Even trying to relate that with rails and use it as a point of difference between rails and php, is totally lame. Once again, rails didn't fail you. You failed yourself. |
| startup multi millionaire
2007-09-23 05:22:43 | i like your site, minimalist, pure techie site.

However you can do better.

I agree to your point about php and R&R...;

R&R; 's too simple, that's exactly what kills it, it will never make it to the top.

php - your house wife, it WORKs for you, however ugly
R&R; - your beautiful one-night-stand, however you can have 20 of them each year

I can say it right here: any language that requires too much brain power, absolutely and definitely WILL NOT make it to the top.

WHY? No managers likes thinking too much, unless the efficiency really is important.

My ability of being able to "Get on with it" while you are still tweaking your R&R; code, is PRICELESS - why?? because I grabbed 2/3 of your customer before you laugh your site!!

To be WINNING in this world you had to take risks, if you haven't been investing 180~190% of the all you've got[startup $$], and talk to 1000+ of your potential customers, your project would most likely to fail -
NOT because your code or service is BAD, but because you spend just a bit of time TWEAKING on computers when you should be communicating with someone else...

Remember: business is always business, you are selling a service,
if you are only an employee, who take proud of the clever code and admiring comments from colleagues, then you WILL always be an employee.

Take risks, work hard, COMMUNICATE, and HAVE FUN.
You will find your millions or billions[with luck+ lawyer/acc friend]. |
| Pippo
2007-09-23 05:29:13 | @jason
yeah, I thought that too! LOL
woot a holy crap website! :/ |
| Dave
2007-09-23 05:34:12 | Memcache? Fragment caching? Cap deployments onto a tuned set of mongrel servers? nginx front-end dispatcher?

Did you or your rails "expert" do any of these things?

We have use rails to develop an enterprise software system which is now in production with a number of clients, so I am speaking from first-hand experience here.

The Ruby interpreter is currently slow and will hopefully improve over time. But there is no reason why a site that can't be written in 2 years can be written by YOU in a month using PHP. By your own argument, "when I took a real emotionless non-prejudiced look at it, I realized the language didn’t matter that much."

So what the hell was the problem? |
| Dave
2007-09-23 05:40:34 | Oh and I just checked out your site. What an ugly P.O.S!

2 years and you can't build craigslist for CD's using rails. Jesus.

|
| Pratik
2007-09-23 05:45:44 | And for those idiotic rails evangelists who don't know a shit about rails - check http://rubyonrails.com/core and if you ever saw changelog of rails, you wouldn't be being a moron here. |
| Matt
2007-09-23 06:16:19 | You're not alone. Although my site doesn't have the exposure yours has, I went through the exact same thing only I had been using ASP.Net. Not to pat my own back, but I'm pretty good with ASP.Net and SQL. Fortunately, it occurred to me about 4 months in. |
| Scott
2007-09-23 06:23:23 | Wow, if you liked PHP for those reasons, you should REALLY try ASP.NET (don't worry, you can run it on Mono if you blindly-hate Microsoft like most other people on O'Reilly). |
| Lachlan
2007-09-23 06:24:02 | It seems to be we have two types of commentors; those who understand where you are coming from (even if they disagree) and the pre-pubescent fan-boys you'd only expect to see with something like Nintendo, Sony or Halo. |
| G
2007-09-23 06:25:30 | The one thing I've noticed working on several rails projects is this: If you're starting on a new project, fresh and clean, no existing database, you can't beat rails. However, if you're trying to migrate an existing project to rails, more specifically, have a database that rails must be laid on top of, it gets a LOT more difficult.

Just my experiences there,

G
|
| Carl
2007-09-23 06:30:57 | cdbaby.com is comprised of over 100k lines of sourcecode?... terrible... you certainly are one wasteful, beat-around-the-bush lengthy programmer, as the americans usually are. |
| Carl's buddy Mark
2007-09-23 06:35:54 | If you need 100,000 lines of code to provide what cdbaby.com does and is, I wouldn't want to hire you in a lifetime. |
| GB
2007-09-23 06:43:52 | I too love SQL, and dislike abstractions that take the power away from you.

I'm coming from a Java perspective here, rather than a PHP perspective, but I will not use database interface engines like JDO which turn 1 clear concise line of SQL (stuck into a prepared statement) into 10 messy method calls to do the same things, with a horde of behaviours that aren't what I want it to do. Spending months fighting and bypassing JDO's issues was a nightmare, and I will never do it again. Writing some DAOs with PreparedStatements took a tenth of the time, far less code, and is far more maintainable by someone who knows Java, but doesn't have JDO experience.

That said, things like Struts and Tiles - lightweight frameworks that make your work easier without limiting the power available to you - are good. Indeed Tomcat itself is a framework for writing a webserver that takes all the webserver grunt away leaving you to just write the logic.

What I don't understand is why you didn't drop the limiting framework - Rails - and just stick with Ruby. I don't know Ruby, but Rails must be built upon libraries for database use, etc, that you can access yourself, write your own SQL statements, do things the correct way, in a language you admit you like?

On the other hand, when you need to do something quickly, it is far better to do it using mechanisms you know and understand. |
| bryan
2007-09-23 07:03:44 | I've had the exact opposite experience, but i won't turn this into a PHP vs the world thing. Our sites handle tens of thousands of users per day and we have some extremely elaborate things going on. There have been extreme challenges, as with any other language, but we have figured out good ways to handle every obstacle with Ruby. We've even built our own distributed ruby application to handle the heavy lifting pieces, which has worked great.

Anyway, to your... arguments?

1. "But when I took a real emotionless non-prejudiced look at it, I realized the language didn’t matter that much."
So you're saying that end the end you went back to the language you were most comfortable with, not that Rails couldn't handle your app, right?

2. The One Big Day switch doesn't work. We have tried it before, and you end up getting a flood of repeated questions and you end up confusing a lot of people. The best way to do this is to prioritize the intranet pieces and website pieces and switch sites an intranet apps one at a time. We have 30 intranet apps being used by a few hundred people... We held big meetings to say, "hey, this is going to change and this is what we imagine it will look like." A few months later, their pieces started changing and they were (mostly) prepared. But, doing it in pieces allowed us to re-evaluate how each project was being used and make improvements, where your One Big Day approach limits you to trying to build it to function as it did before as quickly as possible.

3. Yeah... there's a lot of crap in Rails. A lot of plugins and libraries that never get used, and there are several libs that are just too unstable for real use. It would help if they cleaned up the docs and API a bit. This is a problem :(

4. Small & fast... you mean Rails, right? It's easy enough to set up a mongrel cluster with Apache proxy balancing that your 2U LAMP server should've been able to handle most anything.

5. Rails lets you do exactly the same thing.

6. I think those who use the object associations directly in Rails are doomed to failure. You can't just do someobj.otherthings and expect it to be optimized in any way. You can do direct SQL in rails, but what I like to do is: someobj.otherthings.find(:all, :conditions => "otherkey='asdf'", :select => "the, fields, I, want"). I adjusted all of our queries to be limited to only getting what I want and it improved performance significantly... especially in cases where I'm sorting after-the-fact through hashes of arrays and whatnot.

7. I kindof see where you're going with this, and agree that any exposure to a new language is a growing experience.

What I'd like to see are specific examples of what you couldn't do with Rails or what exactly made it more difficult. Without specific examples, I have to say, your post just sounds like a PHP fanboy that gave Rails a try, did learn some interesting stuff, but went back to what he was already more comfortable with. I suppose there's nothing wrong with that in itself. The ridiculously misleading and idiotic summary on slashdot of your post:

"Two years later, through blood and sweat, the project was then canceled because of limitations of Rails. Rails just wasn't meant to do everything since it is very much "canned" project"

Now that I've actually read the article, it is obvious you didn't mean your post as flamebait, but you are lacking specific examples of how Rails didn't meet your needs. |

|

|   |
|

|

|

Sign up today to receive special discounts,
product alerts, and news from O'Reilly.

| | |

| Privacy Policy >
View Sample Newsletter > |

• Twitter
• YouTube
• Slideshare
• Facebook
• RSS
• View All RSS Feeds > |

© 2017, O’Reilly Media, Inc.

(707) 827-7019 (800) 889-8969

All trademarks and registered trademarks appearing on oreilly.com are the property of their respective owners.

About O'Reilly

• : Sign In
• Academic Solutions
• Jobs
• Contacts
• Corporate Information
• Press Room
• Privacy Policy
• Terms of Service
• Writing for O'Reilly

Community

• Authors
• Community & Featured Users
• Forums
• Membership
• Newsletters
• O'Reilly Answers
• RSS Feeds
• User Groups

More O'Reilly Sites

• igniteshow.com
• makerfaire.com
• makezine.com
• craftzine.com
• labs.oreilly.com

• Partner Sites

• PayPal Developer Zone
• O'Reilly Insights on Forbes.com

Shop O'Reilly

• Customer Service
• Contact Us
• Shipping Information
• Ordering & Payment
• The O'Reilly Guarantee

|