In this post I’m going to show you how use ruby-install to build a Debian package of MRI itself, and put together a trivial apt repository so you can serve it on your local network. Why do this? First, you aren’t dependent on ftp.ruby-lang.org being available when you want to deploy. Second, that you don’t waste time during your deployment rebuilding a ruby binary. I’ve seen builds of ruby 2. Read more

In this article I’ll describe the toolset I use to do ruby development. It’s not complicated. It is pleasingly robust. I’ve hacked together a couple of simple tools to make it easier. I do all my development (in fact, all my everything) on Debian stable (currently Wheezy), but everything here should apply equally to Ubuntu and, with a following wind, OS X. ruby-install I install rubies with ruby-install from here. Read more

Over the past few months, I’ve been thinking about when it might be correct to say rescue Exception instead of rescue StandardError, or a more specific exception class. This line of thought was first triggered by a particularly hairy debug session which was made extremely difficult because, unbeknownst to me, some library code did a rescue Exception at the top-level of a Thread, where I was expecting Thread.abort_on_exception to explicitly break and tell me what was happening. Read more

Avdi Grimm has a post on using a shortcut ec script for emacsclient here. I used something like that for a few months, but got quickly frustrated with one peculiar quirk of my development setup. I do the vast majority of my development in ruby, in a terminal window, and almost all of it is TDD using minitest/unit. Now, when I get a test failure, it looks something like this: Read more

Ruby’s Logger class, and the ruby logging ecosystem in general, has grown up with 5 standard log levels: FATAL, ERROR, WARN, INFO and DEBUG. There are no generally accepted guidelines for how these should be used, other than that those “high” on the list should be used in “more serious” situations than those lower down. This is not detailed enough for a useful policy. Better guidelines would mean that your logs would become more predictable and more useful. Read more

When writing a test, sometimes the only way to initially write the test is by duplicating the implementation code in the test to assert that the expected value is returned. This can happen for a number of reasons, but often arises because you are trying to test what is being performed, rather than how it’s being done, especially where the details of what’s being done are complicated and out of your control. Read more