Flashback to 2007: Migrations Constraints

Whoa. Guess what I found?

An old Ruby-on-Rails plugin I put up on RubyForge way back in 2007, that, get this—added the ability to declare constraints during ActiveRecord migrations.

Migrations Constraints is a Rails plugin that allows creation and management of database constraints such as uniqueness and referential integrity (foreign keys) using ActiveRecord Migrations.


The neat thing is that, except for foreign keys, it actually provided the same syntax that ActiveRecord migrations currently uses!

Not saying that my project influenced ActiveRecord, but it’s pleasing to know how my design fell in-line with Rails core. 🙂

This just inspires me to publish more of my Ruby/Rails reusable code as Ruby gems or Railties or Rails Plugins/Engines.

Steam on Mac, case-sensitive workaround

So, Steam for OS X just went live.


Then they announce Portal is FREE! (until May 24th, 2010 at least).


So I download the Steam .dmg to my Mac, copy Steam over to /Applications, try to run it, and promptly get:

Steam requires that Steam.app/Contents/MacOS be created on a case-insensitive file system, with read-write access.



(I mean, why couldn’t they have ported the thing properly and made sure the paths/file names in the code were all lower case or something?)

You know—there are people who like case-sensitive file systems because it forces them to be more careful with how they code. You know—not every file system is like, FAT32 where “readme.txt”, “README.TXT” and “ReadMe.tXt” all refer to the same file!

Anyway—while I love to rant, I also like to fix things. So here goes:

1. Create a new partition, formatted simply as Mac OS Extended (Journaled)

Note—NOT case-sensitive. I made mine 10GB, and labeled it steam. Fortunately, Disk Utility lets us play around with partitions. Who needs Partition Magic?

2. Copy Steam.app to the new partition

But wait, there’s more! If you try to run Steam now, it’ll complain about ~/Library/Application Support/Steam (and later, ~/Documents/Steam Content). Hang in there with me for a second.

3. Create the necessary folders on your new partition

I ended up creating /Application Support/Steam and /Documents/Steam Content on the steam volume.

4. Create symbolic links to these new folders from where Steam looks for them

First make sure that the folders ~/Library/Application Support/Steam and ~/Documents/Steam Content don’t exist yet (the Steam app will try to create these for you). If they do, just delete them.

Time for some Terminal magic. Run Terminal, and go

cd ~/Library/Application\ Support/
ln -ns /Volumes/steam/Application\ Support/Steam/ Steam
cd ~/Documents
ln -ns /Volumes/steam/Documents/Steam\ Content/ "Steam Content"
sudo ln -s /Volumes/ /volumes

The last line will require you to enter your administrator password. I just added that in courtesy of Josh Anderson’s own post. Without that other symbolic link, it seems Steam will have trouble finding the content/games it’s already downloaded.

5. Run Steam.

6. Download Portal

7. …

8. Profit!

You’re welcome.

Added: Also, here’s another workaround by Josh Anderson that doesn’t require you to create a new partition, but uses a case-insensitive disk image instead.

A Simple, Efficient P(n,k) Algorithm

Jeffrey A. Johnson’s SEPA: A Simple, Efficient Permutation Algorithm is indeed a fast and simple way to generate all the permutations of n items or P(n) in lexicographic order. In this article, I describe a similar algorithm for generating partial permutations of n items taken k at a time, which we denote as P(n, k).

SEPA Explained

Johnson discovered that a set of logical steps could be taken from one permutation to the next. Repeatedly calling the algorithm on the last output obtained generates all permutations in sorted order.

It works by first scanning for the rightmost ascent or pair of numbers where the first number is less than the one immediately after it.

Table 1: P(5)17..24 with rightmost ascents highlighted.
Pi a0 a1 a2 a3 a4
17 0 3 4 2 1
18 0 4 1 2 3
19 0 4 1 3 2
20 0 4 2 1 3
21 0 4 2 3 1
22 0 4 3 1 2
23 0 4 3 2 1
24 1 0 2 3 4

If no ascent is found, then all numbers are in descending order and this is the last, lexicographic permutation.

Otherwise, the number at the start of the ascent is swapped with the smallest higher number to its right.

Table 2: P'(5)17..24 after swaps (in red). Highlighted cells are about to be reversed.
P’i a0 a1 a2 a3 a4
17′ 0 4 3 2 1
18′ 0 4 1 3 2
19′ 0 4 2 3 1
20′ 0 4 2 3 1
21′ 0 4 2 3 1
22′ 0 4 3 2 1
23′ 1 4 3 2 0
24′ 1 0 2 4 3

Finally, all the numbers to the right (which will be in descending order) are ‘flipped’ or reversed (to ascending order). The resulting array is the next permutation.

P(n) to P(n,k)

To begin generating P(n,k), let’s take a look at the first few permutations of 5 elements taken 3 at a time, P(5,3) and compare this with P(5):

Continue reading

Functional HTTP testing revisited using JUnit 4.7 Interceptors

(I originally planned this to be a single article, but because of the scope decided to split it into two parts. Read the first part for the the basics of using Sun’s HttpServer to conduct functional HTTP testing. Here we revisit our functional test and rewrite it using JUnit 4.7’s new Interceptors feature.)


In my previous post, I demonstrated how to use Sun’s HttpServer API to write a functional test of an HTTP ‘conversation’.

Recall that I thought my initial solution seemed inelegant. It was verbose, with some start up and shutdown code that would have to be repeated for each test, and which I felt cluttered the actual test code.

