Jim's Depository

I brought up email on a domain which hasn't had it for 15 years or so. I am instantly being barraged with spammers who actually remember the names of the people on that domain!

But I have to wonder, are these real messages and just a very persistent delivery agent? 15 years of trying to deliver the message? I'm tempted to add the users just to see.

If you want to look up countries for an IP address, because say all your comment spam in your blog comes from the same country, then the nice folks at MaxMind will hook you up with their GeoLite2 databases for no cost, though there is a license to pay attention to.

These files are in MMDB format which excels at encoding partitions of natural numbers. The format is documented and there are a number of libraries to access the files, but I wanted native Swift to keep my cross platform building nightmares in check.

You can check out swift-mmdb which I keep on github. I haven't made a change in 4 years, but that's just because it keeps working.

The performance cost is about 9MB for the data and 150µS per lookup.

I've finished rewriting femtoblogger again. Now it is in Swift 6 concurrency using the Hummingbird 2 web framework.

Thoughts:

• Swift 6 is surprisingly good at identifying concurrency foot guns. Sometimes it is obtuse about corrective action, but it caught a number of cases where I would have risked uncontrolled concurrent access.
• Hummingbird is ok, but I find it missing some features which should really be included. There are places to hook them in, and they generally write what you need in the documentation, but it would be nicer if they were included. (e.g.: access to the remote IP in the request context, or parsing multipart/form-data.
• For building on Debian, the binaries are tied to the Swift Stdlib which might not be synced on your deploy machine, so I've resorted to swift build --static-swift-stdlib in my Makefile and keeping the Swift Stdlib embedded.
• For simple packages, you can organize all the parts in a directoy at build time and use dpkg-deb --build --root-owner-group to make a Debian package with minimal fuss. If you need to screw with file owners other than root then you'll have to get into a fakeroot or something. The dpkg-deb man page alludes to them adding a owner/mode manifest, so I'd hold out for that.
• brew can install dpkg on your Mac so you can test building the package there. You'll get your macos binary, so it isn't usable. If you used the Swift Static SDK you could build your Debian packages on the mac, but I didn't want to mess with that.
• I used Lighter to access the database, but I'm not sure I like it. The API has like three ways of doing everything and doesn't really talk about them, so it's kind of random exploration to get something to work. It makes a set of struct to map to your SQLite tables which is kind of its thing, but I kept finding myself working with partial data so bypassing that layer on insert, update, or delete. For reading I ended up making my own structs anyway for reasons on about half the tables. Still, I like the strongly typed access.

So, maybe I'll write more here now that the software works again.