Programming Leftovers
-
Formalizing Stability and Resilience Properties
Sent to me via mailbag:
Resilience Engineering, to my understanding, refers to building systems that can function in the presence of disruptions. For example, if a backend service gets overloaded, its dependencies can automatically switch to fallback logic to keep serving customers and give the service time to recover.
I’ve not done much work personally with “resilience engineering”. But the idea comes up a lot in formal methods, in the form of resilience properties. These are goals of the systems that we want (and use resilience engineering) to achieve. And I think the details of resilience properties are interesting enough for a deep dive. I’ll use syntax, but it should be applicable to other specification languages, too.
[...]
Finally, resilience. Itâs possible to achieve stability in a closed system, where the only thing that matters is the other components of the system, but in an open system, the outside world has a vote too. The temperature can be thrown out of the right range by a sudden heat wave, or a storm knocks out one of our servers, and so puts us out of control. Often the best we can do is guarantee we can recover from a shock: RESILIENT is the property that we always eventually return to control, or in TLA+ []<>Control.
-
Book review - Practical Design Patterns for Java Developers
The goal of the book wants to break a returning pattern many programmers go through during their careers. When you start using a programming language like Python, JavaScript, or even Java, the platform allows you to create messy code. Itâs only when you learn and understand patterns and debugging, and use a strongly typed language like Java, that you start writing ârealâ code. When someone starts a programming career with Java and has a solid understanding of design patterns, a lot of bad practices can be avoided.
-
Jan Grulich: Explained: QGnomePlatform and Adwaita-qt
-
Compiler optimization and its effect on debugger line information
In my previous article, I described the DWARF information used to map regular and inlined functions between an executable binary and its source code. Functions can be dozens of lines, so you might like to know specifically where the processor is in your source code. The compiler includes information mapping between instructions and specific lines in the source code to provide a precise location. In this article, I describe line mapping information, and some of the issues caused by compiler optimizations.
Start with the same example code from the previous article:
The compiler only includes the line mapping information when the code is compiled with debugging information enabled (the -g option):