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:
- 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`.
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.
I think the Google Go style guide is really nice and pragmatic. There are some references to the GoTips for some advanced subjects. I hope they release it someday.
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.
My favorite story about him was when he caught a student sleeping in his class. He paused, mid-sentence, and asked the student if they were too tired. The student looked up sheepishly and confirmed.
"Did it get a bit late last night? Can't keep your eyes open?"
Again, the student agreed. Rolf flashed a huge smile and in a singsong voice said "then I have something for you!". He walked over to his bag, pulled out a stuffed animal and a tiny embroidered pillow. (I have a grainy photo of them somewhere).
Rolf tiptoed up to the student, put the pillow in front of him, and as the student rested his head on the pillow Rolf gave him a pat on the head.
After this Rolf went back, said that if you're that tired it's better to sleep in your own bed. He resumed the lecture, picking up in the middle of the sentence where he'd stopped. No one slept in his class for the rest of the course.
I have a similar anecdote which completely stunned us, but which may possibly be part of his standard routine, and thus something he does for every set of students:
He always wore the same striped sweater. At one point, he took a break to drink some water and remove his sweater. But beneath the sweater was another identical sweater!
I assume everything he did was very well-planned and part of his pedagogic system and routine, but it was often hard to tell if he was acting, or if he was actually being serious but eccentric.
I don't remember that but a lot of his antics seemed to be planned and part of his way of keeping people awake and paying attention. If it is part of his routine I wonder when he added it. I took his courses in 2006-2007.
I took that course in 2015 or 2016, so yeah, I guess that's about a decade in which he could have added it. I just browsed around Chalmers' course pages and am very happy to see that he's still teaching that course.
Concrete example from that article: with improved detection of cancer, it’s true that “people with cancer live longer on average” and also that “people without cancer live longer on average” even if there’s no change to the treatment or anyone’s lifespan.
I absolutely loved his classes. I bumped into him a few years ago when I was holding a recruitment thing for Ghost Games and it happened to be just after his lecture. I told him how much I enjoyed his courses.
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.
Thanks. Do you have some resources how Google Artman fits into this? It looks like mix/match of Protobuf with Yaml to define a Rest Api. But I don’t see it promoted very much except with the cloud endpoint
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.
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.
I used to use bspwm, but ended up moving back to i3wm. While i3wm is not perfect, I always found it to be more practical than bspwm. The ability to stack, for example, is very nice. What's the thing that you really like about bspwm? As much as I wanted to really like bspwm, when it came to using it for work, I just found it lacked something.
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.
Have been using it for a few years, really hits the sweet spot of easy-config + awesome functionality (stacked terminal windows with remote server load averages piped through title bar are a real nice-to-have for example). Floatable dock (i.e. scratchpad) is also pretty handy for skype, music player, notes, etc.
Only issue that's really bothered me is a minor one: with stacked windows you can't get the desktop background to show through properly with transparency enabled (via Compton or other compositor). Apparently that's been fixed in 4.11.
Anyway, no shortage of TWM options on Linux, everyone can have their (nearly) ideal setup ;-)
Well, I would like to have more control over the floating windows (that will never happen), for example.
One of the things I did like in i3 better than bspwm, for example, is resizing. Another big advantage is it works out of the box very well. Oh, another thing I remember now is i3 is more intuitive when moving things around the screen, especially when trying to switch between vertical and horizontal splits, at least in my experience. I can't really recall all the reasons. They were all small things that build up. I do run i3 straight from the git repository (next branch).
That said, in my experience, tiling wm are way ahead of other wm, especially if you are a programmer. I'm a big fan of vim and tmux (and vimperator for firefox, which adds vim-like behavior to it) and I have no mouse. I have a trackpoint, for whenever I need it.
With i3, I never found an easy way to swap two windows at different levels of the tree. With awesome or bspwm, I can just mod+drag. Also, automatic tiling in various layouts is nice.
I don't usually have complex layouts, and I really appreciate the stacking from i3, so in that sense i3 wins for me, but I guess if your layouts are more complex, you might appreciate bspwm power in that regard.
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...).