This action will delete this post on this instance and on all federated instances, and it cannot be undone. Are you certain you want to delete this post?
This action will delete this post on this instance and on all federated instances, and it cannot be undone. Are you certain you want to delete this post?
This action will block this actor and hide all of their past and future posts. Are you certain you want to block this actor?
This action will block this object. Are you certain you want to block this object?
Are you sure you want to delete the OAuth client [Client Name]? This action cannot be undone and will revoke all access tokens for this client.
Are you sure you want to revoke the OAuth token [Token ID]? This action cannot be undone and will immediately revoke access for this token.
| Introduction | https://epiktistes.com/introduction |
|---|---|
| GitHub | https://github.com/toddsundsted/ktistec |
| Pronouns | he/him |
| 🌎 | Sector 001 |

in ktistec news, commits 4d2f699 through 4d2f699 include several improvements and bug fixes. highlights:
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.TaskWorker now kicks off as soon as a new task is scheduled. the previous implementation polled for new work every five seconds.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.

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.

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

this happened today:
https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/
i don't disagree with their approach at all, but since the change was designed to just work for newer clients, and since older clients are, well, older, and since the change happens on servers but it impacts their clients, it was hard to see this coming until it hit.
in my case the fix was easy—upgrade openssl and rebuild—but reading the threads about this change highlights how disruptive the expiration of a root certificate can be, especially as older clients, which may not be as easy to upgrade, proliferate.

what a difference one line of code makes!
commit fe18dc5 moved the line @saved_record : self | Nil = nil from the module Ktistec::Model::InstanceMethods into the macro Ktistec::Model.included.
that single change cut the build time in half and reduced the memory required to build by about a third. you can be sure the improvement came as a surprise!
but really, it wasn't just this change itself—although it introduced the biggest improvement—because after all of the subsequent refactoring, simply moving the line back didn't increase the build time again.
the build time also improved slightly after other subsequent commits. and several of those commits introduced changes that reduced the amount of macro generated code. and that's the key insight: macros reduce visible boilderplate but don't reduce actual code that needs to be compiled.
i'm still investigating, but clearly the original placement of the line resulted in the generation of a lot of redundant/unnecessary code!
TL;DR if you're planning on using macros in crystal, check your build times before and after your changes—i'm sure there's a corresponding commit somewhere in the past that introduced this problem and i didn't catch it!

i logged in to my twitter account yesterday... my last two tweets were in 2018, then only one in 2017—so i haven't exactly been active. but i have to hand it to all of my old tweeps who are still active and keeping it together over there!
:birdsite:

OpenAI Shuts Down GPT-3 Bot Used To Emulate Dead Fiancée https://futurism.com/openai-dead-fiancee

it seems like people talk about activitypub everywhere except on the fediverse.

日本語を勉強している
