Show newer

You know, perhaps the idea of a centralized search engine for the whole web - *any* centralized search engine - was just a major design mistake of the early web, and we should all have been working on community-curated search engines instead.

POLL: What type of device are you using, RIGHT NOW, when you see this question?

(Please note I am not asking for opinions on the merits of devices, nor do I want to know the other devices you have. I want to know what device you're using to answer this question right now.)

Hey y'all! Quick reminder that you can still sign up to attend #SolsticeSchool talks until the event itself, here ✨ solsticeschool.scholar.social/

What talks are you most looking forward to attending?!

oh i get it. it's called "cgit" because its "cgi git" but also "a git frontend in c" that lets you "see git"

seekseek devlog, long-ish, technical details 

I'm currently working on the auto-expiry of dependent tasks, ie. tasks which should be run once another task has completed. This is somewhat tricky.

For a bit of background: in srap (the working name for the backend), everything is expressed as 'items' with 'tags', and 'tasks' which are run on items that match the tags configured for those tasks. Tasks can then, at runtime, decide to invoke functions that create or modify items in the dataset (by name or otherwise), and assign tags.

It's possible for multiple tasks to run on items with the same tag, and it's also possible for those tasks to specify dependencies on each other; for example, given a page ID, you may want to 1) scrape the page contents and only then 2) normalize the scraped contents to some standard format, as separate tasks.

Now the challenge here is to ensure that once task 1 is re-run (because the TTL expires and it needs to be re-scraped), task 2 will *also* be re-queued. There's no explicit queue, the queue is just "whatever items are eligible tag-wise and do not have a recent-enough successful run registered for a task".

This is made difficult by the fact that the backend doesn't actually have a full dependency graph! It can know that task 2 dependsOn task 1, but the item may have been originally created by a task 0 which scraped a list of items (like a sitemap), and there's nothing telling the backend that task 0 can create page ID items, other than it just *happening to do so*.

The solution I've come up with so far, is to expire a taskRun for an item under two circumstances, checked whenever an item is modified:

1. The task in question does not have any dependencies, ie. it is the root/first task to run for a given tag - and the task that *modified* the item would itself never run for that item (to prevent cycles of dependents re-triggering the root task). This handles the "list -> item" case.

2. The task is a direct dependency of the task that is doing the modifying. This handles the "two tasks for one item with a dependency relation" case.

Now to actually implement this :)

Show thread

Once again I ask if anyone has a FOSS todo app (self-hosted web interface or local app, doesn't need to sync) that supports blockers; i.e. one task blocking another, with one task being able to block multiple tasks and tasks being able to be blocked by multiple tasks and the app being able to show me which tasks are currently not blocked by any open tasks?

It’s really this thing that gets me.

Let’s say you’re on a big mission in the world. You think websites should be more accessible. Websites should work for anyone regardless of their disabilities. You also think the web right now is failing in this regard. There are far too many inaccessible websites existing and being created. You think that educating developers is great and that developers should make accessible websites, but that’s not doing enough.

chriscoyier.net/2024/07/13/its

We desperately need to start a Slow Software movement. High quality, intentionally designed, low defect software done at a quarter of the pace for the same price. Because we've been destroying the mental health of developers for the last quarter century, and what do we have to show for it but a giant mess?

uspol 

Political violence didn't start with Trump, nor will it end when he's gone, but he has done an awful lot to normalize it. Remember the curb-stomping that he cheered on during his first candidacy, or bragging that he could shoot someone on 5th Avenue and get away with it, or his lawyers arguing he has the right to send Seal Team 6 after his rivals?

He has never been shy about violence as a means to achieve his political ends, and we cannot afford to forget or erase that now.

Show thread

uspol 

Last time I went to Costco, there was a guy with a "Fuck Your Feelings" gun-club t-shirt. That's political violence.

When we flew a progress pride flag, someone took it down and threw it in the dirt. That's political violence.

I live in a relatively progressive city, and lead a pretty privileged life, and I still see the edges of that violence.

If your concern about political violence starts and ends with what happened to Trump, there's a whole fucking lot more you're ignoring.

“"GitHub" Is Starting to Feel Like Legacy Software - The Future Is Now”

mistys-internet.website/blog/b

> The once-industry-leading status page no longer reports minor availability issues in an even vaguely timely manner; Actions runs randomly drop network connections to GitHub’s own APIs; hitting the merge button sometimes scrolls the page to the wrong position—but this is the first moment where it really hit me that GitHub’s probably not going to get better again from here.

seekseek devlog, long-ish, technical details 

I'm currently working on the auto-expiry of dependent tasks, ie. tasks which should be run once another task has completed. This is somewhat tricky.

For a bit of background: in srap (the working name for the backend), everything is expressed as 'items' with 'tags', and 'tasks' which are run on items that match the tags configured for those tasks. Tasks can then, at runtime, decide to invoke functions that create or modify items in the dataset (by name or otherwise), and assign tags.

It's possible for multiple tasks to run on items with the same tag, and it's also possible for those tasks to specify dependencies on each other; for example, given a page ID, you may want to 1) scrape the page contents and only then 2) normalize the scraped contents to some standard format, as separate tasks.

