eternityforest

Very cool!

I've always wanted something like this!

But I'd want to see some kind of clouds storage sync to actually use it for anything practical.

Maybe it could include YJS, with agents taught to use it, and save/load them to Google Docs?

I sometimes use unit tests to fill in gaps. I just caught a function with almost full coverage except for an if statement.

Playwright e2e tests are harder to maintain than pytest code, so I wrote a test just for that one case, and while I was at it, a few other input strings that seemed like they could be problems.

If the function had no test coverage at all, I probably would have tried to get it with an integration test, because that would mean the callers also weren't getting tested.

Would a splitter fix this?

Are there approximate solutions with fewer sides that would have less than 1 in a trillion or something unfairness?

I think there's no real need to learn with leaded anymore now that we have temp controlled irons and better fluxes and such.

Wearing gloves and washing your hands five million times is more annoying than just using lead free.

And even with perfect precautions, the flux expands and makes it spit tiny little balls, which then contaminates your whole work area with a somewhat fine dust.

The important thing with lead free is you're not looking for the color or texture when inspecting, you're looking for the shape, and absence of any tiny seam or cracks.

It's probably not gonna be 100% shiny, that's fine, it just has to wet effectively instead of just kind of hovering in a blob.

Lead free is the only thing I use unless I'm repairing some old pre rohs era thing I guess, but I generally don't encounter many of those.

C245 clones seem to be the new current standard tip format, they're pretty nice.

Not supported by any open third party firmware usually, but that's fine with me.

One thing to watch out for is tip grounding, some cheap irons leak a few volts at micro to milliamp level power, relative to ground, which could matter if you solder very sensitive things that are grounded, which you probably don't.

DIY fume extractors are hard to do, you need powerful fans unless you have an arm to put the extractor right above the iron. Also remember that when it's just sitting in the stand, it will still smoke for a few seconds, so the extractor must cover that too.

Those thin wispy activated carbon pads probably aren't doing much, you need actual particulate filtering like a HEPA or similar, but almost anything is better than having the smoke directly in your face with no fans.

I tried to start something similar as a GitHub Awesome list(awesome-standards), but this seems like it could be way more powerful.

Although this seems to be focused on specialist professionals, and I was focusing on things that are universal enough that a non specialist wouldn't be annoyed about buying for a project.

It would be nice if it had wiki-like info for any specific oddities that professionals would know.

Some of the stuff on there is pretty surprising, like leaded solder and the FX-888D soldering iron, in the age of C210/C245.

A lot of the time the thing you already have is totally good enough, but it's not what you'd buy if you were buying new.

I think an actually interesting malleable solid base for non-hackers would be a platform that you log into, create a workspace, share it, and add an app made of some JS that runs in a sandbox, everything fully managed, your app never sees even a user email if it doesn't have to.

Is there a reliable app to detect these without using excessive amounts of battery?

Atuin already solves that very well for me, although I might consider this for new commands

I use it rather often in professional projects, usually for figuring out power supply inrush transients, and I usually point anyone who wants to learn electronics to it.

Just be sure you set the simulation step size appropriately if there's high frequency stuff happening, or the results will not make any sense.

It looks really cool, except the case looks like it puts mechanical force on the connectors, which aren't exactly known for reliability.

Having a tie bar with a screw into each half, or even just some bosses to prevent lateral movement would be nice.

The C instead of C++ or Rust SDK would be a major negative point for me, but I'm sure the more hacker minded people will love it!

