RidingTheClutch.com

It’s been a while since I’ve posted anything here, but I’ve been hard at work, at work. We created the Light Engineering Group late last year as sort of a skunkworks R&D department. We don’t have product managers or process of any kind really. We experiment with new technologies and markets and pretty much have free reign as far as architecture, languages, server setup, you name it! It really is a dream job for a programmer. I’ve had a couple big projects go out the door recently and that seemed like a good enough reason to crawl out of the dark and write a new blog entry!

ActiveReader

My first iPhone app! This one brings down articles from Active.com and stores them in your phone for on/offline reading. On the server-side the articles are stored in CouchDB which is my new favorite database. I love JSON and I love HTTP—so does Couch. Couch sits behind Pound to make sure only certain URLs are visible to the outside world.

Widgets

We wanted a way for people to embed a simple little widget on their website that pulled upcoming events from our directory, but we also wanted people to be able to customize it easily. widgets.active.com is what we’ve come up with. The widget itself is all Javascript. The site for configuring the widget is a small little Sinatra app running on thin behind nginx

labs.active.com

This site has actually been up for a while but we just launched a refresh with lots of HTML5 goodness. It shows some current projects as well as those that have “graduated” and made it to the big time.

A few months ago I had to take down several open source projects that I had built at my job since we didn’t have an official policy for open source software. Well, we finally put one together and I was able to open source these projects again just a few minutes ago! They’re listed under my employer’s Github account

In no particular order, here are the ones that are up so far with many more to come!

• encosion – A Ruby gem for talking to the Brightcove Media API
• postal – A Ruby gem for talking to the Lyris API
• gattica – A Ruby gem for talking to the Google Analytics API
• gasohol – A Ruby library (not quite a gem yet) for talking to a Google Server Appliance

As I’ve mentioned previously woodworking is taking over more and more of my free time. I was working on my latest project at school this evening and thought about how woodworking is really just a giant puzzle, but in three dimensions.

The difference is you make the pieces yourself and there’s no picture on the box to help—you create that too. It’s very challenging and very rewarding. Sketchup is a great way to visualize this complex combination of puzzle pieces. Flipping into x-ray mode shows you the insides of your pieces, specifically the joinery (assuming you took the time to model it):

It’s hard to believe that it’s possible to keep track of all that and actually make it out of wood. But, slowly but surely it comes together. You end up with a lot of saw dust, wood chips and a few boards that are within thousands of an inch of where you wanted them. In most do-it-yourself projects around the house, 1/16th of an inch is about as accurate as you need to be. But in fine furniture you really do deal with thousands of an inch. And it’s actually easy to do with good tools. Taking off half a thousandth of an inch is common.

Back to our puzzle. What if after about 10% of your puzzle is assembled you can’t really count on the picture any more? As the pieces of your project start coming together there are always slight differences in widths or heights from your plan. These add up as you assemble your project. So you need to compensate for it. You start taking measurements off the pieces themselves and count less and less on your plans. By the time you’re done you aren’t even using your original project diagrams any more—the project itself becomes your reference.

Woodworking has been around almost as long as we have and it’s amazing how much there is to learn. But apply those time-tested techniques and, after tens or hundreds of hours, you don’t have a puzzle any more but a box or a table or a chair that you made yourself using only your hands and mind, and with little care will outlive you and even your children.

I was never really happy with the previous design of this site. I was on a bit of a typography kick and wanted to stay as pure to typographical conventions as I could, but it ended up being a little boring and just plain not satisfying. The other day I had a vision of a red block with RidingTheClutch.com set at the bottom of it in white. That’s where this design started.

This design makes heavy use of HTML 5 and CSS 3. HTML 5 is pretty well supported across all major browsers with a little kickstart for IE. It’s really no different than HTML 4.01 with the exception a few new tags like <header>, <nav> and <article> which gives your page more meaning instead of just generic containers for layout. CSS 3 is used in the photo show in the upper right, along with giving the red header a subtle gradient (in Safari/Chrome) and subtle rollover effects on links (Safari/Chrome again).

The best way to experience the site is on a Mac in Safari since you’ll have Helvetica Neue and can see the sans-serif text on the page the way it was supposed to be seen. You’ll also have more complete coverage of CSS 3. The photos at the upper right are my latest uploads from Flickr (did you try clicking on them?). The Javascript code for this is open sourced on my Github page and is called stack.

This is only phase one of the redesign. I’m going to be adding navigation to a few sub pages as well as a footer with feeds from all of my various endpoints around the web: twitter, facebook, flickr, github, and content from some of my other sites.

I’ve been rethinking what it means to have a blog. It should really be a collection of all my “stuff,” not just random story-like posts whenever I get around to it. It should be the hub of everything “me” on the internet, no? When I commit a new piece of code to Github, or upload a photo of a new woodworking project to flickr, that information is all part of what’s going on with me at that moment. This site will be the place where all of this content is collected. I realize this can be a bit overwhelming so the standard RSS feed will still be blog posts, but there will be additional feeds for more thorough coverage. I will most likely be building my own piece of software to run this blog and migrate from jekyll.

Keep watching!

I’m working on a project at work that allows a user to upload videos. We use Brightcove to host and present our video so I wrote a little library for working with their API. It’s called encosion and it’s over at Github . I haven’t completely duplicated the functionality of their API yet since all I needed to do was read and write video, but I encourage others to contribute and add on to the project!

I recently discovered Sinatra and and found that after a few tests with Apache Bench that it was pretty fast. It felt almost as fast as a Rack application. But how fast was it, really?

