I recently bought a new PC and have been installing a bright sparkly new set of 64bit applications and marvelling at the speed of them and highlighting the lack of speed of my brain at the same time.

I was just going through the process of checking out our rails apps and getting them up and running when I hit on issues with rails connecting to 64bit mysql using the mysql gem.

The error it showed was:

193: %1 is not a valid Win32 application

After trying a lot of different solutions, this one finally worked. Wonderful and simple, courtesy of stackoverflow.com and osdir.com

Simply copy this libmysql.dll file into your ruby/bin directory and hey presto!

Last year I did a contract for a startup consultancy in which I was the only person with IT application know-how, everyone else had plenty of business know-how. This created an interesting situation where the excitement of a startup winning its first client threatened to swamp any IT strategy. The eagerness of the team to see results immediately was a daunting prospect as the previous project I worked on had quarterly releases and teams for dev, testing and deployment! So I had to find a different approach, that’s when I tried a web app framework called Hobo which is a set of plugins on top of Rails.

Hobo does clarify one deviation from RoR regarding Interface First approach. The development starts with sketching the Models rather than designing the interface (“what people see is what you’re selling”), this is explained by an ambitious statement about rewriting the rule because “…Hobo, is actually quicker than creating html designs.”

Hmmm, lets run with it a bit longer….

I created the app, with the hobo command, which looked almost identical to a standard RoR project. So then using a Hobo generator to create the model resources (much like the Rails scaffold generator) gives me controllers and models as you would expect but there are no view files. This is very much like Groovy on Grails where the (default) views (and routes) are generated at runtime and you only override if you want to change them. The Controllers were much leaner, containing just 2 directives to the Hobo framework for the default behaviour and conversely the Models had the field definitions and some Hobo permission methods for access control, so more than usual.

And where were the DB migrations? Well these are created by another Hobo generator which is quite clever. It looks at the Model code and compares it to the DB schema and creates a migration file to get the DB from current state to the new state as defined in the Model. This works for adding, modifying and removing fields in the Model. This turned out to be a life saver as it drastically reduced the turnaround of Model changes so that they could be done during a demo to incorporate some feedback immediately or show other possibilities. Ah that’s fine for flat table structures but what about relationships I hear you say, well it handles those too and even adds indexes where necessary. This allowed me to try out new things quickly in front of the team, safe in the knowledge that I could roll back the code and DB to a working baseline in a couple of clicks (in Netbeans). I liked this feature a lot.

Hobo gives you a lot by default which you can remove or modify very easily. The first to strike me was the default user model created with each Hobo project which allows signup and basic admin such as editing or resending a forgotten password. This together with the permissions I mentioned earlier, specify who can do what to each Model. Also, in dev mode, Hobo displays a “user changer” which allows you to navigate the app and see it from different roles (admin, user and guest roles available by default). You can also specify permissions to maintain data integrity and the UI will reflect the change. E.g. by default you can change the parent of a Model in the UI. If isn’t what is required you can withdraw that permission and the UI will automatically not show the drop down in the edit screen. So when I was asked to make a subset of data/functionality available to certain group of users by the next day, it was possible with Hobo not least, due to this feature.

Another default that is neat is when you want the view of a Model to list its children, it is a simple directive in the view hints file for that Model e.g. children :tasks. What this also does is when viewing a Model that is a child, the parent is shown as a breadcrumb navigation.

Other default behaviour includes pagination and an application wide search facility.

So a little work on the models and controllers and the UI was enough for the team to try out and give feedback and refine the data model … in a matter of days. It was as close to the 80-20 rule as I have seen.

Of course we needed a little more than the default UI but that will wait for another day.

We have been migrating a lot of our apps onto JRuby with a goal of running them on Tomcat on AWS.

One of difficulties in doing that is that we can’t run migrations but need to migrate our database in just the same way you would for a standard rails app.

I searched around assuming there must be a solution and found Jay Fields article Rails Generate SQL from Migrations and also a hint at a tool active_record_io_mode which I could no longer access the source code for.

I had problems making Jay’s code run for certain migrations and not being as smart as him couldn’t fix them so I created a more basic version which is a combination of Jay’s and Mark/Zach’s approach.

I have patched Active Record to do a few things:

• Patch ActiveRecord::Base to store an object which any sql that’s run gets written to
• Patch the AbstractAdapter log_info method to check for that object and write any sql to it (with appropriate separators)
• Patch the Migrator migrate method to create an up or down file for a migration and set that in the object (step 1).

This file just needs placing in lib at the start of your project and then require it in your environment.rb. I’m sure there is a cleaner way to do this.

There are a few limitations of the approach:

• you have to run a migration to get the sql (which really means a migrate/rollback/migrate)
• it’s not been tested far and wide, only on 2.3.5 and using jruby

Still, it helps us and I’m sure we can finess it as we move forward.