My recipe for Arvid Nordquist mellanrost. I started by trying to replicate The Ultimate V60 technique by James Hoffmann (which is what I normally brew) and I realized just how hard it is to control the flow rate now that I don’t have my gooseneck kettle (being shipped from Singapore), and I hadn’t really realized just what a difference controlling the pour makes for the taste!

I was in an AMA at work, and someone asked me what makes a good software engineer. I said: Someone who is curious and wants to understand why from many points of view (tech, product, customer, etc.), and someone who cares about the outcome, not that they were the ones to “get it” or “make the decision.”

The more I think about it, the more I realize that curiosity is the foundation. You need curiosity about the system you’re building, the organization’s actual goals, and especially about the people you’re working with. But curiosity alone isn’t enough, you also need to be intellectually honest about what you find.

The principle I try to live by is: I would rather be correct than right.

We’ve always had to figure out who to trust for expertise, but until now, that access wasn’t universal. Used to be the bloke at the pub who ‘knew things,’ or that friend of a friend who could fix computers (me as a kid), or books if you had the patience. Rich people had their ‘real’ experts on call, though Bernie Madoff shows how well that could work out.

The internet changed things, sure. Suddenly you could reach out to actual experts, find communities, and learn from people across the world. But you still needed judgment, because you could also find a community that agreed the earth was flat, so, you know, mixed bag.

What hasn’t changed is we’ve always had to figure out who to trust. What’s changing is how we get our answers, and who gets to sound like an expert.

I’m trying something new here. Instead of waiting for fully-formed thoughts, I’m going to share more as I go: quick things I’ve learned, half-baked ideas, useful links. I’ve added some structure to keep things findable, but the main goal is just to share more often.

The main feed will give you everything I post, if you only want certain types of posts, I’ve also made section-specific feeds. The blog feed is what you’ve been getting if you were already subscribed.

A colleague recently said something that’s been rattling around in my head: “AI gives you speed, but it doesn’t give you direction.” And the more I use these tools, the more I think that undersells the danger.

I have been wondering how to think about AIs (or genies) and how computers are like bicycles for the mind, as Steve Jobs put it, and I think these tools take it further. They are more like motorcycles for the mind. They go really fast, and you better not treat them like a bike, because you need to know what you’re doing. How to handle that thing. You need to make sure you don’t try to go too fast too soon, or for too long, because you’ll get speed blind and… things will happen.

I was in an incident review recently where one of the problems was a human going too fast. This process is very manual, repetitive, and boring, and it rarely fails, so we skip some steps. That mostly works (see Why Do Things Go right?), except when it doesn’t. Ripe for occasional issues and likely in need of automation.

I believe we often skip steps because we don’t know why we do them. It’s not tedious for tediousness sake, it’s often there because it’s important. And until we have the automation, or maybe we’ve intentionally chosen not to automate it, we need to find some way of helping the human ’live the situation.'

I was trying to speed up our slow CI by caching Go builds. The easy win was caching Go’s module downloads (via GOPATH), but when I added GOCACHE for the build cache, I got a pleasant surprise: the tests were caching too. 🥳

I shared the change for review, and a colleague raised a great point: “What about our black box integration tests?” These tests hit APIs and external services that Go can’t track as dependencies. If they cache when they shouldn’t, we might miss real failures: the tests would pass because they didn’t re-run, not because the code actually works.

You’ve probably sat through your fair share of meetings where time slips away as conversations wander aimlessly, not unlike being dropped into an unfamiliar codebase, with twisting branches all alike.

A colleague asked for feedback on a meeting they ran, and after sharing my thoughts, I realized my advice about meetings sounded exactly like how I talk about planning projects. This got me thinking: the skills for running good meetings and successful projects are nearly identical.

I try to be aware of where I have friction in my day-to-day when working at my computer, keeping an eye out for TOIL to remove. Whether it’s from manually repeated actions, or from differing behaviors across apps and services I use. When I identify any of these I try to spend some small amount of time automating or changing how I work to improve.

All of these things don’t necessarily make a lot of sense from how much time I save, but, it also makes me happy to spend a bit of time improving my environment, and spending a bit of time to make me happy is good enough for me.

In the Docker Desktop app you can go into Features in Development and check Use containerd for pulling and storing images.

