Owen Dall has been Chief Systems Architect for Barquin International for the past seven years. Duringthat time he has led a data warehousing, business intelligence, and web systems practice and hasbecome

an evangelist for agile

development methodologies. His search for replacements

to Java webframeworks led him to Hobo open

source

environment for Ruby on Rails (RoR) in late 2007.

In his 25+years software development experience, he has authored several software packages used by diverseclients

in both the private and public sectors.

Jeff Lapides

Jeff Lapides was educated as a physicist and has worked as a CIO and senior operating executive

in alarge public corporation. For most of the past decade, he consulted with private industry in informationtechnology, business management and science. He is currently engaged at a nationally ranked researchuniversity where he develops relationships between research scientists in engineering, informationtechnology, physical and life sciences and foundations and corporations.

Tom Locke

Tom is the founder and original developer of the Hobo project. He is also co-founder of ArtisanTechnology, asoftware and web development company exploring commercial opportunities around Hoboand other open-source projects. Prior to founding Artisan Technology Tom has been a freelance softwaredeveloper for over ten years, and has been experimenting with innovative and agile approaches to webdevelopment since as early as 1996.

xi

CONTRIBUTORS

Venka Ashtakala

Venka is

a Software Engineering Consultant with over 10 years experience in the InformationTechnology industry.

His expertise lies in the fields of rapid development of data driven web solutions,search, reporting and data warehousing solutions for both structured and non structured data andimplementing the latest in open source technologies.

He has consulted on a variety of projects in both thePrivate and Public sectors, most recently with the National Institute of Food and Agriculture andTandberg LTD.

Tola Awofolu

Tola is

a software engineer with over seven years of experience with standalone Java and Javaweb development frameworks. She’s been working with Ruby on Rails and Hobo

for over a yearas part of the Barquin International team at USDA on two major projects. She is a protégé ofTom Locke and Bryan Larsen and has become Barquin

International’s leading Ruby developer.

Tiago Franco

Tiago Franco is

a Project and Technical Manager working in Software development for more than tenyears, currently working for the Aerospace & Defense market. He's been working with Ruby on Railssince 2006, and adopted Hobo

in 2008 to

re-design Cavortify.com.

Marcelo Giorgi

Marcelo is

a software engineer with over seven years of experience with standalone Java and Java webdevelopment frameworks. He’s been working with Ruby on Rails for more than two years, and had theopportunity to

work with (and make some contributions to) Hobo during last year.

Matt Jones

Matt is

a software engineer who can remember when Real Web Programmers wrote NPH CGI scripts to

be loaded up in Mosaic. When he’s not buildingHobo applications, he’s often found hunting Rails bugsor helping new users on rails-talk and hobo-users. He also has the dubious honor of being the unofficialmaintainer of the Rails 2.x-era “config.gem” mechanism, earned after fixing the borked 2.1 series versionto work better with Hobo.

Bryan Larsen

Bryan sold his first video game in 1987 and has never stopped.

Joining the ranks of fathers this year hasslowed him down, but he's still having fun.

While building and rebuilding the outline of what we thoughtwere the book’s requirements, we soon realized that it would take much more focus and energythan we anticipated to complete this project.

Our goalseemed simple enough:

“Create a full set of rock-solid instructions and tutorials so that even a novice developer cancreate, revise, and deploy non-trivial data-richWeb

2.0

applications. The user must have funwhile learning, and develop the confidence to take the next step ofdiving in tolearn more aboutHobo, Rails andthe elegant and powerful object-oriented language behind these frameworks-

Ruby.”

Right.Well, you know how these things go.OK, so we bit off more than we could chew, at leastin the timeframe we envisioned. So instead of three months it took a year…at least it comes outsynchronized with the release of Hobo 1.0!

So--we hope we have been at least partially successful. We havehada few “beta” testers ofearly versions that have made it through without serious injury.More recently it has beenreports of minor typos and suggested phrasing enhancements.

Letting this simmer for a whilehas been a good thing.

I hope you aregrateful

that we parsed off the last 200 pages into a more advanced companionbook with the tentative moniker “Hobo Under the Hood.” Jeff liked the Acronymthis

created,“HuH?” . It really represents the awe(with initial confusion)we sometimes feel about the Ruby“spells” within Hobo and Rails that appear to be magical to the newly initiated, which includesus.

Abriefhistory

The search for a new web development framework began with my frustration with the

