Given the recent news about large dumps of user-account data from various hacked sites, I downloaded the full list of records for my mail email domain from HaveIBeenPwned, and found nothing new and interesting. Just the adobe, linkedin, kickstarter, and dropbox hacks from several years ago.

Oddly, none of the email addresses used by Honor Hacker and friends in attempts to extort bitcoin show up in their DB, even though one of those was actually a legit closed account (I briefly had a Livejournal account for commenting, with a unique name and strong password, and the “hacker” included the correct password).

The amusing one was that the “Onliner Spambot” collection from 2017 had a confirmed hit for user “xoratmusoqxee” at my domain. That one doesn’t even show up in my spam, despite being at least as plausible as “hand04”, “quinones12”, “bain66”, “Donnell4Stark”, or the ever-popular “ekgknmfylvtl” (seriously, my spam folder gets daily messages directed to that username, all of them in Japanese).

Dumas was limping a bit when I went out to the porch this morning, so I started to give him a lecture about toxic masculinity and how violence never solved anything, and he gave me a look that said,

"Dude, it got me laid last night; now open the

damn cat food.”

Stumbled across the word 矢場女 today. On the surface, this means “archery-range girl”, kind of like a ball boy at a tennis court. Except that many Edo-period shooting galleries were actually thinly-disguised brothels, so she was really more of a shaft girl.

(via)

I hear they run a special class for journalists who want to learn to code.

(via)

Just another curated random subset to stir up my Pixiv recommendations. That is, a script opens 100 random images out of ~11,000, and I choose whatever catches my eye, repeating until I get at least 26 in both the sfw and nsfw sets.

The workflow is: drag-and-drop from Preview into a Terminal window where I’ve typed an echo command, switch focus to the terminal, press spacebar twice, and switch back to Preview. When I’m done, switch to the terminal and hit enter, then edit the echo command into an mv into a subdirectory.

Why the odd steps? Because Apple keeps making Preview.app flakier with each release. Normally, when you drag files into Terminal, you get the properly-escaped full path followed by a space, but when you drag from Preview, it will be followed by a backslash and a return, except when it’s followed by a non-backslashed return, which happens at random intervals. That’s why I’m collecting the list with echo instead of using mv directly.

This is in addition to the way it will sometimes return a quarantine path for files that have extended attributes, which is why I strip those off immediately after downloading (xattr -d com.apple.quarantine *.*, or copy them to an ExFAT volume and periodically rm ._*).

I defer the mv to the end because Preview refreshes all the image thumbnails when it detects that some of them have moved. This is no big deal when you have only 100 images open, but if you’re, say, pulling up everything that Pixiv tagged as 魅惑の谷間 (~1,500 at the moment…), it’s annoying.

The rest of my workflow is resizing with ImageMagick and optimizing JPEG size with Guetzli, pulling in links and tags with my PixivPy script, and uploading with s3cmd. I generally accept the shuffled order, but select one image to pull above the fold, then maybe shift a few that got clustered, and put a punchline at the end if I have one. And a cleanup script to number them all sequentially before posting.

more...

Once more into the breeches!

[this collection proudly assembled under the supervision of a neighborhood stray cat, with inspirational music provided by Konya Wa Hurricane on endless repeat. No journalists were harmed during the production of this entry, not even the Huffgawkbuzzhos I spotted holding up “wil hait-tweet 4 food” signs outside the discount medical-marijuana dispensary.]

more...

I bit the bullet and upgraded Hugo finally, from 0.41 to 0.53. Why so far? Because in 0.42, they re-did the internals for making relative references to pages by name, and made it a fatal error if pages in completely different sections had the same filename. Even if you never actually referenced them.

This was a show-stopper, because the only way to build your site was to fix all filename collisions, which meant breaking external links. In my case, about 300 of them on the blog, and several thousand on the recipe site (which, being automatically generated based on the recipe name, was hard to deal with; why, after all, shouldn’t two completely different collections be able to have a recipe named “egg-salad”?).

After some back-and-forth, they made it a warning that such references will return non-deterministic results, but by then there had been other changes that affected output, and I always do a full diff of the site to catch undocumented changes. And the diffs kept getting bigger.

Today I finally broke down, renamed all the colliding entries in my various microblogs (mostly affecting external links to the Quotes section), and scrolled through the 93,923 lines of diff output. Fortunately, 95% of it turned out to be removal of a bunch of gratuitous <p></p> pairs inserted by the old version of their Markdown library (either completely empty, or around <div> tags). Looks like they actually undid some of the changes that had increased the diff size for earlier versions.

As far as I can tell, nothing noteworthy broke, so I’m back in sync with the devs, and I’ve shaved a few seconds off my build time again.

So, I knocked together a quick Perl script (as one does) to generate a PDF file containing an unusual sort of grid:

In the source I was working from, the polygon was 2x7, so I used PDF::API2 to scale the coordinate system and draw one at 0,0, and then wrote a little loop that translated the origin around the page and drew the same poly all over the place. The resulting PDF is 1,642 bytes.

For comparison, the GIF up there is 5 times larger than the PDF file, and that’s after optimizing it down to 4 colors.

But I thought to myself, “self, you’ve got a gajillion wasted savestate/transform/restorestate operations in there; you should just calculate the locations of each poly and plug the numbers in directly.”

Self can be a bit of a dick, but sometimes he’s right. This time, not so much, because whatever trivial performance gain I might get by avoiding PDF’s highly-optimized state and transform operations turns out to be completely swamped by the 25x increase in file size.

And that’s just on US letter paper; render it on 11x17, and it’s up to 36x. Why? Because in the lazy, naive version of the script, the largest number used in the loop is the integer 7, and itty-bitty integers can be packed in good and tight.

By the way, the code is so simple-minded that it draws the wide grid line at 0,0 and then translates up the page, making it upside-down. So I added a line at the start that transforms the origin to the upper right corner and rotates the page -180 degrees. This added 13 bytes to the output, which I don’t feel the need to optimize out by drawing rightside up. 😁

Update

Rewriting the code to draw every line segment exactly once shaved a whole 87 bytes off of the file size, but cost about twenty minutes of sketching out grid components (5) on a piece of paper and then re-writing the loops.