Or you can do add the following to Docker’s daemon.json file:

{
  "features": {
    "containerd-snapshotter": true
  }
}

This comes from a comment in a ticket for resuming downloads when they fail.

I use Roam Research as my primary way of thinking and keeping track of tasks. My current workflow has me creating a list of all tasks I want to get done, and then I drag them to either Done or some follow-up/waiting area for future action. So I only see things I can act on now.

My list of things to action can get quite long, and when I’m processing follow-up items, I would have a hard time dragging them to Done because it was too far away in the sidebar. So I wished I would make the Done float with me, so I could always have a quick way of pulling it there.

I just misplaced my Apple Watch in my apartment. Walking around looking for it, and getting frustrated, I was thinking, “There ought to be a way to make it make some sound, then I can play Marco Polo with the watch”. But my Google-fu failed me: no obvious way to “ping my watch”. There’s functionality for pinging the phone from the watch though.

But there’s a way to make some noise: testing out the alert volume in the companion app on the phone.

I’m running an open source project called gocd-cli which is, well, a command line interface for Go continuous delivery. The intention is to make it easier to handle common tasks around Go. But this post isn’t really about that.

This project is supposed to be as portable as I can make it, becuse the original need I felt for it was born on RHEL6. Which is blessed with Python 2.6 by default. And we should definitely be looking to the future, meaning supporting Python 3, and I luckily got a pull request for just that. Since I couldn’t find any free hosted Go around I went for the next best thing, Snap CI, which is also built by ThoughtWorks.

I’ve for almost a year now been using Python as my day to day language as it’s what is used at my job. I’m starting to come around to really liking most parts of Python now, although there is definitely parts that are way more clunky than I would expect from a language so popular. And especially given how much talk there’s about the included batteries and to a small extent how there seems to bit of dickishness involved with hard core Python people. For an example of the latter just:

I spend some of my free time helping out with server administration and programming for the Swedish Pirate Party, Piratpartiet (look ma, X-Varnish), and we use Varnish for our caches. At the moment it’s just used on some of our projects, but we’re going to migrate most of our projects to be behind our Varnish caches.

The thing is though that we got two hosts running the exact same configuration, and we’d like to keep those hosts in sync. A quick search on Google gave me nothing for syncing varnish configuration over several hosts, or a farm as it were. So I took matters into my own hands and wrote varnishsync, a little bash script that uses rsync and ssh to sync the configuration folder and then to load and use the new configuration.

Yesterday I wrote a quick step-by-step guide for installing apache and setting your system up for Wikileaks mass-mirror project in Swedish and I’ve had requests for it to be translated into English.

This guide assumes you’re running Ubuntu or a Debian based system.

I’ve made a script that does all the steps below, feel free to use it!
The script: http://sanitarium.se/files/wikileaks-mirror.sh
Usage: wget http://sanitarium.se/files/wikileaks-mirror.sh && chmod +x wikileaks-mirror.sh && ./wikileaks-mirror.sh

Installing Apache and adding the wikileaks user #

# is the prompt as root:

A translation of this post is available in English.

En kommentar i Rick Falkvinges inlägg Fullt krig om informationen så efterfrågades en snabbguide för att dra igång en Wikileaksspegling i ett vanligt Linuxssystem.

Jag utgår från Ubuntu eftersom det är vanligt och vad jag själv använder.

Uppdatering 2010-12-05: Jag har gjort ett script som utför alla stegen nedan, använd gärna det!
Filen: http://sanitarium.se/files/wikileaks-mirror.sh
Användning: wget http://sanitarium.se/files/wikileaks-mirror.sh && chmod +x wikileaks-mirror.sh && ./wikileaks-mirror.sh

Installera Apache #

# är prompten som root:

I’ve so far in all my travels never found a terminal I like better than xterm, maybe urxvt, but I’ve had a problem disabling bold fonts for a very long time. Update: Seems this is a known bug for xterm.

There are a lot of X resource configuration options that makes you think you can disable bold fonts, but alas, I’ve had no luck with any of them. But if you set the same font for both normal and bold fonts it’ll work! This little gem of knowledge I found as an off-hand remark on a configuration page by Emil Mikulic, thank you!