Last year I did a contract for a startup consultancy in which I was the only person with IT application know-how, everyone else had plenty of business know-how. This created an interesting situation where the excitement of a startup winning its first client threatened to swamp any IT strategy. The eagerness of the team to see results immediately was a daunting prospect as the previous project I worked on had quarterly releases and teams for dev, testing and deployment! So I had to find a different approach, that’s when I tried a web app framework called Hobo which is a set of plugins on top of Rails.

Hobo does clarify one deviation from RoR regarding Interface First approach. The development starts with sketching the Models rather than designing the interface (“what people see is what you’re selling”), this is explained by an ambitious statement about rewriting the rule because “…Hobo, is actually quicker than creating html designs.”

Hmmm, lets run with it a bit longer….

I created the app, with the hobo command, which looked almost identical to a standard RoR project. So then using a Hobo generator to create the model resources (much like the Rails scaffold generator) gives me controllers and models as you would expect but there are no view files. This is very much like Groovy on Grails where the (default) views (and routes) are generated at runtime and you only override if you want to change them. The Controllers were much leaner, containing just 2 directives to the Hobo framework for the default behaviour and conversely the Models had the field definitions and some Hobo permission methods for access control, so more than usual.

And where were the DB migrations? Well these are created by another Hobo generator which is quite clever. It looks at the Model code and compares it to the DB schema and creates a migration file to get the DB from current state to the new state as defined in the Model. This works for adding, modifying and removing fields in the Model. This turned out to be a life saver as it drastically reduced the turnaround of Model changes so that they could be done during a demo to incorporate some feedback immediately or show other possibilities. Ah that’s fine for flat table structures but what about relationships I hear you say, well it handles those too and even adds indexes where necessary. This allowed me to try out new things quickly in front of the team, safe in the knowledge that I could roll back the code and DB to a working baseline in a couple of clicks (in Netbeans). I liked this feature a lot.

Hobo gives you a lot by default which you can remove or modify very easily. The first to strike me was the default user model created with each Hobo project which allows signup and basic admin such as editing or resending a forgotten password. This together with the permissions I mentioned earlier, specify who can do what to each Model. Also, in dev mode, Hobo displays a “user changer” which allows you to navigate the app and see it from different roles (admin, user and guest roles available by default). You can also specify permissions to maintain data integrity and the UI will reflect the change. E.g. by default you can change the parent of a Model in the UI. If isn’t what is required you can withdraw that permission and the UI will automatically not show the drop down in the edit screen. So when I was asked to make a subset of data/functionality available to certain group of users by the next day, it was possible with Hobo not least, due to this feature.

Another default that is neat is when you want the view of a Model to list its children, it is a simple directive in the view hints file for that Model e.g. children :tasks. What this also does is when viewing a Model that is a child, the parent is shown as a breadcrumb navigation.

Other default behaviour includes pagination and an application wide search facility.

So a little work on the models and controllers and the UI was enough for the team to try out and give feedback and refine the data model … in a matter of days. It was as close to the 80-20 rule as I have seen.

Of course we needed a little more than the default UI but that will wait for another day.