Updated: 6/6/2012 This blog post is out of date, and the software referenced in it, Strip Sync, has been discontinued in favor of Strip for Windows and Strip for OS X.

Update: Fixed bad link to the beta sign up.

As many of our customers have noticed, Strip Sync is still in beta (you can sign up here). We have a few finishing touches to work out and a final set of builds to run through the beta before we declare it official. Y.T. has to update the documentation, as well. We are planning to do a public release early next week.

I’ve just pushed an update to Strip Sync for Mac OS X (0.2.2), that we hope is a good if not final release candidate for that version. An update to Strip Sync for Windows is on the way to resolve many of the data import issues that were discovered in the last build (turns out that an MSFT data adapter was behaving somewhat badly, and we’ve got a fix on the way). This next update of the applications also provides a minor bug fix for multi-device replication.

Both the Mac OS X and Windows versions of Strip Sync automatically check for signed updates, so you should only need to run the software and you’ll be asked if you’d like to download the latest and greatest.

Recently I visited Mohit Muthanna’s blog 0xFE for the first time (a great nerd tech read, subscribed!) and came across this post about his new favorite font for programming, Raph Levien’s Inconsolata:

It’s super, super snazzy. Switched both TextMate and XCode over to it as my default, it’s quite pleasant. I’m not exactly a typography connoisseur, and while I’ve looked at other mono-space fonts before as an alternative to my usual default of Monaco, this is the first I was ever tempted to really switch.

Also, it’s free. Apparently, variants of the font are breeding rapidly, although I’m not feeling any of them in particular. Also, I don’t need straight-quotes, I think the quotes look just fantastic:

Many thanks to Raph for making this available! Check out the aforementioned home page, this Google engineer is quite an interesting character!

The 2008 and 2009 results are listed, too. If you code in Ruby, you should fill it out and have a look at the previous stats!

Among the expected results are that Rails appears to be pulling more users away from Merb, due probably to Rails 3 being the merger of the two frameworks. Also, readership of the pickaxe is down, but only a little.

Meanwhile, I continue to be surprised by how few people use Haml! I just assumed that because it was so easy and that I personally found it such an important tool, that everyone else would, too. Well, shows me!

Perhaps the auto-completing short-cuts that many folks use for HTML and ERB make this a non-issue. But I can’t stand to write ERB anymore. Grumble, grumble.

Rack::Zetetic::Campaign

A Rack-based URL Shortener for Link Tracking

If you’re like us and you like to send out a newsletter once in a while about one of your new products – in particular if you’re running promotional ad campaigns and your own marketing efforts – you’ve probably tried tacking on Google’s various utm_.* variables to the URLs you are sending people. These are really handy in that Google’s analytics code looks for these when users visit your website, allowing you to start tracking which of your ads, promos, and newsletters is performing well, and which are bombing.

The only problem with this is that you end up trying to put links like this into emails, and they’re long enough to be problematic on display, in particular in plain-text emails:

Write a blog post about Strip telling us what you like and 
what you don't like, and we'll hook you up with a candy-
bar! Click here to learn more: (not an actual link)

http://getstrip.com/promos/blogging?utm_medium=email&utm_term=&utm_campaign=new+promotional+offer&utm_content=textlink&utm_source=newsletter&

We’ve all seen emails where that URL gets garbled and cut into two lines.

What we used to do for this was to employ a URL shortener like bit.ly or tinyurl.com, resulting in links like http://bit.ly/abc123. This solves the problem of munging, but brings on two new problems: your links are dependent on bit.ly always being available and working correctly, and they’re not always easy to “fix” once they’re out there. In particular if you decide to change up the various UTM variables you’re sending to Google Analytics. PITA.

Suffice it to say, many sites are choosing to implement their own URL shorteners to ensure their carefully crafted links don’t rot, and we decided that we’d do ours as a tiny Rack application with a YAML file:

# Rack-up config
require 'rubygems'
require 'rack/zetetic/rack-campaign'
run Rack::Zetetic::Campaign.new('/path/to/your/campaigns.yml')

To install:

gem install rack-campaign

Here we list our campaigns out in YAML:

blog-rack-campaign:
  url: http://dev.zetetic.net/blog/2010/06/11/introducing-rack-campaign
  tokens:
    campaign: rack-campaign
    source: blog
    medium: internets
    content: example link

blog-getstrip:
  url: http://getstrip.com
  tokens:
    campaign: rack-campaign
    source: blog
    medium: internets
    term: strip rocks!
    content: example link

At the top level of our Nginx config, we define an upstream directive for Unicorn, which will host our Rack application over a unix socket (mwahahaha):

