Was this Rails/PHP comparison the one from Slashdot et al regarding CDBaby?
If so, the article was very light on technical details. Not once did the author of the article expound the reasons /why/ he decided to move back to PHP, except to say:
- Rails didn't do what he thought it could
- He rewrote it in PHP so that it was compact and only what he needed
I have yet to find any articles from Jeremy Kemper, the gentlemen in charge of the main bulk of programming CDBaby. I do not know him in particular, except that I do know that he hacks on the Rails code itself and has contributed a lot to it.
With he being able to speak Rails and Ruby in his sleep, you would think that CDBaby would have been able to launch and perform well under the Rails framework - except that no one really knows the technical details of why the project was scrapped in favour of its ultimate incarnation in PHP.
Now, maybe Jeremy was smart, went above and beyond, and just got tired of having to fix everything to do what he wanted, or maybe the project manager just felt it wasn't working out? Either way, we will never know until some details surface. One comment on Slashdot says:
Quote:
Different first-person perspective
(Score:0)
by Anonymous Coward on Sunday September 23, @12:37PM (#20719943)
(The post below provides insight into the situation. It was posted as a comment to the original blog. Another thing that comes out in the comments is that Derek has some serious issues that likely exacerbated the problems.)
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.
|
So who knows? Make your own decision.
At any rate, the thing you have to remember about Rails is that it is a framework. Frameworks are designed to allow programmers to build things quickly using the same background of assets. You've seen thousands of Movable Type, Wordpress, etc diaries, yes? You can think of those as mini-frameworks to build journals. They all look the same because they, in a small part, are frameworks themselves.
Frameworks are rigid. Some frameworks allow a great deal of flexibility, others don't. Rails allows you to override a lot of things, and build plugins from scratch if A) it doesn't allow it or B) the main Rails developers think it's a bad idea to put into the trunk. If it doesn't work the way you like, /contribute to it in some way/.
That being said, I am not a /strong/ programmer, although that is my background. You have to pick the tool that gets your work done efficiently - financially and expeditiously. If Rails works for you, great! If it doesn't, then either contribute to it, or find something else that will work for you.
I don't like PHP. Type "PHP sucks" into Google and you'll see why. Function declaration inconsistencies (think "needle, haystack" vs "haystack, needle") and the fact that OOP paradigm was bolted on as a gross after-thought. And this is coming from someone who got into PHP when PHP3 was /becoming/ the new guy in town. Now, I've never built an enterprise-grade ERP with dozens of table joins, temporary tables, HTML cache problems etc, so take the previous with a grain of salt. The design of the language just grated on me and I've since attempted to learn something different.
I have rebuilt my journal from PHP into Rails. Not having to worry about SQL injection, sessions, writing queries by hand and templating has really sped up the development of this little project. Again, it's nothing enterprise-grade (and I have no idea if it will scale, but it plays nicely so far!), however, it has really impressed me so far.
I would love to see any Rails projects built by anyone here. If anyone wants to trade tips, advice, or whatever, I'd be glad to help. Spill it - what do you like about Rails, hate about Rails (or other frameworks) and what cool things have you built?