Zen and the art of catnapping


Vacation funds secured…


Dear Amazon,

Are you sure this is for toddlers?

These two recommendations really go together…

Carefully eat machine translation

  1. The cucumber remains a stick, sprinkle with salt and rub.

  2. Rinse with water and wipe off the water with a cut-down bar.

  3. Put a cucumber and seasoning in a bag such as a flop. Pull out the air, Has schooled rub seasoning will go around evenly when closed.

  4. Put it in the refrigerator and marinate for half a day. I maceration to see you on the way.

  5. Discard the juicy and eat without washing away.

One for Steven…

…wherever he is: moe maid glasses shop, with plenty of under-rim glasses styles.

Note that this is part of the Candy Fruit maid empire, which includes an actual housemaid service (“we do windows, but we won’t do you!”).

“Life finds a way…”

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.


Learn to code!

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. 😁


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.

Dear Internet,

Never change.

“Need a clue, take a clue,
 got a clue, leave a clue”