Digests » 398
Vettery specializes in developer roles and is completely free for job seekers. Interested? Here’s how it works: create a profile, name your salary, and connect with hiring managers at startups to Fortune 500 companies that are growing their dev teams. Get started today!
this week's favorite
I've been noticing that while there's a lot of appreciation for backend and distributed systems challenges, there's a lot less empathy for why mobile development is hard when done at scale. Building a backend system that serves millions of parallel customers means building highly available and scalable systems and operating these reliably. But what about the mobile clients for the same systems?
This is intended to be a casual introduction to the perils of lock-free programming (which I last wrote about some fifteen years ago), but also some explanation of why ARM’s weak memory model breaks some code, and why that code was probably broken already.
Complexity in software, whether it’s a programming languages, an API, or a user interface, is generally regarded as a vice. And yet complexity is exceptionally common, even though no one ever sets out to build something complex. For people interested in building easy to use software, understanding the causes of complexity is critical. Fortunately, I believe there is a straightforward explanation.
This is the last article in a series covering all the various aspects of creating forms for the web. Each article can be read independently, but I wrote them in the order that makes the most sense. If you have not read the others, I would encourage you to take a look.
Here's the situation: it's 1984, and you're assigned to write the spellchecker for a new MS-DOS word processor. Some users, but not many, will have 640K of memory in their PCs. You need to support systems with as little as 256K. That's a quarter megabyte to contain the word processor, the document being edited, and the memory needed by the operating system. Oh, and the spellchecker.