Semantici.st

Today is the first day for my new plan of not watching TV at 8pm, and here I am watching TV while I wait for my food to cook.

I’m happy with that, though, since the project management system is looking good and I want to take some time to write up my first experiences with developing and deploying a basic Rails application.

The first thing I’ll say is that Ruby on Rails is an absolutely fantastic framework, and the scaffolding system (even just the static scaffolding that’s used in the current releases of Rails) makes it really simple to get started and provide excellent examples for learning from and adapting to your own ends.

It can be deceptive, though. Once you create your models (Rails uses the MVC design pattern) you feel like you’ve got 90% of it done, when what you’ve got left is all the difficult parts. It’s easy to get ahead of yourself and run into trouble when you thought you were almost done.

Some parts of Rails are pretty impenetrable – routing is the obvious one here. If it wasn’t for advice from Craig Webster (who is an absolutely excellent guy) I’m not sure I ever would have figured out one particular problem I was having. The solution looks trivial once you see it, but it’s nothing like obvious before it’s pointed out.

Similarly, while the ‘act_as_tree’ plug-in makes organising my heirarchy of tasks trivial, it seemed really difficult to install until a random web search suggested running script/plugin discover to get the plug-in system to update its sources. If only that had been mentioned in the Rails book (my reference material is the latest beta of the Rails book and the latest beta of Programming Ruby 1.9 – sadly, I’m using Ruby 1.8.7, but it’s not been too confusing so far), it would have saved me a lot of fiddling and faffing.

I suspect that a more experienced software developer would be able to pick Rails up much more quickly than I am – for a start, they wouldn’t keep making mistakes like if @blah.thing = whatever.

Early on in my build, I disabled the scaffold’s options for deleting projects and tasks. Obviously I knew I’d need to be able to remove them, but I also knew that I’d need to make sure that the full tree of objects (all tasks assigned to a project, and all sub-tasks of a task) would be deleted when the root was deleted. I think my favourite moment of the process so far was when I discovered that all I needed to do was include the following line in the ‘Project’ model file:

has_many :tasks, :dependent => :destroy

Because act_as_tree automatically handles destruction of child objects (it uses the has_many/belongs_to methods internally), setting that one line meant that calling the ‘destroy’ method on any Project or Task object would not only kill it, but would magically clean up all its children.

Another nice point has been the use of a ‘partial’ to display an individual task. Partials are a part of Rails’ templating system which are essentially functions/subroutines for views. The use of partials makes it easy to walk over the tree of tasks, as the partial can check for children and call itself recursively as needed. Because I’m displaying trees of tasks in several locations this means I can follow ‘DRY‘ and re-use this partial all over the place. It’s been really satisfying to add additional code to the partial (or to be called from the partial) and see it instantly appear all over the application. I’m not sure if the amount of controls I’ve added to each task in this partial is the best thing from a usability standpoint, but at this stage I’m just trying to create a prototype and learn the language and the framework.

Overall, I’ve found Rails to be quite excellent for a novice developer to hack away on. Ruby is already extremely readable and Rails enhances that, except in the odd random spot when it’s completely impenetrable. At times it felt like Rails development was only either really easy or completely impossible, with nothing in the middle.

After getting my app up to a state where it’s just about usable for tracking its own development, I decided to deploy it to my personal projects VM. That’s deserving a separate post, because parts of getting the system ready to deploy were incredibly easy, and parts trashed my Ruby install causing other applications I run on that VM to fail in the middle of the night.