Hi,
it’s great that you want to try RoR and I think there’s no better way
to learn something new than to take it for a spin “in the real world”.
However, I’d like to inject a bit of reality here.
On two different occasions I’ve had people come to me with Rails
projects that needed rescuing. Both times either the client or the
developer asserted that the project was X% done and both times they
had grossly overestimated how much work had actually been completed.
Both times my response was “but there’s nothing there!”. Not one
feature had meaningful unit or functional tests and all they really
had was the result of a database schema and calls to “./script/
generate scaffold”.
Yes, a database schema does take time to define but apart from
that, weeks of development effort had gone into something that any
experienced rails developer could have done in a couple of hours.
It was as if they defined the schema, generated the scaffold and then
said: “now what?”. And they spent weeks trying (and failing) to
answer that question.
So, assuming this isn’t a toy project and you have a real deliverable
for a paying client, here’s my advice:
1 - Budget extra time.
Rails does make things easier but only if you don’t fight the
framework. It’s unrealistic to expect that Rails will shave 30% off
your development effort for a 3 week project if you’re not already
used to doing things the Rails way.
Just how much extra time you budget depends on point #2.
2 - Have an early success metric.
You need to have a milestone that you can hit within your budgeted
“extra” time that will tell you if you need to abort and implement it
in PHP.
My advice is to choose a feature that is at the very core of your
application - an aspect that is at least partly the reason for the
app existing in the first place.
And here’s the critical part: develop that feature from start to
finish. Unit tests, functional tests, all logic. Ignore stuff
like navigation or graphics, even user login - concentrate solely on
the logic and interaction for that one feature.
3 - Decide whether it’s worth the risk for this project.
Once you’ve fully implemented the feature (or you’ve run out of time)
you have to decide whether to continue with Rails for this project.
If the first feature is a resounding success or a dismal failure the
decision is pretty easy.
Chances are though, it’ll be somewhere in the middle. You’ll get it
done but it will have been a struggle. You’ll have to look at the
rest of your app and do some math.
I budgeted X days to do the first feature in PHP and it took me X
days to do it in rails. What lessons did you learn? How much time
did I burn because I didn’t understand “why” something is done a
certain way in Rails? Will I burn less time on the next feature?
Ultimately if your answer to “can I hit my delivery date with Rails”
isn’t “hell yeah!” then you are taking a big risk.
4 - If you decide to abort, try again.
If it doesn’t work out and you decide that (for the client’s benefit)
you’re going to implement in PHP, make sure you revisit Rails - it
really is worth it. An excellent learning experience would be to re-
implement this project in Rails after you’ve delivered the PHP
version to your client.
–
I hope this all doesn’t come off as too negative. Much of what you
hear about productivity gains can be backed up by a lot of people,
myself included. However, I personally believe you won’t start to
realize those gains until your next “three week” Rails project.
Good Luck!
Trevor
On 7-Mar-06, at 8:49 AM, Shalin Jain wrote:
However, I want to take an opportunity to learn Ruby On Rails. I
sets etc
etc.
be traveling a bit in the near future and would love to code when I
I think these are quite a lot. Thanks in advance. I look forward to
http://lists.rubyonrails.org/mailman/listinfo/rails
–
Trevor S.
http://somethinglearned.com
