Spent a better part of today updating the theme of my blog... For a long time I wanted to replace the cold blue colors with something nicer and warmer, and I'm pleased with the result. At the same time it's a little bit sad because for the first time since this blog existed I completely abandoned the white-panel-over-blue-gradient style I've faithfully carried through 4 different blog engines. For the comparison, I will include screenshots of the same post with 2011 design and one from yesterday.

While at it, I killed a few sources of unnecessary bloat: applied PurgeCSS to the gigantic Bootstrap stylesheet and replaced 300KiB of js with 311 bytes.

Reading https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell made me feel not quite so bad about the poor old GCL. Though I wonder which one caused more revenue loss globally :)

A funny thing about GopherJS that took me a while to figure out: struct data is actually stored in what is technically a runtime representation of a pointer-to-struct type, and the struct object itself almost never exists

You'd say, but wait, no way it works without structs, surely they do exist and are represented by a plain old JavaScript object. Well, sort of. In reality, there is a pointer to a struct type that is represented by a JavaScript object. So when you write something like this:

type S struct { f int }
s := S{} // ← non-pointer type!
ptr := &s
reflect.TypeOf(s)

...it translates into something similar to:

var S = $newType(...., function() { this.f = 0 })
var s = new S.ptr()  // ← actually uses pointer constructor!
var ptr = s; // ← noop, it's already kind of a pointer.
reflect.TypeOf(new S(s))  // ← adds a wrapper with the correct type information when interfaces get involved.

This is counter-intuitive, but also makes sense because JavaScript's pass-by-reference semantics for objects is a lot like a pointer in Go, and GopherJS actually has to take extra steps to emulate value type semantics on top of it.

#golang #gopherjs

Tried https://kopia.io/ today for backups of my Minecraft server, and it's looking really nice. Runs fast (our world is fairly small about ~3GiB), uses very little CPU and memory, incremental backups use very little disk space, supports retention advanced policies. Much, much nicer than Textile Backup mod I've been using before.

For the moment backups are just to the local disk, but adding a remote storage won't be too difficult.

#minecraft #self-hosted

Before I became a GopherJS maintainer I had no idea how incredible of an achievement that would be: https://mastodon.social/@andrewrk/109621905821062620

Growing an active contributor community is hard. Even harder when it comes to folks willing to do the unfancy, grindy work such as triaging old issues — very few people consider it an enjoyable leisure activity, or are willing to do it regardless of not being paid. So hats off to the Zig authors for getting there, I'm sure it required a lot of persistence.

As for GopherJS, I am truly delighted that virtually all changes that went into 1.18.0-beta2 release came from contributors outside of the core maintainer group. Many of them are non-trivial too. We are still struggling to find volunteers for recurring tasks such as new Go version support, but hey, hopefully we'll get there.

#golang #gopherjs #opensource

My wishes for 2023:

Engaygement as a business success metric.

Interview for a management role:

Interviewer: Do you have experience managing managers?
Interviewee: Yes. A few of my previous managers required careful handling to let me actually do the work.
Interviewer:

All characters in this post are fictional and any similarities to real people are accidental.

I gained a deep dislike for writing by hand in primary school, and I am immensely glad that I mostly have to use the keyboard in my daily life. Seeing posts like this makes me want to try it, but then I come to my senses and order another keyboard

(joking, I've been using the same mechanical keyboard for the last 6 years and have no desire to replace it)

https://marketplace.ultimaker.com/app/cura/plugins/Ghostkeeper/SettingsGuide2 is probably my best tool in learning 3d printing so far. All those million slicing parameters explained right in the UI. What's so great about it is that the tooltips not only explain what a setting does, but also the trade-off about using it or not.

#3dprinting

To the tune of your pager ringtone:

You better watch out
You better not try
You stop the rollout
I'm telling you why
Santa Pager is coming to town

He's watching commits
He's checking your bugs
He's gonna find out who's naughty or nice
Santa Pager is coming to town

He sees you when you're coding
And he knows what you'll break
He knows if you cause pages
So don't push to prod for goodness sake

You better watch out
You better not try
You stop the rollout
I'm telling you why
'Cause Santa Pager is coming to town

Oh, let's go
Now, he does code review
And he knows your test's a flake
He knows if you force-push
So be good for goodness sake

You better watch out
You better not try
Better stop your rollout
I'm telling you why
Santa Pager is coming to town

You better watch out
You better not try
You better log out
I'm telling you why
Santa Pager is coming to town

#oncall #sre

One of the biggest shifts in how I understand the Site Reliability Engineer role was a transition from "SREs take a product and add reliability features to it (monitoring, load balancing, failover, etc.)" to "SREs empower product developers to make their product reliable".

The empowerment comes in many forms: building tools and frameworks, contributing to the product core, participating in design process, documenting best practices and writing postmortems. But one of the most important ways is reaching out to your fellow product engineers, at individual level, and educating them about all you've learned as an SRE. You don't have to have "reliability" in your job title to understand and implement the ideas behind reliability engineering.

Developing technical credibility with your dev teams is what ultimately opens the door to your ability to educate. A few things that worked for me well: make deep technical contributions to the product core, participate in design discussions and show your interest in learning the product's problem space, don't be afraid to ask silly questions, be willing to listen and acknowledge your mistakes.

Or, in other words, if you come across as a seagull who shows up in your design doc comments, shits all over it and calls the author an idiot, people will not like or trust you even if you are technically correct.

#SRE #reliability

I have a love-hate with performance optimization. It's really fun to design benchmarks, stare at flamegraphs and RPC traces and eventually make it run faster, but waiting for a benchmark run to actually complete is the most boring thing ever.