hcarvalhoalves

Yes, it happens. A way to deal with it is carrying some counter on the message metadata and incrementing it every time a consumer passes it along, so you can detect recursions. Another is having messages carry a unique id, and consumers record already seen messages.

I don't see how using pub-sub or not changes how you model the data. It should be orthogonal. Do you have a good example?

Here's how you can do this. You have 3 accounts: A, B and in-flight.

1. Debit A, Credit in-flight.

2. Credit B, Debit in-flight.

If 1. fails, nothing happened and everything is consistent.

If 2. fails, you know (because you have money left on in-flight), and you can retry later, or refund A.

This way at no point your total balance decreases, so everything is always consistent.

The situation of messages vs events is analogous to append-only database vs update-in-place database. You get exposed to the same issues at scale if you rely on the later.

Being notified only _when_ something happened isn't always useful the world is changing underneath you (it _can be_ useful in particular situations, when you know state is final, but not as a general architecture principle).

The "produce a trigger event then have the consumer reach back to the producer and fetch data" can be an anti-pattern. You expose yourself to all kinds of race conditions and cache incoherency, then you start trying to fix with cache invalidation or pinning readers, and the result is you can't scale readers well.

If you're a using a message queue, the message should convey necessary information such that, if all messages were replayed, the consumer would reach the same state. Anything other than that, you'll be in a world of pain at scale.

Last year I bought an M1 Pro used, but the last MPB I had was an early 2015. I just didn't bothered upgrading, in fact the later Intel models were markedly worse (keyboard, battery life, quality control). The Apple Silicon era is going to be the PowerPC prime over again.

Great timing. I _almost_ bought a perpetual license last week. Now I know I'll wait.

I bought their previous software "RAW Power", because it was a one-time perpetual license. Then they rewrote the app (it's worse now BTW), rebranded as Nitro, and stopped updating the previous one to be able to charge again.

The Pixelmator team did the same thing with "Pixelmator Classic".

In real life you both can't afford having reputation risk and you need to ship anyway. If you have an incident, guess who's going to be liable – the manager or the name on the commit?

Stop negotiating quality; negotiate scope and set a realistic time. Shipping a lot of crap faster is actually slower. 99% of the companies out there can't focus on doing _one_ thing _well_, that's how you beat the odds.

Can you share the instructions on how to do that?

I feel Tesla is a US bubble. Despite all the disproportionate media this brand and it’s CEO gets, in my country I haven’t even seen one in the street yet, but I see EV Volvo, Renault, Fiat, BYD, GWM and others daily.

Every other movie coming out of Hollywood features the army, guns or military equipment in some fashion. Cinema is a PR channel for this industry.

The Pentax followed the distance of the M42, which was pretty much an open standard by then, and many manufacturers at the time released lenses in K bayonet. The other camera makers diverged from the standard.

> An organization can offer the following benefits to employees: Comp(salary, bonus, etc), health Benefits(health, insurance, counselling), autonomy, interesting/challenging work, push you out of your comfort zone, a non-toxic environment, etc.

A non-toxic work environment isn’t a “benefit”, it’s a basic requirement. Same for autonomy. Healthcare is just compensation.

In the end, compensation is what matters.

Debatable. Here's a counter-point:

https://www.youtube.com/watch?v=aSEQfqNYNAc

But ok, it's less bad in Python since objects are dicts anyway and you don't need getters.

See these demos for the kinds of interactive systems LISP enabled back in the day:

https://www.youtube.com/watch?v=o4-YnLpLgtk

https://www.youtube.com/watch?v=gV5obrYaogU

It makes working on VSCode today look like banging rocks together, let alone 30 years ago.

This rhetoric is outdated by more than 200 years, when kids worked at coal mines in 18th century Britain.

> Imagine if corrupt governments could no longer shut down the internet and cell service. Even a world war probably wouldn't disrupt this.

That’s quite naive, to believe a private company is not under political influence.

https://ofac.treasury.gov/sanctions-programs-and-country-inf...

Art and entertainment are different things.

The global IT infrastructure is expected to use 1/5 of the world's energy budget in 2025 by some estimates. The AI hype has the potential to push this even further in the next years. Considering we're in the middle of a climate crisis and racing to shift the energy matrix to renewables, having IT be a main responsible in increasing demand is absurd, we should be dramatically _decreasing_ energy demand.

You definitely can, but the ergonomics of doing that on top of tables vs. on top of a triple-store data model are very different.

Is not UI programming, it’s designing UIs on top of HTML and CSS. There’s way too many degrees of freedom, while basic things like forms should work well by default.

Here’s one using Emacs’ Org mode:

https://github.com/hcarvalhoalves/org-mode-site-template

The nuance in this argument is that everybody shares risk.

Workers take risk not only of the financial kind (choosing to take a job at company A instead of B is a bet), as well as physical risk most times.

If we believe shareholder of a oil company is taking more risk than the worker in a platform, we value capital more than labour.

Last time I witnessed a meteor shower (I guess it was early 2000s or late 90s in Brazil), I swear I could hear it, but it was so faint that wasn't sure if I was imagining the sound.

BTW, I was watching the meteors from the attic, where my dad had a music studio, so lots of transducers around. The radio waves theory from the article would make sense.

Despite all other factors involved in the accident, it seems fundamentally hard to make this kind of control obvious with a touch screen. With a physical throttle control, like used in aviation [1], it's more obvious when you're pushing one side or both, as you have both vision and tactile senses to confirm position.

[1] https://tse2.mm.bing.net/th?id=OIP.y8DdQsqhqkM_iA1f8k-qcAHaE...

Magnesium Chelate, is the most bio available.

Exactly. My point is: a small team can have huge impact writing software. The biggest public company right now could be investing a rounding error on software, but chose not to.

> Sort of, but... not really? In my experience, more resources means more polish and more scale. It's the usual 80/20 problem: with a small team you can get to 80%, but the last 20% bogs you down forever. Certainly large teams come with their own problems, but that last 20% is hard.

Consider this: AAPL is valued at 3.4 trillion USD. Both the polish and breadth of their software took a nose dive compared to early 2000s. There’s no more Aperture, Logic, Final Cut, Shake…

Unfortunately these practices are biased to the English language, as slugs are limited to ASCII.