jph

> Whenever you touch this kind of data, regulatory regimes like HIPAA apply,

My understanding is you're an actual attorney, yes?

Can you shed any light on this area...? My understanding is HIPAA and similar laws aren't applied as a result of a user disclosing their own information for their own purposes. For example, you can freely put your own personal medical information into Google Docs, Apple Notes, Facebook post, X tweet, Excel spreadsheet, etc.

I ask because Kate's App is similar in ways to my app BoldContacts, which is helps people care for their parents and disabled loved ones. I strongly believe that these kinds of apps need some kinds of privacy protections that are lighter-weight than HIPAA. I haven't yet found a perfect answer.

https://boldcontacts.org

Yes you're 100% right. Dekker is a valuable complement to CAST & STAMP because Dekker emphasizes people aspects of psychology, goals, beliefs, etc., while CAST emphasizes engineering aspects of processes, practices, metrics, etc.

CAST describes how to pragmatically bring together the people aspects and the engineering aspects, by having stakeholders write a short explicit safety philosophy:

https://github.com/joelparkerhenderson/safety-philosophy

> This is too theoretical to grok for me

Here's a fast, easy, practical way to think about CAST:

1. Causal: Novices may believe accidents are due to one "root cause" or a few "probable causes", but it turns out that accidents are actually due to many interacting causes.

2. Analysis: Novices may blame people, but it's smarter to do blame-free examination of why the loss occurred, and how it occurred i.e. "ask why and how, not who".

3. Systems: Novices may fix just one thing that broke, but it turns out it's better to discover multiple causes, then plan multiple ways to improve the whole system.

The article describes Causal Analysis based on Systems Theory (CAST) which is akin to many-factor root cause analysis.

I am a big fan of CAST for software teams, and of MIT Prof. Nancy Leveson who leads CAST.

My CAST summary notes for tech teams:

https://github.com/joelparkerhenderson/causal-analysis-based...

MIT CAST Handbook:

http://sunnyday.mit.edu/CAST-Handbook.pdf

This is so great Peter-- first I've heard of pgtestdb and it's immediately useful for me. How can people donate money to the pgtestdb project? Or hire you for consulting for pgtestdb? I'm joel@joelparkerhenderson.com and would love to help fund your work.

Type refinements are a great concept and I'd love to see them in Rust. And double-refinement types are great for helping with conversions, such as with Rust From/Into, and potentially a dynamic converter function.

Examples of double-refinements that I'd like:

- Common units like Length:Meter and Length:Foot.

- Color bits like Color:RGB24 and Color:CYMK24.

- Worldwide currency like Money:USD and Money:GBP with a converter function that knows exchange rates.

- Human languages like String:English vs String:Cymraeg with a converter function that knows translations.

Estimates are tricky because different manager roles and different personalities bias toward totally different/incompatible concepts of what an estimate actually means. The author's article is conflating realistic and pessimistic estimates:

- Realistic e.g. tech managers and people who favors agile/lean/XP/etc.

- Optimistic e.g. sales managers and people who want to promote.

- Pessimistic e.g. risk managers and people who need firm deadlines.

- Equilabristic e.g. project managers and people doing critical chain

The abbreviation is ROPE, and it turns out to work really well in practice to cover all four bases. My notes are below. Constructive criticism welcome.

https://github.com/SixArm/project-management-rope-estimate

GitAlias - https://github.com/GitAlias/gitalias/

GitAlias is a big list of git alias commands that aims to help developers by providing shortcuts, patterns, workflows, etc.

We're always looking for better ways to use git. This includes coming up with new aliases, and also improving existing aliases by adding parameters, and writing better docs.

Assertables: Rust crate of assert macros for better testing and runtime vetting.

https://github.com/sixarm/assertables-rust-crate/

BEGINNER-FRIENDLY for documentation help such as creating examples, outreach help such as connecting with developers.

INTERMEDIATE-FRIENDLY adding capabilities for no_std, and for values without debug, and for env var configuration, etc.

SICP is available for free: https://web.mit.edu/6.001/6.037/sicp.pdf

If you want to get it elsewhere, the full info is: Structure and interpretation of computer programs by Hal Abelson and Jerry Sussman (MIT Press. 1984. ISBN 0-262-01077-1).

Excellent, thank you. I do this with sed & awk & sometimes an IDE, and scooter looks better in every way.

I'm adding scooter to my cargo install favorites:

https://github.com/sixarm/cargo-install-favorites

