Brandur

I had read the portion you quoted and found it interesting as well.

I've always been fascinated by long running processes. I'm sure you might have heard about the Clock of the Long Now [1] (Wikipedia article [2] seems more useful than the official website), which is meant to work for 10000 years. It's under construction, but their strategies to handle adversities over a 10000 year period worth looking into.

Related to that, I've read about an attempt by a software engineer presumably named Brandur who, inspired by the aforementioned clock, has attempted to build a software that would send out tweets for the next 10000 years [3]. While I personally feel it probably wouldn't succeed because there's too many things that can go wrong, it was nice to read the considerations that went into the program. Perhaps more than tweeting for the next 10000 years itself, Brandur was really trying to point out that it's difficult to build long lasting software products.

Writing software that endures for a long time without too much additional maintenance is something I'd like to do.

Another long running — though in comparison to the above much smaller — group of equipments are the space probes Voyager 1 (launched in 1977), Voyager 2 (1977) and New Horizons (2006). Unless I'm mistaken they all continue to function in limited ways and continue to send back data to the earth. Isn't it mind-blowing that something that left Earth about 45 years ago still works?! (Or maybe it's not mind…

I love when friends do this. It's hard to keep up with people and what they're up to. Publishing and letting people subscribe to me is a great way to share things. A few examples of some friends who are doing this:

Justin Searls (fairly known in Ruby and Rails community) mostly quit a lot of various social channels though publishes on some of them one direction. He started a podcast that wasn't meant to be guests of some specific topic, it's just him updating you on things. What he's working on, what he's learning, random stories, etc. - https://justin.searls.co/casts/

Brandur who I've worked with at a couple of places (Heroku previously, and now Crunchy Data) who writes great technical pieces that often end up here also has more of a personal newsletter. While there are technical pieces in there at times he'll also talk about personal experiences my favorite one is some of the unique experiences hiking the Pacific Trail (https://brandur.org/nanoglyphs/039-trails).

Last time this discussion came up, someone shared this nice article[0] about all the different ID options. It mentions Stripe IDs, which have pretty prefixes like "prod_foo" and "user_bar". These are great for users of their API (no wondering what an ID refers to) and for internal tooling and debugging, but have to be stored as inefficient varchars, which is not great for indexing and whatnot.

So I spent the weekend creating "UPID"[1], which is like ULID but prefixable! Up to four characters for the prefix, 40 bits of time (256ms precision, but could change in a revision) and still 64 bits of randomness. So you can do pretty Stripe-style IDs without losing the benefits of a neat 128-bit UUID column. Have implemented it for Python, Rust and Postgres, maybe worth a kick around for someone!

[0] https://brandur.org/nanoglyphs/026-ids

[1] https://github.com/carderne/upid

Given the unanimous consensus on HN that Postgres is all you will ever need. I will present 2 resources which I came across recently which changed my perspective on this blind reverence for Postgres for everything.

First is this Oxide and Friends episode [1] where Bryan and gang explains war stories related to operating Postgres during their Joyent days and why they went with Cockroach DB for Oxide.

Second is this amazing blog from brandur which explains several issues with using Postgres as high throughput queue and some mitigations.

Online forums like Hacker news can be a bit echo chamber-y. It is always good to ensure that the people you are taking advice from are solving the same problem as you.

[1] https://oxide-and-friends.transistor.fm/episodes/whither-cockroachdb/
[2] https://brandur.org/postgres-queues

> Oban allows you to insert and process jobs using only your database. You can insert the job to send a confirmation email in the same database transaction where you create the user. If one thing fails, everything is rolled back.

This is such a key feature. Lots of people will tell you that you shouldn't use a relational database as a worker queue, but they inevitably miss out on how important transactions are for this - it's really useful to be able to say "queue this work if the transaction commits, don't queue it if it fails".

Brandur Leach wrote a fantastic piece on this a few years ago: https://brandur.org/job-drain - describing how, even if you have a separate queue system, you should still feed it by logging queue tasks to a temporary database table that can be updated as part of those transactions.

I wrote this one. I've been working with Ruby roughly six years, but didn't understand its memory internals at all beyond the surface level until I started doing the research for this one.

If there's one takeway/point of interest that I'd recommend looking at, it's the novel way that Ruby shares a pointer value between actual pointers to memory and special "immediate" values that simply occupy the pointer value itself [1]. For example, a fixnum (most integers) has its binary value shifted by one bit to the left, and then a "1" flag applied in its rightmost position so that Ruby can recognize it. It doesn't have to go to heap, and the runtime can take advantage of that for faster calculations.

[1] https://brandur.org/ruby-memory#value