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.

If you can use ES6 template strings, you can write reactive, componentized views using less than 500 bytes of helper code.

Let me be clear. This approach isn’t intended as a serious replacement for React+Redux/RxJS. It doesn’t re-render views very quickly and the way it handles events is verbose. It’s simply an experimental way to write light, simple applications that need to load fast, without the hassle of transpiling JSX or rendering on the server. I’m sharing it as a curiosity more than anything else.

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.

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.

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.

I’ve recently had some fun writing a browser quicksort.

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?

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.

The JavaScript world seems to be entering a crisis of churn rate. Frameworks and technologies are being pushed out and burned through at an unsustainable speed. But I think the community will adapt and adopt new practices in response. Developers will move, I believe, from monolithic frameworks like Angular.js and Ember to a ‘pick n mix’ of small, dedicated libraries to mitigate the risk of churn and to allow solutions to different concerns to compete separately.

Obviously, this post has big red ‘opinion’ stickers over it. But hear me out.

I’ve been working with Knockout.js on a commercial project for a couple of months now and think I have a decent sense of its capabilities. However, I’ve never worked with any other web application frameworks before and wondered how others felt Knockout compared to them.