jump to navigation

Mandatory Viewing 2014w27: “Find the Right Abstraction Level for Your Tests” 2014/07/04

Posted by Angelo van der Sijpt in Uncategorized.
add a comment

Finding the Right Abstraction Level for Your Tests

This week’s Mandatory Viewing is by Gerard Meszaros (the guy behind XUnit Test Patterns).

Gerard talks us through a topic most of us have run in to: you start out with a nice set of readable tests, and while your understanding of the system grows, you end up with lots of cruft in your test code. Your tests no longer describe what the system is doing, but how you need to use the components of your system to make something happen. Good as documentation, bad as specification.

Mandatory Viewing 2014w26: “Play by Play: Jim Weirich” 2014/06/27

Posted by Angelo van der Sijpt in Uncategorized.
add a comment

Play by Play: Jim Weirich

This weeks Mandatory Viewing is Jim Weirich’s Play by Play. Pluralsight has put up this talk shortly after Jim passed away, as a tribute.

In this almost 90-minute session, you can watch Jim take a problem, and iterate through a vast number of API designs, trying to get a feel for how his designs influence the user’s happiness. Even if you don’t know Ruby, you can follow the process of someone who thinks in code, and isn’t afraid to say “let’s try this, and see what it does.”

The process of “trying out” what an API will look like before using it resonates well with me. I prefer to make my tests read as close as possible to the thinking process of an API user. Try to put yourself in the user’s IDE, and try to feel what he’s feeling while using your API; empathy with your user reduces the number of WTFs per minute drastically.

Notable quotes,

  • “The maturity of frameworks can be shown in how good their error messages are.”
  • “We’ve prove the basic technology works. We can write a proxy. Now is the task of finding the right API that works well… if it’s too complex to use, people won’t like it.”
  • “We explored a couple paths that proved unfruitful. I think that’s good in that you explore these things and you find that’s not really what I wanted.”

Software architecture as a wicked problem 2014/05/20

Posted by Angelo van der Sijpt in Uncategorized.
add a comment

While writing my master’s thesis, quite a few years ago, I wrote a trio of supporting papers to help me structure my thoughts. I recently came across them, and was surprised by how relevant they still are, even given what I’ve learned about software architecture in the past years. You might like them!

  • Software architecture as a wicked problem deals with what makes software architecture hard, and how this overlaps with planning problems.
  • An engineer is not a carpenter shows how software engineering is not a real engineering discipline. It contrasts software with other ‘materials’ we work with.
  • Architecting adaptive software is basically a readable shape of my master’ thesis. It deals with what adaptivity is, how you can’t design it into systems, and what factors you can use to make a system exhibit adaptive behavior.

Using XPath to match a key/value paired XML message 2013/03/15

Posted by Angelo van der Sijpt in Uncategorized.
add a comment

In one of my current projects, we have an XML message that looks a little like this.

    <values>van der Sijpt<values>

For testing purposes, I want to use XPath to get values from this, i.e. match first-name to Angelo.

After some fiddling, I wound up with this slightly ugly contraption. Might be useful for you one day, though I hope you can be spared…


Dealing with interruptions as a Scrum team member 2013/01/19

Posted by Angelo van der Sijpt in Uncategorized.
Tags: , ,
add a comment

For the last months, I have coached some engineering teams in a large software-intensive organization. Some are running fine, some need extra work. A topic that regularly pops up is “how do I handle all these interruptions during my day?”

I define an interruption as anything that makes you context-switch away from the work you’re doing for the team. So, questions from teammates are not interruptions. Neither is responding to email at the time of your choosing. Phone calls regarding different projects, or people showing up at your desk with unrelated questions are.

Scrum ask for a distraction-free environment, routing interruptions through the product owner. However, interruptions are a cultural phenomenon, not an organizational one. I will assume interruptions as a given of the current situation, channeling them in a productive manner, and slowly driving them out.

Company culture has its reasons for existence, and is hard to change. I believe there are three intertwined cultural components in interruptions,

  • “it has always worked like this”,
  • there is no pushback,
  • costs are hidden.

