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.

OK, let’s grab the code:

git clone http://github.com/tablatom/hobo.git

The Rails 3 work is happening on the cunningly named rails3 branch, so you now need to

cd hobo
git checkout origin/rails3

Next, we use Rake to generate and install the gems for HoboSupport and HoboFields.

cd hobo_support
rake install
cd ../hobo_fields
rake install

That’s it! We’re ready to try a Rails 3 app with HoboFields. Assuming you have Rails 3 installed, use the new syntax for the rails command to create a new app:

cd somewhere/for/your/test/app
rails new test_hobofields
cd test_hobofields

Now, the way to add a gem to a Rails 3 app, is to add the gem to Bundler’s Gemfile. Edit that file, and add this line, at the end:

gem 'hobo_fields', '1.3.0.pre1'

If you now run

rails generate

You should see two Hobo generators listed in the available generators. Let’s create a Hobo model (note the nice new namespaced generator syntax).

rails generate hobo:model book name:string description:text

You can see the fields block has been added to the normal model template if you look at app/models/book.rb:

class Book < ActiveRecord::Base

  fields do
    name        :string
    description :text
  end

end

Now, let’s watch HoboFields work its magic and migrate the database for us.

rails generate hobo:migration

At the prompt, choose “m”, then give the migration a name. If everything is going according to plan, the local SQLite development database should be migrated to include the books table. We can check at the SQLite prompt:

rails dbconsole

Then at the SQLite prompt:

.schema

You should see

CREATE TABLE "books" ("id" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, "name" varchar(255), "description" text);
CREATE TABLE "schema_migrations" ("version" varchar(255) NOT NULL);
CREATE UNIQUE INDEX "unique_schema_migrations" ON "schema_migrations" ("version");

Score! And did you notice? Domizio even gave us a colored prompt in the migration generator. Too much : )

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:

Porting Hobo to Rails 3

The new Rails 3 compatible version of Hobo is on the go. It has been 15 days now that I am involved in the project, and it looks very challenging. Rails 3 introduces a lot of improvements, but also a lot of changes that inevitably break the legacy code. Hobo is not an exception: it is deeply interacting with the Rails internals, so the last version got deeply broken as well.

I can only guess the huge amount of work that it will take to make it work, but the result will absolutely be worth the effort: thanks to Rails 3 the new Hobo will have less code, less monkey patching and more efficiency and flexibility.

Hobo becomes a Rails 3 engine.

Thanks to rails 3 engine capability a lot of code has moved to better places and will be loaded at a better time. All the patches to the frameworks are loaded right after the framework with ActiveSupport.on_load hooks. All the code that needs reloading in developer mode has its own place to live in the config.to_prepare blocks. The programmer will have more choices to configure Hobo internals with the config.hobo.* configuration variables, the code will be more organized and easier to maintain.

New routes system for Hobo 1.3

The old ModelRouter has gone: it was drawing routes directly. The new system generates its own roues file and adds it to the routes_reloader.paths, so no monkey patching is needed anymore. The hobo_routes.rb file may be analized by the programmer that can eventually override any route in the regular routes.rb file.

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.

How would you describe Hobo in a few words?

Hobo is a collection of extensions to Ruby on Rails designed to make coding Rails apps even quicker and easier than it is already. We’re taking ideas that Rails pioneered, like convention over configuration, and pushing them much, much further.

What led you to develop Hobo?

It started pretty much as soon as I started learning Rails, back in 2006. I quickly found that I was extremely productive in Rails, except for the view layer. I had been experimenting with tag languages since as early as 1995 (browsing with Netscape version 1!) and had some ideas stored up. I was learning Ruby at the same time, and as I started experimenting, I quickly realised what a great language it is for this kind of thing. I was hooked. The Hobo project took off from the momentum that Ruby gave me.

Who is using Hobo? How big is the community?

