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.

I just updated my resume for a new round of job hunting, and I think its similar to what you're describing

http://designbymobius.ca/resume

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".

Sqwok looks amazing :)

This is exactly how I write JavaScript.

Sometimes a single operation has multiple ways of failing, each with their own ideal recovery / retry plan.

You want to catch the error, examine context (app state, error type and metadata at crash point) and determine what the best next step is.

This example linked below is from a web crawler service I run.

When an error occurs while logging in (multiple page loads and sometimes a redirect), there is a single handler to determine if retrying the login, crashing or alerting a human is the best course of action.

https://twitter.com/akamaozu/status/1193910918641532934

Ended up with a way to write code that recovers from errors in ways that I might not immediately understand but demonstrably works.

https://twitter.com/akamaozu/status/1274341510419329029

My current data solution is layers of code on top of redis, trying really hard to be everything Rethink was.

Easy access to changelogs should be an "easy to access" feature in all databases. Event driven systems aren't rare: the data store needs to be done to tell interested parties that underlying data has changed.

I was thinking of doing something similar as a lightweight embedded datastore: apply structure to the file system like you would a redis key.

Would love to talk to anyone on the EToys team or anyone who has done something similar.

I'm @akamaozu on twitter.

See: https://stackoverflow.com/questions/8852198/settimeout-if-no...

Was waiting for the first person to point out that what you get when you visit a url is not guaranteed to be the exact same on a subsequent visit.

Not seeing how url-based package management is safer when a package host can use a server that sends a special payload to certain requester ips, headers, cookies or referrer.

Until there are firm guarantees around what you get from a url, a trust-able third party is needed, even if just as an option.

setTimeout is non-standard JavaScript too but I bet your code base has multiple instances of its usage.

Mind explaining how this is a better situation?

Do you feel penalized every time you can't park in a convenient parking spot because it's reserved for people with mobility issues?

If half the houses on a given street have at least one room available to rent at all times, renting a room on that street should be cheaper due to plentiful supply.

Was team screen til this point.

In critical systems, you want to make sure inputs are easy to use in the worst case scenario.

Even the best of touchscreens can't compare to physical controls in tough times.

Hoped to show that JavaScript can be easier to read than you described.

Obviously wrong. My mistake.

Not all JavaScript devs.

Love the language, hate the popularity of anonymous functions and non-descriptive variable names.

My production code as a sample. http://designbymobi.us/wp-content/uploads/2020/02/rabbitmq-c...

I learned this lesson the hard way when I realized my cloud-based database provider won't give me access to change logs.

Ended up building a write queue where updates to be made are put.

Now I have one place that captures all changes, so it doesn't matter if the db has change logs, or if the provider gives me access to it.

I can set up a domain events system even if the backing store is the file system.

Queue changes, publish event after successful change.

Yes but as a security guard, or someone monitoring patient vitals, you want them to actually pay attention to details, not reflexively act from memory

Google helps with discovery of your site on their engine, so now it's your God-given right to get traffic from them because that's how people use the Internet now?

Even sorrier are those who value their time more than it's worth to anyone but themselves.