jhealy

Reminds me of this blog post I read yesterday, about Buildkite introducing jitter in their CI agent to reduce synchronisation

https://buildkite.engineering/sleeping-at-scale/

> No one is ever going back and reading individual commits

I do, regularly! In a repository where care has been taken, it can be super valuable when tracking down a bug or regression, and understanding the intent of the author

The article is wrong, the PDF spec has introduced breaking changes plenty of times. It’s done slowly and conservatively though, particularly now that the format is an ISO spec.

The PDF format is versioned, and in the past new versions have introduced things like new types of encryption. It’s quite probable that a v1.7 compliant PDF won’t open on a reader app written when v1.3 was the latest standard.

Viewable without logging in to x though, and shareable on fediverse

Via fediverse, for those not on x: https://bird.makeup/users/penpizzareport/statuses/2007347706...

interesting idea, good on them for trying something different in the Ruby ecosystem.

The website is quite extensive, but the gem only has ~1.5k downloads. It’s presumably very early on the adoption curve

At a previous employer we did this with our docs repo.

The public docs site was managed and deployed via a private GitHub repository, and we had a public GitHub repo that mirrored it.

The link between them was an action on the private repo that pushed each new man commit to the mirror. Customer PRs on the public mirror would be merged into the private repo, auto synced to the mirror, and GH would mark the public PR as merged when it noticed the PR commits were all on main.

It was a bit of a headache, but worked well enough once stag involved in docs built up some workflow conventions. The driver for the setup was the docs writers want the option to develop pre-release docs discretely, but customer contributions were also valued.

Since 2024 you can disable the root credentials on all accounts except the Organization management account: https://aws.amazon.com/blogs/aws/centrally-managing-root-acc...

I don't think the post mortem details whether the root access was on the org management account or an org member account.

Not really a new vulnerability, and yet Notion just shipped it this week. All caution thrown to the wind in the name of an announce-able AI feature

See also: https://andre.arko.net/2025/09/19/goodbye-rubygems/

I live in Melbourne (on Jemena’s distribution network) and this isn’t my experience.

Our power is very reliable and rarely goes out. Every few years a car hits a pole or something and we get a brief period of quiet time

Related content: Corey Quinn on the AWS GenAI obsession

https://www.lastweekinaws.com/blog/amazon-genai-services/

If you’re still looking for an alternative, https://dnsimple.com is an excellent engineer focused no bullshit domain registrar and they support .co.za

Implicit or explicit, I’m OK with the global namespace.

On paper it’s awkward, but in reality convention and social norms make it rarely an issue.

The global namespace only supporting exactly one version of each gem encourages a health culture of stable ABIs and deprecation periods too. An absolute dream compared to some language ecosystems

I've never used aurora serverless v1, so I'd somehow never heard of the RDS data API before this.

It seems like it'd be useful in some cases, particularly because connection pooling to postgres is managed for you.

Is anyone using it production workloads? How have you found it?

Bummer that it can only query the writer and not readers.

They were.

https://aws.amazon.com/about-aws/whats-new/2023/12/amazon-au...

I'm not the author but I work at the same company.

None of our systems require perfect ordering of IDs generated across our distributed system. Most of the system was built with random UUIDv4 identifiers so no code assumes the ID ordering is significant.

However, in much of our system recent data is frequently accessed while old data is rarely accessed. In that world, just having the IDs *approximately* clustered in creation order has been a huge performance boost for many queries, and we've seen significant reduction in postgres Write Ahead Log rates, because writes to UID indexes happen in a smaller number of pages.

I'm not the author, but I work at the same company. ULIDs are nice, but we're a 10 year old company with many TBs of data across multiple logical databases and most rows had UUIDv4 ids.

Maybe if we were starting from scratch ULIDs would have been an option, but given where we were UUIDv7 was a much easier transition.