The Cookbook Project

So, I have a friend who's a professional chef. He asked me what it would take to build a web application to store his recipes, of which he has an abnormal number. It needs to do a few things that existing online applications do not offer, such as keeping some of his recipes completely private.

As far as webapp languages, I already know Java and C#, and could easily refresh my stale knowledge of PHP. I was strongly considering doing this application using Ruby on Rails, to use it as a springboard to learning the new technology. The concern on choice of language is threefold; how long will it take to build, how will it be hosted, and how will it be maintained?

In Java, using AppFuse, I could have this prototype done inside of a week. C#.NET, about the same. Unfortunately, since both of these are usually enterprise-level solutions, getting hosting for them will be non-trivial; $20-50/month seems about the going rate. I could host it myself at home, but any time I'm between apartments, the app would be down indefinitely. Maintenance would be pretty easy, however.

In Ruby on Rails, I have no clue how long the prototype would take. I don't know Ruby, so there's a non-trivial learning curve, although it appears that the second project you do with Rails has the potential to be up and running 10x faster than one of the enterprise technologies I know. I don't do much hobby work, so I'm not sure how much utility I'd get out of Rails in the long run. Hosting Rails apps is *cheap*, $5-10 a month, and current free on Heroku. If I wind up not doing anything else in Rails, ever, the maintenance on this thing could be a pain.

I've used PHP in the past for small to mid-size projects. It's been over five years, so there's a learning curve to relearning it, but it was designed to be pretty simple. It's the most-used hobby language, so finding a place to host it would be cheap, and several friends are probably willing to host for free. Maintenance/additions would seem trivial, as well.

For benefiting my general knowledge, Rails wins this game. For getting it done and maintaining this indefinitely, I'd have to lean towards PHP.

Bouncing some ideas off of my friend Ernie the other day, I realized that the data model and web-services access to it might be interesting, as there are a lot of things it could possibly be tied into as a second round of development. Essentially, there are more uses for the data than just the initial front-end.

This leads me to the thought that "getting it done satisfactorily" for the time being is more interesting than "getting it done in an interesting way". If a PHP frontend is quick to construct, I can always replace it later with a Ruby frontend, if that's still of interest.

From my knowledge of Ruby, it's highly recommended that you properly name tables and primary keys in those tables. Searching for "Rails Database Conventions" yields this gem, which is worth a look even if you never intend to work with Rails. This is really, really well thought out, and probably a good subject for another post.