Getting on track with Rails...

A few months back, shortly after my last post, I had a what-if-why-not moment. 

The what-if was on my choice of the language - PHP, so seemed to go the opinion online, was struggling under the weight of its own inconsistencies. Too flexible to be held to a particular convention, too popular to have one decisive framework that would address all of its supposed evils. As must be pretty obvious, most of the people making these claims were Ruby-ists. Ruby-on-rails was the Promised Land, keeping you on track with development and taking care of all the other nasty stuff that us developers have to deal with. Especially the little things that you wished you didn't have to deal with.

Why not, I wondered then? If - despite the challenges of picking up Yii - I were to opt for a framework anyway, why not in a new language? Moreover - if reports are to be believed - Rails developers are rarer than PHP'ers, and therefore an average Rubyist earns a wee-bit more than your slightly-above-average PHP programmer. The clincher was the fact that Rails and PHP are among the most popular languages when it comes to web applications (and my experience as a user of ASP websites has left me in no doubt whatsoever of the migraine awaiting me if I were to choose Microsoft's problem to all solutions).

I decided to give Rails a try.

Picking up Ruby and Rails...

RubyMonk and CodeLearn were two tutoring resources I found extremely useful from a newbie's point of view. While RubyMonk helps you pick up the basics (and a bit more) of Ruby rather effortlessly, CodeLearn's assignment - creating a to-do list application from scratch - does what it should, which is to ease in a coder into the world of Rails programming. I did try other places like CodeCademy, RailsForZombies, etc., but the takeaway from those sites were lesser in comparison.

From the very beginning, one of the things that's struck me about Ruby is its simplicity. Having learnt the lessons from the time I started on PHP, I looked around for a ready-made stack that would give me Ruby/Rails, MySQL and a web server. BitNami - Ruby's equivalent of (W/L)AMP - was a breeze to set up, although running both BN and WAMP on the same machine had its gotcha! moments. You don't need a stack to install and run a Ruby compiler on your machine, though, and if it is a CLI/GUI application you are coding, you can download Ruby right off the site and set it up on your machine.

Over to RubyMonk then. C42, the team behind the tutorial, has done a great job in breaking up the entry to Ruby into a series of small, manageable, memorable steps. Each chapter unveiled a feature of Ruby that appealed to me - and in comparison to PHP, seemed much more organized - and the interface was as fast as if it were run locally.

Interestingly, there were a lot of hints, something I found sorely lacking on Zombies, and in certain instances, common errors were actually explained back to me. The one limitation was the absence of a Rails tutorial (which they have started only very recently, and is therefore not developed to the extent of CodeLearn) As a fan of the Kung Fu Panda series, I liked how they have Shifu sitting in his temple and teaching us the secrets of Ruby Fu.

RubyMonk: Shifu tries to teach you the secret of the Dragon Scroll

Speaking of CL, they have recently revamped their website and it looks much better now - more organized, and gives you a better sense of the tools that you have to work with. At the time I used their tutorial, the console was virtually non-existent, but the explanation - spread over a five-page tutorial - was bang-on. The explanations for the MVC architecture, something I had struggled with until then, was reminiscent of the 'For Dummies' series and has probably shaved a few weeks off my learning curve. 

CodeLearn's course takes you through everything from setting up a new app, folder structure, loading Gems, cranking up the server, etc. - making it easier for an experienced to programmer to identify common grounds and points of difference, and build from there. The new sandbox, with its own console, file browser, web browser and code editor, is a far cry from a recent time when the tutorial was more of a walkthrough that you implemented on your own machine.

CodeLearn, which helps you learn more than just code

Ruby, to the aspiring, ranks especially high on one aspect. It builds in a unit-testing functionality that PHP is only waking up to. Unfortunately, this is also an area where there are more theoretical tutorials than live-coding ones as above. 

In recent times, along with RubyMonk and CodeLearn, most of the other e-learning sites for RoR have expanded their content and/or revamped the user-experience, but I would still recommend these two sites for a newbie who's looking to test these waters. Not only are the courses free, but also is the learning curve much easier to handle. 

At the same time, be warned that they might still be underwhelming to someone who's spent at least a year with the framework, and for those users, RailsForZombies might be a slightly better bet. Then again, nothing beats sitting down in your own pit and trying to make a castle with a spoon and a cup of water, and you would be amazed at what you learn when you don't have a ready-made solution right in front of you.

(Next part, appropriately enough, will be titled 'Getting off track with Rails', and as the name suggests, will explain why I reverted to PHP as my preferred language - at least for ver 1.0!)

The road not taken... really

Sometimes, despite the best - and highly committed - intentions, you have to take a step back and give up on a particular course of action.

One of the phrases that's stuck with me since the earliest OB (Organizational Behaviour) classes is 'escalation of commitment' - which, in its essence, means the pursuit of a failed cause simply because one has committed to it. You throw more resources at it, you ignore other priorities, you try your damndest... and yet, you may still fail because failure was all it was meant to be. And as in most cases where a little knowledge is the most dangerous thing, guarding yourself against this psycho-virus is as dangerous as it would be to ignore it. In your haste to absolve yourself of an escalation of commitment, you may well leave a problem unsolved right at the edge of its solution.

