Where I live, any rental building from this century will be marketed as luxury. There is in fact absolutely nothing luxury about them. Everything is cheap and crummy, just not too dirty/smelly/with rats (yet). Rents are 5-7k for a 2b and being luxury or having amenities have nothing to do with this. Supply and demand do. There are enough people who make this kind of money and value living in a place that is half-decent + easily commutable to the city more than the 6k.
A senior programmer does not suggest adding more complexity/abstraction layers just to say something. An LLM absolutely does, every single time in my experience.
You might not, but every "senior" programmer I have met on my journey has provided bad answers like the LLMs - and because of them I have an inbuilt verifier that means I check what's being proposed (by "seniors" or LLMs)
If PaaS or some "run container as a service" setup can work for your use case, I'd probably go with that. It takes care of many things K8s does without all the baggage. Also you are not investing into anything that doesn't port easily to K8s in the future.
On the other hand, if you are thinking of using bare VMs, then better go with managed K8s. I think in 2025 it's a draw in terms of initial setup complexity, but managed K8s doesn't require constant babysitting in my experience, unlike VMs, and you are not sinking hours into a bespoke throwaway setup.
This was not my experience. Many of the high paying tech companies were actively hiring senior/staff in London for most of 2022. OK, maybe not Google. This very suddenly changed late in the year.
I had to replace a perfectly good T450s because of terrible performance when using external 4k monitors. I had it for 6 years, upgrading everything I could, and it could probably last for at least another 4 hears if not for the outdated CPU. Replaced with a ryzen elitebook because RAM is expandable to 64Gb, hoping it will last for up to 10 years. The difference in performance is staggering compared to the old core i5, well worth the cost of a base model.
You can solve to arbitrary precision but you can't measure and specify initial conditions to arbitrary precision, making the solution wrong outside of a small time interval.
Definitely not. Mine is 16 and it will start swapping after running KDE, jetbtains, firefox and a couple electron apps for a few hours. It is tolerable, but in a year or two it won't be. Good thing it supports up to 64.
Surprised to see Velleman's book so far down. It taught me that proofs are fun and do not in general require clever tricks. As a bonus, it provided plenty of practice with foundational objects such as sets, relations and functions. All this made me much better at doing mathematics and prepared to texts in real analysis, CS, algebra.
CRDTs are useful to be aware of, but they are not a silver bullet they might appear based on the paper and online sources.
They are conflict-free only because they hide conflicts by forcing a consistent order on concurrent updates. How do they do it? By using logical clocks to version events. A logical clock is not magic. It orders concurrent events arbitrarily. Is this correct? In practice, probably not, meaning that more recent updates can be lost in favor of less recent updates. What does 'recent' mean? For a user it means latest in physical time. Just because the system doesn't know any better than to arbitrarily order a pair of events (that appear concurrent), doesn't mean the user doesn't know which event comes first.
This is why not everything is implemented as a CRDT and conflicts will always exist in use cases where updates must never be lost.
A CRDT is a way to solve multi-leader replication without having the application code resolve conflicts.
This is what is required to build an app where any instance (node) can be offline for an arbitrary amount of time, but still be able to share state with the rest of the nodes when it's reconnected.
To implement this, every application node keeps a vector clock per register (an atomic piece of shared state). The vector clock allows any node the compare its own version of the register with the state received from any other node. Two values of a vector clock can either be causally related (in which case the most recent write wins) or concurrent. However the concurrency is from the system's perspective, but not necessarily from the user's perspective. An extra physical timestamp can be kept at the register level to order concurrent updates in a way consistent with the user's time perception.
Now, having the hybrid clocks in place to version each register on each node, the system must implement a protocol to ship every register update to all nodes (reliable broadcast).
Once all updates are shipped to all nodes, it's guaranteed that all nodes have the same (most recent) state.
(I built an offline-first product and had to roll my own protocol)
I've read the CRDT paper but never implemented it. Question - if you're not using LWW (instead you have concurrent values of a vector clock), this is where you have your CRDT and merge the states coming from every node?