Now the challenge here is to ensure that once task 1 is re-run (because the TTL expires and it needs to be re-scraped), task 2 will *also* be re-queued. There's no explicit queue, the queue is just "whatever items are eligible tag-wise and do not have a recent-enough successful run registered for a task".

This is made difficult by the fact that the backend doesn't actually have a full dependency graph! It can know that task 2 dependsOn task 1, but the item may have been originally created by a task 0 which scraped a list of items (like a sitemap), and there's nothing telling the backend that task 0 can create page ID items, other than it just *happening to do so*.

The solution I've come up with so far, is to expire a taskRun for an item under two circumstances, checked whenever an item is modified:

1. The task in question does not have any dependencies, ie. it is the root/first task to run for a given tag - and the task that *modified* the item would itself never run for that item (to prevent cycles of dependents re-triggering the root task). This handles the "list -> item" case.

2. The task is a direct dependency of the task that is doing the modifying. This handles the "two tasks for one item with a dependency relation" case.

Now to actually implement this :)

Show thread

Thanks to everyone who has been CWing their (US) politics posts. This includes most of the folks I follow, which is good to see.

highly recommend "A Psalm for the Wild Built" by Becky Chambers as a heartwarming, beautiful comfort read during these cursed times

I'm gonna do a re-read... the first time felt like a mental health b12 shot

it's got a hopeful solarpunk vision of a beautiful, possible society that's overcome a complicated, familiar history. the nonbinary main character is able to just exist without explanation. there's an adorable, curious robot buddy and delightful musings on human (and nonhuman) experiences, our place in the planet, and everything in between.

there's also a sequel, "A Prayer for the Crown Shy", which is very lovely as well

take care and stay safe. the next few weeks might get ugly 💜💜💜

#selfcare #reading #fucktrump #socloseandyetsofuckingfaraway #worsttimeline

Speaking of which: if you're interested in building your own search engine for something, and want to test out this software, let me know! All it should require to know is basic (JS) programming knowledge, and jQuery syntax. The backend handles the rest of the complexity. The software will run on a laptop easily.

(For hopefully obvious reasons, I will not assist with unethical projects like scraping personal information)

Show thread

The concept of “blood family” is a scam

This is not the only valid way to construct family. People are not entitled to my love, obligation or labor *just* because they are genetically related to me.

If you want to be with them, be with them.

If you don’t want to be with them, leave.

If you would like to be with them, but think they are treating you unfairly, demand a better relationship, and leave if you don’t get it.

Nobody is entitled to your association.

Show thread
Show older
Pixietown

Small server part of the pixie.town infrastructure. Registration is closed.