Complexity is the mind-killer

Chess moves

Last week I read an article from the MIT Technology Review that looked into what causes people to make mistakes. The approach was one I hadn’t seen before: it used data mining on a set of chess games. Their rationale was that:

  • There’s a huge database to feed your model from,
  • Chess is a deterministic domain where you can objectively evaluate good and bad moves,
  • There are clear criteria for the skill level of the participants, even when disparate, which allows you to balance.

As spoiled by the title, complexity was the main factor whenever a player made a mistake.

The bottom line is that the difficulty of the decision is the most important factor in determining whether a player makes a mistake.

So what’s the big deal?

Relevance is now open source

I’ve released Relevance, my smart tab organizer for Chrome, under the MIT license. You can find the ClojureScript source code on GitLab, and the extension on the Chrome web store.

Flexibility Through Immutability, part 2: How and When?

The second part of the original text for “Flexibility Through Immutability“.

The first part focused on the why of immutable data. On this part I’ll review what to do about if you’re working on an object-oriented language.

Flexibility Through Immutability, part 1: Why?

Here’s the original text for “Flexibility Through Immutability“, for those of you who prefer reading to watching a video.

It’s a bit of a long read, so I’ve divided it into two parts. The first one focuses on the motivations behind preferring immutable data, and the second one (which will go up on Wednesday) on how to go about it.

The framework mirage

OK, this is going to be a tough one. Strap down, even if it pisses you off at first - I wouldn’t be writing it if I didn’t think it was helpful.

Stop me if you’ve heard this one before

A programmer has something he wants to build.

He finds a framework.

It looks easy enough to get into. There’s a few tutorials available, which show step by step how to build a basic application of just the right type.

He’s happy. He feels really productive. CRUD just “drops out” of the framework’s design. It’s like it was created with his problem in mind.

Then he’s done with the tutorials. He starts plugging in his own, specific requirements. Every so often he hits a snag, but that’s OK, he can just twist the framework’s arm a bit, right?

It all goes well for a while. Then he hits a big one. The framework doesn’t do quite work the way he wants it to.

Flexibility Through Immutability

While functional programming has a lot of advantages, the more I worked on the paradigm, the more surprised I was at how much thinking in a functional manner made refactoring easier.

As happy as I am to sell people on Clojure, I realized that teams could benefit from adopting some functional programming ideas even on their current language. I decided to try a different approach, and gave a talk at the 2016 ITAKE Unconference in Bucharest, elaborating on the benefits of immutable data. I wanted to focus on how the functional paradigm has a value in-and-of-itself. A secondary goal was to provide some tips that teams who can’t yet pull away from C# or Java can put into effect to help.

You’ll find my screen recording, as well as the slides, below.

AWS Lambda, Clojure and ClojureScript

Introduction

In case you’re not familiar with them, AWS Lambdas are a fascinating idea - they are server functions you can create and run without first provisioning servers: you write your code, upload it, and pay only for the time that is executed.

There’s only one (somewhat minor) catch: given that there is no provisioned server capacity at all, the first time that you execute a lambda it has to be warmed up. The code stays live for a period of time after the first execution, but given Clojure’s start up time cost, I was wondering what effect that would have on a Clojure lambda.

Clojure and DynamoDB with Faraday, Part 4

Update and friends

This is the final part of the series where I convert Amazon’s Getting Started to Clojure with Faraday. If you’ve just arrived, the previous parts were:

This part will correspond to steps 7 and 8 of the Getting Started guide. Let’s move on to updating and deleting data!

Clojure and DynamoDB with Faraday, Part 3

Welcome back

In part 1 we went over the basic table creation operations, as well as writing data, and on part 2 we looked at getting, querying and scanning data.

We’ve only been working with the primary key so far, but often we’ll want to get data using a secondary index. On this part we’ll follow step 6 of Amazon’s Getting Started. We’ll see how to create, query and scan them, as well as how Faraday handles these asynchronous calls.

Clojure and DynamoDB with Faraday, Part 2

The story so far

On Part 1 we went over the basic operations - creating a table, checking its status, getting data in and performing a simple retrieval.

We’ll now look into various ways of retrieving items, including querying, scanning, and using projections to get only a few properties.

This assumes you’ve already completed part 1, since we’ll be using the data we added. As a reminder, I’m following the Javascript examples on basic DynamoDB operations, since they are the ones where the data set-up will more closely match Clojure. You may want to follow along for extra explanations and for comparison purposes.