(On a side note: Metaphors tend to flow more freely towards midnight than at any other time. Hmmm...)

In my last post on July 29th, I had argued for (albeit against myself, proving once again that even when I win an argument, I lose!) adopting Yii. The arguments are perhaps still as sound as they are then - the framework is still a benchmark, it's a proven workhorse and stable and secure - but the experiences of battling with its steep learning curve has finally taken its toll on me. A slower coding speed at the initial stages was acceptable if there was progress; but to be stuck at the starting point itself, relearning the commands and parameters, the do's and the don'ts, for more than a week is asking for trouble. 

And that's led to some serious soul-searching. Should I invest in becoming an expert on Yii (and an expert you need to be, to take full advantage of its possibilities) or should I absorb the best and come up with a framework that I can use to speed up my prototyping? At some point of time, the answer became pretty obvious. Yii had to go. At the end of the day, Yii is just a framework (a very popular one, but still just a framework) in a world that has plenty of frameworks; it looks good on your resume, particularly if you have worked with a team where the collaborative learning would have been superior to picking it up by yourself. No regrets about this road not taken.

At the same time, the experience has not been completely fruitless. Working with MVC architecture has refined my coding and code-organizational skills, helping me hone ProPlan into a better, more flexible, more intuitive and lighter web-development interface. The shackles have really come off in the last 36 hours, with excitingly rapid progress on developing the CRUD/Form-maker module for ProPlan. The idea is to develop both the fundamental engine and it's value-adding components simultaneously, an approach that gives me the chance to keep testing our plug-and-play system continuously. Effective? Yes. Efficient? Getting there...

What else do I take away from this brief but meaningful liaison? One, it pays to do your research on these things before you start. Two, establish your benchmarks when trying out possible solutions - to guard yourself against that escalation of commitment and to keep evaluating your own adaptability. Just as short-term gains should not distract you from long-term investments, the tenure of these long-term plans should itself not be so long as to render it meaningless. It's a highly subjective measure, though... would you rather extend the deadline by 50% more (or even 10% or 20%) to develop the basic requirements with the promise that things will get better? Or would you rather try to finish off your version-1 well within the deadline and then use up another 10-50% of the project schedule for enhancements?

The trade-off you make... speaks volumes about the way you will handle your client's problems!

The road (not) taken

One of the key issues when you are developing a product (as opposed to a custom-built solution) is that there is often no definitive guide that tells you the best route forward.

Consider a trip you are planning to take to a nearby, but unfamiliar, town. The destination is known; perhaps all avenues of travel have also been accounted for. But how sure are you that driving yourself from point A to point B is better than, say, hiring a cab, taking the bus or train or something else? Would it make sense to go from A to C before B, just because C to B might solve some future requirement of yours?

Therein lies the catch when you are working with something as wonderfully - and as infuriatingly - flexible as PHP. Having followed my own style for the past couple of years, it would be infinitely easier for me to start coding for ice-Labs the same way - knock off each module one by one, using my own filing, navigation and  processing systems - rather than spend (a lot of) time learning a new framework and then twisting my plan accordingly to execute it.

The catch, as I expect it, would happen later during the game when I will probably find myself redesigning the code as I go along, modifying it here and there; a bigger pinch would be the amount of time spent on re-coding for the same basic elements (anyone who's coded a form for updating an existing record knows the pain I am talking about!); further down the line, as the next-gen of my staff takes over the maintenance of this product, there must be a clear and coherent framework that's apparent to the slowest among them!

Contrast this with the implications of using a framework such as Yii or CodeIgniter. Most of my basic work is already taken care of, such as modelling the data, setting the flow of control, etc. With Yii, there is an even greater degree of automation that promises to make a lot of my work easier, a lot of it compressed into one-line commands that ties into the API of Yii. Salivating thought... until you realize that the price to be paid is reinventing the way you've usually done things.

That is not often a bad thing - and after all, hundreds of programmers around the globe would not be testifying for these frameworks if the promises remained unfulfilled. Yet, for every site built with frameworks, there are at least two or three or even five that are gloriously independent of any such 'box'... and in some cases, are the better for it. Do you really need to obfuscate your URL or make it searchable by SEOs and bots? For most applications where data security is paramount, the answer would be a resounding no.

There is a learning curve that is associated with the use of frameworks too. The time that you would have spent on re-coding/re-designing/re-using your work at a later stage, when doing it your way, is spent on picking up the rudimentary basics of the frameworks at the initial stages itself. And don't forget the hours that precede this step, hours spent on researching and comparing frameworks to arrive at the shortlist! (Often with no clear winners, GeekWorld being what it is - apples by any other name could be oranges still!)

The clincher for me was merely a matter of pragmatism. Pro-plan, slated to be the first release out of ice-Labs, is a small project in the larger scheme of things - and a large project in the smaller scheme of things. Had I done it my (complete) way, Pro-plan could have been live by now (except maybe for delays caused by Acts of God or my own sloth) - but learning something new is a price worth paying. Between CodeIgniter and Yii, the choice is surprisingly easy for a guy to whom one is as new as the other. Yii wins the vote for its scaffolding features and generators.

The road thus not taken is my own.

Will Yii be the Yiing to my Yaang? Only time will tell...

Till then... Yiip Yiip Yurray! :D