We’ve had over 2,000 downloads of Hobo 1.0 and we’re approaching 500 members of the mailing list. It’s growing pretty quickly at the moment. As for who they are, we’ve had all sorts, from hobbyists to NASA. It’s especially popular with people that would love to create a Rails app but are a little intimidated by how much they have to learn in order to get to their finish line. With Hobo they can see that their goal is within reach.

I’m very happy to say that the Hobo community is very friendly. Newcomers are always welcome, and no one will tell you to RTFM!

What kinds of application is Hobo used for? Why would someone choose Hobo over Rails? Is Hobo useful for developing enterprise/business apps, or is it more for individuals making personal sites? Would professional web developers use Hobo?

Hobo can really be used anywhere that Rails can. The sweet-spot is for smaller projects and prototypes – that’s where the speed-up is most noticeable. With the professional folk, some love the power it gives them, and some seemingly prefer to do things at a slightly lower ‘hands-on’ level. Actually we’ve worked very hard to make sure you can always go ‘under the hood’ and can change anything that you could with regular Rails, but there is a learning-curve to be surmounted before you get to that point.

How does Hobo differ from other similar tools which are available, such as ActiveScaffold or Streamlined (or even make_resourceful and other REST controller frameworks)? Is Hobo just another scaffolding framework?

In my opinion Hobo is entirely different from these tools. I’ve written about this several times over the history of the project because obviously there’s a perceived similarity. Scaffolding frameworks are very useful in situations where rough-and-ready is good enough. For example, as a stop-gap while you’re working, or in an admin site that your public users won’t see. Hobo is for your whole app. You can start with the out-of-the-box UI, which is already closer to a usable site than you might expect, and from there you can gradually tweak anything and everything until you have exactly the user-experience you’re after.

Your site features two books devoted to Hobo. Why does Hobo require two books’ worth of documentation? Is the learning curve steep?

Hobo is a big project. There’s a lot to learn but you only need to learn a little to be up and running and productive. The more particular you choose to be about fine-tuning your app, the further along that learning curve you’ll need to go. In practice it tends to be the people that build several Hobo apps that decide to learn the details.

How many plugins are included in Hobo? Is there more to Hobo than the three plugins HoboFields, HoboSupport, and DRYML? What are the external dependencies? Does Hobo require any native extensions? Can I run it under JRuby?

Actually DRYML still hasn’t been separated, although Bryan Larsen has pretty much done the work now as part of his efforts to support Rails 3. So we have HoboSupport, HoboFields, and Hobo itself which includes DRYML. We rely on will-paginate for pagination and that’s about it. There are no native extensions, and it runs fine under JRuby.

Do we really need another markup language? What does DRYML do for the user that, say, partials in Rails wouldn’t?

DRYML is the part of Hobo that I’m most proud of — I believe it brings some significant and important innovations to the table. It’s main strength is allowing view-code fragments to be packaged up for re-use, without sacrificing flexibility down the line. I think any discerning hacker who’s written a lot of Rails view code knows that we need something better. Projects like Seaside (for Smalltalk) and Erector make low-level languages like ERB and HAML look very primitive.

The important idea in DRYML is nested parameterisation. Imagine method A calls method B which calls method C, and in your code, which is using A, you realise you need to tweak a parameter to C. If that parameter is not exposed by both B and A in turn, you’re sunk. With DRYML you can “drill down” and add that extra parameter to C. In regular code this would be total chaos, but in view-code where all you’re ever doing is generating fragments of HTML, without side-effects, it works wonderfully. You can remove that breadcrumb link, inside that latest-news widget, inside your blog’s index page, without ever having to repeat any of the intermediate HTML code.

If a developer uses HoboFields to specify fields in the model classes, how does HoboFields maintain compatibility with ActiveRecord, which is looking to create those fields by querying the database? Wouldn’t this break ActiveRecord? What are the advantages and disadvantages of moving away from Rails’ philosophy of generating the model dynamically from the database columns?