# define upstream for campaign routing
upstream campaigns {
  server unix:/www/campaigns/tmp/sockets/unicorn.sock;
}

Then, in each of our Nginx vhosts, we add a location directive for /c, telling the server to forward all such requests to the unicorn process:

location /c {
  proxy_redirect     off;
  proxy_set_header   Host             $host;
  proxy_set_header   X-Real-IP        $remote_addr;
  proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
  proxy_max_temp_file_size 0;

  # forward everything else to the mongrel cluster
  if (!-f $request_filename) {
   proxy_pass http://campaigns;
   break;
  }
}

Now, we can pass out the link you may have seen on Twitter:

/c/blog-rack-campaign

When you visit it, you get redirected to:

http://www.zetetic.net/blog/2010/06/11/introducing-rack-campaign?utm_campaign=rack-campaign&utm_source=blog&utm_medium=internets&utm_content=example%20link

Isn’t that neat!?

This needs to perform very well, so we did a little testing with Apache’s ab testing tool and found it runs as fast as a normal nginx rewrite. Here’s what a basic rewrite looks like (/software rewrites to /code):

$ ab -n 500 -c 10 /software
...snip...
Non-2xx responses:      500
Total transferred:      191000 bytes
HTML transferred:       92500 bytes
Requests per second:    4626.33 [#/sec] (mean)
Time per request:       2.162 [ms] (mean)
Time per request:       0.216 [ms] (mean, across all concurrent requests)
Transfer rate:          1721.00 [Kbytes/sec] received
...snip...
Percentage of the requests served within a certain time (ms)
  50%      2
  66%      2
  75%      2
  80%      2
  90%      2
  95%      2
  98%      2
  99%      2
 100%      2 (longest request)

And here’s how rack-campaign is performing:

$ ab -n 500 -c 10 /c/blog-rack-campaign
...snip...
Non-2xx responses:      500
Total transferred:      167500 bytes
HTML transferred:       7000 bytes
Requests per second:    2749.78 [#/sec] (mean)
Time per request:       3.637 [ms] (mean)
Time per request:       0.364 [ms] (mean, across all concurrent requests)
Transfer rate:          896.43 [Kbytes/sec] received
...snip...
Percentage of the requests served within a certain time (ms)
  50%      2
  66%      2
  75%      3
  80%      3
  90%      4
  95%      4
  98%     13
  99%     14
 100%     39 (longest request)

Obviously, there’s some differences but so far, it looks like rack-campaign is doing well enough here. I’m sure it could be faster, and I’m sure that over time a YAML file could become a cumbersome manner of storage, but for now it’s good ’nuff. Feel free to fork it and use a SQLite database (which in this case would likely be very fast).

Installation

gem install rack-campaign

A thing of minor note: we’ve updated the main zetetic.net website. Aside from giving a few of our pages a long-needed refresh, we’ve decided that we really wanted to get all this content out of the database and onto the filesystem.

For a long time, we’ve been using the Radiant CMS to run both the website and the blog. It’s had it’s ups and downs. Radiant is pretty cool, a Rails-based application that has a lot of brilliant tricks for building out a website with a lot of shared content and cross-marketing. However, for us it’s always been a tad volatile and clunky. For instance, it’s easy to accidentally double-submit on a new post to the blog which then creates a page with no parent_id and that makes your whole site impossible to access.

Major version upgrades have been a real nightmare, especially when it comes to getting plugins updated. Plugins are what make Radiant so dynamic, but they tend to be very brittle, and are complex to upgrade with a major update of Radiant. Simple things like tagging or comments really ought to be part of the core system.

Then there’s the memory usage, or rather Ruby’s memory allocator and garbage collector (which could be considered a form of entropy). We don’t see the need to incur and manage this overhead just to provide static HTML content and images.

Finally, we wanted to be able to build out our pages in HAML, manage them over time with Git, and we’ve found that the Ruby gem staticmatic is just the thing for this. It provides a Rails-like project structure, partials, layout capabilities, etc. I even managed to hack in an automatically generated sitemap.xml.

At this point our website is almost entirely static content, with a little jQuery here and there where needed, and the blog itself is still on Radiant, soon to be moved over to another engine. When we have some spare cycles I’ll try to post some of the tips and tricks we employed to make it happen, but it’s nothing that any competent Ruby programmer can’t handle.

As an aside, the staticmatic gem is maintained by Stephen Bartholomew, and he’s doing a great job of actively maintaining the project. The mailing list is pretty active and helpful, and there seems to be a good community of people using it. That tends to give a tool a longer shelf-life and makes us even more confident in our decision to make the switch.