Good Documentation
Tearing apart bad documentation may be cathartic, but there’s good documentation out there too. It deserves recognition. Today, I’m going to pick on SDL. I’m not talking about the quality of the API itself, just its documentation.
Tearing apart bad documentation may be cathartic, but there’s good documentation out there too. It deserves recognition. Today, I’m going to pick on SDL. I’m not talking about the quality of the API itself, just its documentation.
I first came across ThreadX somewhere around 2021, during its stint as Azure RTOS. I guess Microsoft thinks blue is cool or something. Maybe they really want to emulate another blue-themed company. I don’t know. Anyway, it’s 62304-certified and I was working on a class B medical device at the time. While using it, I found a bunch of things that look like this:
There’s a phenomenon that I’ve been observing, and I think it’s time to share my thoughts. In my experience, when someone goes to visit a place and tries to learn some of the language and speak it, the reaction comes in two flavors: people either (type I) act delighted and try to help with the learning, or (type II) switch to English.
I’ve been working in the software industry for 20 years (counting as conservatively as I can) this year, and sometimes people come up with weird styles and enforce them on everyone who touches their codebase. These are a few examples.
Recipe first, commentary later. About an hour total.
Recipe first, commentary later. About 1 hour total.
Recipe first, commentary later. Should take between 30 minutes and an hour.
Recipe first, commentary later. 15 minutes of work and 2.5 hours of baking.
Recipe first, commentary later.
Jeff Atwood wrote about FizzBuzz in 2007. Google used to use weird brain teasers, but no longer does. That hasn’t stopped a plethora of companies who think they’re copying Google from asking tricky puzzle questions. No matter what the approach, though, interview questions measure how well someone answers interview questions.
The other day, a friend of mine brought this to my attention:
Due to some recent events, I’ve found myself in the position of needing to track medicine intake. There are medicines that have to be taken daily, which have to be audited (“Did I remember to take my bufaximol?”) and others taken as needed to manage symptoms (“How much metryptine have I taken today?”).
A co-worker of mine (the incomparable Yohei Manabe) was looking at some disassembled ARM code the other day, and discovered something weird. Lots of d4d4 instructions, scattered about. LLVM’s objdump says this is a relative branch to -0x58. The weird part is that they were always unreachable.
A co-worker discovered an amazing thing the other day. He needed to check out our codebase on a Windows machine (for real, not inside WSL) to do something model-y with Matlab. It’s worked before, and it looked like it was going fine until he got this error:
Sometimes people ask me questions about what it’s like living in a different country. The Netherlands is not all that different from the US, as these things go, but it’s still different enough. This is a collection of things I miss from life in Boston and things that make this place feel foreign.
If you don’t already, you should use an RSS(/Atom) reader.
First, context. Skip to the next section for the important bit.
I’ve got an electric toothbrush. We had a very similar one before leaving the US, but since it wasn’t rated for 240V AC, we got a new one after arriving here.
When I tried to search for the demand version of dumping, I found a lot of articles about regular dumping. A few of those had good definitions, so here’s one:
Yesterday, in make, I talked about what Make does. Today, I’m going to talk about how Make gets abused.
There are many resources out there for how to use make and some of them are very good. However, they mostly focus on details of syntax and how to spell the different text manipulation functions. This document is not that. This document is about why Make is the way it is, and how to help it do its job.
I’ve been writing C code professionally since about 2006, and while I look at a lot of languages (I have varying levels of familiarity with Python, Erlang, Ada, Haskell, Go, Rust, C++, OCaml, D, Javascript, Prolog, Lua, Lisp, Bash, Perl, Forth…you get the idea) I have yet to find one that I would rather use in cases where C is appropriate. Part of this inclination is that I mainly write for…
This post is aimed at people who come from languages with automatic garbage collection and want to get a sense for how to approach memory management in a lower level language. I’ll be using Zig (and a bit of Python) to demonstrate, but the concepts apply to C and other languages where you have to care if your data is going on the stack or the heap.
This post is going to explain how pointers, arrays, and slices work in Zig, without depending on knowledge of other languages that use pointers. If you’re trying to learn Zig and your only programming experience is in a language with managed memory, this is for you. If you’re struggling to understand pointers in C, this might help. If you’re coming from C or C++ and just want to know the…
This guide was last updated in July of 2026 with an 0.17.0-dev build. Zig is a moving target, and stuff written about it may fall out of date. If you find something broken about this, feel free to let me know.
Update: April 2024 - A lot has happened since I originally wrote this article. I may still update it in to cover the current state of things, but Killian Vounckx wrote an update in February of 2022 and Issue 130 has been closed. I’m not porting the original version of this article to the Sphinx site, so if you want to read it, you can find it here.
This post is going to look at wrapping a C library in Zig. The library to wrap will be libsodium, a “modern, easy-to-use software library for encryption, decryption, signatures, password hashing and more.”