In the seminal book Accelerate, Forsgren and her co-authors provide empirical evidence that Continuous Delivery has a positive impact on the performance of software development organisations. If organisations neglect some of the principles and practices of Continuous Delivery, their performance will suffer. They will reach the point where simple changes will take ages to implement. Not so with Continuous Delivery.Read More »The Key Principles of Continuous Delivery
After having built the reference Linux image from a SoM, SoC or terminal maker and having run it on the board, we must inevitably custom-tailor this image to our needs. We must create our own Yocto layer. We must remove all the unnecessary packages and make our core application start automatically on power-up. Here is a step-by-step guide how to turn the application layer for a Toradex Verdin iMX8M Plus board into our own custom layer. The guide should also work for other boards.Read More »Creating A Custom Yocto Layer
In the post Setting Up Yocto Projects with kas, we built the Linux image for the Toradex Verdin iMX8M Plus. It’s time to flash the image on the board using the Toradex Easy Installer (TEZI). It’s a three-step procedure: wire up the board in a special way, install and run TEZI on the board, and flash our custom-built Linux image from a USB drive on the board.Read More »Installing Linux Images on Toradex Verdin Boards
The parking experience at Munich Airport is awful. It is too easy to do something wrong, which can only be remedied by calling support. The bad user experience is caused by a bad system architecture. The pieces for a better architecture are already in place. Improving the interaction between these pieces improves the architecture and a fortiori the user experience. I can at least dream of a better parking experience in the future, although I can’t change the current one.Read More »Parking at Munich Airport: An Awful Experience
Not right away! Trunk-Based Development requires that the software builds and passes enough tests, before we integrate our changes into the main branch (a.k.a., trunk). We have enough tests, if breaking the software is highly unlikely. By definition, legacy code has no or not enough tests. Hence, we cannot apply trunk-based development right way, but should evolve our development process towards it.Read More »Can We Use Trunk-Based Development for Legacy Software?
We start with unit tests reading a file line by line with
QFile. Unit tests accessing the file system are not considered unit tests, as they may be slow and may depend on each other in surprising ways (see A Set of Unit Testing Rules by Michael Feathers). In a first step, we encapsulate
QFile in a class
TextFile and provide a fake implementation representing the file as a list of strings kept in main memory. In a second step, we introduce an interface, from which the product and fake implementations derive. We can now apply TDD to classes accessing files.
Signals and slots are my favourite Qt feature, as they make loose coupling between components or between layers super easy. I miss them most when I must write pure C++ code without the Qt goodies. I invite you to follow along while I translate signals and slots into function-object member variables and lambda functions, respectively.Read More »Implementing Qt Signals and Slots in Pure C++
A client recently asked me to help them get a legacy HAL driver under test. They want to use TDD to maintain and extend the driver. We ran into a couple of problems, because the tests run on a 64-bit computer, whereas the production code runs on a 32-bit microcontroller. I’ll explain the problems and how to solve them.Read More »Applying TDD to HAL Drivers with Memory-Mapped I/O
I never got the hang of UML: overly complicated, hard to understand, too close to code. Hence, I was skeptical about C4 diagrams when I… Read More »Visualising the Architecture of Qt Embedded Systems: Context and Container Diagrams