Whenever a new framework comes out people like to display a bunch of benchmarks showing how fast it can display “hello, world.” But I hadn’t seen many that compared several frameworks objectively. That’s where this post comes in. I wanted to compare the most popular frameworks and as a byproduct I also ended up testing the most popular templating languages. I ran everything against Ruby 1.9.1 since I wanted speed and so far it looks to be around 2x faster than 1.8.7.

So I ended up testing Rails vs. Rack vs. Sinatra, each of them using ERB, Builder, HAML and plain HTML templates. (I know that Camping has been around almost as long as Rails, and is pretty popular, but it’s not compatible with Ruby 1.9.1 as of yet.) Each framework would be served by Thin – generally considered the fastest way to serve Ruby apps right now. In addition I tested Rails served through Passenger and Apache. For comparison I wanted to test these frameworks against Apache and Nginx serving static HTML.

You can download the code for my tests at Github which includes the server setup scripts and web server configs I talk about below.

First I needed some hardware. I set up a medium-sized high cpu instance on Amazon’s EC2. I found a barebones Ubuntu 8.10 install (ami-0372946a). I installed several aptitude packages that allowed Ruby and Passenger to be built, along with the required gems to run the different frameworks. For the framework code I kept it simple: each created a variable to hold the time and then output that variable (along with some text) in each of the different frameworks. For example, the Rack/ERB template:

["\nrequire 'rubygems'\nrequire 'rack'\nrequire 'erb'\n \nclass Go\n  def call(env)\n    now = Time.now\n    [ 200, \n      {'Content-Type' => 'text/html'}, \n      ERB.new(\"<h1>Rack - ERB</h1><p>The time is:<%= now %>\").result(binding) ]\n  end\nend\n \nRack::Handler::Thin.run Go.new, :Port => 3000\n"]

For the actual tests I used Apache Bench. I know there’s a lot of controversy out there about how well AB actually works, whether it can create as many concurrent requests as you think you’re getting, etc. but for this test I thought it was adequate. I only went up to a maximum of 50 concurrent requests which I’ve read is a good maximum. I ran three different groups:

• 1000 requests, consecutive (one request goes out and returns before the next is sent)
• 1000 requests, 10 concurrent
• 10000 requests, 50 concurrent

For part 1 of this performance test I only hit a single instance of each framework, and tested from the server that was running the code. This removes any latency of the internet and will be an absolute pie-in-the-sky best case scenario. You will never see numbers this high in real life, sorry. :) One ssh session ran the server and the other ran Apache Bench. These were the only things running on the box at the time, besides standard kernel stuff.

I ran each test once to get the framework loaded into memory, then repeated it 10 times and recorded the average. I shut down that server and then started the next. I tried to keep everything as controlled as a could.

Here are the results (or the Google Doc ). Each column is the number of requests/per second. Each is an average of 10 runs using the Apache Bench settings in the column header (-n 1000 -c 10 means 1000 total requests, 10 concurrent). Numbers at the bottom of the column, below the double-line border, are the average of the numbers above. How to interpret these numbers

So, with one instance of a framework running, Rack is definitely the fastest. Rack serving plain HTML. As for templating languages, ERB and Builder are in a dead heat, but HAML isn’t that far behind. If you just need raw static serving speed, stick with nginx.

This is only part 1 of my Ultimate Ruby Performance Test. In part 2 I’ll put several instances of a framework behind Apache and Nginx and we should really start to see some benefit when doing the concurrent tests. Stay tuned!

Just released a new Ruby library on Github called Gattica . Gattica is a gem that lets you talk to the newly released Google Analytics API . Check it out and let me know what you think!

Just picked up a new book and found the following advice in the forward:

“While learning something new, many students will think, ‘Damn, this is hard for me. I wonder if I am stupid.’ Because stupidity is such an unthinkably terrible thing in our culture, the students will then spend hours constructing arguments that explain why they are intelligent yet are having difficulties. The moment you start down this path, you have lost your focus.

“I used to have a boss named Rock. Rock had earned a degree in astrophysics from Cal Tech and had never had a job in which he used his knowledge of the heavens. Once I asked him whether he regretted getting the degree. ‘Actually, my degree in astrophysics has proven to be very valuable,’ he said. ‘Some things in this world are just hard. When I am struggling with something, I sometimes think “Damn, this is hard for me. I wonder if I am stupid,” and then I remember that I have a degree in astrophysics from Cal Tech; I must not be stupid.’"

Up until now I have never had a passport. But we’re starting to travel more and with the new laws in effect it’s about time I got one.

The requirements to get a passport are: a valid US birth certificate and photo ID. No problem, just get my “official documentation” folder and I’m good to go. I get out the folder and there’s no birth certificate. Uh oh. When was the last time I saw it? On our cruise back in February. I used it as a bookmark so that I could keep track of it. But for which book?

Then my wife remembered taking a photo of that book while on our cruise. I quickly opened up iPhoto and scanned through the photos from the cruise:

Jackpot! I couldn’t read the spine but remembered the color: In Defense of Food (which I have yet to finish). I went to the bookshelf…search…no book. I went up to the loft and went through the additional boxes of books we don’t have shelf space for. Flip, flip ,flip…green cover, black spline, got it! And look what’s sticking out of the top:

Another release today, this time it’s a small Ruby library for searching a Google Appliance Server called Gasohol . I’ve been working on a prototype search at my job as a full Rails app, but I removed the part that searches and parses results from the GSA and open sourced it.

As always, check out the readme for usage instructions. I plan to turn this into a gem eventually, but for now you’ll need to pull the files down manually and drop into the rest of your code. More to come!