d: statsd, metrics, and measuring what you do

A long time ago in web years was written a blog post “Measure Anything, Measure Everything” by the devs at Etsy. It got me thinking about this issue, and it’s been really critical to me ever since. Years ago Seth Godin advised me that you have to measure in order to understand your effectiveness. And I’ve since found that whether that’s big or small, measuring removes anxiety. You know. You don’t have to guess. It’s either working or it’s not. And… it’s amazing how often people guess wrong. Also, people don’t believe that it is possible to measure a lot of things. But I’ve seen some great examples of making it possible to measure even really difficult things (like how you’re feeling) and reflect that data in a way that makes it clear.

A stat example

In this specific case… I loved that fact that UDP keeps things loosely coupled, and that statsd rolls up measurements so that the raw data isn’t overwhelmingly large.

And last, I liked the fact that the folks at Metrics were friendly and helpful, even though they’re running pretty fast to get Metrics where they want it to be.

This is a brief guide to the steps I took to get a Rails 3 app sending notifications to statsd running on Ubuntu in the EC2 cloud, and pointed it at Metrics. I borrowed knowledge from here for the first steps, but I didn’t want some of the stuff that follows, and the recipes have grown out of date a bit, so realize that you’ll have some digging to do to get it to run. Generally, I didn’t find all that much on the topic of how to set this up so, maybe this will save another busy developer some time.

Note that this fires up a small EC2 instance, so you’ll have to pay for it…

download and install the EC2 API tools (e.g., into ~/tools)
generate a X.509 certificate (both public cert-…pem and private pk-…pem files) on the AWS Security Credentials page
generate a keypair (statsd_setup.pem) in the AWS Management Console
I stored the key files in ~/.ec2/ locally.

$ sudo chmod 600 ~/.ec2/statsd_setup.pem # set appropriate permissions on private key file
The EC2 API tools require certain environment variables to be set. I put the following in a local file (e.g., ~/bash/statsd_setup.sh):

export EC2_HOME=~/tools/ec2-api-tools-1.5.2.5
export EC2_PRIVATE_KEY=~/.ec2/pk-statsd_setup.pem
export EC2_CERT=~/.ec2/cert-statsd_setup.pem
export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home
export PATH=$PATH:$EC2_HOME/bin

$ source ~/bash/statsd_setup.sh

Finally, start the instances and modify some basic security settings:

$ ec2-run-instances ami-06ad526f -k statsd_setup # start a new instance with a recent Ubuntu 11 image
$ ec2-authorize default -p 22 # permit SSH
$ ec2-authorize default -p 80 # permit HTTP
$ ec2-authorize default -p 8125 -P udp # statsd will listen here

Then I logged into the instance once it was running: ssh -i ~/.ec2/statsd_setup.pem ubuntu@your_instance_here.amazonaws.com

Next, node and npm.

Install the dependencies:

sudo apt-get install g++ curl libssl-dev apache2-utils
sudo apt-get install git-core
sudo apt-get install make

When all done running…

mkdir dev
cd dev
git clone git://github.com/ry/node.git
cd node
./configure
make
sudo make install

If all went well node is installed. I smoke tested by simply typing the command “node”, and sure enough I got the prompt.

Since this is a test box, I took over /usr/local

sudo chown -R `whoami` /usr/local

and then installed npm in classic fashion: curl http://npmjs.org/install.sh | sh

next I moved back out to dev (cd ../)

And cloned statsd. Since I’m using Librato’s fork: git clone git://github.com/librato/statsd.git

I made a copy of the config example, and copied the settings I wanted in there.

I ran (as usual) npm install to get the dependencies installed, and then I fired it up: node stats.js myconfig.js

Win!

Locally, I fire up irb, where the gem statsd-ruby is already installed. I require ‘statsd’ (be warned, there’s more than one, and the namespaces collide), and fire off a few stats statsd = Statsd.new(your_host_here), and then statsd.increment ‘test’.

I already had my Metrics account, so I logged in and voilà, stats.

Next step wiring this into a Rails app. I create an initializer called notifications.rb. Inside is the code below cribbed mostly from here:

Linked.

