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 |

next up on ktistec...
i'm writing a simple tdop/pratt parser for rules, now. i've done it before for other projects, with more complicated grammars, and imo they're easier to understand and extend than lr/ll parsers. douglas crockford popularized them in a post a while back—writing a javascript parser in javascript.

@Gargron it's been a good weekend for cat photos!

status update on ktistec...
commits 831dce60 to aa608699 reimplement notifications and timeline management as declarative rules rather than procedural logic. this is the culmination of work announced a while back. here's a sample of what the code looks like now:
rule "create" do
condition var("activity"), IsAddressedTo, var("actor")
condition CreateActivity, var("activity"), object: var("object")
any Mention, var("mention"), subject: var("object"), href: var("actor").iri
none Notification, owner: var("actor"), activity: var("activity")
assert Notification, owner: var("actor"), activity: var("activity")
end
rule "announce" do
condition var("activity"), IsAddressedTo, var("actor")
condition AnnounceActivity, var("activity"), object: var("object")
condition Object, var("object"), attributed_to: var("actor")
none Notification, owner: var("actor"), activity: var("activity")
assert Notification, owner: var("actor"), activity: var("activity")
end
...the first rule says, if an object (post) mentions the actor (you) and a notification doesn't already exist, create one. the second rule says, if someone announces (shares/boosts) an object (post) attributed to the actor (you) and a notification doesn't already exist, create one.
the implementation took three steps: 1) implement a simple, generic rules engine called school, 2) implement logic in ktistec to make it possible to expose the object model and records in the database as facts in the rules engine, 3) reimplement the rules. there was plenty of yak-shaving, too—the preceding ~15-20 commits were fixing things that were in the way. (my usual heuristic assumes 25% refactoring existing code and 75% developing new code, but in this case it was 75%/25% in the other direction.)
while not trivial, rules are easier to reason about than code. toward the end of the project i realized that i wasn't adding replies addressed to me to the timeline (they were only visible in a thread). i was able to fix that defect with a small modification to the rules.
the goal is to make rules modifiable by the user at runtime so that users can customize their ktistec instance without having to rebuild it. the next step toward that end is a simple rules definition language and parser.


whenever i start researching a new, but relatively popular, topic—i’m looking for open source 3d cad/modeling software for 3d printing—i’m always surprised by how much less useful the web has become.

companies are increasingly using tools like otter.ai to record candidate interviews—for later review and to use for training. i recommend candidates do the same, and use the recording, themselves, to improve their interviewing skills.



how in the world does she only have 23k followers...?

[Sunday, July 20, 2014: 10:00 am] The LambdaMOO server, the application server that still powers the LambdaMOO online community and that was the engine for hundreds of other text-based virtual worlds (MUDs), was first released over 20 years ago, in 1991. MUDs (Multi-User Dungeons) were the first networked virtual worlds; and they were popular long before Second Life, Word of Warcraft, and MMORPGs in general made their appearance. Even though much of the code in the current LambdaMOO server is unchanged from the early 90s, people today still download the code, compile it, and build little worlds with it. Motivated by a desire to build simple little immersive experiments that users could interact with and extend via programming, but frustrated by LambdaMOO's lack of features as well as source code that was several decades away from modern best practices, Todd Sundsted spent the last four years modernizing the server, and building applications and a library of application building blocks. The result is a fork of the codebase called Stunt that speaks HTTP (instead of telnet), includes up-to-date cryptographic primitives, and sports language enhancements like multiple inheritance and garbage-collected, anonymous objects. On top of this platform, he built a simple, modern MVC web framework. In the process, he learned quite a bit about maintaining, evolving, and extending old code, and about interacting with a small but passionate community of longtime users! Sharing these learnings, rather than talking about the specific technical details, is the purpose of the presentation.

the lever for the blade guard on a circular saw i picked up was broken, and the replacement part was discontinued/unavailable, so i printed a replacement from the piece that remained and some online photos.


the part wasn't available anywhere. well, that's not strictly true. i did find the part listed for $99 somewhere. i had the piece that connected to the saw for reference and a sears parts site had photos, so making my own seemed more reasonable.


it looks better in black imo.

i had to master printing supports to deal with the slight overhang, so it was a learning opportunity, as well.