Eat, sleep, code, repeat.
Jelgava, Latvija
Joined May 2012
- Tweets 393
- Following 1,471
- Followers 171
- Likes 22,445
aivarsk retweeted
“ If your engineers are trying to get to 4,000 transactions per second, you should be asking them, ‘Very well—how are we going get to a hundred thousand? How are we going to get to a million?’ ”
@jorandirkgreef predicts the future of transaction processing at @money2020 EU'24.
aivarsk retweeted
$5 lunch in Korea.
You can get a 4GB VPS from Hetzner for almost half this price for an entire month.
This: Reasonable performance is not obtained from doing clever optimizations. It's obtained from avoiding work.
I don't think people understand this enough:
Reasonable performance is not obtained from doing clever optimizations.
It's obtained from avoiding work.
When you implement a task using abstractions or building blocks you don't understand, there's a very good chance that these abstractions push tons of work for the computer to do — work that does not need to be done in order to achieve your desired results.
Computers are very fast. Each piece of work can be done very quickly even if done sloppily.
The problems is that latencies add up.
20ms could be considered an acceptable wait time for a certain piece of work.
If you push a hundred such pieces of work on to the CPU, the latencies add up and things end up taking seconds instead of milli-seconds.
In the past, in order to achieve acceptable performance, you had to worry about both: the amount of work you push on to the CPU, and the time it takes to complete each piece of work. But now, you don't have to worry about the time it takes to complete a small piece of work, because usually it's so fast it doesn't matter.
What you still need to worry about is pushing work to the computer that does not contribute to the desired result you wish to be produced.
That usually translates to architecture: how to arrange the appropriate building blocks of the solution so that you are not constantly pushing tons of unnecessary work to the CPU.
If you conceive of programming as just the stitching together of black boxes, and "it doesn't matter how they work", then how can you know whether you're pushing unnecessary work to the CPU or not?
This is why if you follow OOP/CleanCode paradigm, you are almost guaranteed to produce awful results, because they teach you to *not* care about how things work under the cover.
aivarsk retweeted
👤 Aivars Kalvāns
How to solve a Python mystery
Categoría: DevOps, Cloud and Infrastructure
aivarsk retweeted
Unpopular opinion: Software engineering is the only job where the interview is harder than the actual job
Interview: Design a distributed system for 10M users
Job: The login button moved 2 pixels, please fix
Found a weak magnet bug in the badge, patched it and deployed to production. LGTM #bsideskrakow
aivarsk retweeted
⚔️ On this day in 1236, the Baltic tribes stood united at the Battle of Saulė, facing the mighty Crusader knights. They fought not only for their land, but for their freedom, their culture, and their future. And they prevailed.
Today, Lithuanians and Latvians honor that unity.🌿
aivarsk retweeted
One of the coolest tech + data videos I've ever seen. If you like hardware, high performance data and ML check it out :-)
piped.video/watch?v=T8HT_XBG…
aivarsk retweeted
In software, we mostly care about two metrics: whether the code does what we want and whether it does so efficiently. Often, efficiency isn’t critical. Keep building web services in Python—that’s fine.
But when performance matters—and it eventually does—people sometimes assume they’re facing a Pareto distribution: one bottleneck that, if eliminated, will drastically improve performance. This holds true at the micro level, in isolated benchmarks, but not broadly.
Consider shopping for a TV. You first head to the TV section, then narrow it down to the sizes you need. Next, you optimize for price, seeking the cheapest TV that meets your needs.
How do you produce affordable TVs?
As the new CEO of a TV company, you’d first examine major costs. Transportation, perhaps? Some cost components, like taxes or already-cheap boxes, can be ruled out as insignificant.
However, you eventually realize that making affordable TVs requires getting hundreds, if not thousands, of details right.
The same applies to software. High efficiency demands getting hundreds of things right. This is often used as an excuse not to optimize: “Why bother with X? It only helps in specific cases.” That’s fallacious. To win the war, you must win hundreds of battles. Win the battles one by one.
aivarsk retweeted
Netflix Tudum drops CQRS Architecture & eventual consistency and replaces it with strong read-after-write consistency for improved user experiences.
CQRS & NoSQL communities have been pushing eventual consistency too much in the past.
Consistency at scale is easier than ever.
aivarsk retweeted
There’s a whole generation of programmers who have not been taught how to make modular software without using a network stack.
We used to teach modularity and loose coupling between in-memory modules.
SO much faster and without having to adopt network failures.