Redo: Making HMAC Hashes in Ruby

This is a post from May 5th, 2007 that was on my old blog. I let it go a while back and have now started blogging again. I’m posting this article again because it may still be useful for some people. It’s actually still generating traffic to my domain!

I was trying to make a quick little Ruby script for Authorize.net SIM for one of my clients and became really annoyed trying to find a flipping document, tutorial or README on HMAC for Ruby. I eventually found something rather unrelated to what I am doing but had the little piece of code that saved my life that day.

OpenSSL::HMAC.hexdigest(OpenSSL::Digest::Digest.new('md5'), key, data)

How handy, HMAC lives right inside Ruby’s OpenSSL libraries—just fill in the key and data variables. Before I found this I tried installing HMAC Libraries directly but with no luck obviously. It still amazes me how little documentation is out there for HMAC with Ruby.

Why The ‘Don’t Touch That Framework!’ Mentality is not Pragmatic or Agile

I recently came across another framework sanctity nazi over IRC. You know the guys that freak out when you mention changing a core class or customizing what gets loaded by default or other things specific to your app. Oh, you are one too? Well maybe if stick around and read further with an open mind I can help you see things from a pragmatic perspective. 

First off most new programmers or even somewhat experienced engineers should not go around messing with things in the framework classes for the hell of it. Also you should try to see if there is a straight forward way of doing what you need to do without changing framework code. It’s always best to just change a controller or the configuration if it makes sense that way. Even if there is only a not so straight forward way of completing a task without touching the framework you should weigh it out and try to avoid changing the framework.

The But…

However, if the solution costs about 3 minutes to change the framework and 3 hours to avoid changing the framework then there might be a good reason to just change the framework. For instance lets say we have are a building a web app. The web app needs to do (or not do) something on every request…no matter what. Sure I could change something outside the framework to get the app to work that way. But that is bad on many levels. First off, if someone down the road wants to change that global behavior, she will most likely look at the framework first…since it is global. Secondly, you will spend much more time testing and bug-fixing to make sure your non-framework-touching change really did work globally. That’s certainly not pragmatic.

Also, if you are working in an agile environment on a new project and are trying to make quick iterations you don’t want to spend 3 hours on something that could have taken 3 minutes just because you don’t want to touch the framework. You can always fine tune things later and refactor your code when you get to the launch phase. You can use litter markers like @todo and search for those areas you have been meaning to refactor when it makes sense to…but right now just iterate so you know you are building what they want in the first place. 

Of course you can ignore the logic I pose here and continue on your path of perfectionism and framework sanctity. Or you could get stuff done. 

Making Ubuntu Usable Again - Cleaning up the Natty Unity Mess

The Unity interface is plagued by bugs and for many people it is completely unintuitive. I gave Unity an honest chance but things I used so often were hidden and other things I never used got in the way. My first thought was to go back to Ubuntu GNOME or Classic as it is now known in the Ubuntu world. This is also plagued by one very annoying bug: it randomly switches your preferences to an ugly interface circa 1995. I found myself restarting gnome every hour or so…not exactly my definition of productive. 

Time to shop for desktop environments

The most popular alternative is of course KDE and since Linus Trovalds thinks it’s the best without further explanation than it must be the way to go. Well not so much unless you like a very Windows-y interface and you like to wait 20 minutes for your desktop environment to load after you log in. So I took the risk of going against the self proclaimed god of open source, software and know-it-all-ness and tried XFCE/Xubuntu. It’s a very easy change:

sudo apt-get install xubuntu-desktop

XFCE looks good, is as configurable as GNOME and even faster and more lightweight than gnome. I have no complaints and it does everything I need it to and nothing that would annoy me. I did not like the way the panels were configured at first but it took me about 5 minutes to configure it to my preferences. The window theme was a bit too bright for me as well so I just changed the theme to Albatross and I could not be happier. Best of all there are no major bugs  (or minor bugs that I noticed) and it does not get in your way.

If you want a desktop environment to stay out of your way so you can continue to get work done I suggest you try it as an alternative to Unity/Gnome/KDE.

Dragonfly resting on a plant