Which fires off all sorts of great info to statsd when you fire up the app and hit a few pages. Also, $statsd is available all over the place so you can measure pretty much anything going on in your app. I was surprised that there isn’t a simpler setup for this, but as I write this I tried Heroku, and Engineyard Cloud beta for node, and asked over at no.de and nodejitsu, and none of them support the standard port, or the UDP routing, or several of these requirements. It seems like this is an atypical scenario for now. Too bad, because it’s a great way to start measuring everything. A few months might change all of this, but for now that’s the state of things, so off to EC2 I went.

Rookies in the bike shed

Rookies in the bike shed:

The ability to spot this is one of the most valuable skills a software developer can possess. There are endless features we could build and debates in which we could engage, but only a small subset are worth the effort.

The best developers aren’t the ones who can write the most code in the shortest amount of time or out-reason anyone on the internets. They are the ones that only write the code that’s most valuable to execute and only enter the debates of high substance.

[And that is what makes anyone good at what they do. It is about editing things down to the most important things and concentrating on those.]

Why the new iPad screen is the future of display

ipad screen large

Why the new iPad screen is the future of display:

Well, I am sure Steve Jobs and friends looked at that situation several years ago and saw “stuck” instead of “settled.” The new iPad is the first clear clue that this was the case.

[I’m amazed at how well the whole idea of improved resolution holds up. Not everything needs it… the resolution of the thermostats I installed the other day seem just fine, and they don’t appear to be ‘retina’ level displays, but then, seriously, how often do I want to look at them? If they’re doing their job, I don’t. My phone however, I look at all the time, and it makes some other devices I own almost impossibly crude by comparison. Same with the monitor in the office vs. the one I have at home. Screen real estate matters, and so does resolution.]

Source: Doc Searls Weblog

AnandTech Tests New iPad Battery Life

AnandTech Tests New iPad Battery Life:

Anand Lal Shimpi:

Now for the killer. If you have an iPad on Verizon’s LTE network and
use it as a personal hotspot (not currently possible on the AT&T
version), it will last you roughly 25.3 hours on a single charge.
Obviously that’s with the display turned off, but with a 42.5Wh
battery driving Qualcomm’s MDM9600 you get tons of life out of the new
iPad as a personal hotspot.

[Nice. We’re I to get one, this would be a primary benefit.]

Source: Daring Fireball

Don’t Steal Ideas, It Is Discouraging

Don’t Steal Ideas, It Is Discouraging:

Don’t Steal Ideas, It Is Discouraging
As the dust is settling from the Svbtle vs Obtvse debacle, I’m left feeling a little discouraged. The reason I feel this way is because a consensus had been made between part of the community that communicates: “It’s okay to steal and duplicate an idea as long as you write your own code.”  If you don’t already know the story, read the summary below and check out some of the discussion on Hacker News.

[What I find discouraging is the knee jerk reaction. in the end it’s just another blogging tool. As the proof that it is commodity item, for the most part, something extremely similar was written in no time. And even then, I don’t deny that subtleties matter, and that the thinking behind Svbtle changed the way the he thought about writing, it was just that. the technique, whether reinforced or not can be applied to many tools that are already out there. Don’t title, don’t publish seem like the core initial impulses. So with that in mind, why all the upset because this code wasn’t released? Yet another subtle bit. In the original post about it, there’s an implication that he was about to release it, and then he pulled it back in order to create an invitation only blogging network. So he pushed the buttons of a community that demands openness in code with this bit. If he was looking for attention, this might have worked, although I suspect it is more tempest in a teapot than viral explosion… in the end, the visual design similarity is troubling to me. It flies in the face of what he was trying to do in the end, which is create a network where the visual sues stand for quality. Making it hard to discern by making use of the design is what I find unfortunate here.]

How Apple.com will serve retina images to new iPads « Cloud Four

How Apple.com will serve retina images to new iPads « Cloud Four:

One of the more interesting questions raised by the new iPad and its retina display is whether or not web sites should deliver higher resolution images when there is no way to know the connection speed. AppleInsider found that Apple.com is being prepped to deliver high-res images and documented how you can test it in Safari on your desktop.

As you can imagine given my research on responsive images, I was keenly interested to see what approach Apple took.

What they’ve chose to do is load the regular images for the site and then if the device requesting the page is a new iPad with the retina display, they use javascript to replace the image with a high-res version of it.

[Oh boy. I’d carefully consider the importance of a hi-res image, take a careful look at my traffic stats, and go from there…]