Not a very long time ago, I found the Ruby object model very confusing. Part of my problem was that I was trying to model the relationships as a directed acyclic graph, whereas in reality, the model contains cycles. I’m guessing that others have found this confusing, so I’m going attempt to explain how it works in a way that my past self would have understood! Note that this is a basic explanation, and glosses over higher-level concepts like the eigenclass/metaclass (I’ll leave that for a later post).

Back in April I got a Kindle for my birthday. It’s changed my tech-life massively, and I thought I’d write a few words on that here, from a developer’s perspective. (Disclaimer: the Amazon links in this blog post are Amazon Affiliate links, which means I get a percentage of any sales resulting from you following them. If you don’t feel I deserve that percentage, then feel free to go to amazon.

In the previous post I showed how good use of Underscore.js’s map function can substantially increase the quality of your code. This time I’ll explore some other functional collection favourites: reduce, select and all. Reduce that array over a low heat until thick and creamy Have you ever had to do something like this? Basically, this is going through some kind of list of values, calculating a new value from each one and accumulating some kind of answer.

So, you’ve been developing in JavaScript for a while, you’re getting on quite well with your for and while loops, when somebody comes along and tells you you shouldn’t be doing that, that JavaScript is a functional programming language and there’s much better ways to solve most problems that with loops. Whaaa…? Well, that’s what I’m here to tell you anyway. What is functional programming? Functional programming (FP) is all about the idea of functions as a mapping from one value to another.

JavaScript is such an important language today. It’s stopped being a toy scripting language, and become a serious programming language. Unfortunately, the vast majority of JavaScript developers don’t unit test their code. Testing is a vital part of modern development. Code without tests isn’t code - it’s random scribblings that may or may not be executable. Even if they are executable, the only way you can tell if they all work is by loading your application or website, and trying out every single thing that a user could possibly do.

As a developer, my job is to make software. To start off with, this software lives only in my head. Programming is the act of extracting the software out of my head and into the computer. The keyboard is the interface between my brain and my computer. There are times when I’m primarily thinking, and my speed on the keyboard doesn’t matter. But when a thought comes to me, I want to get it out of my brain and into the computer as fast as possible, or I might lose it.

Apparently they started out using God, but switched to Bluepill due to its ability to monitor child processes, such as things spawned by Unicorn. From Episode 166 of The Ruby Show.

As web developers we’re working through a transitionary period. New technologies are becoming widespread enough to be usable in real web apps - not just toys. After years of stagnation in JavaScript engines, Google Chrome started an arms race in speed, with all the major browser makers competing to make the fastest JavaScript interpreter. These changes are opening up a new world of web app development that hasn’t been fully explored yet, but this means we may have to rethink some of the best practices we’ve been following for the past decade.

This is a follow-up post to JavaScript and the end of progressive enhancement you may want to read that first if you haven’t already. The comments are worth a read, as well as the Reddit thread. The app/doc divide What I didn’t make clear in my original post (because I wasn’t fully clear about it at the time) is the distinction between document-based web sites, and web applications. Documents are made to be read, whereas apps are made to be interacted with.