“It has always worked like this”

What and why

People have lost trust that goals and deadlines will be met. Especially with deadlines far into the future, there is a track record of slippage and work not getting done at all.

Managers have learned that anything not marked as urgent has a tendency to be left alone, and not get done. People get results by declaring emergency. And you know what? It works.

How to handle

This is ingrained into the organization, and hard to counter. Make commitments, and consistently meet them (“I’ll get back to you next Friday”). Make promises, and keep them, and people will learn to accept you deferring work. We will get back to this. I promise.

There is no pushback

What and why

As engineers, we are inherently nice. When faced with the choice to either shine in front of someone present, of diligently work on for someone that isn’t, we choose the former.

But, apart from an opportunity to please, is this work really that important?

How to handle

This is about personal choice and reputation: build up a track record of being dependable, and your pushback will be more gladly accepted.

Most interruptions are not that urgent at all, but our desire to please gets the better of us. To handle this well, we need to make a well-reasoned decision on the importance of the work before us.

Personal productivity methods provide some help in this. For instance, my personal favorite Getting Things Done forces you to make a choice for interruption over two minutes: Do, Delegate, Defer, Drop.

‘Defer’ can be part of your system, but is more effective as a team. If you decide to deal with your interruption demons, and to not be as available for the team as you could be, you’re hurting the sprint result.

There are many ways to handle this. For instance,

  • One of the teams has picked Tuesday as the ‘interruptions day’. For every interruption, they ask “can this wait until next Tuesday?”
  • The notion of core hours is written up best in chapter 10 of the Scrum Field Guide. In short, these are the hours every member is supposed to be available for the team. Outside of these hours your free to work the way you want, and any interruptions can be dealt with then.

About promises

Making promises and keeping them it not external behavior, it is part of who you are. Be dependable to both your clients, and to yourself.

If you make a promise to yourself to get some work done, treat it just the same as making a promise to someone else. If you need to break it, renegotiate. You can’t be dependable without being authentic.

Costs are hidden

What and why

We all know context switches are expensive, but just how expensive? How can you explain to the angry manager at your desk “ah, yes, well, you know, you bothering me will take roughly 22.6 minutes of productivity away. From another project.” Remember, as engineers we’re way too polite for that.

How to handle

Transparency. Don’t hide incoming work in some support process, taking away control from your product owner. Make it visible that incoming work hurts by keeping it on the same sprint board as the regular work, and show this pushes out planned work. Start counting interruptions, and show the correlation between interruptions and velocity.

I see interruptions as a part of the process, but we can make them exceptional. There are many ways to handle this, but picking just a few,

  • use short sprints, so this work can be planned in a regular fashion, or
  • spend time increasing product quality, so we end up with fewer emergencies.


Well, what does that mean for you? What can you, as an engineer, do?

Always wonder “what is the most valuable thing I can do at this moment in time” by consciously making the Do/Delegate/Defer/Drop decision.

Build up a track record of dependability: make promises, and keep them. Real emergencies are rare.

With your new aura of dependability, use it to manage interruptions even further. Ask people’s input to be less disruptive: don’t call, email. Don’t visit your desk, create a well-written bug report. Use IRC if you must. This leaves you free to handle the interruptions regularly, but when you choose to.

Every interruption is a chance to shine. Shine only at your own terms.

Markdown in the browser, without additional tools 2012/11/28

Posted by Angelo van der Sijpt in Uncategorized.
Tags: , , , ,
add a comment

Today I ran into a typical documentation problem.

  • Organization uses mainly Word, but I don’t use word.
  • I want a solution that, while the documents are checked into subversion, is navigable in the browser.
  • So, HTML is probably good, but I’m not going to write HTML by hand.
  • I don’t want any server-side code, and I also don’t want to check in ‘compiled’ HTML.

So, I wanted to write Markdown, and needed some way of processing it in the browser. Enter: Showdown.

Showdown is a Markdown processor, written in Javascript. I ended up with documents that look roughly like this,

<div id="content">
<!-- This div contains all content in Markdown. -->

Showdown is