I have a ~200 line file of style rules that I copy and paste between all my projects(There's got to be a better way to manage files like that!) but I can never quite tell if it's helping anything....

I usually prompt with very specific architectures, defining classes, functions, and JSON schemas, plus what libraries I want to use, and that seems to work, most of the time.

I generally use AiderDesk with MiniMax M2.5

They made the laser drill from The Core IRL?

I have my own personal formal debrief process for larger projects: https://github.com/EternityForest/THUNDERWARS

Usually if I notice anything of interest to others, it just winds up in a group chat.

There are two other solutions, make the automation so reliable that the human skill is not needed, or make the consequences of failure low enough that you can just accept failure.

As far as I know, Places that actually care about safety apply all of them at once.

They add layers of failsafes that don't rely on humans, they make the automation better and better, and for the most critical stuff, they continue training for things that will almost certainly not happen.

And for the rare(depending on personality) cases where we care about the pilot's ability more than the result, just don't automate at all.

This inventory tracker app that runs entirely in the browser with yjs, and syncs over peer.js, that I have not been very good about using lately

https://eternityforest.github.io/Stuffer/

Not an app, but a productivity system, partially refined by telling AI every time I forgot anything and asking for research references on human error that are relevant to that specific mistake:

https://github.com/EternityForest/THUNDERWARS

I've been doing LARP and tabletop most of my life, that's exactly the feel I was going for.

Most of the actual functional "backend" parts come from computer science and various research used in safety critical industries (Like Crew Resource Management), but the general aesthetic is heavily tabletop influenced.

I haven't done much with most of the explicit "gamification" elements like habit trackers use, because those usually don't actually feel like games, they're mostly just performance metrics without any story or gameplay mechanics.

I think it would be cool in theory to have some sort of XP system, but mostly everything I've seen seems too much like bookkeeping overhead.

In real TTRPGs, the points actually represent something, but with habit trackers, they're representing results that already exist automatically in the real world as a consequence of the habit.

I can't imagine that mics are going to be affected by anything that doesn't also seriously bother at least some animals, definitely not something I'd use outside of some ultra secure conference room or something.

A web based inventory management app. I've wanted to try something like this for a long time, but it always seemed completely impractical to spend a few weeks on before AI, without knowing if the entire idea is actually practical.

So far, I think it is in fact worth it, but only in specific use cases, like very rarely accessed items with no obvious place, and making sure your AV gear you bring to events comes back with you.

* Every item is a container, unlimited nesting

* Everything stored in the browser with YJS, very clunky peer.js or manual file sync available

* Select an object, click add items, scan QR codes to add those items

* There's also NFC support on Chrome mobile

* Generate random printable QR sheets(Still need to fix sticker alignment issues)

* Tracks where an item was last scanned with GPS

* Save container contents as a loadout, check contents against loadout

* Can mark a container as needing re-inventory, contents that haven't been re-added after that show a warning

https://eternityforest.github.io/Stuffer/

Local hubs solve that pretty well, aside from still needing to update the hub.

I remember doing my own backups with rsync a super long time ago! It worked pretty well, but it didn't have compression, encryption, desktop integration, or deduplication, and adding anything would be one more script to maintain.

Now I use Kopia, no real complaints there. I used to use Borg but until recently it needed some fussy extra community package to work on Synology.

I'd love to see a new battery standard.

Something future proof for new chemistries, consumer friendly and self protected, able to be series-es and paralleled if needed, etc.

Maybe even designed to be an external part of the case like 2 way radio and tool batteries, with the option of a retaining screw for toys and tamper resistance.

A few different sizes, from keychain up to power tool, and paralleling adapters to go bigger.

The electronics would probably cost pennies in volume, just like the tech that goes into those lithium AAs with built-in chargers and buck converters that are almost really awesome.

I've been using one folder per client, one folder per project for years, with no issues, although I don't tend to work on small pieces very often, I rarely do anything that seems too small to make its own project folder.

I used to do the FHS style organizing things by category, but now I'm pretty strongly against non-isolated project environments.

Sodium ion showed up a year or two ago and you can buy them on Amazon as 12v lead acid replacements, 18650s are also available but the voltage range is different from normal lithium.

Debugging rarely works correctly between languages, and features like "find all references" usually break too. Maybe that's not an issue with Prolog because a C logic solver would also be hard to debug, but it's a problem with many template languages.

Is there an online demo? How does it compare to Opus?

Tests freeze behavior in place, and manual end to end testing can confirm that the most common paths are at least kind of correct ish.

Obviously that's not good enough, but I'd much rather have AI tests than poor test coverage.