Rosetta Code is a great resource and uses the GNU Free Documentation License 1.2.

GitHub repos of mine are seeing upticks in strange PRs that may be attacks. But the article's PR doesn't seem innocent at all; it's more akin to a huge dangerous red flag.

If any GitHub teammates are reading here, open source repo maintainers (including me) really need better/stronger tools for potentially risky PRs and contributors.

In order of importance IMHO:

1. Throttle PRs for new participants. For example, why is a new account able to send the same kinds of PRs to so many repos, and all at the same time?

2. Help a repo owner confirm that a new PR author is human and legit. For example, when a PR author submits their first PR to a repo, can the repo automatically do some kind of challenge such as a captcha prompt, or email confirmation, or multi-factor authentication, etc.?

3. Create across-repo across-organization flagging for risky PRs. For example, when a repo owner sees a PR that's questionable, currently the repo owner can report it to GitHub staff but that takes quite a while; instead, what if a repo owner can flag a PR as questionable, which in turn can propagate cautionary flags on similar PRs or similar author activity?

Good intro to KM survival stats. I appreciate the author highlighting the limitations of KM due to non-parametric results because of discrete/binned data, such as "number of machines that failed per month".

IMHO it's well worth also knowing about parametric results using continuous data, especially if you're involved in tech products, because tech product telemetry can often provide individual timestamps, such as "this specific phone worked at $timestamp and didn't work after".

A good place to start for the continuous approach is with the Weibull distribution: https://en.wikipedia.org/wiki/Weibull_distribution

Zork was amazing, and was on the internet in the 1970's.

Zork history is pretty amazing too: https://www.mentalfloss.com/article/29885/eaten-grue-brief-h...

If you've ever seen source code with comment warnings such as "It is pitch black" or "You are likely to be eaten by a grue" or "You're in a maze of twisty little passages", then you've encountered some of Zork's famous lines.

Plume's paean/elegy is very kind. Kudos to Colin and Jae for creating cohost and all the optimism. For HN people who are not familiar with the project, here are a couple quotaions.

“We have watched the world buy into the lies of people who ‘believe in the disruptive potential of technology,’ and who think the best way to realize that potential is to build for-profit businesses that enable a creative-class petit bourgeois to make it through their day without acknowledging another human being,” the founders, Colin Bayer and Jae Kaplan, stated back in 2020. “We think we can do better, by building tools that focus on fair dealing and sustainable growth rather than market dominance,” their manifesto read.

The company had been sharing its financial difficulties in a series of updates starting in March 2024, which warned that the site’s major funder, who prefers to remain anonymous, had gone completely incommunicado as the funds were running out. Cohost, however, was nowhere near being able to sustain itself, as it had just 30,000 monthly active users and just 2,630 subscribers as of March 11, 2024.

https://techcrunch.com/2024/09/12/cohost-the-x-rival-founded...

Svelte 5 runes are Svelte-specific syntax for the generic idea of JS signals such as found in SolidJS. Svelte runes are effectively compiler keywords.

Broadly speaking, runes are aiming to be higher level (e.g. pretty syntax to help developers declare state) whereas signals are lower level (e.g. how internal implement state dependencies).

Svelte runes, as a concept, are somewhat contentious among some developers. This is because runes make Svelte feel more like React or Vue, yet feel less simple. My opinion is that runes are a good/necessary step for building larger apps, even though it makes it a bit harder for novices.

Awesome work & congratulations Rich and team. I'm a longtime Svelte user and advocate for Svelte over React and Vue. I'm glad to Svelte 5 growing in strength and finesse. In particular, the new runes and new snippets are both much appreciated.

IMHO you're on HN and reading this, and know about React or Vue, then give Svelte 5 a look. It's easy to pick up because Svelte uses all the HTML, CSS, and JS/TS that you already know. And Svelte 5 works with SvelteKit, which is a great framework for apps, including routers, caches, SSR, etc.

> All the most-impactful projects in the data engineering world are now written in Rust.

Is this true? I love Rust and use it daily, yet I often hear from data engineering peers that Rust has too much friction for most data engineering projects, because of the borrow checker, lifetimes, compile times, inability to express functions and traits in some ways, async futures, and ABI/FFI issues with external data processing code.

Happy to be corrected about all the above, though.

Thanks for the reply. It turns out the current JSON file approach can't prove ownership of the project nor the domain, so perhaps there's a gap in my understanding or your team's understanding...? Feel free to contact me about this a because I believe in your mission: joel@joelparkerhenderson.com

