As you may already know, you can open a file from the command line using the “open” command. The file will be opened using the default application for the file type. For example, running “open spreadsheet.xls” will open that file in Numbers or Excel, and running “open” on a directory will open that directory in a new Finder window. Think of it as a double click from the command line.

However, while working in the terminal today, I found myself wanting to open a spreadsheet using Quick Look just to get a single value. There’s a command called “qlmanage” that allows you to open the Quick Look preview of a file using the -p option. To make it more convenient, I created a short executable shell script called “ql” and put it in a directory that’s in my $PATH:

#!/bin/sh

# Display the Quick Look preview for the given file.

if [ -z "$1" ] ; then
  echo "Usage: ql ”
  exit 1
fi

exec qlmanage -p $1 2> /dev/null

Now I can preview a spreadsheet (or any file) from the command line using “ql spreadsheet.xls”. To close the preview, just hit Ctrl-C.

They’ve just released a new promotional video that they’re showing during Jack Johnson’s world tour. I love Tyler Stableford’s photography, and the soundtrack is great too (Matt Costa):

Since our first day in business, West Arete Computing has been proud to be a member of 1% For The Planet (we’re member #97). It’s great knowing that every project that we’ve ever worked on has resulted in more funding for some of our favorite nonprofit environmental organizations.

It’s been a privilege knowing the people at 1% For The Planet for the past few years. You’ll never find a more driven, energetic, fascinating group of people. It’s been thrilling to watch how much the movement has taken off recently — there are more than 900 member companies now.

Keep your eye out for the 1% For The Planet logo. I keep on finding it in places that I didn’t expect. It’s great to see it on things that you’ve been buying for years.

It’s also great to go to work each day knowing that part of that effort goes towards keeping central Pennsylvania beautiful.

Tom gave me a ring a few days before leaving for his trip to see if we could put together a quick program for his laptop. He had a set of barometers/thermometers that connected to the USB port on his Windows laptop, and he wanted us to write some software to read the data from the devices and record it. He also wanted to ensure that it could all run unattended, and that it would maximize battery life. We also had to be 100% sure that the program would work properly, since he would hardly have any outside contact once he entered the desert.

Using the specifications from the manufacturer, we put together a Ruby program to talk to the devices and record the data (we used the ruby-serialport gem, if you’re wondering how). Getting the timing right with the devices was the only tricky part — they were very picky about how much time elapsed between sending and receiving each character, and between sending a command and retrieving the response.

To save power, we set up the code and data on a flash drive so it wouldn’t use the hard drive. We then set up a power scheme that would keep the computer running, but would shut down the hard drive, display, and allow the machine to keep running with the lid closed (essential for keeping out dust and sand).

All in all, we had everything developed, tested, and installed in about 24 hours.

After hearing about what his trip was going to entail, we also set up a blog for him to write about his experiences. He’s been writing some great stories and taking a lot of amazing pictures. I’m really struck by how similar some of the desert pictures are to the ones from the Mars rovers!

I highly recommend checking out the Stratamodel blog. Also be sure to check out the Stratamodel photo stream on flickr. Great material. Have a great trip Tom!

Take a look, download the code, open it in your editor, and run it (Apple-R in TextMate). Mess around with it.

Did I miss anything? Did I get anything wrong? Post your comments and questions in the comments below.

I know that sounds terrible, but consider the following example. We were recently writing a class to parse a known set of data that didn’t include any whitespace between tokens. Our one-time class worked great for this particular data set, and we didn’t anticipate having to use it on another data set. However, if you were to pass it similar data that did have whitespace between tokens, then you wouldn’t get the desired output.

We could have spent a bunch of time expanding the class to handle whitespace properly, but we quickly realized that this would have doubled the development time for the class, all for adding a feature that we weren’t going to use.

Instead, we added some anti-specs for the class that documented the undesirable behavior:

  describe "Unfortunately, #quote_nodes" do
    it "will preserve whitespace around each node" do
      quote_nodes(" snap , crackle ,( pop )").should == "' snap ',' crackle ',(' pop ')"
    end

    it "will quote whitespace as a node if it appears between delimiters" do
      quote_nodes(" , , ( ) ").should == "' ',' ',' '(' ')' '"
    end
  end

Note how instead of the usual RSpec phrasing, e.g. “#quote_nodes … should put single quotes around each node”, we start the context with “Unfortunately” to immediately tell the reader that this is undesirable behavior, and we use the word “will” instead of “should” to tell you that this isn’t what we would want in an ideal world, but it’s what we’re getting anyway. You wind up with spec docs that clearly document the good and the bad:

#quote_nodes:
- should put single quotes around each node
- should quote nested nodes too
- should only treat parentheses and commas as delimiters
- should preserve whitespace within nodes

Unfortunately, #quote_nodes:
- will preserve whitespace around each node
- will quote whitespace as a node if it's between delimiters

Down the road, we may wind up re-using this code in another application. If we need to fix the bad behavior, we can simply modify the specs to document the new desired behavior, and then add the additional code to properly handle whitespace and make the tests pass.

I didn’t see anyone else writing about this use of RSpec, but we’ve found it to be useful for these somewhat rare cases.

There’s no reason why you couldn’t do this with Test::Unit and have “anti-tests”, but I particuarly like the phrasing that you get to use with a BDD framework such as RSpec or shoulda.

This is on a Xen virtual server and memory is somewhat limited (256MB). Both rsync and restore took *way* too much memory. Rsync would have required many gigabytes of memory, and restore required at least a couple. Restore also required a large amount of temporary disk space (a couple gigabytes) for storing permissions and mode information. In the end, the good old tar command was the highest-performance method, consuming about 150MB of memory at its peak for the restore. The bash command line was:

  (cd /data && tar -c -p -f - .) | (cd /data2 && tar -x -p -f -)

Tar is dependent on the current directory for its context, so I used a subshell around each command to ensure that they were in the right directory. I could have used semicolons to separate the “cd” command from the “tar” command in each subshell, but then the “tar” would have proceeded whether or not the “cd” was successful (for example if I had made a typo in the directory name). This would be bad since a failed “cd” before a tar restore could result in all of those files being written and potentially intermingled with the wrong filesystem. Using “&&” to separate the commands ensures that the tar command only proceeds if the “cd” was successful.

  def show
    @dog = Dog.find(params[:id])
  end

an exception is raised if the “id” parameter is omitted (e.g. /dog/show rather than /dog/show/5), and you get a rails application error by default. It seemed like there should be a way to declare that this action requires an “id” parameter of type integer, and provide a graceful way to recover if that constraint isn’t met.

This was something that we had built into our in-house PHP framework long ago, and we had become quite accustomed to it. Such a feature essentially allows you to describe and enforce the interface to your controllers’ actions.

It’s a good exercise to define the set of valid methods and parameters that can be used to call your actions, and it’s very handy to have notification and helpful logging messages for when your constraints aren’t met. It’s the same argument as the one that says that you should carefully consider the interface between your classes.

So I wrote a new plugin called validate_request to easily perform this type of checking, and recover gracefully (and configurably) if the constraints aren’t met. Now you can specify constraints like this:

  def show
    validate_request(:get, :id => :integer) or return
    @dog = Dog.find(params[:id])
  end

and perhaps more importantly like this:

  def update
    validate_request(:post, :id => :integer, :dog => Dog) or return
    @dog = Dog.find(params[:id])
    @dog.update_attributes(params[:dog])
    ...
  end

This way, your argument checking isn’t as tightly coupled to your database schema — attributes can be added and removed from the Dog model, and you won’t have to change your request validation code.

That’s a lot of benefit for only one line of code per action.

You can install the plugin by running the following commands from your rails application’s directory:

  ./script/plugin source svn://rubyforge.org//var/svn/validaterequest/plugins
  ./script/plugin install validate_request

Here are some other resources:

• The RubyForge project page
• The README file
• The USAGE file, which gives more in-depth instructions on how to use validate_request in your code

There are a few items that are on the to-do list, such as support for aspects in RESTful URLs, and what amounts to enumerated types.

Let me know how things work out for you.

For small installations, it turns out that it can be quite sufficient to run a single mongrel daemon behind Apache 2.0 and plain old mod_proxy, all on one machine. No, you won’t get high concurrency, and you won’t be able to load balance across machines, but it’s an incredibly simple, stable setup that can have your rails app up and running without mucking around with upgrading your web server or installing foreign RPMs.

Here are the prerequisites:

• You have apache 2.0 already installed and running.
• If you’re on a shared host, you’ve been assigned a high-numbered port to use for mongrel to listen on (just file a support ticket requesting this).
• You’ve followed one of the other tutorials online to verify that you can get a single mongrel instance running (even by hand) for your rails application on your high-numbered port on the same machine as the apache server.

From here on out, let’s presume the following. Substitute appropriately in the examples:

1. The website that you’re developing is example.com
2. Your high-numbered port is 4000

Go ahead and start up mongrel in production mode on your server. If you’re doing it by hand, you’ll probably use a command like:

    $ cd /var/www/domains/example.com/current/
    $ mongrel_rails start -e production -p 4000

Now you should be able to visit http://example.com/4000, and see your rails application. If you get a rails application error, check your production rails log and the mongrel log to see what’s going wrong. Make sure you’ve set up your production database (and production stanza in database.yml) properly. You might also have trouble if the host in question has firewalled the high-numbered ports, and your browser is running on a different machine. In that case, you can use the command-line web client “curl” on the server itself to request the page:

    $ curl http://localhost:4000/

It should spit out the HTML of example.com’s home page.

Once you’re sure that mongrel is running properly on port 4000, we’re ready to use apache to proxy requests back to it, so that you can access the site without the port number.

If you’re using virtual hosts, this is the stanza that you can use in your httpd.conf file:

    <VirtualHost *:80>
        ServerName example.com
        ProxyPass / http://localhost:4000/
        ProxyPassReverse / http://localhost:4000/
    </VirtualHost>

This simply tells apache that for requests that are destinted for example.com, proxy them to port 4000 on the localhost, which is where mongrel is running.

After checking and reloading your apache configuration, your site should now be available on http://example.com/

Making It Stick

The site’s running, but if the server reboots, mongrel may not be set up to restart automatically, so nothing will be serving your rails site. You’ll probably want to create a startup script that starts your mongrel servers on boot. My startup script contains a line like this for each site:

mongrel_rails start -e production -d -a 127.0.0.1 --user mongrel --group mongrel -p 4000 -c /var/www/domains/mydomain.com/current

Some things above are worth mentioning:

• It would be nicer to use a mongrel config file to store this information, rather than specifying it all on the command line. Unfortunately, I couldn’t seem to get the config files to work — mongrel would always ignore them. I eventually retreated to command-line options again.
• -a 127.0.0.1 tells mongrel to only accept requests from localhost. We don’t need to allow outsiders to access port 4000.
• (Extra credit) It’s a good idea to run your services under their own account for security reasons. Mongrel supports this via the –user and –group options. I created a “mongrel” user and group, and then make sure that that user can read but not write to the source files. You also can give the mongrel user ownership of the directories that it needs to write to (log and sessions), rather than making those directories world-writable.
• The -c option tells mongrel which directory to “cd” to before it starts, so this points to the rails application directory.