Jimmy Breck-McKye

A lazy programmer

I’m a Pair-programming Skeptic

I’ve attempted pair-programming several times, including in an organization that (briefly) considered rolling it out as a mandatory process for all engineers (you can guess how well that idea panned out). Personally, I’m not a huge fan. In fact, I’ll go further than that – I’m a downright pair programming skeptic.

Of course I’ve always tried to keep an open mind – this is an industry ripe with innovation and continual churn in technologies and practices. You don’t have fun in this game unless you’re happy with habitual change and continuous improvement. But I am so far absolutely convinced that pair programming is kryptonite, at least in the ways I’ve seen it practiced.

More’s ‘Utopia’ May Mean ‘Nowhere’ - but That Needn’t Make It a Satire

When students read More’s Utopia, the first thing they learn is that the name is coined from the Greek for ‘no-place’, or ‘no-where’. The second thing they usually learn is that the name Hythloday means ‘peddler of nonsense’. From this spring two responses: either that the tale is fraudulent, and More expects us to ridicule it, or that More wants to publicly disavow the tale to avoid political controversy.

I think both interpretations miss something: that though the tale is fictional, its fiction isn’t supposed to matter. Words are hollow in Utopia, and communication rarely occurs as planned. Messages get lost; topics of argument are forgotten. But that’s okay, because the real value of words isn’t in their center, in the semantics of the message, but on their edges in some fashion – the digressions they lead to; their accidental consequences; the marginalia of a book; as philosophical thought-experiments; where they end up rather than where they were intended to lead.

In this model, it doesn’t matter if the original message was a falsehood, because the message’s ultimate value was never in what it meant to begin with. In fact, I’ll eventually argue that to read the name ‘Utopia’ as signifying the work’s fiction is itself a kind of paradox. This will become clearer later.

Spying on Third-party JavaScript

Very rarely, it is useful to intercept calls to hidden methods on third party scripts. I had recent need of this when I wanted to spy on calls to DFP’s undocumented googletag.debug_log.log method, so that I could report detailed advert timings. But working with undocumented APIs is always treacherous – those methods can change or disappear at any moment. We need a safe way to spy on third party code.

Ghetto Dependency Injection

So, you’re writing a piece of JavaScript that you want to test, but it has dependencies you need to stub or mock out somehow. You know that dependency injection would be really handy, but you’re not sure how to do it. You might have heard about JavaScript IOC containers like bottle or Intravenous. You may have also heard of Jest, which lets your tests inspect and override the behaviour of require.

Let’s say, however, that right now, it’s just not appropriate – you’re writing something small, you’re writing something quickly, or you’re writing something before you have the chance to evaluate those technologies. Or maybe, like me… you’re just a lazy programmer. Look, I’m not going to judge – at least you’re testing your code, right?

Whatever your reasoning, Ghetto Dependency Injection is here to help.

Hiring You as a Front End Developer: Reading Your CV

In the last few months, I’ve interviewed a lot of front end developers. I’ve also sat on the other side of the table, interviewing for new roles of my own. So I’ve lately thought a lot about how this process works – and how both sides often miss each others’ perspectives. In the next few posts, I want to give developers looking for new roles an insight into my perspective as a hirer. In this one: what happens when you send your CV, and what happens when I read it.

Testing Knockout Custom Bindings

In my last post, Testing Knockout.js Web Applications, I explained how to unit test a simple viewmodel using Karma and Jasmine, so you could validate the values and methods on the viewmodel bound to the DOM.

This is all very well and good, but what happens when we want to bind our model data to the document in novel ways? If we can’t use the standard Knockout bindings, we need to write our own. Using custom bindings to handle view concerns is a good pattern for keeping viewmodels manageable and making view code reusable. But how can we test them?

Testing Knockout.js Web Applications

I’ve been working with Knockout.js for a few months now. I’m impressed, but one thing I’ve found lacking is much community documentation on how to test Knockout apps. I thought I’d write an introductory post on testing Knockout.js applications for those new to the idea – like I myself was, a few moons ago.