Back in 2011, in my first year on the BSc Software Development, I built a link shortening site. The project was pretty much abandoned within half a year and has been lying dormant since.

This is how the main page of the site looked:

I have recently started migrating things to a new server, and that brought me to reevaluate the site. It is currently offline, so you will have to rely on the pictures I show here for an idea of it.

One part of the application is showing statistics over who has visited a link. This happens by recording a visit whenever a visitor accesses a link. For example, if you visited http://drng.dk/1 the application would record your user agent before sending you off to the destination, http://hypesystem.dk.

I wanted to show a breakdown of what browser and operating system a user was using to visit the site. When I was creating the data model and the corresponding...

In 2015, I started drawing things that I wrote about. I also started writing a whole bunch more. Here is an overview of some of what I wrote during the year, including all the illustrations.

Leadership and Workplace

Team Leaders Should Shield Developers was my first claim about leadership. It is impossible to get anything done while being constantly interrupted or while under constant pressure. It is the (tough) job of Team Leaders to deal with the pressure, and relieve the developers of it, I argued.

In the image above, a Team Leader is at a meeting while the developer gets some work done.

In Workspace Ownership, I argued that the best work is done in a workspace where the developer feels comfortable. Comfortability can, for example, be achieved by allowing fun (and useful) activities, such as pingpong, in the office.

Most popularly, in this category, I wrote about what I...

Adding debounce to a function results in the function is only run once a break has occurred in triggering.

Simple debounce

If a user is typing in an input field (a search field, for example) you don’t want to perform a HTTP request for each keystroke. Debouncing the keystroke listener will result in a HTTP request being sent once the user stops (or has a break in) typing and not before.

Debouncing is implemented with a debounce function, which takes a inner function (the action) and a delay (the time that should pass with no triggering before the action is taken).

My best suggestion for a simple debounce function (after writing something, then looking at the one in lodash, the one in underscore, and finally stumbling upon a great one by @rem) looks something like this:

function debounce(fn, delay) {
  if(typeof delay == "undefined") {
    delay = 250;
  }
  var timer = null;

Back in February 2015 (a year ago!) I wrote that I wouldn’t recommend Scrum. Looking back I see that I was merely grasping at the end of a bigger concept.

Here I will try to clarify and generalize from the original post.

I would like to reiterate that I do not think Scrum is bad nor did I argue so in the original post. I understand that, based on the title, it is reasonable to assume that that was my point.

This post is called I wouldn’t recommend process but I do not mean to say that processes are bad and should be avoided. Processes can be valuable, as long as they are not overly bureaucratic and do not get in the way. Processes are helpful when they codify what is already being done and free up cognitive resources.

My first introduction to the world of Agile software development came through Extreme Programming Explained (XPE) Second Edition. Extreme Programming is known by...

If you want your text to flow nicely on responsive web sites, there are two tricks I like to use: soft hyphens for optional break points, and text-overflow ellipsis for situations where there is only room for a limited amount of text.

One at a time, now.

Soft hyphens

A soft hyphen &173; is an optional breakpoint for a word. The browser will determine, when layouting, if this breakpoint should be used. If the word extends across the right-most side of the box it is in, it will break.

I made a quick little example with a resizable box that lets you see the effect.

This will also work as your layout shrinks and grows, making your text look good, with text lines of similar length.

We used this on Mærkelex to make sure the names of badges were always readable, even at very dynamic sizes of containing divs:

Text-overflow

You probably know about the CSS attribute overflow. It lets...

Here’s a quick idea for making your code more readable.

In your code you want a method to get a specific user, getUser, but you also want a method to get all users, getUsers. These two functions will inevitably have different interfaces:

db.getUser(id); // id distinguishes this user from others
db.getUsers();

As a developer you spend a lot of time writing code, but even more reading it. While the distinction between User and Users is clear enough when writing it, it is easily overlooked when skimming through code. A mistake, such as leaving out a letter, can easily be overlooked because the reader expects the correct form to be used.

My colleague Asbjørn Thegler made the excellent point to me that there is a simple solution for this: be explicit in plurality.

This means writing getAllUsers instead of getUsers, lessening the similarity between the singular and plural forms...

I don’t have any New Years Resolutions for 2016.

My New Years Resolutions for 2015 — the first New Years Resolutions I’ve ever made — were:

1. Publish 24 blog posts
2. Publish an illustration or drawing each month

The tally at the end of the year was:

1. 22/24 (no posts in December)
2. 11/12 (no drawings in December)

So, I failed. I failed to reach the goals I set at the beginning of ‘15. That’s the simplest way of putting it.

Many people see resolutions as promises made to themselves. I chose deliberately not to. Breaking a promise to yourself is a horrible and harsh thing to do, and definitely not something that anyone would want to become a habit. Making promises only to break them is lying to yourself, and that is never good. Moving forward requires being honest with yourself.

Seeing a resolution as a goal (not a promise) changes things. A goal is something you strive for. Something...

This is a general lesson I learned and it is a story. It’s also about software. Eventually. I swear!

I went to the pharmacy to get a new pack of astma medicine. I had been to the doctor recently, because I felt like my astma had been getting worse. I had gotten short of breath from trivial exercise, like cycling a bit fast. That doesn’t normally happen.

“Do you know how to take the medicine?” asked the woman behind the counter. I had heard that question before. I had always politely declined their offer to show me how to use the inhaler—after all, I had used it for years—but this pharmacist was friendly and grandmotherly and when I said that I had been taking the medicine for years she said that maybe I had forgotten how and she made it sound like a friendly suggestion instead of accusatory and doubtful. So I said yes. Please. Maybe I have forgotten.

I paid for the medicine, she put...

In Software Is Never Finished and Code Can Always Be Improved I mentioned that you get to know systems better as they grow:

You get to know a system as you are building it, and, in the process of doing so, realize what fits and what doesn’t. The longer you work on a system, the more you test and stress your early abstractions, the more likely it is that you will find a better abstraction for your system.

What I describe in that post is a sort of uncovering. But an uncovering of what? I like to think of it as the system’s personality. As with a person it is the upbringing that eventually shapes what it will like and dislike and how it will behave when matured.

Systems never stop changing, but the early stages of their development are often the most important to what they will end up doing. A system with a rigid personality will never do more than it does, never be used in new...

“Software: never finished, only abandoned,” John Saddington paraphrased Leonardo da Vinci, around a year ago, in the best blog post I have found for the well-known adage “software is never done”. Where it actually originated I have no idea.

A lot has been written on this saying, but in a lot of cases there is also what I would characterize as confusion of the concept of software, leading to an unconstructive debate. I define two separate terms: software, which ideally helps or solves problems for people, and code, which is ideally the means of producing fault-tolerant, extendable software.

Software consists of code and code builds software, but they are two different things at separate levels of abstraction. I think it is more constructive to discuss each separately, to see if it is true that (a) software is never finished, and (b) code can always be improved.

I define Finished...