Julia and I are in CA for LessOnline this weekend, and we're staying with friends. It happened that they were hosting a party, and while this is not a group of dancing friends they asked if I'd be up for leading some dancing. One of my hosts let me borrow their violin (which I'll also have with me today at LessOnline if anyone would like to jam some), and the space was small enough not to need any amplification.

Playing and calling at the same time is only something I can do if I play simple tunes I know very well while calling simple dances, and both my playing and calling suffer from the multitasking. But my hosts encouraged me not to worry about this and thought we'd have a good time. I think they were right!

Historically people kept up with blogs via RSS, but it's been on its way out for over a decade. These days receiving posts via email is popular, and I should probably make my posts available this way. I considered implementing my own emailing system, but bulk email is (or at least was, I'm not up to date here) a pain. Instead I decided to start cross-posting to Substack: jefftkaufman.substack.com. This will be yet another way to read my posts, similar to the LessWrong mirror and my text-only FB cross-posts.

I have a full RSS feed of all my posts, and Substack imported it fine. It doesn't look like there's an option to do ongoing RSS-based imports, but copy-paste seems to work well enough; I did this post and the previous one that way. At some point I'll look into automatic cross-posting, though right now it looks like Substack doesn't support anything good. And if I'm going to reverse engineer something I'll start with their comments implementation, since I always want to rehost comments.

One aspect that's a bit eerie is the URLs: both Substack and my blog would use /p/post-name-in-title-case as the url for a post titled "Post Name In Title Case". I've been doing this since 2013-10-28 and Substack got started in 2017 so I know I didn't copy them ;)

When I came home from work today Lily was very excited: she wanted to build a playhouse for our 1y11m neighbor Jo. Lily had gotten parental permission, the yard had space, and I was the only remaining obstacle. I'd normally be pretty excited about a project like this, but it was 5pm and I was signed up to cook dinner.

On the other hand, we'd recently been reading the Little House books and Farmer Boy and we'd been joking about how the fathers in the books built things unrealistically quickly. Most recently, Almanzo's father builds a bobsled from scratch in a single a day, including identifying and felling the trees. Still, most of the unrealism comes from what they had to work with: no pre-cut pre-seasoned lumber, no power tools, pegs for fasteners, etc. Perhaps with modern tools we could build a minimal playhouse together and still have dinner on the table by 7pm? Sounds fun!

The unix sort command is clever: to sort very large files it does a series of in-memory sorts, saving sorted chunks to temporary files, and then does a merge sort on those chunks. Except this often doesn't work anymore.

Here's what I see if I run man sort and look at the documentation for --buffer-size:

I'm a big fan of small focused PRs: it's much easier to tell whether they're actually doing the right thing. For example, I recently ran into a common scenario where I started adding some functionality, and realized this required some refactoring. The refactoring also made it clear that the original code was missing some important test coverage, so I added some tests. I ended up with a big set of changes which combined large refactors and a major (intended) change to the output.

This is a bad combination: if my refactoring accidentally changed functionality in a way not captured by the tests we might miss it. And with so many changes it's going to be hard for the reviewer (and even the author) to keep it all in their head at once. Instead, it would have been better if I had first done the refactoring and added tests, and then followed up with the new functionality. The first PR would be a bit noisy but conceptually straightforward and easy to validate because it produces exactly the same output for all inputs. The second PR would be very clean, but would require careful validation to verify that the changes really are an improvement.

I might be tempted to say "oh well, I should have approached this differently, I'll do better next time" but really I did need to combine these two changes when writing them: I didn't know for sure what I would want for the refactoring until I'd tried to use it to implement the functionality change. So if my plan was to do better next time I wouldn't actually do any better.

As I wrote about last week, it's worth it for everyone to have an elastomeric respirator in case of emergencies: the chance of a severe pandemic is high enough that even under reasonably conservative assumptions the return on investment is ~10x. Because not every mask fits every face and a poorly fitting mask will leak air around the seal—it doesn't matter how good the filters are if they're bypassed—it's good to try on a range and see what's good. I invited some people over to try out a range of masks and play with fit testing.