We’ve all seem them before. They’re everywhere! In fact, it’s probably one the most popular anti-pattern in software development. I’m talking about the setter methods.

class Person {
    private String name;

    public void setName(String name) {
        this.name = name;
    }
}

Here we have a class Person with a setter method for the property name. It looks pretty innocent, right? But what’s really the difference to the following class?

class Person {
    public String name;
}

Uugh, that’s nasty!

If you’ve been working with an object oriented language before, you probably know that it’s a bad idea to expose a property to the public like that. But what’s really the difference to have a setter method?

None.

When you have a class with a setter method, or a public property, you expose its values to the public and allow anyone to mutate them. By doing so, you introduce a shared mutable state to your application. This is bad for several reasons. One of them is that it becomes hard to understand where the values origins from since they can be written in one place and read from another (and let’s not even talk about multithreading). When you have an application full of objects like this, the entire application becomes hard to reason about and bugs will follow.

You might argue that having a setter method is better than a public property. What if we need to apply some kind of logic, like validating the name, before setting the value? Then we can use the setter method to validate it before we set it. First off, is it then still a setter method? Either way, I bet that if you have a look in the code of your current project, it’s very likely that you won’t find much logic in your so-called setter methods. And even if you find a few cases where more logic is needed, there are better ways to approach this!

But don’t get me wrong. I don’t suggest that you should expose your properties publicly instead of using setters. Instead I suggest that you shouldn’t create a mutable object in the first place. Always make the properties immutable! If you need to change the value of a property, let’s create a new object with a different set of values. With this very simple idea you solve all the hard problems caused by a shared mutable state. You should have a very good reason to create a mutable object, and performance is likely not one of them.

My suggestion: Make all the properties final/readonly and set the values in the constructors. That’s it!

(This post is in Swedish)

Har du någonsin undrat hur budgivningen påverkas av vädret på visningsdagen? Det har jag!

tl;dr Nästan inte alls faktiskt.

Jag tittade ~2600 lägenhetsvisningar i Stockholms kommun mellan vecka 12 aug-18 dec 2014 och jämförde dessa med nederbördsdata från samma period. Som man brukar säga, en graf säger mer än 1000 ord:

Data från Booli.se och SMHI

The engagement KPI represents how much a user is engaging with the content on a site. In many domains, it’s an extremely relevant number to look at and track over time. If a user is engaging a lot with the content, he/she is probably more likely to convert compared to an average user.

What conversion really is depends on your domain. For example, if you are running an e-commerce store a conversion could be to actually buy something, i.e. complete the checkout flow.

But the engagement KPI does not only indicate how likely it is for a user to convert, it’s also a good way of measuring the quality of your content. It’s likely to think that a product with crisp images and a great product description will engage a user more than a product with a crappy image and description. The engagement KPI also says a lot about the UI and the over-all user experience. If the user cannot find the information, then it’s of course impossible to consume it. It encourages users to spend more time on the site, look at more products and in the end being a more satisfied customer.

If you aren’t already tracking user engagement, it’s about time!

How to track and measure it

The engagement KPI has a bit of a bad reputation when it comes to actually measuring it. And no wonder why, the definition of the KPI is pretty fuzzy. But it doesn’t have to be that hard! Google Analytics comes with a great set of tools to help.

The basic idea is simple. We use event tracking in Google Analytics to keep track of what the user has done on the site. We then assume that the more actions a user has completed, the higher is the level of engagement.

First off, we need to come up with actions that indicates that a user has engaged with the content. We then score each action with a number of points, where a higher number means that the action is more valuable. An example of actions and scoring for an e-commerce store could be something like this:

Action Score
Visits a product 1 point
Clicking on a product image 1 point
Have looked at all the images in the slideshow 2 points
Clicking on a link in the product description 1 point
Put the product in the shopping cart 3 points

If a user has done all of these actions, he/she definitely seems interested in buying the product. And that’s exactly what we want to measure!

To get this up and running in Google Analytics:

  • Track an event for the action
  • Set up a goal for that action
  • Set the goal value to the number of points for the action

Goal values in Google Analytics is typically measured in USD (or any other configured currency). But that doesn’t matter, you can simply think of 1 USD = 1 point.

Getting the reports

Now comes the hard part: Waiting. Goals in Google Analytics are not applied retroactively, so we have to wait for new data. While waiting, we can setup some reports to get a better understanding of how the site is being used.

Let’s first define three new segments: Low-, medium- and high-engagement users. We segment the users based on goal value, which is the total score of the user. You can think of low-, medium- and high as buckets for our users, where a user can only be placed in one bucket at a time. The only thing we need to do is to come up with limits for these buckets, this could for example be:

  • Low, 0-2 points
  • Medium, 3-4 points
  • High, 5+ points

Sidenote: Make sure to segment based on user goal value and not session goal value, otherwise the user will not keep the score between visits. User-based goal values are by default kept for 7 days. Meaning a returning visitor will add points to its previous score, which is exactly what we want.

We can now get all our usual reports segmented by engagement. How cool is that? For example, you could evaluate things like:

  • Where do high engagement users come from? Direct traffic? Google? Facebook?
  • Which part of the country attracts most high engagement users?
  • How did the last marketing campaign go? Which one generated the most medium- and high-engagement users?

And the most important of them all: We can now track how the proportions of these segments change over time. Are our users moving from low-to-medium and from medium-to-high? If that is the case, then we’re building the right things.

Summary

The engagement KPI is a great way of getting to know our users. It can help us prioritize what to build and how to build it, and since it integrates well with Google Analytics it easily can combined with A/B-testing. To get it set up doesn’t take long. As soon as the events are reported to Google Analytics, it’s just a matter of configuration.

There’s been a lot of buzz around Gulp lately, and one of the most common arguments for switching from Grunt to Gulp is speed. Gulp is tremendously fast! However, what I have experienced is that Grunt is often unnecessarily slow due to a poor configuration. If you are running Grunt today, it could be a good idea to speed up your tasks instead of paying the price of switching to another tool.

Grunt-time is a great node package to analyze your setup, it visualises how the time is spent when running Grunt tasks.

It turns out that in many cases, most of the time is spent on loading Grunt tasks instead of running them. A common setup for Grunt looks something like this:

module.exports = function(grunt) {
  grunt.initConfig({
    jshint: ...
    watch: ...
    jasmine: ...
    sass: ...
    requirejs: ...
  });

  grunt.loadNpmTasks('grunt-contrib-jshint');
  grunt.loadNpmTasks('grunt-contrib-watch');
  grunt.loadNpmTasks('grunt-contrib-jasmine');
  grunt.loadNpmTasks('grunt-contrib-sass');
  grunt.loadNpmTasks('grunt-contrib-requirejs');

  grunt.registerTask('jslint', 'jshint');
};

Let’s say that want to run the jshint task, what happens is that Grunt will first load all the tasks specified by grunt.loadNpmTasks(), and then run the actual task. In this case we are loading several modules that will never be used. This can very well take quite some time.

Compare the configuration above to this other example, where we only load the tasks that are about to be used.

module.exports = function(grunt) {
  grunt.initConfig({
    jshint: ...
    watch: ...
    jasmine: ...
    sass: ...
    requirejs: ...
  });

  grunt.registerTask('jslint', [], function() {
    grunt.loadNpmTasks('grunt-contrib-jshint');
    grunt.task.run('jshint');
  });
};

Faster execution time → Shorter feedback loop → Epic win.

Last week I held a keynote at @ValtechSweden about web performance, and in particular the basics in how to optimize your page load time. The video is now available at Vimeo. As a disclaimer I should probably mention that the talk was given in swedish, sorry about that.