Monday, November 22, 2010

Hobo, Finally

During the previous setting up of the Heroku staging, I found out the name Heroku gave to my new application:

Creating afternoon-water-18...... done
Created |
Git remote leapercan added

OK, that's a bit strange, but I can deal with it. The name of my app as known by Heroku is "afternoon-water-18". 

I need a database for my Hobo. I choose MySQL, just because it makes me do something to set up. Plus, I've already got it installed. 

I update my Gemfile to include the mysql gem:
mvim Gemfile
gem 'mysql'

then invoke bundler again
bundle install

Now to create the database:
mysql -h localhost -u root 
mysql> create database leapercan;
Query OK, 1 row affected (0.12 sec)
mysql> quit

I don't have a password set up for my database. I should. There's no excuse for laziness, except procrastination. I'll do that later.  The changes will go into database.yml . Since I don't have a password set up it should just work.

Now I call Hobo to generate the application:

hobo -d mysql leapercan

Lots of output. Well, everything is great, except that the app now lives under a subdirectory. I use mv to put the files up one directory. 

mv leapercan/* .
rmdir leapercan

There, that's better. Next time I'll do that a bit differently. 

I follow the tutorial from here, and create a hobo migration:
ruby script/generate hobo_migration
Unknown database 'leapercan_development'

Uh-oh... did I miss something obvious? Yup -- I omitted the _development from the intended database name... go back into mysql... drop database leapercan; create database leapercan_development;

Try again... looks good this time. It asks me if I want to generate or migrate now, or cancel?  I migrate now and accept the default migration name. Hobo takes care of running the migration for me, so I don't have to rake db:migrate at this point.

OK, so time to try it out a little:

ruby script/server 

A mongrel server is started, which we can visit at localhost:3000.  Very niftily (I know that's not a word): hobo has created a closed shell of an application with user accounts, and is ready to set up an administrative user.  Hobo feels more like a 4GL rapid application builder than Rails alone. 

I'm adding a model now. The tutorial is talking about Contacts, but I want to think about the warranty information I had to track down this morning.  I carry around keys and coins and never really have trouble finding them because they are either in my pocket or dropped into a bowl on the nightstand. I admit, sometimes I leave them in my pocket and dig them out before throwing the clothes into the laundry.

ruby script/generate hobo_model_resource pocket name:string content:text

Wow, it really generates a lot of stuff. A RoR purist might say it is a bit much, but I don't know enough to be that picky. I migrate again, same method as before:

ruby script/generate hobo_migration

Cool. Now there's a new tab for Pockets, apparently with the CRUD interfaces bootstrapped for me. I create a new Pocket, call it Leapercan, and put some application maintenance details in it. Stuff someone would eventually ask about, if they were asked to support the application.

It just works. That's a very, very nice quality.

Did I mention how little I value debugging? Debugging other peoples' code is like trying to understand and have a discussion with another developer by relaying the messages through a stupid, more or less insane, and completely soulless being. I'm in awe of people who can do it, but I'm finding I have less and less tolerance for stuff that doesn't work as expected.

The tutorial mentions how Hobo works at this point, automagically adding or removing fields and tables, based directly upon what it finds or doesn't in the models. To delete a table, just delete its model and generate another migration. You'll be doing the hobo_migration dance a lot during early development.

On the other hand, rolling back to a previous version apparently involves editing of the migration files directly and a  rake db:migrate VERSION = version_no  

It isn't much, but I'll push it anyway. Nope... Heroku says I need to run bundler. Bundler says I don't. What gives?  It tells me to look at completely unhelpful advice... GoogleTime... looks like a common problem, but the advice offered doesn't work. Like, AT ALL.

git add Gemfile.lock
git commit -m "Added Gemfile.lock"

After several attempts at modifying the Gemfile, running bundler, and adding both the Gemfile and Gemfile.lock, git push leapercan master still craps out with that same error. Every Time. Even when I destroy and reinit the git repository.

Looks like Heroku is in the crapper at this point in time. It took me from a nearly seamless experience to an brick wall. Epic fail. Waiting, wondering, and - the thing I hate most of all - debugging someone else's code.

I'm starting to hate you, Heroku, and I hardly even know you.

So I start hacking, wildly guessing. I figure, something is lying to me, so I decide to do exactly the opposite of what it seems to be telling me. It says

   You have modified your Gemfile in development but did not check the resulting snapshot (Gemfile.lock) into version control

   You have deleted from the Gemfile:
   * version: 1.0.6

MISDIRECTION! I really wish that some programmers would learn to communicate better than brain damaged slugs.

Google had a lot of bad advice, utter nonsense, akin to cutting off a chicken's head and sprinkling its blood on the ground. The true reason for the problem is that Bundler records its version number in the METADATA section (which happens to be at version 1.0.6), and the bundler up on Heroku (version 1.0.3) apparently cannot deal with the fact that it has a slightly different revision level.  So I deleted the version number line from Gemfile.lock, and BAM, it just works.


Except... it didn't work. The command line says "yes" but the Web interface says something went drastically wrong. Wait. I forgot one more step: the Heroku database migration.

heroku rake db:migrate

Ah, such sweet release. All done.

The bundler version discrepancy reminds me of US EPA emissions requirements for commuter vehicles: not only do the requirements add to the cost and complexity of the auto, the emissions parts are directly the cause of most of the failures. How much difference is there between 1.0.3 and 1.0.6? Probably very little. Yet the version labels themselves completely HOSED the system. There's a lesson in there somewhere, about not enforcing something that doesn't really matter.

Rapid Rails with Hobo (Free from the Hobo site)


upnishad said...

Dont know where "Gemfile.create" file is. Or is it Gemfile.lock ?

Jersey Boy said...

You're right -- thanks for the edit. "Gemfile.create" was wrong, and "Gemfile.lock" is where the fix was made.

Aditya said...

The new way to fixing this problem is to update bundler to version 1.0.7 then running bundle install in your repository again.

gem update bundler
gem list bundler # see version 1.0.7 in use
cd /path/to/app
bundle install
git diff # see difference
git commit -m "fixed Gemfile.lock with new bunlder version"
git push heroku

Jersey Boy said...

Interesting. Thanks!

My analysis was based on the thought that Heroku had its own version (1.0.3), rather than using the one pushed in my own git repository.

While I don't expect things to fail miserably just because of a version number, I wonder how updating the local version fixes it? If it fixes the problem by not complaining at all about version discrepancies, that is a bit surprising in itself.

Or is it that the Heroku copy is what happened to be checked into git initially, and my updated 1.0.6, not having been checked into git, never got pushed either?

Jersey Boy said...

Aditya, there appears to be a missing git add step.