It was also tedious, in the sense that the raw HttpHandler and HttpExchange API required us to do quite a few things manually, and unintuitively (such as having to compute and write out the length of our response before the response itself).

In this post, we’ll explore how to use the new Interceptors feature ‘quietly’ released with JUnit 4.7 to write reusable, portable pre and post-test behaviour. I’ll also exhibit a convenient HttpHandler implementation that simplifies some of the effort required in responding to HTTP requests.

Continue reading

Using Sun Java 6 HttpServer to write a functional HTTP test

(I originally planned this to be a single article, but because of the scope decided to split it into two parts. This first part explores the basics of using Sun’s HttpServer to conduct functional HTTP testing. Part 2 revisits the following test using JUnit 4.7’s new interceptors (rules) feature and demonstrates a simpler HTTP handler.)


At work, we recently had the need to perform functional testing of a custom client that used HTTP as a transport. This isn’t strictly unit testing since we’re conducting actual HTTP over a socket & port instead of stubbing out or mocking the server, but in this case that was the only real way to test the client.

I could’ve fired up a standalone Web server and used that, but decided against it for a couple of reasons.

First, I wanted to have the server respond in a specific way to a particular client request. For example, if the request was for GET /1234.xml I might want to respond with an HTTP 200 and an XML response body. Another request for GET /0.xml might return an HTTP 404 instead.

To do that using, say, a Servlet container would mean writing multiple Servlets (mapped to various request URI) or a ‘rich’ Servlet with additional complexity. I didn’t want to have to write tests to test my test scaffolding!

Secondly, a standalone server would have to be started and stopped outside of our standard compile/test/package process (using Maven). Other people wouldn’t be able to run the tests successfully without having the test server up as well.

Clearly, the best way to go was to use an embedded HTTP server, which would allow us to provide specific responses tailored for each unit test.

As luck would have it, it turns out that Sun’s Java 6 implementation comes with a lightweight HTTP server API built in. Read on as I demonstrate the basic use of Sun’s HTTP server classes to write a functional test.

Continue reading

Ruby script to install JFace JARs into your local Maven repository

After figuring out how to use Maven to write SWT applications, I figured it was time to tackle JFace.

If you read through the JFace wiki page above, though, it says that to use JFace + SWT outside of Eclipse we basically have to locate several dependencies, namely:

  • org.eclipse.core.commands_<version info>.jar
  • org.eclipse.equinox.common_<version info>.jar
  • org.eclipse.jface_<version info>.jar
  • org.eclipse.osgi_<version info>.jar
  • org.eclipse.ui.workbench_<version info>.jar

All of these are available in the standard installation of Eclipse IDE in the ${ECLIPSE_HOME}/plugins directory.

Now, it would be a 10 minute job to manually search for, copy and paste the actual JAR filenames and execute the Maven commands to install those into the local repository with proper group and artifact ids.

Since I’m ‘lazy’, though, instead of 10 minutes I decided to spend a couple of hours writing a Ruby script to do this all for me (I originally started to write it in bash but I realized it’d be a lot easier in Ruby).

Here it is. Continue reading

Writing Eclipse SWT apps using Maven

I’ve been trying to get my feet wet writing code for the Eclipse platform. I figured a good first step is to become familiar with Eclipse SWT—the Standard Widget Toolkit, and work my way up from there.

Since I use Maven, I had to struggle a bit finding out how to configure my Maven project properly so that it’ll build an SWT app that’ll run both under Eclipse and from the terminal.

A little Googling brought me to Brice Lambi’s post on Maven SWT builds, but that was a little outdated.

In particular (and only after careful reading), the guide to Deploying SWT apps on Mac OS X says that the -Djava.library.path=.. option is needed for Eclipse 3.2.2 and earlier. Apparently, starting with 3.4 all you need is your OS-specific JAR (see here).

Anyway, after much fiddling about, I was able to get it all working like so: Continue reading

ActiveTest – Instantiation, mocking, and injection for the lazy

David Saff wrote in on Introducing MagicTest, asking why not just instantiate the variable in-line (private Foo foo = new Foo();).

Which brings me to the real reason for coming up with MagicTestActiveTest.

A code sample is worth a thousand words. Suppose we have a Spring JPA data access object:

public class WidgetDao extends JpaDaoSupport {

  public WidgetDao(final EntityManager entityManager) {

  public Widget find(long id) {
    return getJpaTemplate().find(Widget.class, id);


WidgetDao needs a JPA EntityManager provided to it at construction time. Normally, to write a unit test for WidgetDao we’d have to create our mock objects and setup our test scaffolding manually.

Using ActiveTest, however, all we need to write is:

public class WidgetDaoTest extends ActiveTest<WidgetDao> {

  private WidgetDao widgetDao;

  private EntityManager em;

  public void testFind() {
    Mockito.verify(em).find(Widget.class, 42);


I’m lazy like that.
Continue reading

Introducing MagicTest

If you’ve written enough JUnit 4 tests, then you should be familiar with code that looks like:

public class FooTest {

  private Foo foo;

  public void setUp() {
    foo = new Foo();

  public void testBar() {

Now, how often have you wished it were possible to simply go straight to @Test, do not pass setUp(), do not have to new Foo()?

Introducing MagicTest

So I came up with MagicTest, a parameterized base class for JUnit 4 tests that’ll let us do just that. Continue reading