In my world as an engineer, the objective is to minimize the cost of creating and maintaining a thing, while maximizing the effectiveness of the thing towards some cool goal. Shopify is one such thing that experiences this tension: its goal of making selling stuff really really easy is well on it’s way to accomplished, but it has taken a sizable army of software developers to get and keep it there. The main cost we’re afraid of is that as the system gets bigger and more complicated we will be immobilized by all the complexity we’ve introduced, which means we couldn’t stay competitive as the markets around us change. So, I’d like to share a principle that serves our value of building maintainable, low-service-cost things at Shopify. It’s something I call drawing circles.

This is an explanation and demonstration of an extraordinarily neat algorithm called Paxos. Paxos is a family of algorithms for teaching a whole bunch of decidedly unreliable processes to reliably decide on stuff. More formally: it allows a group of unreliable processors to deterministically and safely reach consensus if some certain conditions can be met, while ensuring the group remains consistent if the conditions can’t be met.

In which I try to justify data driven software development, just not for performance management.

If you are, say, a piece of e-commerce software, and, say, you want a record of when your customers buy stuff, how might you ensure that you get a record of each transaction every single time one happens? Money is changing hands, and people aren’t very fond of losing money without any gain in return, so having a correct ledger for transactions sure is important.

Yep. That’s all. This is a test post, and secretly an attempt at making this blog look a bit more loved, whoopee!

I want to use your JavaScript library. I really do.

Unfortunately, a lot of you are bad at documenting it, so I can’t figure out how to use it before I give up and find something easier to learn.

Batman.js is Shopify’s new open source CoffeeScript framework, and I’m absolutely elated to introduce it to the world after spending so much time on it. Find Batman on GitHub here.

Batman emerges into a world populated with extraordinary frameworks being used to great effect. With the incredible stuff being pushed out in projects like Sproutcore 2.0 and Backbone.js, how is a developer to know what to use when? There’s only so much time to play with cool new stuff, so I’d like to give a quick tour of what makes Batman different and why you might want to use it instead of the other amazing frameworks available today.

Here I’ll try and demonstrate a neat optimization algorithm based on the principles of performing jazz musicians by applying it to solve Sudoku puzzles. Update Sept 28th 2015: Turns out this algorithm is ballyhoo and I don’t like it any more, use something else. Kind of a fun idea though. See http://www.dennisweyland.net/blog/?p=12.

Harmony Search (often abbreviated HS) is a metaheuristic optimization algorithm pioneered by Dr Zong Woo Geem. Metaheuristic algorithms like harmony search attempt to find the optimal input to some objecting measure of quality, or in other words, find the “best” solution to a given problem. Harmony search has been successfully applied to a vast array of such problems, such as the Travelling Salesman problem, water network design, and actual algorithmic music generation.

I had to convert a sizeable test suite from Jasmine to QUnit. The former has a wide array of matchers and situation specific helpers for explicitly testing things, and the latter is about as barebones as it gets. This is all well and good, it just means converting is a pain.

In this post I’ll explain and demonstrate an algorithm that simulates a group of entities grouping together, illustrating something called “flocking”. I think it’s quite neat because the flock exhibits some complex collective intelligence when just a few simple governing rules are applied to each entity.

It seems clear to me that today, web development sucks.

It’s hairy, scary, maybe even downright abominable. Here I’ll try and explain why I think our current tool chains are inadequate, and where I think we should be going to fix it.

The core of the problem revolves around the most exciting domain in web application development today: Javascript. The explosion of Javascript has given rise to amazing applications of stellar quality for quite some time now, but I see them coming only from teams with gobs of time and expertise.