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.
Epiktistes is my home in the Fediverse. It is an instance of Ktistec, a single-user ActivityPub server like Mastodon, but with fewer users and fewer commits. Here's my introduction (last updated early-2025).
I wrote a series of posts about optimizing the performance of the Ktistec server, its build time, and its executable size: part 1, part 2, part 3, part 4, and part 5.
Some things I regularly write about, organized by hashtag:
I also wrote some #pointfreeverse.
I’ve just read two cookbooks back-to-back. What do I mean by "cookbook"? Short answer: I mean a "how to" style book long on checklists and instruction rather than abstract guidance or case studies. The first of the two books, which I’m writing about now, is Sprint.
TL;DR If you plan to run a design sprint, you should read this book.
The goal of a design sprint is to get honest customer reaction to a product or feature you believe will be critical to your success—in just five days! Is this kind of customer feedback important? Yes! Too many companies and too many products bet the bank on something that really doesn't matter much to their customers—but they take quarters or years to figure that out. If you believe you know what customers will line up for, test that now! Sprint shows you how to do that.
Some themes stand out:
Write things down. Be literal about the questions you want to answer. Draw maps of the customer journey. Use whiteboards, sticky notes, and pens—put away your devices until you're ready to prototype!
Never brainstorm or engage in group free-for-all discussions of any kind. In a design sprint, feedback is time-boxed and often in writing. Rather than the author of an idea "pitching their idea" to the team, feedback is often summarized and narrated by the Facilitator to the team.
"The Decider decides". A lot of what's good about Sprint can be summarized by this phrase. A design sprint is not a democratic process. There's voting, for sure, but after a vote, the Decider decides what to do (and may go against the vote).
Sprint is full of detail: who's on the team, what their roles are, what the agenda is for every day of the week. It describes how to find customers, how to run interviews, and how to observe and unpack reactions. Sprint includes notes specifically for the Facilitators.
Of course, to do a design sprint well, you can't just read the book—you need to practice!
nearly just shot my foot off with git. i popped a stash full of work onto a branch and then accidentally reset hard against my main branch by picking the wrong command in my shell history. poof! thankfully, with enough effort you can do anything in git—including checking out the commit representing that deleted stash...
but, some things you should somehow never allow in your shell history:
* rm -rf <anything>
* git reset --hard <anything>
* probably others...
i had to roll back to emacs v28.2 on osx (ventura). magit on v29.1-1 was super-slow and, generally, frames would unpredictably lock up and stop accepting input. it's not even obvious where i'd report this issue...
I just finished reading Minding the Weather: How Expert Forecasters Think.
TL;DR it's really a book on expertise—you won't learn how to forecast the weather by reading it.
My interest in weather comes via my company's work on maritime voyage and route optimization. I finished the book with a much deeper understanding of what weather forecasters do and what it means for them to forecast the weather, generally—which was the goal (the objective being to understand what it would look like to stand up our own weather team).
Surprisingly (or maybe not surprisingly), the idea that someone could actually forecast the weather was once thought of alongside pseudoscience like astrology.
As expected, the book includes a few chapters on using machines to forecast the weather. Unfortunately, if this is what you're looking for, the coverage is way out of date—and I don't mean in the 2017 to today sense. I mean in the late 1980's to today sense—the authors talk about using expert systems to forecast the weather. What?!? I don't expect coverage of GraphCast but I do expect something other than expert systems! (Maybe no one has used a NNs on weather data in the last ten years—I'd be surprised but I guess I'll check it out next.)
That aside, it was well worth my time to read. It definitely corrected many naive assumptions, and that's what I was looking for!
@rahul you are one of the people running ktistec v2.0.0-9. the "dist" branch had a bug that affects the metrics—all data points are added up each run, instead of only the new data points. you may not care, in which case everything should be fine. but it you do care, i recommend building and deploying the latest "dist" (or maybe let me run it for a day or two more) and then if you want the historical metrics to be correct deleting some data from the database, which i can help you with. let me know! (if you are running off "main" then you are probably not affected.)
@jayvii you are one of the people running ktistec v2.0.0-9. the "dist" branch had a bug that affects the metrics—all data points are added up each run, instead of only the new data points. you may not care, in which case everything should be fine. but it you do, i recommend building and deploying the latest "dist" (or maybe let me run it for a day or two more) and then if you want the historical metrics to be correct deleting some data from the database, which i can help you with. let me know!
i added code to log slow queries in ktistec and it's already paying dividends. most are obviously missing indexes and it's great to fix them, but the latest example—which is missing an index—is querying a table that only has one row (in my single user instance). should that table need an index on that column? i mean, just return that row...
fwiw, a slow query is currently anything that takes longer than 50msec. i wonder if that is tight enough...?
i depend on visual patterns and cues, and i need so so so many colors!
after all these years it still amazes me how often i fat-finger ^X^C and accidentally exit emacs...
getting consistent query performance, for all but the simplest queries, across different versions of sqlite feels like playing wack-a-mole. the best practice seems to be distributing a version of sqlite that's tested and works vs. depending on the system installed version?