I needed to test some HAProxy and Let’s Encrypt stuff, and it was easiest to just test it on my development machine, so I wanted a way to quickly and easily expose ports 80 and 443 from my laptop. Here’s my brief survey of what I found.

I got a new MacBook Pro (MBP), so now I have two Macs, and of course I want to sync a bunch of preferences between them. I want my trackpad to work the same on both machines, I want the same keyboard shortcuts, they’re the same screen size so I want the same resolution on both, and so on.

I’ve seen plenty of people scripting their macOS system preferences. One of the most well known is probably Mathias Bynens’ .macos script, but there are plenty of others doing this. So when I got my new MBP, I said, “Finally, time for me to get my hastily noted preferences out of an org-mode file and into a reusable script!” After all, I love automation.

After untold hours of searching the web, reading Apple’s open source, disassembling Apple software, and trial and error, I have probably figured out how to make three finger horizontal trackpad swipes go backward/forward pages. On Mojave, at least. It requires using at least one private framework. I expect it to break in some future macOS release—who knows, maybe the one coming out this fall.

Or I could click one single setting in the System Preferences GUI. That takes about ten seconds, including starting System Preferences.

Maybe scripting some preferences isn’t worth it.

I was trying to use getmntinfo(3) in macOS today to get information about mounted file systems. getmntinfo returns some struct statfs containing the desired information. I wasn’t just trying to use it from C, though. That would be too easy. No, I was calling getmntinfo from Python using its ctypes library.

I was really curious which blocking lists Pi-hole uses. It took me forever to find them. Turns out they are in basic-install.sh (for now, at least). Here’s the relevant excerpt:

In my prior post on using dateutil for time zone information in Python, I half-jokingly posted a bit at the end about the size of pickled pytz tzinfo instances compared to pickled dateutil tzinfo instance. Paul Ganssle later emailed me to speculate that pytz’s smaller size is due to the fact that pytz is storing the key (name) of the time zone when you pickle one of its instances, whereas a pickled dateutil instance has all of the information about its time zone.

I’m not one to ignore the generous gift of someone’s time and knowledge, so let me dig into that a bit further. (Though Paul emailed me about four months ago, so I guess I am one to postpone acknowledgment of said gift.)

The TL;DR here is that Paul is basically right, and understanding this difference could be useful if you find yourself pickling/unpickling tzinfo instances from either library.

Paul Ganssle, current maintainer of dateutil, asked me to review my 2014 post “The Case for pytz over dateutil” because he believes that dateutil now addresses the concerns I had in my post that caused me to give a slight nod to pytz over dateutil. He’s right: I don’t see any particular reason to use pytz anymore for my applications.

I was actually going to title this, “A Brief and Incomplete Catalog of Static Site Search Options, None of Which You Will Love”, but I thought that would be too long.

This is a list of options I’ve found for adding search functionality to this web site, which is to say a small, statically-generated site that is a hobby and doesn’t produce any revenue. I mention that bit about no revenue because if this was more than just a personal site, and particularly if it were a site that makes money for me, I’d have no problem plunking down $40/month or so to get some kind of hosted search, or even just hosting something like Apache Solr myself.

I’m writing some software that interfaces with the GPIOs on a Raspberry Pi. I found myself wanting to test this software on my Mac while I was developing it, meaning I’d need to make “mock GPIO files” to test against. The trick was that I needed something I could send to select(2) and signal an “exceptional condition,” since that’s how Linux indicates an interrupt on a GPIO. This ended up being an education for me on both TCP out-of-band data and, surprisingly, pseudo terminals.

Often enough, in Python, I find myself wanting to do something with a key’s value in a dictionary, but only if the key exists. I think that the most obvious way to write this is:

if key in some_dict:
    do_something_with(some_dict[key])

However, I always thought looking up the key in the dictionary twice was wasteful. Instead I preferred to write the following code, which remains readable but does only a single dictionary look up:

value = some_dict.get(key)
if value is not None:
    do_something_with(value)

Surely one dictionary look up is faster than two!

Unfortunately I think my assumption was wrong.