Half a Mind

I recently posted to the Artsy engineering blog about why projects need code names.

At Artsy, our systems have peculiar code names like Gravity, Pulse, and Vortex. There’s a persistent learning curve as you contribute to different repositories or as new services get created. Numerous times, I’ve wondered: are code names worth the trouble?

Mike Perham published an excellent rant pleading with developers (and especially developers of Ruby gems) to Kill Your Dependencies.

This is a common enough idea (see A quick note on dependencies in Ruby on Rails projects), and anyone responsible for maintaining a large, complex, or elderly codebase has probably arrived at the conclusion independently. Still, a reminder is in order. I’ve certainly been guilty myself of leaning a little too heavily on the casual contributions of others.

The Artsy Platform Engineering team has established a “Future Fridays” tradition.

The rules are simple. Each Friday, we give ourselves permission to suspend our usual work. Instead, we zoom out and try to answer:

2014-12-16: existing kitchen

Artsy practices a sort of continuous delivery: builds are automated, and there is always a deployable version of the codebase. Thus commits form a pipeline:

Trying to understand how instance variables, class variables, and class instance variables interacted in Ruby, I wrote this quick demo:

class Foo
  def get_instance_v
    @v ||= '@v'.tap { puts 'Setting @v from instance method!' }

Artsy depends on statsd and graphite every day. When our graphite server failed recently, I took the opportunity to revisit an old post about the simplest possible steps for setting up your own statsd and graphite server.

Chrome’s recent update removed the webkitNotifications API, which broke Unique Tabs briefly. I’ve just pushed version 0.4 of the extension. Enjoy!

Add Unique Tabs from the Chrome web store

We at Artsy have been carving a monolith into separate applications. It’s an appropriate move at our scale and complexity, but not as easy a decision as some might believe. One casualty: the usefulness of our tests.

Artsy has been growing its audience and scaling its systems. In the process, we’ve been launching new services and extracting, migrating, or discarding existing ones. I wrote Refactoring Infrastructure about how we’ve done that with incremental improvements and minimal interruption.