learningcurve and the lack of agility I experienced with the current open source frameworks at the time.A major client had stipulated that we were to use move to a totally open source technology stack.In the early 2000’s that meant to us Linux, JBoss, Hibernate, MySQL, and Java web frameworkssuch as Struts. We eventually moved “up” to using Java Server Faces (JSF). The learning curvewas steep for our new programmers who were learning on the job.

This was particularly frustrating to me as I had experience with the “agile” tools of the 1980’sand 1990’s, which included Revelation and PowerBuilder, client-server technologies that didn’tmanage to survive into theInternet

age. With Revelation we could build an applicationprototype that included complex business logic while sitting in front of a client. We didn’t call itAgile Development. We just did it. We built dozens of mission-critical applications and manyPREFACE

shrink-wrapped tools. Things were good. Then they weren’t. The dinosaurs didn’t survive themeteorthat hit with the World Wide Web.

So, as the development team lead at one of our major sites as well as the chief systems architectof our small company, I thought it was my duty to start looking for another solution in earnest.

It was in the middle of2006 that I had a long discussion with Venka Ashtakala about this newquest. (Venka and I had survived two unsuccessful framework searches together starting in1998. The first was as Alpha testers of the PowerBuilder web converter. Our goal was tomigrate a very successful client-server budgeting system used by a large number state and localgovernments to the web. That experiment was a disaster at the time, so we dropped it.)

A few daysafter our initial discussionhe emailed me about a relatively new framework called“Ruby on Rails” that had gotten some good press.

He heard of a few guys who vouched for it,but couldn’t find any “mission critical” apps we could use as references.

I was intrigued. I did asearch and found

the first edition of “Agile Development with Rails”, and tried it out.

My first simple application worked, but I have to admit it looked very plain and uninspiring tome. I was a designer and architect, and didn’t want to code HTML and JavaScript.I didn’t wantto go backward.

“I am too old for this!” was my mantra at the time.I couldn’t understand whythe framework didn’t take care of basic things I had been used to for over 20 year. Among otherthings, I was looking for a data-driven navigation system, user authentication,and a decent userinterface baked in.

I dropped the search for almost a year. I stumbled on a link on one of the major Oracle sitesabout interesting add-ons to Rails, which led to a post by therenowned

Ruby evangelist, PeterCooper, in January of 2007. Here are two short quotes.

“You may have thought Ruby on Rails was enough to get Web applications developed quickly,but enter Hobo. Hobo makes the process of creating Web applications and prototypes evenquicker. For example, out of the box, with nolines of code written, you get a dummy app with auser signup, login, and authentication system.

…There's quite a lot to Hobo, so you'll want to go through its comprehensive official site andwatch the Hoboscreen cast

to get a real feel for it where a classified ads app is created withinminutes.”

I watched the

screen cast

three times. I was blown away. I had finally found someone whogotit. It was Tom Locke.

Following an open source project was something totally new to me. We I owned my ownsoftware business for a dozen years I used proprietary tools that I paid licenses for. I couldn’tsee the source code. Oracle and Microsoft weren’t giving me the code to their database servers,applications servers, or WYSIWYG design tools. I paid support and expected THEM to fix theproblems we invariably discovered building our vertical applications in the 1980’s and 1990’s.

The closest

I came to the open source world was being a senior member of the RevelationRoundtable, a board of keydevelopers and integrators

Revelation development tools.A few of our products were shrink-wrapped add-ons for otherdevelopers.This gaveusclout for recommending priorities for new development and the abilityto get the president on the phone if one of my very high profile customers was having an issue.

So posting to a forum and waiting for an answer to my (probably) stupid question didn’t comeeasy to me. This was the thing (I thought) for generation X, not an aging

survivor of decades ofsoftware wars.

It was a welcome and pleasant surprise to find supportive, generous, and incredibly talentedpeople willing to help. Even Tom Locke would answer my questions, patiently. Later I waslucky enough to spend time with Tom in person on a number of occasions, which increased myrespect for his vision and capabilities.

In Early 2008 an opportunity arose at one of our major clients, The National Institute for Foodand Agriculture (Formerly CSREES), tomigrate a legacy app to the web.I invited the CIO,Michel Desbois (a

forward-looking open source advocate) to experience a demo of building anapplication using Hobo. My position at NIFA was Chief Systems Architect of the Barquin team,not one of our senior developers. So Michel was intrigued that I was going to sit with himwithout a coder coaching.

