- Timely computation of derived values
-
In my penultimate post, I described the use-case of an e-commerce shop.
In general, interactions in such a shop are the following:
- You can browse a catalog of items
- Each item has a price tag
- You can put x items in your cart
It’s when the exciting part starts.
On most pages, you want to give users a condensed view of their cart’s state. Here are a couple of options for the state’s view:
- Empty/non-empty
- Number of cart lines
- Number of items
- Total cost. In demos, it’s as simple as the sum of each cart line which amounts to the item’s price times the quantity; in real life, there will be discounts, get X for Y, etc.
All the above views consist of derived values. The question is now, when would you compute it? There are two general approaches:
- eagerly ,i.e., every time you change the cart (by adding, updating, or removing a cart line)
- or on-demand ,i.e., only when you display the condensed view
- Send this article to your friend who still thinks the cloud is a good idea
-
I feel like most devs have this magical notion in their heads that their project is something like Netflix. It’s wishful thinking, and I get it – you want to be as successful as Netflix. But it makes you make the wrong technical decisions, and all of a sudden they think they need to have distributed servers all over the world because their users will somehow notice a few milliseconds difference in latency when they tap a button.
- Spring Boot vs Quarkus: A Migration Story with Ugly Truths
-
We didn’t realize how much we loved Spring Boot Actuator until it was gone. Health checks, metrics, environment details — all “just worked” in Spring. With Quarkus, we had to piece together multiple extensions and still felt like something was missing.
Spring Security sugar? Rewrite. Kafka integration? Manual elbow grease. Using Quarkus sometimes felt like dating someone who’s fun at parties but forgets your birthday.
- Battle-Tested Lessons from 10 Years in a Single Codebase
-
Lesson should be singular:
I try not to judge design decisions on whether they end up being prescient, but on how easily they can be changed when we learn exactly why they weren’t. Instead of elaborate, future-proofed code, I try to encourage small, simple bits of code that are easy to move around, change, build on, or even delete.
- À quoi ça sert, des certifs en 2025 ?
-
The post does a good job of stating pros and cons of certifications. It’s actually marginally more positive than me.
- You Should Write An Agent
-
I approve this message. Doing something to understand how it works has been my motto for two decades.
- k8s-1m Overview
-
This is an effort to create a fully functional Kubernetes cluster with 1 million active nodes.
The post is very thorough and teaches a lot about Kubernetes; I’ll be honest, I didn’t read everything. I’ll keep it as a great reference, though.
- Optimise for continuous change, not modernisation or legacy
-
TL;DR:
- Legacy systems lack a universal definition and mean different things to engineers (code they didn’t write), architects (non-strategic systems), and executives (products without market fit).
- Most people incorrectly define modernisation as complete rewrites, which historically fail (citing Netscape’s failed browser rewrite that cost them market dominance).
- Organisations should optimise for continuous change rather than debating legacy vs. modernisation, building systems that are inherently adaptable and replaceable.
- Monorepo vs Multi-repo vs Git submodule vs Git Subtree: A Complete Guide for Developers
-
I don’t really think it’s a complete guide, but it’s a good enough introduction, and I learned about Git subtrees.
- Redis Critical Remote Code Execution Vulnerability Discovered After 13 Years
-
It can happen. The "fun" part is the following:
While there is no evidence that the vulnerability was ever exploited, Wiz identified 330K Redis instances exposed to the internet, including over 60K without authentication configured, and 57% of cloud environments installing Redis as container images, many without proper security hardening.
People didn’t learn from MongoDB and ElasticSearch former issues.
- Analyzing 4 million payment card details found on the dark web
-
Database breaches aren’t the only way to get hacked payment card details anymore. Increasingly, the card numbers sold on the dark web are brute forced.
It means that you can keep your CC details safe, they can still be exposed, sold, and used. It makes additional security measures, such as disabling payment in certain countries, or disabling online payments. Check settings in your banking app, and don’t be shy: switch banks if they don’t offer such settings, or reimbursements of fraudulent debits.