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.

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 respect for craft 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

So, someone shared some code on Github and some classic developer snark rolled in. And then there were some apologies about it. I saw those snarky tweets when they came through, clicked to the Github project, didn’t understand what the issue was, and went back to work.

Now, I’m all for bad projects and bad code being called out. Our industry produces some shitty code, and a general lack of repsect for craft can kill business, or even people. So bad code needs to be pointed out. The question is, is this bad code? I think we can all agree that if it is bad code, we should try to point it out in a more constructive way (and I know it’s easier said than done), but let’s forget the tone and focus on the message. Is replace a silly project, or implemented in a stupid way?

No, it’s not.

Saw a blog post this morning titled Why Functional Programming in Java is Dangerous. Author Elliotte Rusty Harold sets up the world’s worst straw man I’ve seen. He talks about Uncle Bob’s post on the advantages of functional programming. Elliotte’s thesis is that Java and JVM just can’t handle this sort of thing, and then sets out to prove this with some terrible code that, unsurprisingly, is terrible. He takes this bit of Clojure

(take 25 (squares-of (integers)))

And “re-implements” it in Java. He does this by implementing integers to just allocate an array of all the integers.

Yeah.

Both DHH and Tim Bray make great points about “dependency injection” and its issues regarding Ruby and testing. My colleague Adam Keys makes a similar point, though doesn’t call his anti-pattern “dependency injection”.

The scare quotes are because neither DHH nor Tim are accurately representing the purpose of dependency injection. Dependency Injection is not about a framework, XML, factories, or testing. It’s about simplifying code. Let’s see how.