I found this quote from the paper by Catchpole et al. quite important:
"Whilst it is encouraging that analogies from other industries with longstanding cultures of safety and reliability may be extrapolated, it is also important to recognize the unique demands of health care. One crucial difference that emerged was that Formula 1 and aviation both have a relatively stable workforce, with minimal staff turnover. For example, out of about 20 members of a pit team, only one or two members change annually. In contrast, turnover of staff in health care is far higher, with six residents rotating every 3 months in the study unit, and a nurse turnover of approximately 10%."
Turnover could also be seen as an addressable problem. "People are dying because of poor staff retention and rotation practices" this could be studied and improved upon.
A novel mechanism would be for a patient suing a hospital for malpractice for failing to retain nursing staff which it seems could be proven to be linked to worse outcomes. And when it comes to it, liability lawsuits are an adequate last resort to push back against hospitals cutting corners with staffing levels and staff pay when it comes to nurses.
FWIW, the Haribo charger seems to be rather well made: https://www.youtube.com/watch?v=xT_t5nvFcoY (26:50, by ZeroBrain, a German YouTuber that disassembles electronic devices)
The Whisperfish [1] project (a Signal messenger for Sailfish OS) maintains an independent Signal client library written in Rust [2]. It works quite well - unless Signal decides to change their protocols or kick non-standard clients.
hiq's comment was not about Whisperfish but about the presage library.
My comment can be read as "Whisperfish wrote their own implementation of the signal protocol" - which is wrong. (Sorry, can't edit it anymore)
With presage, Whisperfish has a high-level Rust library that wraps the official libsignal libraries (which are also written in Rust) and makes it much easier to write clients. The official Signal repo only contains Java/Typescript/Swift wrappers. As presage is rather obscure, I thought that some HN readers might appreciate the link.
Thanks HN! I regularly open HN during lectures. There is no better way to show my students what software engineering entails and why I focus on certain topics.
Is SCRUM really as great as its evangelists claim? Let's read HN comments.
What are good use cases for UML? Let's check out HN.
Does anyone actually care about CoCoMo or CMMI? Let's read ... oh - nearly nobody's talking about it there. Maybe it won't be that relevant to the students.
- In a nutshell: everyone should know about UML and how some relevant diagram types look. Nobody should use it religiously.
- Diagrams are great tools for communicating ideas and implementations on an abstract level, and for interactively thinking about ideas that can be drawn in some way. A diagram can also visually highlight problem areas (e.g., components with many dependencies).
- Good use cases for diagrams in SE are e.g., explaining high-level architecture to someone, thinking about and refining database schemas, documenting interaction flows, or giving an overview of class structure in automatically generated code documentation
- It is nice to have visual consistency - it makes parsing a diagram so much faster and less error-prone. UML provides sensible guidelines or inspiration on how to draw e.g., a sequence diagram or a class diagram. There is no need to re-invent the wheel.
- In most cases, knowing about the diagram types and their approximate design is enough. As probably very few people know what the different styles of arrows or boxes might mean, it is a good idea to annotate important elements with their meaning.
- For thinking/communication, drawing diagrams by hand is the best way. Excalidraw/tldraw are nice for stuff that should go into static documents.
- Documenting the state of a system with manually generated diagrams is tedious and requires constant updates. A better way is to auto-generate e.g., class diagrams using PlantUML or Mermaid.
- Nobody uses UML for designing complex systems and then auto-generating code.
The startup I work for is pretty flat. There's the chief product officer who is actually pretty technical, the chief technical officer, and engineers basically.
We use UMLs and flow charts in miro to diagram things from both a high level (for product to understand) to intricate details.
(but seriously, I'm interested it's just everything I've seen before had the strong scent of "we're doing this nonsense because we believe we're supposed to but don't understand why")
It's useful to have a common language for diagrams (actors, storage, etc)
It's not useful for more than very abstract concepts though. If you're UMLing your entire Java app before you add another class/method/function, you're doing it wrong.
Yeah we don't go that overkill, we really just diagram surface area (how does the backend communicate with the frontend and through which apis and when, and when should the front end expect a socket message, etc)
As a method of communication between projects, it works wonderfully
Fortunately I've never worked for an org that did "stuff" for the sake of doing stuff, or at least I never lasted long with those orgs. In order to be lean and efficient we need to cut out all the stuff that doesn't serve the purpose of building product.
I've personally found sequence diagrams to be immensely valuable the handful of times I've worked with them. Both for documenting the intended way to use an API and for analyzing the ways the different components of a system can interact. This has often helped me escape my tendency to focus on the happy path when analyzing systems.
Having architecture diagrams is not fundamentally a bad thing, and standardizing the conventions for them is not fundamentally a bad thing. I think the thing that gave UML a terribly bad name was the cavalcade of early "zero code" or "low code" tools trying to turn your UML diagram into code; those were terrible.
Drawing things on whiteboards to see the architecture, absolutely.
The more formalism it has and the more it was insisted on was always a strong signal that was was happening was a middle management cargo cult and not actually useful work.
I believe that there exist organizations that derived value from this sort of thing, I just haven't seen them.
Dito. I 'grew up' with Bash in the early 2000s and never knew about the globstar. I an pretty sure that I never encountered it in any scripts or tutorials - otherwise I'd certainly have looked it up.
Given the code has been completely vibe-coded, what does this mean in practice?:
> Copyright (c) 2025
Whose copyright? IIRC, it is consensus that AI cannot create copyrightable works. If the author does not own the copyright, can they add a legally binding license? If not, does this have any legal meaning?:
> IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
Hypothetically, some people who own such an idiotic device might have pets that bring in lots of dirt from the fields, lose lots of hair, and get a little bit agitated by the normal vacuum cleaner but more or less ignore the robot vacuum.
Cats aren't that bothered by vacuum cleaners unless you come at them with it and they normally just run into another room. Never seen a dog that bothered by them.
The point being made is that some people like to make much a do about nothing. Just put the dog or cat temporarily in the other room, outside and the problem is solved.
I can confirm this. We have been using it for 10 years now in our research lab. No data loss so far. Performance is great. Integration with OnlyOffice works quite well (there were sync problems a few years ago - I think upgrading OnlyOffice solved this issue).
The original paper by Catchpole et al. (2006): https://onlinelibrary.wiley.com/doi/10.1111/j.1460-9592.2006...
A quite interesting lecture on the whole project, given by Elliott in a racecar driver's suit: https://www.youtube.com/watch?v=ZeMGrHcfRjY
Annotated transcript of the talk available here: https://www.gresham.ac.uk/watch-now/formula-1-and-its-contri...
A WSJ article from 2006: A Hospital Races To Learn Lessons Of Ferrari Pit Stop: http://www.wsj.com/articles/SB116346916169622261 (archived copy: https://archive.is/xEbio)
Times article from 2024: The surgeon who used F1 pitstop techniques to save lives of babies: https://www.thetimes.com/sport/formula-one/article/professor... (archived copy: https://archive.is/1iGXK)
reply