It's not magic, you just don't understand it yet

Dev 1: “Wait, how did it do that?”
Dev 2: “I have not clue, it’s Spring* magic.”
Dev 1: “Oh well, as long as it just works!”
* substitute Spring for any library or framework

Every time I hear (or, admittedly, say) something like this, I cringe.

When we refer to code as magic, we perpetuate the mindset that some code is unaccessible. That we don’t need to know how something works, only that is does work. This is not the mindset of a true craftsman. A craftsman seeks to understand the tools she uses, because she knows that she will be able to use them more effectively, and will be more able to deal with inevitable failures.

On Injecting a JavaScript Environment

Updated 2017-02-12: Added a strategy for loading configuration at initial page load, using an “env.js” file.

Recently, I needed to inject some configuration variables into my client-side app. Because Googling for it turned up a lot of “well, you could maybe do this…” I decided to write down what I see as the 3 main options:

  • Best in show: Load configuration at run time.
  • Prize for simplest solution: Build your application with configuration variables as constants at compile time.
  • Runner up: Use server-side templating to inject configuration at render time.

Harmonious Stylesheets and Inline Styles in React

Styling React components seems to be one of those things where there are a lot of solutions (libraries) emerging that try to solve the problem of how to use only inline styles in JavaScript sustainably. To me, it seems that this problem has been invented and can easily be avoided; and introducing a new library or tool is only adding to the complexity and cognitive overhead of your app. Many times it really is just better to stick with plain ol CSS stylesheets.

Both traditional stylesheets and inline styles have their place within React applications. By using them harmoniously you can have the best of both worlds.

Homogeneous Pipelines with Docker

Continuous Integration Build Pipelines are a dirty, nasty place. What usually starts out as a couple of simple tasks or bash scripts inevitably ends up as a heap of scripts, Gradle/Rake/Maven/(insert build tool here) tasks, and manually configured jobs held together with a thin layer of Elmer’s glue and Scotch tape.

Why? Partly because modern applications are complex; even simple stacks use multiple languages and tools. And partly because developers are lazy, and sometimes hesitant to “mess with the pipeline.” I don’t often see the amount of rigor in cleanliness applied to them as to other parts of the codebase, leading to unnecessarily complex and unfortunately tangled build pipelines.

So, my current team attacked this head-on using a great piece of technology: Docker! Using Docker as our sole interface to running things in our build pipeline, we sped it up, simplified it, and lived happily ever after.

To give credit where credit is due, the implementation of this pattern was spearheaded by my colleague Amber Houle.