- legend...
- ...wait for it...
- ...dary!

<!-- End of div with markdown -->

 <!-- This script translates markdown to readable HTML -->
<script src="https://raw.github.com/coreyti/showdown/master/compressed/showdown.js" ></script>
var converter = new Showdown.converter();
var content = document.getElementById('content');
content.innerHTML = converter.makeHtml(content.innerHTML);

which gives me a page that says the following,

Showdown is

  • legend…
  • …wait for it…
  • …dary!

Isn’t that an awesomely simple solution? Just type Markdown in the predefined div, save, commit, and enjoy.

Oh yeah, subversion

When using this solution in Subversion, remember to set the SVN mimetype to text/html, so the file can be viewed in the browser. You can do this using

svn propedit svn:mime-type <file>

Devnology community day 2012 2012/02/11

Posted by Angelo van der Sijpt in Uncategorized.
Tags: ,
1 comment so far

First up: for those that don’t know Devnology, you probably should. Visit devnology.nl and sign up for one of the upcoming event!

Devnology’s third Community Day took place at Vx Company in Baarn, in the best-furnished basement I ever visited. The community day is like a one-day conference with blocks of time carved out for different sessions and workshops; I’m only human and have not experienced them all, so I just picked the ones I was a part of.

You shall not pass

Not exactly an activity, but it is becoming a tradition for the Community Day: upon arrival, we find closed gates. After some 45 minutes, a security guard shows up, and once inside, things start heating up. Literally: it was roughly -15 C outside, with blue skies and some sunshine, making it not all that unpleasant. I have never skied, but I imagine this is what apres ski feels like.

Cloud9, or, why do I install all of this stuff

Mike de Boer is a developer at Cloud9, and gave a very nice introductory talk into the way Cloud9

“is to Eclipse as Google Docs is to MSOffice”

I liked the way he walked us through the various features and advantages of Cloud9, but I would have liked a more developer-oriented pitch. We were shown a quick demo of debugging and live changes, but nothing showed up that made me go “wow, time to ditch IntelliJ, Eclipse and TextMate at the same time!”

To inifinity, and beyond!

Never too shabby to take an engineer out of his comfort zone, into the land of mathematics, Felienne Hermans flipcharted her way from ancient Greece’s Zeno’s Paradox through the more modern notion of Hilbert’s Hotel. Felt a bit like infinity-related excerpts from The Clockwork Universe, all compressed into roughly an hour. Also, I’m very charmed by the let’s-have-a-flipchart-and-start-talking way of presenting.

On a slightly less related note, it was her birthday!


Martin van Amersfoort led a 150-minute workshop on Clojurescript. What I really liked is the way he built up the workshop, starting at the language level, getting the tools set up, and slowly moving up to the actual subject, running Clojure on top of JavaScript.

What I didn’t like so much is that there was too much material for the reserved timeslot; probably a day’s worth of material paraded by in some two hours, barely leaving time for hands-on Clojuring. I hope Martin finds the time reduce the amount of material (to, let’s say an afternoon), then I’ll be first in line again!

A programming language is a language too, right?

My day ended with Michel Rijnders doing some storytelling on how he started out as a philosopher by trade, and recently stumbled onto his books on the philosophy of language. There surely should be a link between human language and programming, right?

Well, no. As Michel expertly showed, even though human language is all about conveying meaning and alluding to another person’s mental model of the world, the link to programming is pretty slim. Since in science there is no such thing as a failed experiment, I enjoyed this deviation from our usual programming-the-world view.

It later dawned on me that there may perhaps be more of a link between programming and classic poetry: both force you to take your ideas, and fit them into a strict harness. Any thoughts on that, Michel?

About the photos: you may know my photo gear is pretty retro, and I usually touch up the most annoying artifacts after scanning. This time, the weather (condensation along the bottom of the film strip) and the processing laboratory (numerous slanted, almost horizontal scratches) got the better of me.

Roomba and Poang: they can live happily together 2011/10/08

Posted by Angelo van der Sijpt in Uncategorized.
Tags: , ,

