Space Vatican

Ramblings of a curious coder

Ruby Truth Serum

One of the joys of ruby is its flexibility – there are very few things set in stone. Occasionally this can make things hard to figure out. For example if someone has overridden the class method (not that uncommon when using proxies), then you can waste a lot of time wondering why something that claims to be an array isn’t quite behaving like one. Once you’ve established this, how would you find out what the real class of the object is?

I came across a neat trick today for dealing with this:

1
2
3
4
5
6
7
8
9
class Suspicious
  def self.class
    Array
  end
end

object = Suspicious.new
object.class #=> Array
Object.instance_method(:class).bind(object).call #=> Suspiscious

What we’re doing here is using Object’s implementation of the class method and calling it with the object we have at hand. Nifty

Keep It Secret, Keep It Safe

AWS credentials are very powerful — in the wrong hands you could lose data or incur large costs — so you need to manage them carefully. I don’t think there’s a one size fits all here and as usual security and convenience tend to pull in opposite directions, but I think there are at least some general guideslines:

  • You should very rarely be using the master account, instead use IAM to create users with specific permissions
  • Try to attach policies to groups rather than users — this makes them easier to manage
  • Make groups task focussed rather than service focussed. For example I’d have a backup group that had relevant access to S3 and glacier rather than having an S3 group and a glacier group
  • Only give people access to what they need. Your accountant for example only needs access to the billing data, not the api or console

The downside of this is that you now have multiple sets of credentials to manage for all these IAM users. For me, credentials fall into 3 categories:

  • Credentials that the app uses itself
  • Credentials for using the web console
  • Credentials for management scripts (provisioning new instances etc.)

Replacing a Duplicate Season Ticket

Or how to waste half an hour

This weekend I lost my season ticket. Normally it’s not the end of the world — as long it’s the first time that year you can order a duplicate. If you bought the ticket in person you can do this at the station, but if you ordered the ticket from the first capital connect website (as I had) then you have to apply for a duplicate through the website.

I’d already tried and failed to find this on the website a few days ago (my ticket had recently stopped working at the barriers) but this time I had no choice but to persist. The website certainly used to have this feature — I’m not on my first lost ticket — but the website had recently received some sort of overhaul.

The short version is that you can probably call the trainline on 0871 244 1545 or possibly 0870 024 0463, but since it took me quite a few rounds of phone tag to get to the bottom of it I feel I have to inflict the full version on you.

Using Statsd and Graphite From a Rails App

I recently wanted to start recording various business level metrics for our Rails app. We already use New Relic for performance monitoring and while you can inject custom metrics you can only surface them if you have the Pro version (unless they happen to surface naturally as one of the top n slowest/highest throughput/highest total time metrics). I’d been hearing a lot of good things about statsd and graphite so decided to try my hand at setting those up. Graphite is written in python, so this meant venturing out of my cosy little ruby world.

Starting EC2 Instances With Ephemeral Storage

Amazon EC2 instances can have two forms of storage attached: EBS, which is basically a SAN and instance local storage. The instance local storage is free (the amount you get depends on the instance type), but doesn’t persist once the instance is terminated. EBS storage is pricier (you pay per GB), but is persistent and you can do neat things like snapshot volumes or move volumes from one instance to another.