Caffeinate is burned into my muscle memory at this point. I attribute that to the realization that you could repeat opt flags. There's something catchy about
The biggest weakness in the study is that Taxi and ambulance drivers in the dataset died around 64 to 67, versus 74 for other occupations [0]. If Alzheimer's is much more likely to show up later, then lower Alzheimer's related death rates among Taxi and ambulance drivers may reflect earlier mortality rather than any effect from the job.
If you read it, one of the first things they discuss is methodology for adjusting for age at death as it relates to Alzheimer's mortality, citing exactly this objection. I'm not a statistician and I don't know if their methodology is solid or not, but it's been addressed.
This isn't theoretical. In my 20 years in retail and logistics, I've seen these libraries repeatedly fail in production. Real world examples include:
* Invoices: Totals get pushed to a new page with no repeated <thead> header. This is a classic failure of CSS table rendering across page breaks. properties like page-break-inside: avoid are notoriously inconsistent in browser print to PDF engines. Line items get split mid row because the engine doesn't understand the semantic integrity of the data.
* Bills of Lading & Manifests: These documents are infamous for unpredictable page breaks. One page cuts a row in half, the next duplicates headers, the next drops content entirely. This often stems from complex flexbox or grid layouts that the PDF rendering engine struggles to paginate deterministically.
* Shipping Labels: A barcode or QR code shifting by a few pixels is often a DPI or scaling artifact. The browser rendering at a logical 96 DPI doesn't translate perfectly to a 300 or 600 DPI thermal printer format, introducing rounding errors that are catastrophic for scanners. Addresses drift outside the printable area because CSS margins (margin, padding) can be interpreted differently by the print media engine versus the screen engine.
* Digital Forms: This is a classic failure of absolute vs. relative positioning. When you overlay HTML form fields on a scanned PDF background (a common requirement), the HTML box model's flow layout simply cannot guarantee pixel-perfect alignment with the fixed grid of the underlying image. I've seen teams resort to printing, using white out, and hand filling forms because the software couldn't align (x, y) coordinates.
* Tickets & Passes: Scanner rejection due to incorrect sizing is often due to the browser engine's "print scaling" or "fit-to-page" logic, which can be difficult to disable and varies between environments (e.g., a local Docker container vs. an AWS Lambda function with different system fonts or libraries installed).
This always turns into a long tail of support tickets. The only truly reliable solution is to bypass the HTML/CSS rendering model entirely and build the document on a canvas with an absolute coordinate system. This means using libraries like FPDF (PHP), ReportLab (Python), or lower-level tools like iText/PDFBox (Java), where you aren't "converting" a document, you are drawing it. You place text at (x, y), draw a line from (x1, y1) to (x2, y2), and manage page breaks and object placement explicitly.
It's not cheap. The initial build cost is high because every layout is effectively a small, “programmaticd CAD project”. You can't just "throw HTML at it". But the payoff in reliability is immense. It becomes a set and forget system that produces identical documents every time, which stops the endless firefighting.
Yes, two years later it can be painful to update when the original developer is gone. But I would take that trade off any day over constantly battling with imprecise, non deterministic tools. In twenty years of building systems where documents are mission critical, "close enough" rendering was almost never good enough.
Have you looked at something like Latex or Typst? They come with their own layout engine, so potentially less tedious work like specifying exact positions.
Diátaxis is a great way to structure documentation, but I think its real value is in simplifying how we think about writing docs.
It shifts the focus from trying to cram everything into one ‘perfect document’ to recognizing that different users have different needs.
Like, tutorials are for learning by doing, guides are for solving specific problems, reference is for quick lookups, and explanations dive into the ‘why.’
That clarity alone can make one write useful docs.
That being said, sticking too rigidly to any system can be a trap.
A great companion read is Martin Fowler’s “Accounting Patterns”[1]. Having built and maintained systems that manage financial events for over a decade, I wish I had read these patterns earlier.
I think Fowler's work is an underrated must-read for anyone who works in domains related to moving money. Makes any kind of engineering practices and architecture principles logical and make sense.
Yes, and I was lucky enough to read his stuff on finance within 6 months of starting work! He has some very good design ideas for many things, just as always treat it like things in your toolbox and not dogma.
More like "is it released after all those years". I've been very interested in the concept, but that's the last I've heard from them in the last 3-4 years.
Article | Software Engineer | Vancouver, BC | ONSITE, VISA | C$90 - C$160 | https://www.article.com
Article is on the mission to engineer remarkably better furniture experiences. To accomplish this goal we manage ourselves relationship with the factories and suppliers, ocean shipping, warehousing, customer service, quality assurance, operations, transportation network and final mile delivers.
We are building software systems to make an impact on each and every aspect of above mentioned areas. We are fast growing startup and we were recently named Canada's fast growing startup[0]. Come help us build remarkably better furniture experiences.
We are hiring for following positions:
Software Engineer,
Senior Software Engineer,
Principal Software Engineer
Article | Software Engineer, Product Manager | Vancouver, BC | ONSITE, VISA | C$80 - C$150 | https://www.article.com
Article is on the mission to engineer remarkably better furniture experiences. To accomplish this goal we manage ourselves relationship with the factories and suppliers, ocean shipping, warehousing, customer service, quality assurance, operations, transportation network and final mile delivers.
We are building software systems to make an impact on each and every aspect of above mentioned areas. We are 5 year old startup and we are growing at exponential rate. Come help us build remarkably better furniture experiences.
Article | Software Engineer, Product Manager | Vancouver, BC | ONSITE, VISA | C$90 - C$140 | https://www.article.com
Article is on the mission to engineer remarkably better furniture experiences. To accomplish this goal we are manage our own factories, ocean shipping, warehousing, customer service, quality assurance, operations, transportation network and final mile delivers.
We are building software systems to make an impact on each and every aspect of above mentioned areas. We are 5 year old startup and we are growing at exponential rate. Come help us build remarkably better furniture experiences.
We are hiring for following positions:
Software Engineer
Front End Engineer
Principal Software Engineer
Product Manager
For example:
caffeinate -dimsu
That keeps the Mac awake so I can use Claude remotely from phone.
You can also wrap your command as well, but I rarely use it.
caffeinate -dimsu your-agent-command