That demo led to a small “proof of concept” task to build a Topic Classification system foragriculture research projects using Hobo and Oracle as a back end. Michel took a risk andstarted the ball rolling for us with Hobo.

As this project moved forward, and additional Barquin team members became interested inlearning, it became more and more urgent to have a solid resource for training not onlydevelopers,but also

our requirements analysts and designers. We were building wireframesusing software (e.g., Axure) that built great documentation. It even generated HTML pages soyou could simulate the page flow of an application.

Unfortunately

these becamethrowaway

artifacts, as there was no way of generating a databasedriven application.

What we needed was a prototyping tool designers could use and then pass onto developers.

Hobo appeared to be the best solution for both prototyping and mission-critical

web development.

Here is what I reported in May of 2008 about Barquin International’sdecision to provide some seed money to Hobo:

"This is the first time in over a decade I have been excited about the potential in a newdevelopment framework," explains Owen Dall, Chief Systems Architect for BarquinInternational, "Although Hobo is already a brilliant and significant enhancement to Rails,we are looking forward to the great leap forward we know is coming…”

More recently we have two significant development efforts underway using Hobo that will put inproduction this year. The new Leadership and Management Dashboard (LMD) led by JoeBarbano, and the REEport (Research, Education and Economics Reporting) project lifecyclereporting system under the direction of John Mingee. Anyone who things government cannot beagile should come on by and have coffee with the NIFA application development projectPREFACE

Hobo is a software framework that radically reduces the effort required to develop database-driven, interactive web sites and web-based applications. Strictly speaking it’s more of a “half-framework”—

Hobo builds

on the amazingly successfulRuby on Rails

and that’s where muchof the functionality comes from. The original motivation for the Hobo project can be summed uppretty succinctly with a single sentiment: “Do I really have to code all this stuff upagain?.

In other words Hobo is about not re-inventing the wheel. In software-engineer-speak, we call thatcode reuse. If you mention that term in a room full of experienced programmers you’ll probablyfind yourself the recipient of various frowns and sighs; you might even get laughed at. It allsounds so simple-

if you’ve done it before just go dig out that code and use it again. The troubleis, the thing you want to do this time is just a bit different, here and there, from what you did lasttime. That innocuoussounding “just a bit different” turns out to be a twelve-headed beast thateats up 150% of your budget and stomps all over your deadline. Re-use, it turns out, is a verytough problem. Real programmers know this. Real programmers code it up from scratch.

Except they don’t. Ask any programmer to list the existing software technologies they drew uponto create their Amazing New Thing and you had better have a lot of time to spare. Modernprogramming languages ship with huge class libraries, we rely on databases that haveunthinkable amounts of engineering time invested in them, and our web browsers have beengrowing more and more sophisticated for years. Nowadays we also draw upon very sophisticatedonline services, for example web based mapping and geo-location, and we add features to ourproducts that would otherwise have been far beyond our reach.

So it turns out the quest for re-use has been a great success after all—we just have to change ourperspective slightly, and look at the infrastructure our application is built on rather than theapplication code itself. This is probably because our attitude to infrastructure is different—youlike it or lump it. If your mapping service doesn’t provide a certain feature, you just do without.You can’t dream of coding up your own mapping service, and some maps is better than no maps.

We’ve traded flexibility for reach, and boy is it a good trade.

Programmers get to stand on the shoulders of giants. Small teams with relatively tiny budgetscan now successfully take on projects that would have been unthinkable a decade ago. How farcan this trend continue? Can team sizes be reduced to one? Can timelines be measured in days orweeks instead of months and years? The answer is yes,if

In part, this is what Hobo is about. If you’re prepared for your app to sit firmly inside the box ofHobo’s “standard database app”, you can be up and running with startlingly little effort. So little,

in fact,

that you can just about squeeze by without even knowinghow

to program. But that’sonly one part of Hobo. The other part comes from the fact that nobody likes to be boxed in. Whatif Iam

a programmer, or I have access to programmers? What if I don’t mind spending moretime on this project?

We would like this “flexibility for reach” tradeoff to be a bit more fluid. Can I buy back someflexibility by adding more programming skills and more time? In the past this has been a hugeproblem. Lots of products have made it incredibly easy to create a simple database app, butadding flexibility has been an all-or-nothing proposition. You could either stick with the out-of-the-box application, or jump off the “scripting extensions” cliff, at which point things get awfullysimilar to coding the app from scratch.