It doesn’t break any aspect of ActiveRecord. ActiveRecord still creates the fields by interrogating the database. The fields block in a HoboFields model is used by our migration generator. Originally it wasn’t used at runtime at all. The migration generator essentially does a ‘diff’ of your database and your field declarations, and writes both the up and down migrations for you. So for example, if you want to rename a field, you literally go to the model and rename it, and then run the migration generator. Job done. ActiveRecord carries on as normal, taking the field name from the (now updated) database.

Once that was working we realised that the fields block was a great place to add a few more conveniences, like some nice shorthands for validations (e.g. name :string, :required).

I’ve honestly not encountered any down-sides at all. There’s really no need for anyone to write migrations by hand any more.

If I add a new field to a model, HoboFields creates a new migration to add a column to the database. How does it keep track of what additional migrations it needs to create? Isn’t this process fragile?

There’s nothing to keep track of. You run the generator, it creates a migration that will bring your database into line with your code. Once you’ve run that migration you can sanity-check by running the migration generator again and it will say “Database and models match – nothing to change”. It’s rock-solid. The one issue that is a challenge for any tool that attempts this is that you can’t tell the difference between an add/remove and a rename. For example, the migration generator sees a column in the database called ‘name’ that’s missing from the model, and a field in the model called ‘title’ for which there is no column. Did you remove the ‘name’ field (and hence want all the name data to be dropped) and add a new one called ‘title’, or did you rename ‘name’ to ‘title’? It’s impossible to tell. One solution is to require the developer to include some kind of hint in the source code, which could later be removed, but that’s clunky. In the end I realised that there was a simple solution – just ask! So the migration generator is interactive: is this an add/remove or a rename. It only asks when there is ambiguity.

What are HoboFields Rich Types? What kinds of types are there?

A rich type allows you to capture higher level information about your data, such as “this is an email address”, or “this is Markdown formatted text”. You know that information when you are coding your model, so it’s a shame not to capture it. Doing so allows you to do some nice tricks, like rendering Markdown text correctly as HTML without having to do a thing in your view code, or getting validations for email addresses. These things happen automatically as soon as you tell HoboFields the type of your fields. You can very easily add your own rich types.

Does Hobo add tools for building AJAX applications over and above what’s provided with Rails?

Yes. In Rails, if you have a fragment of a page that needs to be updated via AJAX, you have to factor that out into a partial – a separate template file. Sometimes they are ridiculously small and you can end up with unmanageably large numbers of them. DRYML has the concept of a part, which is a section of your template that is marked as something you want to update. There’s no need to go to a separate file. Even better, in many cases Hobo knows how to update the part for you. You can just annotate, say, an ajax form or button, with update="foo" where ‘foo’ is the name of your part, and it just works — the page is updated according to the new state of the database after the ajax operation is complete. To be honest that’s one of the more magical features in Hobo — perhaps too magical for some people’s tastes. But it’s totally optional.

What makes the 1.0 release a milestone release?

It means we stopped adding features and focused on documentation and stability until we felt ready to say, OK, all sorts of people can feel comfortable using this now. We’ve also made a commitment to not make major breaking changes without a grace period of warning messages, very much as with Rails.

How do you see Hobo evolving after 1.0?

To be honest I feel that this is now up to the community. There are a million ideas to explore, but which ones get done depends on what people want, and what people are going to contribute. We’ve just had a fantastic contribution to the internationalisation support, and to be frank that wasn’t on my radar at all. It’s great to see the project gain it’s own momentum like that.

*The Hobo site says that Barquin International sponsors Hobo. Was Barquin involved with Hobo from its inception? What does Barquin’s support enable that you wouldn’t have if you were simply an open-source project without funding? *

