Every count on this site links here, because a number is only defensible with
its method attached.
the two axes
Axis 1, publicly verifiable. A repository is
counted as public when it exists on a public GitHub account, in which case
the name is a link and you can check the claim yourself. Everything else is
counted but not named. Three internal names are shown because they are
already public knowledge; the rest are not, because some of them identify a
client.
Axis 2, paid work. Taken from my curriculum
vitae: employer, period, role. It names the party that paid, never the end
client behind private work. Where the CV omits a relationship deliberately,
this site omits it too.
The axes have different units and different denominators, and
they overlap freely. A skill can be strong on one and empty on the other:
Git
is 0 repositories and
5 employers,
C++
is the reverse. That is why you will never see
them here as one number split in two — "8 projects: 3 paid, 5 internal" reads
as a single total and is arithmetically wrong.
what the numbers are worth
Repository counts are self-reported. They come from
a private manifest of my own work, and you cannot audit them. The public
subset is the part you can: follow the links.
Skills are derived from file extensions across those repositories, then
normalised — LuaLaTeX, LaTeX2e and TeX all count as LaTeX, and Bash counts as
Shell, so one skill is not inflated by being spelled three ways. Domain skills
like PDF compliance do not follow from file types at all and are recorded by
hand.
A repository counts once per skill regardless of how much of it uses that
skill. One file of Lua in a large project counts the same as a project that
is entirely Lua. The counts measure breadth, not depth.
how the site is built
Static HTML generated by a small Python program from the same YAML files that
hold the underlying record. There is no database and no analytics. The
aggregated data is published as
skills.json so the numbers on these pages can be
checked against each other.
Before anything is published, the output is scanned for the names of clients
and internal projects, derived from my own business records. The build fails
rather than publishing a match. Terminal recordings are rendered to SVG with
real text nodes specifically so that this scan can read them — a screen
recording would be an image, and an image is opaque to the check.
Colour is load-bearing rather than decorative: green marks what is publicly
verifiable, cyan what was paid for, magenta the one page where money is
discussed. Every colour pair is checked against WCAG contrast thresholds at
build time, in both themes.
the music
The scores come from the book, not from a web export made to look like one.
Each piece is a LilyPond source in the same repository the book is typeset
from, engraved by lyluatex — the package that runs
LilyPond inside a LuaLaTeX document, and one I help maintain. The page you
read and the page that would be printed are set from the same file.
Getting that onto the web takes three steps, because the obvious one does
not work. LaTeX renders to HTML through tex4ht, which cannot embed the PDFs
lyluatex produces and falls back to rasterising them; the EPS that LilyPond
leaves behind per system is converted to real SVG instead. That SVG is then
inlined into the page rather than linked, because an
<img src="score.svg"> cannot see this stylesheet — it
would follow neither the theme toggle nor currentColor, and a
score drawn in black would vanish into a dark page.
Ink is handed to CSS on the way through: the staves and glyphs become
currentColor, and the white patch behind each tablature fret
number — which masks the string line running under the digit — is repainted
to the page background rather than deleted, so it goes on masking in either
theme. In the dark themes the ink is deliberately a step softer than body
text: a score is a large dense field of fine lines, and near-white over that
much dark ground glares in a way ink on paper never does. It is still held
to the same contrast threshold as text, and checked at build time like every
other colour pair.
Systems are scaled as one: the widest line in a piece reaches the full
column and every other is drawn as its own fraction of it. Relative width
carries the length of a phrase, so stretching each line to fill the page
independently would misreport the music — and would blow a two-bar tag up
to the size of a full system.
Every piece is published with a recording, rendered from the score's own
MIDI. That is not a bonus track. A LilyPond engraving contains no text at
all — the notation is drawn, and so are any lyrics printed under the staff —
so for anyone who cannot see it, the recording is the piece. Where there are
words they are also set out as ordinary text, in the language they are sung
in. See accessibility.
Not everything in that repository appears here. It carries twenty-one
engravings and most of them are the modal studies the book is built on —
material that means something in a chapter and nothing on its own. The
pieces on ~/music are named one by one in a list the
build reads; anything added to the repository later stays off this site
until it is added to that list deliberately. Nor are the LilyPond sources
published — a choice, not a technical limit. And there are more songs than
there are engravings: writing one out properly is the slow part, and a
piece only reaches this page once that is done.
The English under the lyrics is a plain translation. It carries the sense
and not the metre: it does not fit the music and is not meant to be sung.
The Dutch is what a piece is called and what it says.
the drawings
Every drawing on this site is decoration, and every one of them is hidden
from assistive technology — because an alt text that says more than the
picture shows would only move the problem to whoever can see it. So the
reasons are here instead, in words, for everybody:
A pixel-art portrait. Two frames alternate, and only the hair moves.
The MacLotsen profile picture, redrawn pixel by pixel — the same face that fronts the accounts, so the page opens with someone recognisable rather than a stock portrait. The photograph behind it was taken at TUG 2024 in Prague. Only the hair moves, which is about as much animation as a portrait can take before it becomes a mascot.
Beside the paragraph that says he plays one. Music came first and never left; the drawing sits next to the sentence rather than illustrating it from a distance.
An answer to the question of what a machine thinks LaTeX writing looks like. It is quietly clickable and always has been — no pointer cursor and no external-link mark, because it is there to be found rather than advertised. The link carries its own accessible name, so a keyboard and a screen reader both find what the eye has to hunt for.
A car driving across a long, otherwise empty strip of road.
From a meme by Germen M. Haijtema, shown during “Meeting TeX friends: Adventures across LUGs” at TUG 2026. It sits under the conferences because that is what the talk was about. The car is the meme's, not the itinerary's — Kerala and Calgary were not driven to.
Where engineering ends up standing. Sales comes first and needs it to work; once it works, compliance explains that it may not be done that way. The hammer is what that position feels like from underneath.
Two frames, alternating: a skater crouched over the board, and the same skater in mid-air.
Drawn from a photograph taken mid-air, during a frontside pop shove-it. What came out is an ollie: the board never turns under him. It stayed that way.
elsewhere
The company is Xerdi.
This site is about the person; that one is about the work you can hire.