Archive for the 'software' Category

Introducing Statim


I just push Statim, a very simple static site generator that I’ve worked on the past couple days. It is written in shell as an attempt to limit run-time dependencies so that it can be used on pretty much any Unix server. I more or less wanted a simple site generator that I could trigger on a git hook to build a website where I was less concerned about looks, and just wanted a quick way to push up information.

Currently running statim does the following:

  1. Copies all files from the content directory to the destination directory of your choice
  2. Runs any files ending in “.md” or “.markdown” through the “markdown” command and relocates the resulting html
  3. For each subdirectory it creates links based on file names and camel-casing conventions (like a wiki)
    • There’s nothing super complicated or revolutionary here, its just a simple tool for me because none of the others did what I wanted.

Ruby Development Woes


After getting back into the flow of things post vacation I decided it was about time to put something up on my blog. A few days ago one of the Debian ruby package maintainers quit with a post detailing what he found to be some current problems with the Ruby community. As someone who works mostly in Ruby I share some of his opinions, albeit for different reasons.

To me the biggest problem with the Ruby development community is also its greatest strength. In the Ruby ecosystem nearly everything is optimized for the developer. What do I mean by this? Let’s look at it from the example of a couple of of the conclusions reached in the above-mentioned post.

The core Ruby development community should mature

One of my favorite things about being a Ruby programmer is how fast it is to code, package and distribute a library. Seriously, look at the front page of

gem update --system
gem build foo.gemspec
gem push foo-1.0.0.gem

Just run these commands and you have released your code and anyone else can easily search for and install it on their system.

However, I think this process is often too easy. It seems very frequent that versions of gems are pushed before they are completely finished resulting in quick second versions release immediately after the first. Even worse, since a developer can share their project so easily version are often pushed in a “good enough” state and never reach major releases. Rake &emdash; the standard for Ruby project build scripts; used in pretty much any Ruby project you’ll come across &emdash; is still on version 0.8.7!? (That’s not to say that Rake isn’t stable software, I’m just pointing out how common it is for a Ruby developer to use libraries and tools that haven’t even reached their first major release and not even think about it).

I’m guilty of this myself. Pretty much everything that I’ve pushed out to rubygems was nowhere near complete. I just pushed it out because it was the easiest way to share it with my friends/co-workers and it was “good enough” for our purposes.

In addition to this, it is very difficult to judge the quality of any library you will see on rubygems. Does this gem being version “0.1.0” mean that it is incomplete, or are they just judicious in their versioning? This isn’t a problem unique to Ruby, but the easy of releasing Ruby packages certainly exacerbates the issue.

The Ruby community should acknowledge that RVM and Rubygems are not for everybody

RVM and Rubygems make my life much easier. I can search for gems to help me write applications I’m working on, isolate them from the rest of my system, and test against multiple versions or Ruby very easily. However, RVM and Rubygems do make somethings more complicated for an average user.

If I want to install an application written in Ruby, I shouldn’t have to install compilers and package managements tools. I want to be able to install a Ruby application and not worry about which ruby/gemset RVM is currently pointed at. These tools are fantastic when you are developing and manageable when your used to them, but if you want to just use a Ruby application without understanding the whole standard development environment they can be a pain in the butt.

What’s the point?

These problems aren’t a huge deal, but it is frustrating to see people claim an argument has no validity because the environment works for them. The Ruby community seems to rush to defend everything that gains popularity without really thinking through the repercussions for people in different situations. It’s this eagerness that drives me to Ruby development, but at time I think this eagerness that will send others rushing away.

Testing mobile sites with Cucumber


Recently I was working on a site that had been originally built with Rails 2 and was later migrated to Rails 3. As part of the migration the cucumber integration tests were switched from using Webrat to drive the UI to using Capybara. Unfortunately this broke a handful of tests for the mobile version of the UI.

Take One

The site decides whether or not to show the user the mobile version of the site based on the user agent. The problem is that Capybara won’t let you set custom headers (such as the user agent) the Webrat will. After a quick search of the internet I can across This site. In short the blog post details a way to open up the current RackTest driver (the default driver that cucumber uses) and adds a way to put in arbitrary headers.

I added the code in the blog post to my project and indeed it fixed my tests (with a little reorganizing). Something about it struck me as wrong. Even the blog post I got the technique from calls the class a “Hack.” I wanted to find a cleaner way…

Introducing capybara-iphone

My “cleaner” solution was to write a new Capybara driver that pretends to be an IPhone and to have the mobile specific tests run with that. It is a very simple project that extends the Capybara::Driver::RackTest code and adds an additional user agent header to identify itself as an IPhone. Now all you have to do is set up the capybara-iphone gem in your project and tag the tests that you want to run the a mobile browser with ‘@iphone’.

The Future

One could imagine an incarnation of capybara-iphone that adds support for handling that IPhone specific javascript calls, and lets you do other things that better test your application’s IPhone interface. At the moment, however, I don’t have plans to do any of these, but the project sounds fun enough that with a little push I might start working on it.

More information on using capybara-iphone can be found in the Readme on Github.


Get every new post delivered to your Inbox.