The project had already been going for about two years when Owen Dall of Barquin spotted us and decided to get on board. To be clear, we’re not talking about VC-like funding here, with a long line of zeros. Barquin supported myself, and later Bryan Larsen to work on the code and still be able to pay the rent. Progress accelerated a great deal compared to fitting the project in on the side. I’m married with kids so the days when I could stay up all night working on a hobby are long gone. We also learned a lot by watching a company picking up Hobo and training their team. We were able to make the learning curve a lot more pleasant as a direct result of that experience. More recently, the project to create the Hobo books came entirely from Barquin. Some of my words were used, from documentation I’d written already, and for that I got authorship credit, but in truth the books happened entirely because of Owen and Jeff over at Barquin. The community has benefited enormously of course, so all in all we’re extremely grateful.

gem update hobo

There are two speedups: one that reduces the number of database accesses by Matt Jones and one that speeds up compilation of DRYML by Petteri Räty.

If you’re interested in the details of what got fixed, take a look at the commit log on github.

Thanks very much to everyone who contributed!

Meanwhile work continues on Hobo 1.1. Watch this space : )

Go get it!

gem update hobo

or

gem install hobo

I for one never thought it would take that long! But then the project has changed such a lot. In the early days we thought the automatic UI provided by Hobo would be a good starting point, but not much more. As we went on we noticed more and more patterns in web UIs, patterns we could capture in Hobo. As a result you can now get a surprisingly usable app for almost no effort beyond creating your models.

Of course from there you can customise things to your heart’s content – that was the goal right from the start and it hasn’t changed.

Along the way we added some killer features too. Writing migrations by hand is pretty much a thing of the past in Hobo apps, since we added the migration generator (also available with the rest of Hobo!). Hobo’s lifecycles make it so much easier to implement multi-step processes, you get a UI to your lifecycles with little or no code, and there’s even support for secure links in email messages (for implementing things like forgotten-password and account-activation).

We’ve also put a huge effort into getting Hobo documented. We’ve built a community driven documentation site – cookbook.hobocentral.net, which is also the home of the extensive manual. There’s a new introductory screencast. Oh and there’s two books available to download, and a third on the way!

Perhaps more importantly than any of that, there’s a thriving and very friendly community. One of the most consistent comments we get from developers is how much they appreciated all the help and support they got while building their first Hobo app. Be sure to check out all the cool apps they’ve built.

For myself personally, and on behalf of the whole Hobo community, a huge thank-you goes out to all the people that helped us get here. In the beginning there was Line Learning & Communications and Jiva Technology, who contributed enormously by choosing Hobo for major projects, and of course my coding partner on those projects and the early version of Hobo, James Garlick. James’ keen sense of aesthetics has had huge impact on the design of Hobo, inside and out. We had a good laugh too!

Today of course there’s Owen Dall, Ramon Barquin, and the team at Barquin International. Owen spotted us at an early stage. He saw in Hobo a vision for the future and took a big bet on us. Barquin’s sponsorship has made Hobo 1.0 possible. Thanks Owen! There are too many people in the open-source community to thank individually, but a mention has to go to core contributors Matt Jones and Bryan Larsen — as you know, it’s been you guys much more than me that have polished things off, fixed the bugs, and got us to 1.0. And in the background all along, unseen by most, is my business partner, coach, cheerleader, agony-uncle and general strategist, the one and only Mr. Nigel Powell. Well done everyone!

At this point it is customary to say “and this is only the beginning!”. In this case however, it’s not just an up-beat signing off remark. I’ve not actually been committing loads of code to Hobo in the last few months while Matt and Bryan have got us to 1.0. The reason is, I’ve been in the back room, quietly tinkering, tweaking, experimenting, honing. The next chapter in this story could just be a game-changer. Stay tuned.

Actually I only just published the gems so don’t forget that Rubyforge takes a while to get its act together.

I’m really posting this on behalf of Bryan who’s done pretty much all the work in this release – thanks Bryan! And thanks to Owen and the guys at Barquin for their continued support.

This release is mostly bug fixes. The low-down, as usual, is in the changelog

