This page lists picoblog entries for the year 2025. For entries from other years, consult the picoblog archive.
It’s almost 2026! And that means I need to update some seriously big portions of my website in preparation.
Luckily, I’ve already updated my pico/microblogs’ frontmatter so that the new-year transition will be almost completely automated. But I’m still nervous about one other thing: I don’t want all my precious microblog and picoblog posts to be relegated to the archives, since that would make my site look a lot less impressive until I’ve built up a new set of posts over the course of 2026.
So to make the pain of this transition a little less sharp, I’ve made it so that the archive page lists how many posts were made in each year, to entice a user to check out years where I was a more prolific writer.
It’s not a perfect band-aid. But it’s better than nothing.
Actually, I’ve changed my mind! New Computer Modern is actually a better choice than Latin Modern.
… I think. It’s still a little up in the air.
The problem is that Latin Modern has \mathbb fonts that look all wrong. They’re missing the serifs on the tips of the E character, for example, which makes expectation operators look worse. New Computer Modern doesn’t have this issue.
I think I’ve made up my mind. Math on this website is going to be rendered in the Latin Modern font. It resembles LaTeX (i.e. the Computer Modern font) a great deal. I was originally hoping to select a math font that showcased some more personality, i.e. something that looks like my math. But it turns out that most math fonts have either
- terrible rendering issues in many browsers, or
- just look plain terrible.
The only real competitor to Latin Modern for replicating a LaTeX-like appearance is New Computer Modern. However, it provides this weird extra functionality of these “stylistic variant calligraphic characters,” and they look different from the Unicode characters that are commonly used to represent \mathcal characters in LaTeX. I’m honestly unsure why I’d need those redundant calligraphic characters.
So… Latin Modern it is!
Now I just need Zine to actually let the programmer choose their own math fonts, which requires decoupling the run-time Temml rendering pipeline from Zine and replacing it with a compile-time MathML Core transpiler from SuperMD files. I hope that functionality gets added soon.
I successfully moved all of the non-post content out of the picoblog and microblog .smd files and into their respective .shtml files! That means I won’t have to update the frontmatter every single time a new year starts.
I’m really excited. This means that the system for displaying/adding picoblog posts and microblog posts is almost completely automated. For the few parts that couldn’t be automated, I wrote myself a tutorial for how to update them so I won’t forget. And with that completed, these pages are fully operational!
It would probably be a good idea to remove the filler entries I have for 1989 and 1990 that came with the starter Zine template. That’ll make it more presentable when it actually goes on the internet. But all of the hard technical barriers to doing that have been overcome.
“It’s like Reddit went to Home Depot.”
*air horns blare*
I’ve been researching different webpages to see what (computed) font size they have. On the low end, it appears that SlateStarCodex uses 12px font for its basic text. Then you have Matklad on the high side, which has approximately a 21px font size.
(Obviously, Matklad is known for having made some very specific design decisions with his font size choices, including using the font-size-adjust CSS property, so I had to check that his fonts looked as if they were 21px manually. It took a lot of trial and error.)
I’m thinking that for someone with a default user agent stylesheet (which usually produces 16px font), I want my basic text font to be 18px. I’ve tested several different values and 18px looks pretty good.
Well, it’s pretty much confirmed that I can’t use BookBrainz. They don’t even have any database entries for Henry H. Neff’s The Tapestry series, which was going to be my first test case. So Open Library it is!
I’m trying to find a good canonical place to link book references on this website. I’ve whittled it down to 6 options, of which only 2 are serious contenders for what I’d like to go with.
- Open Library
- BookBrainz
- Goodreads
- The StoryGraph
- Fable
- Anna’s Archive
The first two are intended to be purely archival, and only archive book metadata, not book contents. They’re supposed to document what books exist, not provide those books to users. I think these two options are the ones I’ll be choosing between.
Goodreads is Amazon-controlled, and I don’t want to further cement their monopoly in the book-enthusiast space. Their webpages also fail to load on mobile devices when cookies aren’t enabled, which is a massive deal-breaker. Seriously, someone needs to fix that. (Unless it’s intentional, which would be even worse.)
The StoryGraph and Fable are both social media apps with slightly different emphases on different parts of the reading+app experience. I’ve perused their websites and feel quite grossed out. They position themselves as Amazon-free alternatives to Goodreads, but lean very heavily into facets of social media that I find really ugly. That’s a tradeoff I don’t want to make. For what it’s worth, some brief internet research reveals that The StoryGraph’s founder, Nadia Odunayo, wasn’t originally intending to create a competitor to Amazon, which she spins as a positive and I spin as a minor negative.
Anna’s Archive has a good mission, but their legal troubles make it so that they might not provide stable URLs to books over the next several decades. The archive itself might be very durable to takedown requests, but URLs to the archive are not. That’s an important distinction. Furthermore, the fact that they provide a book’s contents to the user makes them overkill for my use case.
So that leaves Open Library and BookBrainz. Which one do I go with?
There’s a delightful forum discussion between people who are (presumably) more affiliated with BookBrainz than with Open Library (since the discussion is happening on the BookBrainz forum) about the differences between the two of them.
I’m torn. I like the more rigorous deduping of sources performed by BookBrainz, but I also think it’s kind of neat to be able to link to particular editions of a book. Open Library also has significantly more places from which they acquire data, and I support the Internet Archive’s mission overall.
I think I’m going to (provisionally) go with linking to Open Library. If I encounter a ton of problems with this approach, I’ll likely switch.
I just attempted a talk by on compilers by Tommy McMichen, a 6th year Northwestern PhD student. It was quite informative, especially for someone like me! I’m an enthusiast about compilers, but I know far less about them than someone who works in the systems group. I’m in the theory group, where compiler-related enthusiasm is pretty minimal.
Some takeaways from the talk (and a private Q/A session I had with Tommy afterward) that I wanted to write down before I forget them:
- The first concrete idea for an intermediate representation (IR) was UNCOL, which came from SHARE in 1958. The concept of an IR had existed before then, but (so far as the talk described) no one had proposed a concrete representation.
- You can always construct a Sea of Nodes representation from a CFG representation, but not the other way around. Both these representations try to introduce additional variable definitions such that every variable definition and assignment in the program occurs exactly once. The nodes in that graph and assignment/definition operations, and the edges go from a variable definition to the sole place its used in an assignment. This is a Sea of Nodes, but a CFG representation further holds onto information about the ordering of nodes in a program (i.e. which assignment operations are executed first and which are executed last).
- Sea of Nodes isn’t actually more parallelizable than CFG representations. That’s something people say on the internet in blog posts, but it isn’t actually true.
- The V8 engine used to use a Sea of Nodes representation for its optimizer, but they’ve since moved to a CFG.
- E-graphs require an extraordinarily high amount of memory to store the equivalent representations of an expression. In practice, a compiler can only isolate a small segment of the program where the majority of the running time occurs—called the “kernel”—and use an E-graph to optimize that, since applying it to more of the program would be prohibitively expensive in terms of memory usage.
- (Independently of all the above) SSAs are indeed the right way to structure an optimizing IR, according to Tommy. I get the sense this is the academic consensus?
- Most of the compiler optimizations that exist for purely calculation-related optimizations (not memory-related optimizations) were invented in this one paper from the 1990s. Can’t remember what it’s called—it was written by two people, one of whom had the last name “Cocke.” We’ve since invented more optimizations for non-calculation-related things, but really, LLVM and company are still only applying those calculation-related optimizations to this day.
- Potential pointer aliasing makes compiler optimizations much harder.
The above are messy notes I jotted down in about 20 minutes. Apologies to a reader (e.g. my future self) if they’re not very well organized, at some point I’d like to go back and edit them into a readable version.
I ordered MSG from Amazon, because I was curious to see how it compares to the Takii mushroom powder I usually use—the two of them are meant to be close substitutes. And the MSG just arrived!
To my great dismay, it tastes extraordinarily weak. I’m having a hard time imagining how one could use it as seasoning.
This is a paragraph with code in it. This is supposed to be a length that doesn’t stretch the size of the paragraph.
This is a paragraph with code in it. This is supposed to be a length that doesn’t stretch the size of the paragraph.
… okay, ideally those two paragraphs above are the exact same height. If my CSS is doing what it’s supposed to, they will be.
I made a picoblog post that talked about how to set image attributes. I’ve since figured it out; there’s a way in Zine to do this in a pain-free manner, and it involves using tooling to set the image attributes to the pixel sizes of the images, and then using CSS attributes to set the width and height. Since CSS is render-blocking, the CSS width and height tell you exactly what space to reserve before the image loads in. Furthermore, if you specify a manual CSS width and then set the CSS property height: auto on all your images, the image attributes will be used to fill in the height automatically so long as you’ve manually specified the CSS width. It’s probably better to do it this way than the other way around, since web pages read from top to bottom, and so it’s easier for a designer to know their desired width than their desired height for an image.
So now I know the best practices for web development in this area! Too bad it’s not documented very well literally anywhere online! Ugh.
I think either we need to
- change our notation for sums so that the capital sigma comes after the summed terms, or
- change matrix multiplication to be by default on the right and to have vectors be row vectors.
Explaining this is probably worthy of a microblog post. It also sort of explains how and why the convention for using row-stochastic matrices arose in probability theory; I now have a pretty good guess as to why that happened.
I need to write a manifesto about this. I did write a manifesto about it once, before the App Store deleted it mid-composition. I should document the story of how it got deleted and then actually re-write the manifesto.
I’m mad about flexbox layouts. It seems like the flex-shrink property and applying wrap at the same time is absolutely useless, because flexbox always prefers to wrap items before it bothers to shrink them. That means shrinking only gets applied when there’s literally only a single item in a line. There could be so much more rich behaviors that they could have enabled a developer to take advantage of, but they didn’t.
I think the vast majority of good things in life are not positional goods. This is really core to my worldview, and I think I’d like to write an essay about it someday. I dunno.
He also suggested I should entitle this “My Uncle wants to look inside my brain,” which I think is a humorous title.
How do I set the attributes and CSS styling on my <img> elements so that they (a) never cause any page reflow when they load, (b) are able to scale well across both mobile devices and desktops, and (c) are able to work well on high and low dpi screens alike?
I want to know what the best practices in industry are. I don’t know what they are and that bothers me. An additional constraint I have is that I don’t care how maintainable the optimal solutions are, since that’s a constraint that can be gotten around with sufficiently good tooling. If it’s a lot of extra effort for the developer and/or harder for teams of designers to collaborate to implement an optimal solution with currently available tooling, I don’t care—I want to know what the theoretical optimal way to do your HTML and CSS would be to give users the best possible experience.
This is such nonsense. I’ve heard at least two conflicting definitions of CSS px units so far, and neither of them make a lot of sense.
It’s so frustrating. I’m noticing that objects that should be a certain number of px are visually different on my iPhone vs my Windows computer. But… that difference doesn’t perfectly match up with the 1/96th of an inch vs. 1/72th of an inch distinction between macOS and Windows that I’ve read about. So what gives? What’s going on here? Is there some mysterious third ratio thing for iOS? Is there some other definition I don’t know about? Is it actually consistent with one of the other definitions I’ve read? I don’t know!