zander m's blog


Defer in Go is profoundly weird. In general Go does not do weird. But this appears to be an exception (oh, wait it doesn't have those either 😸). I won't go too much into gotchas and stuff but I wanted to document some things I learned the other day. So what does the following code print? (Playground) package main import "fmt" func main() { a, b := test() fmt.Printf("%d, %s", a, b) } func test() (int, string) { var err string defer func() { err = "after" fmt.

Beyond Userspace

I've written before about being a self-taught programmer. My path into the field was a bit haphazard, but one thing I've noticed is that my trajectory always moved down. Down from the frontend to the backend to the container to the vm to the host. Currently I work largely at the container abstraction layer. I've got some working knowledge of the linux primitives that serve as the foundation to my current world and the specs that make up the boundaries.

Give a damn

In my last post, at the very end, I alluded to a Docker cli gotcha. For those of you who didn't have a shudder of recognition, I'll tell you something it took me a while to figure out: docker run koolKontainer:latest /bin/bash does not update your local copy of the image with that tag. You must docker pull koolKontainer:latest to make sure your image is up to date. In other words, if you have an old copy of that image, tagged with latest, the former command will run that old local copy.

The Joys of debugging

Today at work I was trying to merging a PR, and I noticed something very strange during the rebase. I work on a team that, among other things, manages dependencies for applications []. We define the versions of a runtime available to an application through a manifest, which is in YAML form. And part of the manifest includes SHAs of the runtimes, which we use to verify their integrity. A select few of SHAs now had single quotes around them.

'Learning How to Learn'

‘Learning how to learn’, by Barbara Oakley, is a compendium of techniques for learning effectively or more effectively, backed by neuroscience and cognitive psychology. Increasing ones ability to learn speeds up your knowledge compounding rate, and is time magnificently well spent. Know of and take advantage of the different modes of the brain: Diffuse and Focussed. If you're learning something totally new or you're stuck on a problem, take a break of some sort to allow diffuse mode to do its work.

Working hard to be lazy

So there's a great writer, one of my favorites, UKLG. She's completely not lazy, so apologies to her for inclusion. She's here, though, because she invented something great: The ansible 🌌. And why is that relevant? We'll get there… As any smart human person in charge of configuring and managing computers knows, I'm bad at my job. Or rather, my job is nearly impossible to be good at, given my human limitations.

Stuff you might want to learn if...

** work with computers: How your brain works How to make decisions How to learn [] How to be effective [] Good things other people have already figured out ** work with other people in technology How computers work: From nand to tetris (book + coursera) Computer systems: a programmers perspective GDB: Assembly vidoes: Networking: TCP/IP illustrated, vol. 1 Some videos wireshark

Important Problems

Richard Hamming asked the chemists in the Bell Labs Cafeteria: What are the most important problems in your field? And why aren't you working on them? The ever brilliant Haroon Meer got me thinking about this question recently; what are the important problems these days? And why aren't I working on them? In technology, so much seems driven by the market, advertising, and hype. I suppose that's better than war being the engine, but it somehow seems hollow.

How I learned how to learn how to code

I was reading the Turing Omnibus, doing some research into error correction, and I learned about Hamming Codes. I might have understood the concept at the time, but today, what I remember is the offhand comment my friend made about their creator, Richard Hamming. Oh you should watch his talk “You and Your Research” At this point in my life, I'd been laid off form my first startup and was taking a break to “get better at programming”.

Night & Day

Let's open with a cliche: What a difference a day makes.[1] Yesterday was Friday. An RC batch runs M-Th for “normal” days, reserving Fridays for prepping for interviews and job related stuff. The point is to bracket that time and that stress so the rest of the week we focus on programming, not job hunting. That's smart. Another example of removing the barriers to improvement. Yesterday we did a practice interview project: spend 3 hours building a link shortener ala bit.


I'm afraid to publish this post[1], but naming things can often kill their power over you, as Ged learned of his shadow. And so it is with some trepidation that I bring you the following story: One of my goals at RC was to blog every day I was there. I kept this going for a good while, but I recently fell down. For the last two weeks it's been radio silence.