Update: I should of known better than to post this late at night. Now improved with actual working instructions!
Folks, thanks to Domizio’s great work, HoboFields is ready to try out with Rails 3. Here’s a quick guide to getting it installed and running the migration generator. You’ll need git to grab the latest code, as nothing has been released as a gem, but apart from that you won’t have to do anything too technical. Please note, Rails 3 RC2 just dropped today, but right now we’re still on RC1, so please make sure you have that version of Rails installed if you want to try this out.
If you’re paying attention, you’ll know Domizio Demichelis as the contributor of some big improvements to Hobo’s internationalisation. Well Domizio has jumped in and is now taking over from where Bryan left off in the push to Rails 3 compatibility. Welcome aboard Domizio!
Domizio is going to let us know how he’s getting on via some short posts here on the blog. He just sent me his first thoughts, so over to Domizio:
Although the blog has been quiet of late, one only has to look at the mailing list to see how busy the Hobo world is. I’d like to give a shout-out to Matt and Kevin and everybody else who are patiently answering questions there. The Hobo user community rocks! But a quiet blog does give the wrong impression sometimes.
I’ve got a few other things Hobo related that I hoped to blog about but aren’t ready yet, but there’s nothing stopping me from using this blog to point out tools that will make your Hobo experience better, is there?
Most of the Hobo and Ruby on Rails community uses git for version control. Git is awesome, but there are two common pain points: its learning curve, and submodules.
I won’t go into the problems with git submodules here. If you’ve got a small project with only one developer and you never need to modify your submodules, you’re unlikely to run into problems, but as you add developers and start modifying the modules, hassles quickly creep in.
In the past, when you added a plugin to your project, you basically had two options: copy the files into your project with script/plugin or link the files in using git submodules.
Now you can get the best of both worlds. With git subtree you get the behaviour of a copy, but you can still easily update the plugin and even extract changes to the plugin to push the changes upstream.
For instance, to add Hobo as a plugin to your project:
git subtree add --squash --prefix=vendor/plugins/hobo git://github.com/tablatom/hobo.git master
You can then update the plugin with:
git subtree pull --squash --prefix=vendor/plugins/hobo git://github.com/tablatom/hobo.git master
If you make changes to the Hobo in your app, you can extract them and send them to us with:
git subtree split --prefix=vendor/plugins/hobo --branch hobo-master
git push git@github.com:someuser/hobo.git hobo-master:master
(Replace someuser with your github username). And then send us a pull request.
Git subtree is not yet part of git itself, but hopefully it soon will be. Even if it does not, it isn’t doing anything crazy or unorthodox to your repository, so I wouldn’t worry about using it.
Two other alternatives to git subtree are Braid and Piston. They use similar strategies under the hood. However, I’ve found git subtree to work better for me.
A while back I was approached by Paul Blair who was interested in doing an email interview about Hobo for InfoQ. That interview went out a few weeks back and is available here.
The actual interview was quite a bit longer than the version that got published, and the full version is probably of interest to anyone interested in Hobo, so I’m posting it here in full.
Find what you're looking for quickly by using our keyword search. Can't find it? Try our links below.