Best way to hack code

For the best part of 4 years now I've been doing the majority of my development on a virtual machine. This allows me to keep my development environment perfectly inline with production, same operating system, exact same package versions etc, and then easily hand that disk image around to other developers who might need to hack on it.

Over the years it seems others agreed. Along came vagrant to make this easier. Along came chef/puppet to make installing the packages easier. My point here is that a lot of people are now using VMs as their dev environment. Your desktop can be whatever the hell you want, since your code runs somewhere else. You can easily swap from one project to another without having to worry about that legacy project not working on your nice, up to date desktop.

I've also been using vim as my editor of choice for the past 13 years. I've dabbled with things like UltraEdit, Notepad++, TextMate, E-Editor, SublimeText 2 and I always palmed them off for whatever reason. I decided to check that style of developing out again and I've really come to like it.

TextMate (and in turn E-Editor since it supports all of TextMates plugins) and SublimeText have built quite a large community around them now and plenty of people are writing nice plugins so you can do all kinds of things right inside your text editor. With vim there are certain things I've been doing for years, that these newer editors can now do as well due to the work of these plugins. I'm talking things like git diff/status, compile check this selection of code or entire file. Run this selection through some sort of lint program etc.

However, the desktop editors can only do this if the machine you are using the editor on has the right stuff installed. Due to the VM dilemna mentioned above, the only place that can truly run any kind of proper compile checks or test runs and the likes, is the VM itself. Unfortunately none of the editors mentioned above have the functionality to run commands over SSH, all the plugins etc are just written to run whatever locally. This seems short sighted to me, as mentioned it seems a lot of people are going the VM route.

Cue X-Forwarding. It's a pain to install libgtk on a base VM that just runs ruby code, but I figured I'd try it out. This way I can run the editor directly on the VM and have the output on my desktop. All good in theory. Unfortunately SublimeText runs like an absolute dog over SSH for some reason. Time to start toying with other X based IDEs such as gVim? Or throw my mouse away and start writing more helpful vim macros?

Upgrading to Rails 3 - Part 1

So it's been about 4 years since we wrote CushyCMS in rails 2.1.3. Over the years it eventually got upgraded through 2.2 and 2.3 and is now running on the latest stable version in the 2.3 tree. But as we all know, leaving a site behind will only bite you later when you want to add new features but can't use new gems or find help for your old code etc etc. The smart thing to do is to upgrade to rails 3.

I figured a staggered approach would be best. I'll upgrade to rails 3.0.12, then 3.1.x and then 3.2.x if I still have any motivation left by the time I finish. Making sure everything still works and tests still pass at each step. Should be pretty easy right? There are a tonne of guides and railscasts out there on how to smoothly transition. Wrong.

I marked this blog post as Part 1, even though I don't even know what will go in Part 2, I'm sure there will be a need for one. Let's just start listing the problems I've already endured in the supposedly simple upgrade.

• helpers :all is now on by default. Rails 3.1 has a way of disabling it, but Rails 3.0 does not. This is only a problem if you have a collision in your helper names, which we do, and so do many others according to a quick google search.
• default_url_options is no longer passed a Hash of options that include the controller/action for which the URL is currently being generated. Meaning you can't easily come up with some "default URL options" for a specific route.
• content_tag(:div, '') returns you an ActiveSupport::SafeBuffer instance, which is html_safe, and if you concat a string on the end of it, it will still be html_safe providing said string doesn't have HTML tags in it. However if you concat in the opposite direction, the same is not true. E.g. ('' + content_tag(:div)).html_safe? != (content_tag(:div) + '').html_safe?.
• I18n translations now use %{} as the interpolation mechanism instead of {{}}
• I18n translations require the phrase key to end in "_html" if you want them to be html_safe?. If you host your translations elsewhere, then this is not something that can be easily updated en masse.

Now this is just a list of what I would consider non-standard issues I've hit. There are of course a bunch more "standard" issues that most people will already know about and are usually covered by the guides out there that help you upgrade. Such as:

• ActionMailer has completely changed it's API and you will need to rewrite your entire Notifier models.
• error_messages_for has been completely removed, with no replacement built in.
• You will need to completely rewrite your routes.rb file from scratch.
• If you're using any plugins/gems (and let's face it, who isn't), more than likely you will need to upgrade them along with rails. If you're lucky, they will be well maintained and not have any API changes. I can assure you, I was not so lucky. At least 50% of the plugins we use are no longer maintained and don't work in Rails 3.0. Yay. 

In short. To anyone out there thinking it's going to be easy to upgrade. Think again.