Oh yes, it’s such a first world problem. Yet, my Roomba has gotten stuck on my Ikea Poang chairs, about once every four or five runs.

The solution I came to was elevating the chair a little bit.

I bought some wooden wheels at Praxis (these are 60mm ones, intended to work as a wheel for, for instance, a storage box, or as helper wheels for a chair).

They are intended to work as wheels, so they are built to have an axle in them. We want to screw them onto out chair, but without the screw sticking out; so, I made sure the screw would recess using a counter sink.

Prepare the chair by pre-drilling some holes. I used a 3mm drill for this. Since the wheels’ 60mm is just as wide as the chair’s legs, there is no need to measure anything, just use your hand as a guide.

Then, attach the wheels. I used 3.5x20mm screws.

To top it all of, attach some felt protectors. I had some Ikea Praktisk protectors lying around.

There you go! The chair is now just high enough so the Roomba’s bumper will hit the chair instead of bravely trying to climb over it. Mind you: this works fine on my hardwood floors, but you may need some additional height if you have carpet.

Evolving systems and the link to service orientation 2011/09/26

Posted by Angelo van der Sijpt in Uncategorized.
add a comment

I gave a talk on ARL and the data evolution problem we find there at the Semantic Technology & Business conference, 26 September 2011.

My git-svn workflow with Tower 2011/07/11

Posted by Angelo van der Sijpt in Uncategorized.
add a comment

Most of the codebases I work on are in Subversion, yet I like working with Git for the sheer joy of it. Below, you will find a short overview of my basic workflow.

I do a lot from the command line, but not everything. For most operations Mac Git client Tower is the best solution you can find.

In short

For the impatient reader, my workflow looks a little like this.

  • One time only: clone repository. git svn clone http://host.com/repository -Ttrunk -bbranches -ttags mylocalcopy
  • Rebase: get all remote changes in. git stash; git svn rebase; git stash pop
  • Create awesome features, committing frequently with Tower.
  • DCommit: push changes back to Subversion. git stash; git svn dcommit; git stash pop

In a little more detail

Checking out

Git works with a local history, which makes it quite distinct from Subversion. Also, Git assumes that you have a working trunk, with optional branches and tags; this means your repository should at least have a trunk directory.

Assuming your trunk is at http://host.com/repository, you can clone a remote Subversion repository to your system using
git svn clone http://host.com/repository -Ttrunk -bbranches -ttags mylocalcopy

This will copy over all revisions of the repository to your own system, placing a Git repository in your mylocalcopy directory. Since it goes through all revisions, this can take a while for repositories with a lot of commits. If Git somehow stops, and your local copy is still empty, go into the local repository directory, and execute git svn fetch.

Updating and committing

With your local working copy, you can use Tower to create your commits.

If your want to merge your copy with the remote Subversion repository, it’s best to only do that after you have (locally) committed all changes. Then, use
git svn rebase
If you need to have some local uncommitted changes, use
git stash; git svn rebase; git stash pop

Pushing your changes to the remote Subversion repository is roughly like rebasing. Again, it’s best to only do that with a ‘clean working copy’, that is, having committed all changes to your own Git repository.
git svn dcommit
Again, if you must, you can pad this command with git stash and git stash pop.

Remember that, when you commit, all your commits will get the timestamp of the dcommit.

How do I use Git with Subversion?

I have noticed that in Git, there are at least six ways to do anything you want. I have settled on a simplified way of doing things, and I know I am missing out on some awesomeness.

  • I rarely use feature branches. I only use them when I am really working on two things at the same time, but not for every feature that comes along.
  • When I do use feature branches, I tend to dcommit from the feature branch, instead of merging to my trunk first.
  • Intellij’s Git integration is pretty good, and it works together nicely with external tools. In Eclipse, I don’t use any integration, but rely on command line tools and Tower only.
  • For Eclipse-based projects, I use Git to keep track of the full working directory, instead of tracking individual Eclipse projects. This usually means that I clone some repository at the level above the Eclipse projects, and import the projects into Eclipse using the ‘Import existing project’ feature.

Get every new post delivered to your Inbox.