https://github.com/architecture-decision-record/architecture...
5,995 karma · joined June 2, 2010
## Email ##
joel@joelparkerhenderson.com
joel.henderson@wales.nhs.uk
## Contacts ##
https://linkedin.com/in/joelparkerhenderson
https://github.com/joelparkerhenderson
https://gitlab.com/joelparkerhenderson
https://codeberg.org/joelparkerhenderson
https://facebook.com/joelparkerhenderson
https://instagram.com/joelparkerhenderson
https://orcid.org/0009-0000-4681-282X
## Open source ##
Architecture Decision Record = https://github.com/architecture-decision-record
GitAlias for git version control = http://gitalias.com
NumCommand for statistics = http://numcommand.com
UpdateCommand for system updates = http://updatecommand.com
ZidPlan for secure random data = http://zidplan.com
## Interests ###
Business e.g. tech strategy, tech tactics, tech startups.
Coding e.g. Rust, Elixir, Ruby, Python, JavaScript, Shell.
Development e.g. Agile, TDD, BDD, XP, SQA, DevOps.
## Projects ###
Software Engineering: Guide + Metrics + Code
- https://software-engineering-guide.github.io
- https://software-engineering-metrics.github.com
- https://crates.io/crates/software-engineering
Public Value: Guide + Metrics + Code
- https://public-value-guide.github.io
- https://public-value-metrics.github.com
- https://crates.io/crates/public-value
Digital Health: Guide + Metrics + Code
- https://digital-health-guide.github.io
- https://digital-health-metrics.github.io
- https://crates.io/crates/digital-health
Health Economics: Guide + Metrics + Code
- https://health-economics-guide.github.io
- https://health-economics-metrics.github.io
- https://crates.io/crates/health-economics
## Medical projects using Rust ##
Fast Healthcare Interoperability Resources (FHIR) = https://fhir-rust.github.io
Open Electronic Patient Record (openEHR) = https://openehr-rust.github.io
Systematised Nomenclature of Medicine (SNOMED) using Rust = https://snomed-rust.github.com
HL7 messages = https://hl7-rust.github.io
ER7 messages = https://er7-rust.github.io
Schematron = https://schematron-rust.github.com
https://github.com/architecture-decision-record/architecture...
Coordinated vulnerability disclosure is especially relevant right now because of the PHP disclosure affecting so many people.
Constructive feedback welcome. Free open source. Written by me by hand. Translated into many languages by Sonnet.
On my wishlist is batteries-included command-line setup support for database access using Diesel instead of SeaORM because I like formal types, and security tokens using PASETO instead of JWT because I like specific algorithms.
The prompt I used was "Goal: rework to reduce the attack surface. Process: move features into feature-flag Rust crates. Output: build a minimal version. Questions: Ask me anything."
This past weekend, Claude Fable/Opus/Sonnet together successfully refactored the whole Vix IDE codebase into many separate Rust crates and Cargo features.
This refactor enables a security-oriented user to pick and choose, and also makes it easier for a security auditor to look at one capability at a time.
If you're curious you can see the commit messages by Claude Sonnet. IMHO they're reasonably good.
sv@next migrate sveltekit-3
I'm upgrading hundreds of projects right now and it's going great so far. Here's the shell script I'm using; adjust as you like. find ~/git -path '*/.*' -prune \
-o -path '\*/node_modules' -prune \
-o -type f -name 'svelte.config.js' -exec dirname {} \; |
while read -r x; do
cd "$x"
echo "y" |
pnpx sv@next migrate sveltekit-3 \
--tasks all \
--confirm \
--install pnpm < /dev/null
doneEMPHASIZE:
- *Summary.* First paragraph like newspaper (who, what, where, when, how, why).
- *Benefits.* Focus on the benefits for the reader.
- *Why this matters* Focus on what it adds to the reader.
NO:
- *No tech stack.* Do not say the tech implementation; covered elsewhere.
- *No counts.* Do not say page counts, part counts, chapter counts, etc.
- *No special formatting.* Do not bold, not italic, not bullet lists.
- *No "if".* Do not say "If you do X then Y"; instead use positive.
- *No run-on sentences.* Do not use many clauses nor too many words.
- *No passive voice.* Do not use passive, or non-subject, sentences.
If you haven't tried jj yet, take it for a spin and see how you like it.
My wishlist: free for open source and paid for closed source, able to do simple projects that are handwritten and also complex projects including AI LLM code that needs CI/CD/auditing, and hosting in the UK or EU.
Aside, I donate money to Codeberg because I think Codeberg is a wonderful service with strong commitment to free open source, and because I host some larger projects and AI projects that are for public welfare social good.
Self-promo links below if you would like to star a few of mine good for developers.
https://gitlab.com/architecture-decision-record
For example: The standard FHIR $export operation can support extensions that take de-identification config details as additional parameters. The standard openEHR can query then return non-id fields. The standard SNOMED codes can be rolled up e.g. high-specificity codes can be aggregated into a low-specificity code.
But: for compliance/legal/auditing reasons, all organizations that I know of personally do not rely exclusively on these protocols for de-identification. Instead, the organizations place their de-indentification processes in a kind of "clean room" that does many more kinds of cleansing, redacting, aggregating, chaffing, filtering, and the like.
Fast Healthcare Interoperability Resources (FHIR) using Rust:
https://github.com/fhir-rust/fhir-rust
Open Electronic Patient Record (openEHR) using Rust:
https://github.com/openehr-rust/openehr-rust
Systematised Nomenclature of Medicine (SNOMED) using Rust:
https://github.com/snomed-rust/snomed-rust
I have work in progress creating stores for PostgreSQL, SQLite, MySQL, MariaDB, MSSQL, Oracle.
- Project portfolio management software. Good results so far. This is unguided experimentation: Fable researches feature ideas and plans them, then Opus 5 implements them, without me in the loop. The features include things such as an auth server, full-text search, audit logging, resource leveling, HA/DR, IaC, and more.
- FHIR & SNOMED medical software experimentation in demo-only environments. This has mixed results so far. This is guided experimentation: the FHIR specifications and SNOMED specifications are thorough and I'm in the loop. Fable plans OK, but Opus 5 is thrashing a lot, going down many rabbit holes.
This sounds like a back door. Is it?
To me, the whole article feels super-unclear about what exactly is involved.
Can HN folks who know more weigh in?
I understand the point of that for unknown accounts; perhaps you could consider faster FTUX by leveraging my other existing social accounts? E.g. GitHub, GitLab, Codeberg, LinkedIn, Reddit, etc. And/or enable me to browse public accounts or example content in the meantime?
If anyone from OpenUI would like to connect with me to add Lily, please do, joel@joelparkerhenderson.com.
A gate is best when it's proportional to what goes through it. Small project? The business case is "Pam thinks it's could be a good idea". Large project? The business case is a formal study. The word "proportional" makes it much easier for all the participants to understand that the gate is a sliding scale.
Even more important: stop using personas, start using actual people. I've experienced many startups make unforced errors by conflating people into personas. A better way is to tag people with attributes, such as specific interests, explicit concerns, tasks to be done, usage goals, learning preferences, and the like.
When you switch from personas to actual people, it opens up many more product experiments-- many of which are surprising and may even feel counter-intuitive to founders. Increase your startup chances of success by carefully connecting with your actual users.
Also shoutout to ratatui because even though it's technically a TUI not GUI, it's superb.
Setup is simply 3 steps:
1. Sign up on each service, ideally with the same username.
2. For each repo you want to share, create the same repo name as a blank repo; do not automatically create a README.
3. Edit your local file .git/config to add push URLs, then push as usual.
Example:
[remote "origin"]
url = git@github.com:foo/bar.git
pushurl = git@codeberg.org:foo/bar.git
pushurl = git@github.com:foo/bar.git
pushurl = git@gitlab.com:foo/bar.git
fetch = +refs/heads/*:refs/remotes/origin/*The Rust crate: https://crates.io/crates/assertables
All the macros have forms for different outcomes:
assert_gt!(1, 2) // panic
assert_gt_as_result!(1, 2) return Result (Ok or Error)
debug_assert_gt!(a, b) // panic when running in debug mode
If anyone here wants to help me port it to Zig, I'm happy to do it.