akamaozu

I don't agree with their assessment, but also not really interested in putting effort into debunking it.

Just occurred to me there's a different possibility:

The extra connection bug mentioned could be from a rogue thread/process/code-path connecting to the queue and fetching an item, but somehow not doing the work.

Verifying this likely requires access to the codebase, so treat this as little more than idle speculation.

i don't understand what you mean by no real indexes

why does generating indexes at start-up not count as having indexes?

(asking because i do this all the time)

why is this so heavily down-voted?

it feels correct, even though it's not a complete guide

(reliably persisting changes to disk is a big part of what dbs do, but is missing here)

the publication recommends articles to read, but i don't see their algo for how the recommended articles were determined

re: Prefetch and Reconnection Issues

- clear case of misconfigured instance (prefetch) and a bug somewhere in the stack (reconnection issue)

- prefetch behavior sounds like they receive a message, ack it then process it

- i wouldn't recommend ack before processing, because you become responsible for tracking and verifying if the worker ran to completion or not.

- work then ack is the way. the other way around ignores key job processing benefits like rabbitmq automagically requeueing messages when a worker crashes and failure related logic like deadletter queues.

- the trick i've started leaning on with rabbitmq is giving each worker their own instance queue (i call it their mailbox).

- when a worker starts a job, it writes the job id, start time and the worker's mailbox to a db. any system can now look up the "running job" in the database, know how long it has been running and can even talk to the worker using its mailbox to inquire if it is running and if that job state in the db is accurate.

- happy the writer and team found what works for them. ultimately, what you understand best would serve you better, so they made a good choice to lean on their strengths (postgre).

Hard Truth 6 does not rhyme with my experience.

Just got back into the job market, and every potential employer has expressed gratitude for my level of honesty and transparency.

I'm "weaker" at negotiations since I've laid out my cards on the table upfront. The other side of the coin is companies are less likely to waste my time unnecessarily, or play hardball too much when you appear to roll over so easily.

My take on Hard Truth 6 is to be careful and strategic with your honesty. It may not always be interpreted the way you intended, so be honest but be wise about what you're disclosing.

You're a better person than myself. Would have suggested the Saudis are behind the downvotes.

Company in question is Google, not Amazon.

You would prefer to never get a thing for free rather than have it at no cost for a brief period in time?

An even simpler alternative is to not accept an offer you aren't comfortable with.

Two wrongs don't make a right.

This quote in the conclusion caught me off-guard:

> Crypto messaging does not appear to be directed at the rational or sensible.

Was really into slowly.app for a while, and pleasantly surprised to see it suggested here.

I would recommend it to anyone looking to experiment with a "high latency social network".