code-e

What's the difference between keeping a passkey in bitwarden, and just using a password, also in bitwarden?

Is there some general purpose (linux) software that could apply these kind of post-processing effects to my any terminal? Or failing that, my whole screen?

It does affect storage and sorting. A native UUID type uses 16 bytes. The alternative is text encoding (32 bytes for hex), or maybe a raw BYTEA. Postgres also has SortSupport for the UUID type, which basically means if the first 8 bytes only has one matching row, then the remaining 8 bytes can be skipped. Combine that with a ULID where the most first half is basically a timestamp, you'll get performance close to using a single 8byte BIGSERIAL.

You can also write a plpgsql function to generate these ULIDs in the database.

As the maintainer of a rabbitmq client library (not the golang one mentioned in the article) the bit about dealing with reconnections really range true. Something about the AMQP protocol seems to make library authors just... avoid dealing with it, forcing the work onto users, or wrapper libraries. It's a real frustration across languages, golang, python, JS, etc. Retry/reconnect is built in to HTTP libraries, and database drivers. Why don't more authors consider this a core component of a RabbitMQ client?

I think you're confusing your application with the language itself.

Adding new syntax and functions to the language is not a breaking change. Old code will continue to work.

If you start using these new features in your application, and it no longer works on old browsers, then sure that's a breaking change. But that's a choice for you to make. The language is still backwards compatible.

RabbitMQ is a popular message broker, i.e. a pub-sub server. I started this project because I was frustrated by the current leading RabbitMQ library for nodejs, amqplib, and everything that tries to build on top of it. Typescript support is poor, connections are not retried, queues/exchanges/bindings are not automatically created, and error handling is inconsistent. The growth of my node_modules directory was also alarming when using the various wrapper libraries, but that's more of a cultural problem with node.

My goals for this project include: Avoid external runtime dependencies. Include fantastic documentation, not only as a separate page, but in the code. Expose a basic API that is at least as fast as amqplib. Build on the basic API to abstract away all the messy re-connection stuff, so I can just have robust publishers and consumers.

Anyway I'm happy enough with the result that I feel I can show it off now.

Support for rolling upgrades (one node at a time) instead of a full-stop upgrade was added in rabbitmq 3.8, about six months before this article was published. So while a full-stop is no longer necessary, it was likely a restriction for the majority of the time the author was using rabbit.

Sounds like the same thing to me, unless you're wealthy. The no-fly list seems a little less discriminatory in that regard.

Poe's Law strikes again

Are you talking about native modules that need to be rebuilt when the V8 version used by node is also upgraded?

I love my ebike. I can get to work relatively quickly with full assist and then pedal on the way home (with some help on the hills) to get my cardio exercise out of the way by the time I get home. I'm no longer stressed out by traffic during the week, either.

I highly recommend it to anyone who lives close enough and can find a safe route.

But the linked bluebird docs says:

  As an optimization, the cancellation signal propagates 
  upwards the promise chain so that an ongoing operation e.g. 
  network request can be aborted.