This, we believe, is where Hobo is a real step forward. Hobo is all about choosing the balancebetween flexibility and reach that works for your particular project. You can start with the out-of-the box solution and have something up and running in your first afternoon. You can thenidentify the things you’d like to tweak and decide if you want to invest programming effortinthem. You can do this, bit by bit, on any aspect of your application, from tiny touches to theuser-interface, all the way up to full-blown custom features.

In the long run, and we’re very much still on the journey, we hope you will never again have to

say “Do I really have to code all this upagain?”, because you’ll only ever be coding the thingsthat are unique to this particular project. To be honest that’s probably a bit of a utopian dream,and some readers will probably be scoffing at this point—you’ve heard it all before. But if wecan makesome

progress,any

progress in that direction, that’s got to be good, right? Well wethink we’ve made a ton of progress already, and there’s plenty more to come!

Background

A brief look at the history leadingup to Hobo might be helpful to put things in context. We’llstart back in ancient times—

2004. At that time the web development scene was hugelydominated by Java with its “enterprise” frameworks like EJB, Struts and Hibernate. It would beeasy, at this point, to launch into a lengthy rant about over-engineered technology that wasdesigned by committee and is painful to program with. But that has all been done before. Sufficeit to say that many programmers felt that they were spending way to much time writing repetitive“boilerplate” code and the dreadedXML configuration files, instead of focusing on the reallycreative stuff that was unique to their project. Not fun and definitely not efficient.

One fellow managed to voice his concerns much more loudlythan anyone else, by showing abetter way. In 2004 David Heinemeier Hansson released a different kind of framework forbuilding web apps, using a then little-known language called Ruby. A video was released inwhich Hansson created a working database-driven Weblog application from scratch in less than15 minutes. That video was impressive enough to rapidly circulate the globe, and before anyonereally even knew what it was, the Ruby on Rails framework was famous.

a wave of hype, Rails (as it is known for short) wasoften dismissed as a passing fad. Five years later the record shows otherwise. Rails is nowsupported by all of the major software companies and powers many household-name websites.

So what was, and is, so special about Ruby on Rails? There are a thousand tiny answers to thatquestion, but they all pretty much come down to one overarching attitude. Rails is, to quote itscreator,opinionated software. The basic idea is very simple: instead of starting with a blank slateand requiring the programmer to specify every little detail, Rails starts with a strong set ofopinions about how things should work. Conventions which “just work” 95% of the time.“Convention over Configuration” is the mantra. If you find yourself in the 5% case where theseconventions don’t fit, you can usually code your way out of trouble with a bit of extra effort. Forthe other 95% Rails just saved you a ton of boring, repetitive work.

In the previous section we talked about tradingflexibility for reach. Convention overconfiguration is pretty much the same deal: don’t require the programmer to make every littlechoice; make some assumptions and move swiftly on. The thinking behind Hobo is very muchinspired by Rails. We’re finding out just how far the idea of convention over configuration canbe pushed. For my part, the experience of learning Rails was a real eye-opener, but Iimmediately wanted more.

I found that certain aspects of Rails development were a real joy. The “conventions”—the stuffthat Rails did for you—were so strong that you were literally just saying what you wanted, andRails would just make it happen. We call this “declarative programming”. Instead of spelling outthe details of a process that would achieve the desired result, you just declare what you want, andthe framework makes it happen.What,

not

how.

The trouble was that Rails achieved these heights in some areas, but not all. In particular, when itcame to building the user interface to your application,you found yourself having to spell thingsout the long way.

It turned out this was very much a conscious decision in the design of Ruby on Rails. DavidHeinemeier Hansson had seen too many projects bitten by what he saw as the “mirage” of high-level components:

I worked in a J2EE shop for seven months that tried to pursue the component pipe dreamfor community tools with chats, user management, forums, calendars. The wholeshebang. And I saw how poorly it adapted to different needs of the particular projects.

On the surface, the dream of components sounds great and cursory overviews of newprojects also appear to be “a perfect fit”. But they never are. Reuse is hard.Parameterized reuse is even harder. And in the end, you’re left with all the complexity ofaSwiss army knife that does everything for no one at great cost and pain.

I must say I find it easy to agree with this perspective, and many projects did seem, in hindsight,to have been chasing a mirage. But it’s also a hugely dissatisfying position.Surely we don’t haveto resign ourselves to re-inventing the wheel forever? So while the incredibly talentedteam