 |
has been coding since the Commodore 64/Apple II days. He has his BSEE, MSEE and MBA and spent the first decade of his career living and working in Switzerland where he earned his business degree and did a lot of skiing. His background is in digital signal processing and algorithms, but lately has become enamored with web development. After a successful career climbing the corporate ladder from engineer, to manager to executive management, Dave left his most recent position overseeing an empire of almost 80 software developers for a smaller team, using agile development methodologies. Dave's current day job is working at Aterrasys, a small startup doing advanced research in location based mobile applications and sensors for security and intelligence applications. Kiwiluv is a vehicle for him to stretch his entrepreneurial wings and build some fun and interesting products using the latest and greatest technologies. In his spare time, Dave hangs out with his family, skis, hikes, mountain bikes and is into photography (the latest toy is a Canon 7D) and travel. Dave's Day Job: www.aterrasys.com Kiwiluv: www.kiwluv.com The Kiwiluv Tech Blog: www.kiwiluv.com/techblog |
Introduction
My work in web development started in the dark ages, when ASP (not ASP.NET) was roaming the countryside killing livestock and spaghetti code was intertwined with each web page. Database access was sprinkled throughout the application and could be implemented differently on each page. It was truly a dark time with evil trolls lurking in the code of most web sites.
Then the renaissance came in the form of Model View Controller (MVC) web application frameworks such as Cake and CodeIgniter for PHP and of course Rails in the Ruby community. Not only did these cleanly separate presentation from business logic and data access, but they provided so much of the application skeletons that it was a breeze to throw together a stable and decent looking web application.
I played with many of these frameworks and ultimately gravitated to Rails. David Heinemeier Hansson’s video of creating a blog in 15 minutes got me intrigued enough to give it a shot. I was amazed how quickly you could put a web application together with Rails. How could it possibly get any faster?
Along Comes Hobo
I found Hobo quite by accident. I was actually exploring to see if anyone had improved upon the scaffolding functions provided by Rails. Of course, I found things like Active Scaffold and a few others, but among the search results, there was also this strange thing called Hobo.
“What a stupid name!” I thought. But it caught my attention and I felt I had to check it out.
Rapid Development on Steroids
Hobo is a framework on top of a framework (Rails). Each of them provides key pieces of application infrastructure. While Rails gives you all the components and tools you need to get something up and running quickly, Hobo adds to this so you can get even more functionality even faster.
The downside with any framework is that if you try to deviate from what the frameworks want you to do, you’re paddling up a fast flowing stream. Hobo is no exception, but if you’re willing to go with the flow you’ll have a very polished application up and running in no time. Tom Locke makes the following statement in the voluminous Hobo documentation: ”We’ve traded flexibility for reach, and boy is it a good trade.”
That’s what Hobo’s all about… you can go very far very fast if you stick with its conventions. Rails is, after all, opinionated software, and so is Hobo.
Hobo Test Drive
The best way to see what Hobo can do for you is to take it for a spin. For my example, after much thought, I decided to go with the most mundane and boring application example imaginable. The dreaded To Do list.
Ready? Here goes. The following will install Hobo, which comes as a gem (make sure you have a current version).
gem install hobo
Now to the real work… let’s create our To Do list app.
hobo boringtodolist
cd boringtodolist
script/generate hobo_model_resource todoitem name:string duedate:date done:boolean
script/generate hobo_migration
When prompted, just hit ‘m’ to migrate now and accept the default migration name. Ok, you’re done. Take a break… it’s important to pace oneself in the perilous world web application development.
So, you can see that this is not unlike creating a simple Rails app and using scaffolding while generating your model. However, Hobo has done much more behind the scenes. Fire up the server and have a look.
script/server
When you bring this up on your browser (http://localhost:3000 in most cases), here’s what you see:
Wow. Where did all this come from? Log in? Sign up? Search? We didn’t even create a User model, let alone use an authentication plugin like Authlogic or Devise. Hobo takes care of that for you.
Hobo assumes that every application will have multiple users and puts all of that piping in place. Hobo applies a convention that the first person to register is granted administrative privileges, so go ahead and create an admin account. In fact, create a few accounts using the “Sign up” link and play around.
Notice the drop box in the upper left corner. Hobo allows you to select a user, which completely bypasses the login page. Is this a hideous security flaw? No. Hobo only makes this control appear in development mode and it is disabled for production deployment. This is a handy way to switch users quickly for testing purposes.
When we created our application, we created a model using hobo_model_resource called todoitem. This had a simple string name, due date and done flag.
Another Hobo convention is that each of these models has its own tab in the applications views. As a default, these are not associated with specific users. Go ahead and create some to-do items.
Hobo did it’s best to choose controls for the data type we defined. If you switch user, you’ll notice that all of the To-Do items are still visible, so we have not established a relationship between individual users and the To-Do items which may be desirable and Hobo certainly allows you to do.
So, we’ve built have a fully functional (if somewhat dull) to-do list manager which is multi-user, supports signup and authentication, has reasonably attractive styles applied, etc. and it took well under 5 minutes.
Oops, Forgot Something
Hobo, like Rails, assumes that your application won’t have a set of models which have been so thoroughly thought out that they will be sufficient for all user needs through the end of time. In our case, I forgot that we should have a priority field. I like “High, Medium, Low” priorities, but to keep things simple at the moment let’s just add a numerical priority to our todoitem model. To do this, just open up your model file and add the new fields.
class Todoitem < ActiveRecord::Base
hobo_model # Don't put anything above this
fields do
name :string
duedate :date
done :boolean
priority :integer # Here’s our new field# that we carelessly forgot!
timestamps
end
# --- Permissions --- #
def create_permitted?
acting_user.administrator?
end
def update_permitted?
acting_user.administrator?
end
def destroy_permitted?
acting_user.administrator?
end
def view_permitted?(field)
true
end
end
Running the migration again will reconcile these changes with the database table, etc. You’ll notice that when you run a Hobo migration you are prompted for various options. In this case, select ‘m’ and use the default file name for the migration. When in doubt, always go with the default, but Hobo politely gives you the ability to give each migration it’s own name, defer running it until later, etc. which can come in handy at times.
script/generate hobo_migration
Now, if you refresh your browser while viewing a to-do item, our new field is there.
Simple!
Some Basic User Interface Tweaks
This has been easy so far. Hobo provides the facility to highly customize the web pages it generates and goes so far as to offer it’s own markup language called DRYML (more on that later). For now, let’s stick with the basics.
Hobo has used the field names and model names verbatim for the view labels. As a user, I’d rather see “New To Do Item” instead of “New Todoitem” and would prefer “Due Date” to “Duedate.”
If all you want to do is have different field names in your view than the actual field name, Hobo provides an easy way to do this. Each Hobo model, has a viewhints file in the app/viewhints directory. Let’s see what damage we can cause with this file.
In our example, we have only one model and our corresponding viewhints file is called todoitem_hints.rb. Here’s what it looks like.
class TodoitemHints < Hobo::ViewHints
# model_name "My Model"
# field_names :field1 => "First Field",
# :field2 => "Second Field"
# field_help :field1 => "Enter what you want in this field"
# children :primary_collection1,
# :aside_collection1, :aside_collection2
end
Nothing there but some instructions which seem pretty clear.
Modifying the file accordingly results in a bit more human readable field tags in our views.
class TodoitemHints < Hobo::ViewHints
# model_name "My Model"
# field_names :field1 => "First Field",
# :field2 => "Second Field"
# field_help :field1 => "Enter what you want in this field"
# children :primary_collection1,
# :aside_collection1, :aside_collection2
model_name "To Do Item"
field_names :name => "Description:",
:duedate => "Due Date:",
:done => "Complete:" ,
:priority => "Priority (1-10):"
field_help :name => "Enter a description of your To Do Item here.",
:duedate => "Enter the date the To Do Item is due.”,
:done => "Check this box when the To Do Item is complete.",
:priority => "Enter the priority from 1 to 10."
end
This changes the labels in the view file, the tab and create button labels and also associates the field help text with each field. Now this is starting to look much better.
Naturally we can do much more by invoking the sinister powers of DRYML, but this is a very convenient shortcut to quickly decouple your field and model names from what the users see.
What Else?
This brief tour just scratched the surface of what Hobo can do. Here’s some more goodies you may wish to know about Hobo.
The Usual
While we didn’t explore it here, Hobo naturally gives you the ability to apply field validations, editing the navigation tabs, establishing more complex model relationships as well as a complete permissions system to manage what users can do.
The Documentation
One frustration I’ve always had by community developed frameworks is that the documentation is spotty. Some is good, some is bad, some impossible to find, some easy to find but useless, etc. One reason I selected Rails for my web development projects is the quality and availability of documentation, podcasts, screencasts, etc.
I must say that Hobo takes this to an extreme and has the finest documentation I’ve seen in an open source project in quite a while. The “Rapid Rails with Hobo” tome is 314 pages long, filled with examples, tutorials, instructions and interesting philosophical comments from Hobo’s creators. The first chapter goes into excruciating detail about setting up your environment on all the major operating systems with several of the most popular database engines. They even give detailed instructions on getting everything working for Windows users, who are often treated as the pariah of the Rails community (go ahead and try to find a single Rails screencast that was done on Windows!).
This and a lot of other useful documentation are available free for download from http://hobocentral.net/. The Hobo documentation is so complete that it’s easier to get started with Hobo than to get started with Rails.
DRYML
The Hobo creators have elected to pollute the water supply with yet another markup language. No, not “the” YAML (Yet Another Markup Language), but just their own markup language used to customize views. DRYML is the Don’t Repeat Yourself Markup Language. DRYML is a full blown markup language specifically designed to manage the tags generated and used by Hobo.
A full tutorial of DRYML would be at least as long as this brief introduction (probably longer), so I won’t dive into it here. Again, since the documentation is so complete a quick Google of DRYML will produce a copious amount of reading material.
I’m not completely sold on DRYML yet, but will give it a fair chance to impress me. Also, stay tuned for release of my own new markup language, OCNAML (Oh Crap, Not Another Markup Langauge), to be released later this year.
Rails 3 Support
You can tell just by the way Hobo works that it has some tentacles going deep into Rails internals. As such, it will be a nontrivial job moving Hobo to Rails 3, but according to HoboCentral.net blog, the Hobo team is already on it and I’m looking forward to seeing how it works. Maybe they’ll be done before Rails 3 ever makes it out of beta!
Last Words
I have to say that I’m very impressed with Hobo. We only had a look at it’s most basic out-of-the box application in this example. You can criticize Hobo for imposing it’s look and feel and conventions on you, but recall we’re exchanging reach for flexibility. If that’s not what you’re looking for Hobo isn’t for you. On the other hand, Hobo will let you create a wide variety of applications extremely fast if you’re willing to sacrifice some freedom. In many cases this is a good trade.