Last night we delivered an update to Tempo, our time-tracking service, called Macross. The previous release version had been named Voltron internally. The reason for naming them, beyond internal version control and tracking, is that we want to start providing some more communication going forward about what’s on the road map for Tempo, and having names for the releases makes it a bit easier.

In any event, Tempo release Macross went into production last night. It brings a number of badly needed performance improvements and runs off the latest and greatest stable version of Rails (2.3.8) AND gets us off Ruby 1.8.6 (now we’re on 1.8.7). In particular, users with very high numbers of projects and users will be happy to know that the management screens are way faster thanks to implementing some over-due pagination. There’s still a lot more optimization we’re planning to do, and we’re starting to consider changes we might make to the UI on the Projects and Team screens to make them more useful, in particular for our larger account holders. If you’ve got your own ideas, please get in touch and tell us what you’d like to see.

Another important update in last night’s release was switching our Twitter API interaction over to OAuth from HTTP Basic Authentication, due to their upcoming switch-over on June 23rd now-postponed conversion to OAuth. Whenever they do make the switch, Tempo will continue to scoop up your time entries via direct messages to @keeptempo.

Macross, named after the TV show Macross and the SDF-1, is mainly a stepping stone, to move us off some really old tech and to better position us for further infrastructure upgrades and service and UI improvements. This is now the current version of Tempo.

The next release, Macross Plus, is currently shaping up. The biggest thing I want to tackle there is moving Tempo to Rails 3; we anticipate that this will deliver some really great performance gains, as well as make on-going development far easier. We still need to firm up the list of other improvements and features that will be in Macross Plus – it will likely remain in flux, so it’s not a contract, but I will post it soon.

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