… is consultant for continuous quality control at CQSE GmbH. He studied computer science and obtained a Master of Science degree at the Technische Universität München.
Over the last few years, Docker has largely been adopted to ease the deployment of applications. One of the key benefits is bundling all required dependencies of an application in a single image that can be used right away without a huge installation and configuration overhead. Hence, we are using Docker for running our own Teamscale instances, as well as for Teamscale instances at the customer site.
Docker containers are also neat when testing and reviewing new features before they are merged back into master. Especially on a local developer machine it is beneficial that the Docker image is small, because you don’t want to waste your SSD space with gigabytes of Docker image data.
Over the last years the Teamscale Docker image became quite large, recently hitting the 1GB mark. This prompted me to inspect the image, in order to find a way to reduce its size. After some (surprisingly) minor adjustments, the size of the resulting image was more than cut in half.
After several technical blog posts I think it’s time for something different: I really enjoyed yesterday’s work day—Why? Because of the freedom I have to manage and arrange my work time at CQSE as I like. I’ll briefly recap the whole work day in this blog post, explaining to you what this exactly means.
In my last blog post I outlined the obstacles we had to master when moving from Subversion to Git. Since then more than one year has passed and several of the assumptions we have once made no longer hold. This post describes what changes we had to make in our development process and build & deployment infrastructure due to migrating to Git and which improvements we gained.
2016 marks the year we switched our development repositories from Subversion to Git. As I was responsible for large parts of this migration, I want to share some technical aspects of this journey with focus on the biggest obstacles we had to master: Combining multiple Subversion repositories into one Git repository, shrinking the repository size, dealing with Subversion externals and resulting changes in our development process.
Posted on 03/21/2016 by Martin Pöhlmann
One side-effect that I have observed from performing code reviews for years is that the code after review is mostly way shorter then it was before. Reducing the size of code will increase maintainability as we have less code to read and comprehend in the future. This stresses one of the primary goals of code reviews: Producing clean and concise code that is easy to understand.
Posted on 08/05/2015 by Martin Pöhlmann
At CQSE we perform peer reviews for almost every line of code that we write to achieve high-end quality control. With the experience we gained (and still gain!) we also help customers to establish review processes or review portions of their code. Besides questions regarding process and tooling there is one question that we get regularly asked: »Is there a list of rules that you apply for reviewing code?« The answer is always »No«—and this is not because we want to keep such knowledge secret. With this blog post I will try to explain why such an exhaustive checklist simply does not exist.
Most of the posts in this blog focus on measuring and improving the quality of software systems. When talking about software quality most of us think about the quality of its source code. However, with the recent trend to continuously deliver new releases the quality of build scripts and thus maintenance costs are becoming increasingly important. From auditing the build systems of our customers we know that coping with clones in build scripts significantly increases maintenance costs and hampers implementation of new build features. This post summarizes how we compared 3,872 systems to interpret cloning in build scripts and examine how it can be avoided.
Talk at the Seventh International Workshop on Software Quality and Maintainability (SQM’05), 2013.
36th International Conference on Software Engineering (ICSE’14), 2014.
2014 IEEE International Conference on Software Maintenance and Evolution (ICSME’14), 2014.
Proceedings of the Seventh International Workshop on Software Quality and Maintainability (SQM’13), 2013.
Revealing Missing Bug-Fixes in Code Clones in Large-Scale Code Bases.
Master’s Thesis. Technische Universität München, 2012.