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.

She looks a bit young for a fryer…

These little suckers are not only great for breaking down all the cardboard boxes you get with your Amazon shipments, they turn out to be a terrific way to tear through ‘ballistic nylon’ straps, duffels, and laptop bags (a power I’ve used only for good…). Much faster than knives or shears, especially for extracting strap and clasp hardware.

In theory, they’re disposable; in practice, they last quite a while.

Pro tip: when disposing of old duffels and laptop bags, check all pockets for leftover cash, gaffer tape, screen cleaner, and tools. I’d been wondering where that old SOG multitool had gotten to…

Never change.

“That’s one small step for a man, one giant lawsuit for the hotel…”

(via)

So, let me see if I’ve got this straight: all your remarkably expensive phones are soooo thin and light that they have terrible battery life, so now you’ve released big chunky battery packs that make them even more expensive, but also clumsier to use and store in pockets.

Y’know, product design isn’t just about fashion and marketing bullet points. Sometimes ya have to provide value for the price…