Saser

I love Cram tests, they can be so readable! Being essentially shell scripts, though, they can be a bit hard to integrate into any given language's regular testing framework though.

I get the sense that "expect tests", also known as "inline snapshots tests", are becoming more and more popular. I think that many, including myself, first learned about it from the Jane Street blog post "What if writing tests was a joyful experience?" (https://blog.janestreet.com/the-joy-of-expect-tests/) because I keep seeing references to it. Indeed, the blog post points to Cram as prior art in this space. I also think Ian Henry's article "My Kind of REPL" (https://ianthehenry.com/posts/my-kind-of-repl/) makes a very convincing case for why expect tests are useful.

Jane Street has published their `ppx_expect` library for OCaml and you can use it today: https://github.com/janestreet/ppx_expect. For other languages, here's an incomplete list of similar libraries I'm vaguely aware of:

- Rust: expect-test, (https://github.com/rust-analyzer/expect-test, quite old), insta (https://insta.rs/) and k9 (https://github.com/boujeepossum/k9)

- JavaScript: Jest has inline snapshot testing: https://jestjs.io/docs/snapshot-testing#inline-snapshots

- Python: inline-snapshot (https://15r10nk.github.io/inline-snapshot/latest/). Also discussed in this post from Pydantic: https://pydantic.dev/articles/inline-snapshot

- Go: https://github.com/hexops/autogold. I like it and use it daily at work. It has some shortcomings around working with strings as the expected value, so I'm fiddling with my own library that will be much more similar to `ppx_expect`.

- Zig: TigerBeetle has an internal `snaptest.zig` library in their codebase (https://github.com/tigerbeetle/tigerbeetle/blob/588123f219f1...), also discussed in their blog post "Snapshot Testing For The Masses" (https://tigerbeetle.com/blog/2024-05-14-snapshot-testing-for...).

This might be what you're thinking of: https://bchess.github.io/k8s-1m/

https://google.github.io/styleguide/go/ is the public version of it. Having read both I'd say the differences are small. The main thing missing, though, are the GoTip episodes that haven't been made public, and which are excellent.

Russ Cox (who worked together with Rob Pike on Go for a long time) solved several of last year's Advent of Code puzzles using Ivy. Here's a YouTube playlist where he has recorded himself doing so: https://youtube.com/playlist?list=PLrwpzH1_9ufMLOB6BAdzO08Qx.... I don't think he's solving the problems for the first time in these videos, instead merely demonstrating how they can be solved using Ivy.

Rolf Snedsböl? :-) Agreed that he was one of the best educators (if not _the_ best) I had

In addition to these, I think that Google's API Design Guide (https://cloud.google.com/apis/design) and their AIPs (https://aip.dev) are good references for learning about how their style of APIs, called resource-oriented APIs, can be designed. There is a linter that can check whether an API follows the AIPs (I know, these acronyms are easy to mix up), available at https://linter.aip.dev. I am building a side project following the AIPs and have found them to be very helpful.

Disclaimer: I work at Google, although I would have recommended these resources anyway.

Makefiles are one situation where one is essentially writing small shell scripts, but which are not really supposed to be quick and dirty in my opinion.

It looks like it supposed to be a Scandinavian language, most likely Norwegian or Danish. It could be interpreted as Swedish as well, in which case the correct corresponding Swedish sentence would be "och en till javanissen". A "nisse" is in Swedish something like a gnome, so "javanissen" would be "the Java gnome". The full translation would then be something like "and one for the Java gnome".

I'm not sure if there's any deeper meaning to the joke. I didn't think much of it until I read the subsequent paragraph of the text and figured out what was meant by "og én til javanissen".

In zsh (or at least with my configuration, which is prezto with a few plugins), Ctrl-q lets you "stash" your current command.

Say that you are typing some really long, complex command, and suddenly you realize that you are in the wrong folder. You press Ctrl-q (which clears the command and "stashes" it), then you cd to the right folder. As soon as you return to the prompt after issuing your cd command, your really long, complex command is back just as you typed it.

It just seems to resonate well with how I think about organizing my windows and I can predict its behaviour. For example, I almost always use manual mode when spawning new windows, so I can almost always predict how my desktop will look afterwards. I also _really_ like the dynamic configuration it provides through its client/daemon model (so you can try out different settings without changing your configuration file and restarting X), and the amount of commands that allow for fine tuning of bspwm's behaviour fits me very well since I like tinkering with it and create a configuration that does exactly what I want.

This looks really similar to bspwm[1] for Linux, which also uses a binary tree for window management, and also uses a daemon/client model for interaction with the window manager. bspwm is by far my favourite window manager, in any OS I have used.

[1]: https://github.com/baskerville/bspwm