First class failure scenarios in Java

Checked exceptions were an effort by the designers of Java to express the possibility of failure in the type signature, aiding users of these methods in handling the failure scenario gracefully. While the intentions of the design were noble, the end result did not pan out as expected. Most Java programmers have dropped checked exceptions in favor of their unchecked counterparts. Contemporary Java allows us to express failure in the type signature in new and better ways. In this post I’ll explain why checked exceptions have fallen out of favor and what better approach there is to expressing the possibility of failure.

Read more →

Advent of code day 8: how simple things can be very hard (…for some people)

This is the first time I joined the Advent of Code event. The last time I did some serious programming was in 2002 (with a short non-professional intermezzo in 2012). Also, I decided to use Python, for the sole reason that I want to learn Python and use it next year. On day 8 I was confronted with the fact that people do neurological differ and my neurological peculiarities tripped me up quite badly. But in a fun way, at least now, when I am looking back.

Read more →

Advent of Code Day 7: share your workflow

As we’re getting into the flow of things again, I notice that there’s a rhythm to approaching a puzzle that is just as much a part of solving a puzzle neatly and efficiently as the puzzle itself. Here’s my workflow, what’s yours?

I start by creating two files: a .py file with the template shown below (, and an empty text file for the puzzle (AoC-2019-input-7.txt). Then I start reading the puzzle. By the time I get to the puzzle input link, I can then just Ctrl+A Ctrl+V the data into the input file.

#!/usr/bin/env python3

"""Solution for Advent of Code challenge 2019 - Day X"""

__author__ = "Serge Beaumont"
__date__ = "December 2019"

def load_input(day):
    with open(f"AoC-2019-input-{day}.txt") as infile:
        return [[int(y) for y in x.split(',')] for x in infile.readlines()]

def do(data):
    return False

if __name__ == '__main__':
    # Run tests
    # assert do(XXX) == YYY

    # Load data
    data = load_input(0)

    # Solve puzzle
    result = do(data)

    # Output
    print(f"Part 1: {result}")

The very first thing is to make sure that the data loads correctly. The print(data) statement in the .py file is there for that specific purpose: I tend to remove it later. Based on the need I might need to split lines, strip whitespace, and split data into tuples. The template above shows one of the more involved versions: read all lines, split along comma boundaries, and convert all numbers to ints. Come to think of it, this year hasn’t been so regex heavy as other years – so far…

The next step is to copy all the examples into assert do(example input) == expected output lines. There are two things that are important to me in my testing approach:

  • having all the examples execute before the actual puzzle: by the time all tests run the actual puzzle tends to execute cleanly, which is a big time saver when processing takes a longer time, and
  • using a do() function so the puzzle can be transparently called either from a test or with the actual puzzle data.

When I try a solution on the puzzle page and it’s wrong, you get a page with some information, sometimes even if the answer was to high or too low. I add these as assert statements at the end of the file.

When I solve part 1 correctly, I first read Part 2 before I decide if I integrate the solution of Part 2 into the Part 1 code, or if I use a separate .py file.

This year I even split out the full IntCode computer in its own library. I’ve seen people complain about having that computer in there for three days, but I’m curious to see what Eric The Puzzle Master Wastl has up his sleeve. What I like about the three days of IntCode computer is that it has allowed/forced me to refactor the code, which is an interesting change to the throwaway code you can write if it’s only for a single day…

If there’s anything else that’s consistent in my approach it’s my timing of shower and breakfast. I intentionally read the puzzle before shower and breakfast, try at a solution, and then force myself to my daily routine. I’ve found it helps me a lot if I mull over the puzzle for a bit while I’m not staring at the screen. I think 80% of my breakthroughs are during that “away time”.

That’s my approach. What’s yours?

Advent of Code: How Excel made my day – and saved my son’s day, too

Ok, I have to admit, I am NOT a developer. My coding skills are extremely limited to some features on Scratch and the fact that I can change an H1 in HTML on a website.

So, when my colleagues asked me to support our yearly Advent of Code activities at Xebia, I definitely limited my commitment to the “let’s get you guys out there and make some noise” part. In other words: promote on Social Media that there is a group of around 30 development enthusiasts, setting their alarm clocks at six AM every morning to solve the latest challenge on

Read more →

How to use Mycroft in a different language

Mycroft is a voice system that can be configured for any language but it requires language files and most importantly a parser for that language. I was listening to some music the other day and this one line in a song really struck me: “Praat Nederlands met me” (“Speak Dutch to me”). I have been working on a Voice Assistant built on Mycroft for quite a while now but it was always in English. So I thought “How hard can it be?”. Well it is not that hard, but I learned a lot along the way. I’ll show you the steps you need to take to achieve this followed by some insights into how language support is evolving within the Mycroft ecosystem.

Read more →

Show who is pair programming on tasks in your Azure DevOps boards

Are you using pair programming to learn from your peers, write better code and save time spent on code reviews? In that case, you might want to make it visible on your digital issue board too. However, in Azure DevOps, you can only have a single assignee per task. Through customizing your process and board you can still show who are working together on a task. Here is how to do it.

Read more →

Epic Focus: Measure your way to a better time to market

There are several recurring wishes our clients bring to us, one of which is speed, to improve time to market. However, there is no dial that we can turn to deliver value faster. Software teams are not like cars; there’s no accelerator pedal. Even if we try to speed up by adding more resources, in many cases, the actual bottleneck will just become more apparent.

In our search for increased delivery of value, we hunt for these bottlenecks. No two contexts are the same, and for this story, we have a particular context in mind. Symptoms in different organizations are often similar, and our story might apply to your setting if you recognize the problems we encountered.

Read more →