Arnt Gulbrandsen
About meAbout this blog

Not sure about creativity

But I think I know the secret of productivity. It has two parts: Start on the job. Stay on the job.

That screenshot displays a clock, and the time shown is in the middle of the working day. And that's the biggest reason why I hate Autotools, Maven and a few other build tools: Their slow builds force pauses, and their forced pauses tempt digression. Hey look at this, there are three contradictory stories about creativity on the HN front page!

Several thousand tests are being rerun as I write this. About 3800 of them passed last time, one failed, the rest weren't run. The test suite isn't even running the test that failed first, so I get to wait for those 3800 tests that could fail in principle before I get the test that has a real chance of failing.


Email tracking pixel support

There once was a font called Smelvetica, a truly terrible prank based on Helvetica. There once was, because Monotype has sent a takedown notice for the git repo. Smelvetica was just like Helvetica except that its kerning was so bad that it was a feature. In fact, it was so bad that the font deserved a takedown notice. It deserved two.

There still exists a mail reader called Outlook, which my sort of people disliked twenty years ago, for good and bad reasons. One of the better reasons was that Outlook would implement harmful features. It still does. For example, (more…)



I make mistakes. I'm a programmer, half of what I do is giving birth to new bugs, and I hate it. So of course I try to improve that percentage. To identify and avoid error-prone routines, to interrupt mistakes before they've gone too far, etc.

Brexit scares me. Britain is an entire country with all the democratic mechanisms and institutions, with a long tradition, with no external pressure, with a full set of checks and balances, no lack of time or other resources except what they imposed on themselves. If experience, review, discussion or routines guard against mistakes, then noone should be more able to avoid big mistakes than Britain. Yet with just three weeks to go, they still seem headed for an utter mess. I can't bear to watch it.


The young traveller's guide to Venice

Venice may quite possibly have the best-looking ambulances in the world.

It also has more of them than I'd expect for a city as small as Venice. Is it possible that the Italians keep a few extra to show off in front of young tourists?

When they're not racing stylishly through the city, the ambulances may be seen waiting in front of the hospital. The fireboats are (more…)


Two small tasks

Today I have implemented two features (or fixed two bugs, depending on viewpoint). This morning I thought they were roughly equally difficult. This afternoon I know that one took eight hours and more than 200 lines of code, the other took fifteen minutes.

I don't even seem to get better at estimation as the years go by. This is frustrating.


static final volatile int foo = 1;

It's likely that my compiler treats foo as though it were just static final, and if you do not understand how a final volatile variable differs from a plain final, then congratulations.

The problem is that although people generally think of static final variables as constants, they aren't quite constant: foo is assigned its value early in the life of the application and can never be reassigned and, but if two or more classes reference each other, so that each class has to be initialised before the other, then code involved in that initialisation may see foo still being 0. This is usually an unpleasant surprise, found while debugging. volatile affects the visibility of the foo=1 assignment, and it probably forbids one of the things my compiler does to handle those loops.

I can fix it and I probably will, although I will not be highly motivated: It's a minor problem, and quite frankly, people whose code depends on the semantics of static final volatile ought to go for a walk in the park and reconsider that aspect of their design.


I write a benchmark

Today I need to write a benchmark.

I have decided to reimplement HTML Tidy in a simple, approximate way. I chose this because:

Of course I realise that this won't be a very good as a benchmark. I chose it because I believe that Jsoup is the kind of code I need to handle well. If my code doesn't do well on Jsoup, then I need to fix it. I don't have the same feeling about specint and other well-known benchmarks. They try to be good, precise benchmarks, and they don't explicitly try to be typical java.

As a result this benchmark will be useful for me, and the cost of that is that its measured performance is imprecise for you.


15000% improvement

I've been working on something that, I think, ought to perform 30%-200% better than the current solutions, depending on the workload and how the measurement mixes values for average/­typical/­best-case/­worst-case time and space. Some workloads might get more than 200% improvement, and I hope less than 30% will be rare.

The very first time I tried to measure the entire system, however, my measured result wasn't 30% improvement or 200%, it was a little over 15000%. Three zeroes. And I wasn't even trying to make a misleading benchmark — I just wanted to measure how well my code worked and I suppose I unconsciously concentrated on parts where the differences should show up clearly.

15000% certainly is a clear difference.

It's also totally meaningless. It measures something you'll never, ever do. However, it's a fantastically big number, I know that I was honest, and it has taught me that even if benchmark results are laughably unrealistic, it's not always because someone tried to brag or mislead. Maybe they are just myopic. Focused on the details of their work.

I've spoken harsh words about other people's benchmarks in the past. I don't think I will do that any more.

Update: 1500000‱.

Update: And the best way to represent it is with a logarithmic bar graph. Most people do not really understand a log scale, but the difference still looks very large and so the meaning is preserved. The label on the y axis makes it formally correct.