What’s the one thing we, as developers, do with source code more than anything else? We read it. Sure, we change it, and even occasionally we write new source code, but, by and large, we read source code. We read it to know how to use it. We read it to know where to change it. We read it to understand what it does.

But, it’s not just the content - the code itself - that affects readability. How it’s presented matters and if we’re going to talk about presentation, we have to talk about typography.

At Stitch Fix, we outsource pretty much all of our hosting and technical needs to Heroku or their add-ons. Given where we are now as a company, it makes total sense: we don’t need to hire an admin, we don’t need to adminster actual boxes, and we can easily add/remove/change our technical infrastructure. If you are a small startup and you are messing with Linode slices, you are probably wasting time.

One thing Heroku doesn’t provide out of the box is a login system for “internal” users. The vast majority of the software at Stitch Fix is targeted at Stitch Fix employees - to operate the warehouse, choose what goes into a fix, etc. The natural way to allow them to login is via Google Apps. We can use everyone’s existing username/password, and employees can be added during onboarding and removed when they leave the company, all in one place.

Getting it to work with our Rails apps seemed easy enough with OmniAuth, but it turned out to be a lot trickier, resulting in random failures with the oh-so-helpful error “invalid_credentials”. Here’s how to fix that, and why you can’t just use the out-of-box configurations recommend by OmniAuth.

From time to time, I see people in my twitter stream attempting to switch to Vim. This is a good thing. The problem is that they appear to be viewing the switch as swapping out one tool for another.

This is not what switching to Vim means, nor is it a good reason to switch.

The reason to switch to Vim is to work better. I realize “better” is subjective, but whatever way you define it is what it means - code faster, edit text more easily, automate your workflow, whatever.

As such, switching to Vim is to throw out your old editor (or plan to) and replace it with a different tool that works differently and is, hopefully, better. Stop asking for “a plugin that does XXX like Sublime Text does things”. If Sublime Text has a plugin for what you want, you don’t need Vim. Vim might very well have a plugin that does whatever XXX is, but it’s more likely that you don’t need a plugin, or that Vim provides a way to accomplish your real goal much more efficiently.

Here’s how to make the move.

One of the main reasons I like working test-first is because I’m lazy. I don’t want to fire up a browser, log in as the right person, navigate to just the right piece of data (which I had to set up manually in the database), and click around to see if things are working.

Don’t get me wrong, I do do that, but only when the code is working according to my tests. Or, when I have to write JavaScript.

At my current job, I’m doing a lot more front-end than I had been, and so more JavaScript. The app I’m working on is a Rails app, and so I looked into the current state of the art with testing JavaScript.

In can be done, and it’s painful.

John Siracusa has, in his laser-focused, analytical style, perfectly captured something about technology that I always knew, but never knew I knew. His latest post, Technological Conservatism is a must read:

Beneath what seems like a reasonable feature request lurks the heart of technological conservatism: what was and is always shall be.

(emphasis his).

I love everything about this, and it’s a helluva lot better than [Steve Yegge’s stinker][yegge].

Siracusa’s article inspires me in two ways:

• Stop holding “what I know” so dearly. “Lead or bleed”, as Chad Fowler says
• Stop accepting unjustified idioms & conventions as being “more correct”. “That’s just the way it’s done” is often the best explanation for doing things a particular way, but it’s not actually a legitimate reason for anything.

With the recent announcement that Google is shutting down Reader, there’s been a lot of talk about RSS: Is it just a geek-only thing? Isn’t Twitter good enough? Why don’t you read “real” journalists instead of blogs?

RSS is a huge part of my online life - every time I fire up Reeder and see stories, I get very happy. The way I use RSS (which I believe is the best way to use it) can’t be replaced by anything else that I’m aware of.

So, why do I think RSS is so great?

The UserVoice developer blog posted an interesting article yesterday talking about how they solve “The Rails Problem” of complex Rails apps having obese models that stymie code re-use. The naive approach is just to make classes.

UserVoice’s approach is different: they made a DSL for describing service calls. The thing is, it’s sort of a type system - and a verbose one at that.

Today is my first official day¹ a Stitch Fix, where I’ll be joining the small but awesome engineering team! What I love about Stitch Fix is that it’s such a simple business: buy clothes for one price, sell them at a higher price. It’s the very essence of what a business does. “All” we have to do is find more people to buy things from us, figure out what they want to buy, and sell to them as efficiently as possible.

In my earlier post on how the replace command-line app isn’t “bad code”, I said:

Now, I’m all for bad projects and bad code being called out. Our industry produces some shitty code, and a general lack of craftsmanship can kill business, or even people. So bad code needs to be pointed out.

The words I’m using here are a bit loaded, and actually distract from my real meaning. I don’t want to change the post, but thought it was worth explaining what I meant and why it’s important.

Friday was my last day at LivingSocial. I’m moving on to a small team at a small startup that I hope will eventually be big. My tenure at LivingSocial was short - it would’ve certainly been longer had this opportunity not come along - but I learned a lot in the 14 months I worked there.

Sure, I learned stuff about Rails, Ruby, service-oriented architectures, asynchronous processing, and credit card payments. But that’s not what I’m talking about. Those skills are great experience and will look just fine on my resume, but I learned two things that made me a better developer:

• Deliver results, not promises
• Assume everyone knows what they’re doing