04-06-2016 - The most provocative algorithm ever made

    You'd think that playing music without skippping would be something
    users would demand from Spotify. Seriosuly, how hard can it be to get
    this right? An analog record player does this without missing a beat
    (pun belabored). 
    However, judging by the sheer rage ciculating forums and comment
    sections online, it seems their users are orders of magnitude more
    upset over their shuffe algorithm.
    These are some of the comments in an ascending order of rage. 
        "For the past couple of weeks I'll skip the same song repeated 1-2
        in a string of about 10 songs, out of 4000+ from my starred list."
        "I've had the same song from my 1,100 track starred list play
        twice in my 35 minute commute."
        "Just did a quick test and my playlist of 48 tracks will only play
        10 of the same songs over and over again and none of the other
        "I've noticed this and am convinced that random isn't random. I
        imagine their random is actually a profit maximization model."
        "I listen to playlists with about 100 songs and with shuffle on,
        it will regularly repeat songs and only play a select number of
        songs instead of going through the whole playlist. This is with
        repeat off. A song will literally repeat after it has just played
        for goodness sake, something isn't right here.."
        "Are you fucking kidding me spotify? This whole article? How about
        another is played a second time! I've had premium over a year. You
        guys are ass."
    So what is going on? At first I chalked this up to the Gamblers
    Fallacy [1].  WIRED wrote an article explaining why true
    randomness is clustered, and not evenly distributed like most people
    intuit. This is the same reason the Brits mistakenly assumed
    that the Germans had an exceptionally good aim with their V-1 flying
    bombs during World War II [2].
    With that said, I have a hard time seeing how the engineers at Spotify
    could mess this up. Shuffle is basically self-explanatory, especially
    if you've ever held a deck of cards. To shuffle a playlist you simply
    change the order of the songs randomly, just like you would when playing
    a card game.
    I rarely activate shuffle on my own playlists, which made it hard to
    confirm the alleged shortcomings above. Fortunately it is quite easy
    to interact with the user interface using AppleScript.
        #!/usr/bin/env bash
        function spotify {
          osascript -e "tell application \"Spotify\" to $*"
        function play_all_the_songs {
          for i in {1..100}
            spotify next track
            ARTIST=`spotify artist of current track`
            TRACK=`spotify name of current track`
            printf "%s - %s\n" "$ARTIST" "$TRACK"
        if [[ $1 = "continous" ]]; then
          spotify set shuffling to false
        elif [[ $1 = "shuffle" ]]; then
          spotify set shuffling to true
    The script above presumes that you have Spotify running and a playlist
    containg 100 unique songs opened. It plays through the entire playlist
    and writes the name of the artist and the song name of the current
    track to stdout. The first argument determines if shuffle should be
    activated or not.
        $ ./listen-through-playlist.sh continous
        Paolo Nutini - New Shoes
        Radiohead - Creep
        The Cars - Drive
        Kendrick Lamar - Backseat Freestyle
    It is trivial to assert that the playlist in fact shuffles the music
    without playing any song more than once. Simply diff the output from a
    continous run against a shuffled run. They contain the same tracks.
        $ diff <(./listen.sh continous | sort) <(./listen.sh shuffle | sort) --report-identical-files
        Files /dev/fd/11 and /dev/fd/12 are identical
    The claim that a song is played more than once, effectively
    duplicating it in the queue, is false. In other words, Spotify
    is undeservingly on the receiving end of a shit storm caused
    by a failure of intution.
    [1] https://www.wired.com/2012/12/what-does-randomness-look-like/
    [2] https://www.britannica.com/topic/Poisson-distribution

    24-07-2015 - Red-Green-Refactor

    Last Christmas I decided to give TDD a try after being inspired from
    Gary Bernhardts screencasts at DestroyAllSoftware.com and reading
    Robert C. Martins book "Clean code". After overcoming the
    counterintuitive nature of writing tests before the actual code, I
    discovered that TDD improves my productivity and overall confidence in
    the code I write.
    In this post I try to define what I regard as a good test, why I like
    practicing TDD and why integration tests are not that useful. Most of
    the ideas in here are borrowed from Robert C. Martin, Gary Bernhardt,
    Martin Fowler and Kent Beck.
    # What to test? 
    TDD is hard. 7 months in I still find it difficult to write valuable
    tests. This is actually the biggest challenge you'll run into when
    starting out: What tests should should you write? There is no definite
    answer, but I've found that testing code that I have a tendency to
    screw up is a good way to start.  However, that's a pretty pretty
    vague and relative heurustic so let me demonstrate what I would
    describe as a worthless test:
        describe('Person', () => {
          describe('name', () => {
            it('should be possible to set', () => {
              var mike  = new Person();
              mike.name = 'Michael';
              assert.equal(mike.name, 'Michael');
    In order to screw up the logic that makes this test pass I would
    somehow have to mess up the setter-method of the name-field in the
    Person class. I find that unlikely and therefore consider this test as
    unnecessary. This becomes even clearer if write the code that makes
    that test pass.
        class Person {
    That's it. The test would now pass. In other words: The sole existence
    of the Person class is enough to pass this test. Let's look at
    different example of a test I consider more valuable.
        describe('Person', () => {
          describe('name', () => {
            it('should be separated by whitespace if first and last name is set', () => {
              var mike = new Person(); 
              mike.firstName = 'Michael';
              mike.lastName  = 'McMillan';
              assert.equal(mike.name, 'Michael McMillan');
            it('should only return first name if last name is not set', () => {
              var michelle = new Person(); 
              michelle.firstName = 'Michelle';
              assert.equal(michelle.name, 'Michelle');
            it('should only return last name if first name is not set', () => {
              var mcLovin = new Person(); 
              mcLovin.lastName = 'McLovin';
              assert.equal(mcLovin.name, 'McLovin');
    This code would pass that test [1]. 
        class Person {
          get name () {
            return ((this.firstName || '') + ' ' + (this.lastName || '')).trim();
    Although this may seem like a no-brainer, it's not something I want my
    code to mess up. I want confidence in that a persons name is properly
    formatted throughout my application. This test will ensure that. If
    anyone were to mess around with that code at least one of those tests
    would necesarrily fail and hopefully keep a bug from entering the code.
    # Monstrous tests 
    Practicing TDD implies unit testing. Unit testing is hard to define
    and I don't want to be pissing on anyones bonfire [2], so I'll rather
    just piggyback off Gary Bernhardts definition: A unit test is when
    "Other classes cant break [the test]". In the previous example no
    other class can interfere with the result of our test because we are
    only testing the only relevant class: Person.  For that reason we can
    claim that we are testing the logic of a Persons name in *isolation*.
    It is perfectly fine to write tests that are not unit tests, I just
    find them to be a lot less valuable, especially system tests, also
    known as integration tests. TDD provides you regression, design and
    easier refactoring. Integration tests on the other hand can only tell
    you if you have broken something (regression) somewhere in the stack.
    Not to mention they take a lot of time to run.
    Imagine you have an application exposing a REST API over HTTP. In
    fact, let's pretend it's the same application as the one containing
    the Person class above. Had we written an integration test instead of
    a unit test our test would probably look something like this.
        describe('Person', () => {
          describe('name', () => {
            it('should be separated by whitespace if first and last name is set', (done) => {
              .send({ firstName: 'Michael', lastName: 'McMillan' })
              .end(function(err, res){
                var mike = res.request.toJSON();
                assert.equal(mike.name, 'Michael McMillan');
    Although we are testing the same logic as before, we are dependent on
    a whole lot of classes and dependencies to not break us. More
    specifically: The web server/proxy (nginx/Apache), the router
    (Express), (perhaps) the database and the HTTP client. Additionally it
    takes a lot more time to complete this test.  In fact, without mocking
    the network layer this is what would happen behind the scene when
    running it [3]:
        1. Client/Server establishes a TCP socket (handshake)
        2. Client POSTs the HTTP request 
        3. Server receives HTTP request
        4. Server parses HTTP request and routes to correct controller
        5. Controller constructs a new Person class with request parameters 
        6. Person class applies logic to return the name correctly
        7. Sever responds to client with a JSON serialized Person object
        8. Client parses response and asserts that the name is correct
    If one of the steps above fail we've been broken by code that
    essentially has nothing to do with the actual logic we're testing: A
    Persons first and last name should be separated with whitespace.
    However, this won't go unoticed: Our test will kindly inform us that
    it didn't pass, from there we need to dig through the entire stack in
    order to hunt down the bug that broke the test. It could be anywhere,
    it could even be located in code we haven't written ourselves.
    # There's a pattern here somewhere ...
    TDD forces you to focus on the application specific logic. If you were
    told to create a web application that had a simple HTML form that
    POST'ed a word to the backend and responded with its Scrabble score,
    where would you start?
    I think most developers would get so disorientated by the word "web
    application" that they'd start by installing a web framework like Ruby
    on Rails, Sails.js/Express or Laravel and start configuring routes and
    controllers in order to complete the task.
    But by practicing TDD (or Unit Testing for that matter) you would be
    forced to start with writing a simple test.  Something along these
    lines is probably where you'd start: 
        describe('Scrabble', () => {
          describe('score', () => {
            it('should be 0 for empty word', () => {
              var word = new ScrabbleWord(' ');
              assert.equal(word.score, 0);
            it('should be 20 for the word "quick"', () => {
              var word = new ScrabbleWord('quick');
              assert.equal(word.score, 20);
            it('should be 20 for the word "quick" in capital letters', () => {
              var word = new ScrabbleWord('QUICK');
              assert.equal(word.score, 20);
            it('should be 20 for the word "quick" reversed', () => {
              var word = new ScrabbleWord('KCIUQ');
              assert.equal(word.score, 20);
            it('should be 7 for the word "slow"', () => {
              var word = new ScrabbleWord('slow');
              assert.equal(word.score, 7);
    As you can see our test is completely agnostic as to whether this is a
    web application or not. This test has essentially helped us separate
    the business logic of calculating Scrabble scores from the I/O channel
    (HTTP). Imagine if the next task was to transform this Scrabble
    calculator into an IRC bot, a command line tool or even a desktop
    application with a GUI. We would only need to change the layer that
    interacts with the client - *not* the entire framework.
    My example may seem contrived due to the small amount of code that
    requires to complete the task of setting up a simple app calculating
    Scrabble scores, after all the algorithm computing the score more or
    less consists of a for-loop and a hashtable. But as with most
    software, complexity gets added with time. If this Scrabble calculator
    one day were to be converted into an actual Scrabble game you would
    only have to write more tests (with corresponding code of course) to
    stay decoupled.
    [1] I arrived at that code after iterating over red-green-refactor
    three times. I skipped that process in order to keep it short and
    [2] DHH on TDD unit test definition:
    [3] https://github.com/alex/what-happens-when#dns-lookup

    25-04-2014 - Studjobb

    While looking for a summerjob online, I realized how tedious and
    uneffective the whole process was. Scouring 3-5 websites in hopes of
    finding someone willing to hire a freshman is not easy. Mostly due to
    the lack of filtering.
    Jason Fried (founder and CEO at Basecamp) said something that stuck with
    me for a while.  
    "[...] It's important to solve your own problems, and to recognize
    that your problem is not unique." I decided to scratch my own itch to
    see if someone else shared my annoyance. Thanks to the great
    prototyping framework Bootstrap, it didn't take long before I had
    Studjobb.no up and running.
    My goal was to make a simple and lazy way of receiving job postings
    for students. After some back-and-forth I ended up with a weekly
    mailing list and a simple table featuring the latest jobs. I also
    added the ability for companies to advertise their positions.
    So far I've only spread the word about the site through a couple of
    internal mailing lists at NTNU. The service is completely automated,
    the only thing that remains is getting the word out.

    01-12-2013 - Referencing sucks

    Paul Graham's essays are always entertaining to read. My favourite
    essay, which I also try to keep in the back of my head whenever a
    "brilliant" idea comes along, is How to Get Startup Ideas.
    "The way to get startup ideas is not to try to think of startup ideas.
    It's to look for problems, preferably problems you have yourself." One
    week ago I decided to solve a problem which has been an annoyance for
    a long time: Referencing. Throughout high-school, being able to
    reference books, articles and websites is an important part of the
    curriculum. Failing to do so will almost certainly negativly affect
    your grade.
    In combination with Bootstrap, Angular, a simple crawler, a
    MySQL-backend glued together with a REST API and some good ol' elbow
    grease - LittList was born.  LittList lets you search for books by
    author, title, ISBN or content, in a huge database consisting of
    metadata for books. The student then proceeds by adding the references
    that were used. Lastly the student clicks Generate and a properly
    formatted bibliography is returned.
    I launched the site on the evening of the 24th of November by posting
    the link to a couple of private Facebook Groups. The response was
    overwhelmingly positive! I quickly received a lot of feedback
    regarding the technical implementation and the general userinterface.
    It was extremely fun, not to mention addictive, to monitor the traffic
    in realtime with Piwik, and getting appreciative e-mails. In the
    course of 5 days the site had received about 5.2 thousand unique
    visitors and over 4.8 thousand bibliographies had been generated.
    It did not take long before other websites started noticing the post
    on Facebook, which was rapidly gaining traction (in the form of likes
    and comments). As a result, StudentTorget.no published an article
    which led to even more traffic. Due to a relativly poor and
    inconsiderate programmed crawler, the CPU of the server LittList was
    hosted on started to choke. Luckily, I managed to resolve the issue
    before crashing the entire box.
    Even though only one week has passed, it has been very rewarding to
    hear that LittList actually helps students who are fed up with
    spending time formatting bibliographies. I guess writing the
    assignment/paper in the first place is boring enough.

    27-11-2013 - Trondheim

    It would be an understatement to say that I'm excited for what my time
    in Trondheim will bring. Being able to study Computer Science has been
    a long-term goal, thus being accepted at NTNU is undoubtely a huge
    achievement for me.
    One of the first things I noticed in Trondheim was the great diversety
    within extracurricular activites you could take part in. There is
    literally something for everyone. I was by coincidence introduced to
    two programs in late September: AppLab and SPARK.
    Both of these programs aims to guide and mentor students with
    startup-ideas towards a minimum viable product. I chose to participate
    in both of them, as AppLab mainly focuses on building an app for
    mobile platforms, and SPARK provides tight follow-ups and personal
    advisory from an NSE-student [1].
    In retrospect I can safely say that I feel very much at home in
    Trondheim.  Being given the opportunity to work on an idea - whether
    it's good or bad - is extremely rewarding and fun! It's a shame that
    programs which try to encourage innovation only seem to be available
    at university. I would have loved to attend something similar in
    I'm really looking forward to the following years.