Oh one more thing. We liked the fresh new look in the previous post so much that it’s now the Hobo default. (that doesn’t mean you need ImageMagick, we just included the generated PNG files in the Clean theme)

Enjoy!

Hobo 0.8.8 is coming very soon, consisting mostly of bug fixes and bringing us that bit closer to the hallowed version 1.0. While we’re waiting, I though I’d quickly let you know about a very simple Rails plugin I knocked up that makes it extremely easy to add gradient background images to your stylesheets. (If you follow the hobousers group you’ve already seen a mention of this.)

For example:

div.featured { background: url(/gradient_images/50:aaa:fff.png) repeat-x white; }

All that’s happening is that the plugin is rendering a PNG image on the fly; 1 pixel wide, 50 high, with a gradient from a light grey (#aaa) to white. It renders the image you would otherwise have to make yourself in Photoshop or whatever.

The general pattern for the image URL is:

/gradient_images/<height>:<start-color>:<end-color>.<format>

Colours are 3 or 6 digit hex values, as in CSS. The format can be anything supported by ImageMagick (e.g. png or jpg).

You can also do multiple gradients in the same image, like this

div.featured {
  height: 100px;
  background: url(/gradient_images/50:aaa:fff::50:fff:aaa.png) repeat-x 
}

That will give an image 100 pixels high fading from grey to white and back to grey.

Note that you only take the performance hit on the first request, after that the images will be served up directly by your web server thanks to Rails’ page caching. You’ll see a bunch of image files in public/gradient_images.

Requires Rails 2.3 and RMagick.

The plugin is available on github.

UPDATE: We just threw up a quick example app on github. It’s great to see how much nicer you can make the default Hobo app look with just three CSS declarations.

First up, I’d like to give a big welcome to Bryan Larsen, who is now working on Hobo full time. Bryan made some excellent contributions entirely off his own back, and he happened to come to the end of a previous project at just the right time so we snapped him up. A big thanks too to our good sponsors at Barquin International for helping us to bring Bryan on to the team.

As requested on hobousers, we’re going to start putting out regular updates on the blog about the latest changes to the code; a sort of “This week in Edge Hobo”. Bryan will be helping out with these posts.

And the other little item of news is that we’ve started the push to Hobo 1.0. The feature set is frozen at this point, and we are working our way through bug fixes, improving the test coverage and docs. If you’ve got a pet bug that you want to see fixed in Hobo 1.0, make sure it’s ticketed.

Stay tuned!

Many thanks to Dr Nic for the early work in getting Hobo running as a gem, and for those super cool TextMate tricks. And to Mathijs and Matt for many fixes and tweaks here and there. And of course Mr. James Garlick for a ton of commits in all areas of Hobo, contributions to the docs, and for making Hobo look good both on the outside (the Clean theme) and the inside (James is my API aesthetics consultant!)

Also a shout to Jason and Joel over at i5labs. These guys helped me out with a Hobo project that I got too busy to finish. If anyone out there needs development or help with a Hobo project, drop i5labs a line – they know what they’re doing.

Also thanks to Pete Ferne and the boys at Jiva, for choosing Hobo for Beanbag, and for the many contributions to Hobo which they funded. I am going to do a proper post about Beanbag at some point – promise!

Finally a big thanks to everyone in the wider Hobo community for their involvement, large or small.

Merry Christmas — or whatever you will be celebrating — to all!

See the changes for the details. As always, remember that Rubyforge takes a good while to catch up, so gem update hobo might not work for a while. You can download the gem files from Rubyforge manually though.

That’s pretty much me done for the year — I’m taking some time off now. And what a year it’s been. Progress has accelerated dramatically since our sponsors Barquin International came on board. We wouldn’t be remotely close to where we are now, especially in terms of documentation, without their support. So I’d like to say a very big thank you to Owen and the team over at Barquin.

It feels like we’re in great shape for a very exciting 2009 with Hobo. Just in time for the meltdown of the entire global economy. Heh – you win some you lose some : )