even a few streets in, you forget that manhattan is an island.

are illegal states
unrepresentable?

are illegal states
just detectable?

or are illegal states
lying in wait
waiting to strike
and utterly
unpredictable?

#pointfreeverse

lorenzo barasti does a great job here making up for the lack of official documentation on crystal’s select statement. the article’s a must-read if you are planning on making use of concurrency.

https://lbarasti.com/post/select_statement/

#crystal

"if there's one thing you don't want to model your adventuring on it's merry and pippin."

#dnd

in ktistec news, commits 4d2f699 through 4d2f699 include several improvements and bug fixes. highlights:

• at runtime, the KTISTEC_DB environment variable overrides the default location for the SQLite database file. i use this during testing. it may be useful for some deployments.
• the background TaskWorker now kicks off as soon as a new task is scheduled. the previous implementation polled for new work every five seconds.
• i collected all inbox/outbox side-effects in one location. this makes mailbox processing easier to reason about, and also made it easier to prevent a race condition that resulted in the same object being added to the timeline more than once†.
• images are lazy loaded in browsers that support loading="lazy".

i'm also now only one feature away—blocking actors and objects—from tagging the 1.0.0 release.

† the race condition occurs when an activity, like a create, arrives that takes a long time to validate, maybe because ids need to be dereferenced. while it's being validated, an announce activity arrives for the same object. now two activities for the same object are being processed concurrently. being added to a timeline is a side-effect, and collecting all side-effects in one location made it easier to put the duplicate check after validation but before any side-effects, which saved me from having to unwind side-effects if a duplicate was detected.

#ktistec

thinking about this: complexity has to live somewhere

complexity has to live somewhere—the trick is putting it in the right place. modern cpus are incredibly complex: multiple tiers of caching, speculative execution, etc. none of which you ever think about when building a web app, which in turn has its own kind of complexity.

a cpu runs on top of some very complex and speculative physics that we only incompletely understand: neutrino oscillations, quark color confinement... luckily you also don’t need to understand any of that when building a web app. 😀

my 2¢ is, put as much complexity as is necessary inside of a microservice, framework or library—as long as the team that maintains it can understand it. but make its interface as simple as possible, so that the team at large can effectively make use of it.

it’s kind of the opposite of worse is better, but i think the use case is different.

#software #complexity

the team at work is talking about the mastodon with guitars and tattoos.