Some options that I use successfully with other donations services and funding services...

- A unique token per project published in a project file

- A unique token per domain published in a DNS TXT record

- A verification of the project's existing setup, such as using GitHub API access or OAuth

- A forwarding to the project's existing funding link, such as using a project's GitHub sponsors link

- A heuristic with the person's existing payment links, such as contact info being identical on GitHub and Venmo

- A challenge/response, such as verifying a small random payment

- A dedicated KYC process such as with a background checking service.

Great idea! I'm trying it now by adding the file `funding.json` to two of my FOSS projects. Feedback welcome. Donations welcome. :-)

1. Assertables is a Rust crate that provides assert macros for smarter testing: https://github.com/SixArm/assertables-rust-crate/blob/main/f...

2. BoldContacts is a mobile app that helps people who have disabilities: https://github.com/BoldContacts/boldcontacts-mobile-app-for-...

Results so far:

1. The JSON spec validation seems to be problematic. For example, I get an error message and there's no obvious way to handle it: "entity.webpageUrl.url and manifest URL host and paths do not match. Expected entity.webpageUrl.wellKnown for provenance check at https://linktr.ee/joelparkerhenderson/*/.well-known/funding-..."

2. An opportunity for improvement is for the JSON spec to favor each project having all it's own information in the JSON file i.e. orient the file toward the project, rather than toward a specific developer, and definitely not toward the naming convention of "/.well-known" subdirectory (which doesn't exist in many projects and has a history of glitches because it's a hidden dot directory).

IMHO success looks like making the file spec simpler, even it means skipping some of the manifest capabilities.

A triage queue can include how/when to do triage. As a specific example, set 60 minutes each Friday to sift through bug reports together. Small teams with good customers can reply honestly with "Thank you for your bug report. We're tracking it now at $URL. We expect to look at it after we've shipped $FEATURE. If we've misunderstood the urgency or severity please call us directly at $PHONE."

Small teams shouldn't split like this IMHO. It's better/smarter/faster IMHO to do "all hands on deck" to get things done.

For prioritization, use a triage queue because it aims the whole team at the most valuable work. This needs to be the mission-critical MVP & PMF work, rather than what the article describes as "event driven" customer requests i.e. interruptions.

If you like music maps and electronic music, there's a great site IMHO called Ishkur's Guide to Electronic Music at https://music.ishkur.com/

A longtime collaborator emailed me directly to point me to the fake profile. I found the other fake profiles just by fiddling with the last character.

> add assertions to your code.

Yes, and many programming languages have assertions such as "assert greater than or equal to".

For example with Rust and the Assertables crate:

    fn calculate_something() -> f64 {
        let big = get_big_number();
        let small = get_small_number();
        assert_ge!(big, small); // >= or panic with message
        (big - small).sqrt
    }

It turns out it's even better if your code has good error handling, such as a runtime assert macro that can return a result that is NaN (not a number) or a "maybe" result that is either Ok or Err.

For example with Rust and the Assertables crate:

    fn calculate_something() -> Result(f64, String) {
        let big = get_big_number()
        let small = get_small_number()
        assert_ge!(big, small)?; // >= or return Err(message)
        (big - small).sqrt
    }

In addition to the military-programming history of "foo", there's also a military-programming history for the variable naming convention of "alfa", "bravo", "charlie", "delta", etc.

The naming convention is known as the NATO phonetic alphabet: https://en.wikipedia.org/wiki/NATO_phonetic_alphabet

This apology is well done. It's humane, humble, acknowledges specific wrongs that were social failures and technical/legal failures, and explains the fixes going forward.

Whatever you may think of Pear AI, or startups playing too fast and loose, IMHO this apology sounds sincere and worthwhile.

Assertables: Rust macros like `assert!` for smarter testing, easier debugging, and faster refactoring.

https://github.com/sixarm/assertables-rust-crate

Counterpoint: I write open source software that lots of people use, and I receive approximately 95% thank yous, 4% simple requests for help or features, 1% attacks/hacks/complaints.

The secret (IMHO) is keep it simple, so people know what they're getting and can figure out how to be successful.

70M downloads of my oldest project, Ruby unaccent port: https://github.com/sixarm/sixarm_ruby_unaccent

200K downloads of my newest project, Rust testing macros: https://github.com/sixarm/assertables-rust-crate

Open source authors inspire me every day to create, improve, and share. The point isn't money; the point is helping each other learn, explore, and grow.