Notices by Ayo (ayo@lonely.town)

> 28 files changed, 627 insertions(+), 1102 deletions(-)

Getting rid of old Elm code from VNDB, one form at a time. :blobcathappy:

@lanodan I threw some VNDB data at the templates for that instance. :blobcathappy:

My latest silly project: Infinite Slop, a template-based random page generator to waste resources of stupid crawlers.

https://code.blicky.net/yorhel/infinite-slop

Now to find some fun ways to direct bots to it.

I had the brilliant idea to embed back-end debug data to pages as links:

<a href="/debugjson?c={..json here}">debug info</a>

Which the '/debuginfo' enpoint would then nicely format.

...but that doesn't seem to work when the debug info easily exceeds 32 KiB, even after trying some compression. Firefox refuses to even follow the link. :blobcatthinking:

I'm feeling an urge to write a new website framework in Perl, taking learnings from my current framework and cleaning up the bad ideas that have accumulated over time.

But my current framework is still kinda okay and barely... wait... 16 years old already!? :blobcatshocked:

So my quest to implement some "quick and easy" optimizations for one page on VNDB ended up in a C rewrite of a module that is widely used across the entire codebase. Was neither quick nor easy, but the wins are now measurable on nearly every page load. :blobcheer:

https://g.blicky.net/tuwf.git/commit/?id=47a5baeecadb11728d4e2d73454c9957e2231581
https://g.blicky.net/vndb.git/commit/?id=456ef9db0e2b3bc1ed5db34457e63120535821e6

(While that was fun, I really ought to start working on *useful* things again...)

Yes, I did just spend 2 hours migrating Manned.org from Apache + mod_fcgid to Nginx + spawn-fcgi, even though I've already had that exact same setup with VNDB for several years now.

Benchmarking some unoptimized Perl code, hoping to find quick and easy wins.

Instead I'm fighting unreliable benchmark results and can't come up with a single change that measurably improves performance. :blobcatnotlikethis:

Am I writing a Perl module in C now? Yes I am. So much for "quick and easy wins". :blobcatshrug:

Happy New Yea--

Oh, never mind, not yet time. Just people being too eager with fireworks again.

@wolf480pl I know, right?

Sadly the only 1-byte type in core Postgres is a boolean, which is... not quite suitable. Using the FK approach with smallints still halves the storage requirements, but meh.

I'm almost considering hacking in support for 1-byte enums into Postgres. Even have an idea on how to do that within its current enum framework, but I doubt there's much enthusiasm among postgres devs to add the complexity unless I can motivate it with some strong use cases and benchmarks.

@wolf480pl Yup, it's essentially a varchar(n) with automatic padding.

I often struggle to disable the micro-optimization-addicted part of my brain when designing SQL schemas.

VNDB has a table with 4 enum columns, each supporting 5-6 possible values. Postgres encodes enums as 4 bytes, so those 4 columns occupy 16 bytes on disk. But the same information would comfortably fit in just 2 bytes!

Of course, I could merge the columns into a single smallint with some fancy bit twiddling, but that comes at the cost of awkward queries and complicating the codebase. The benefits aren't worth it either: space savings will likely be insignificant if you factor in other columns and row overhead, and it's unlikely to make much of a difference in terms of performance.

BUT STILL THAT INFORMATION COULD BE 8 TIMES SMALLER! :blobcatreeeeeee:

@bert_hubert Having worked on one project for 17 years, the best decision I've made was to minimize dependencies and choosing tech that seemed like it'd stick around for a while.

I've had much more recent projects where I already regretted using a library that broke within a year or two and isn't being maintained anymore.

Holy shit.

Upgraded laptop to Alpine 3.21, fully expecting something to break, as usual. But not only does everything seems to be working fine, my laptop can finally go into suspend again after 2 years! And Nheko can load images again. :blobcatjustright:

Love waking up to a PC that refuses to boot.

@ivesen Don't remember a thing from that but apparently I voted that a 3/10. :blobcatnervous:

I have a policy of not starting an anime until it's finished, so that I can watch the entire thing at my own pace. But *every* series that looks even remotely interesting is getting a sequel nowadays. What I am supposed to be watching now? :blobcatnotlikethis:

@lanodan That's an option, but I'd rather see such alternatives be proper libraries on their own rather than pretending to be libjpeg, so applications can optionally use both and/or migrate to the better library over time.

jpegli is actually written that way but the build system doesn't expose it. :blobcattableflip:

I'm starting to think a custom LD_LIBRARY_PATH might be the least awful way of using jpegli.

Overwriting system libjpeg with a custom-built .so sounds insane to me. Creating a static binary specifically for the project that needs it involves unmaintainable magic build system incantations for 10+ dependencies.

I suppose there's Nix or Guix, but I'm too old to be learning new tricks.