-
Continous Integration Extreme! (Slides)
Tonight I will be giving a talk on how to take your Continuous Integration Practice to the extreme at Softwerkskammer Nuremberg. You can download the slides for this talk here If you didn’t catch me live, you can still see this talk at: XPDays Hamburg 2018 JavaLand 2019
-
Making architecture decisions with distributed teams
When it comes to software architectures I am with the agile manifesto that states “The best architectures, requirements, and designs emerge from self-organizing teams.”. As a consequence no single individual should be making all the important (that is the architectural) decisions for a software. I like to see teams tackling these decisions by a quorum of team members, deciding on the important stuff in consensus. While this is a hard thing to do for on-premise teams, it’s even harder to pull off when your team is highly distributed and you can’t just gather everyone around a whiteboard.
Read more… -
Architecting the uncertain - Getting started with Agile Software Architecture
The idea of an Architecture Sprint or Iteration Zero is quite common, though somewhat controversial in agile circles. Although valuable, it’s often misused by teams new to agile, to keep their own waterfall-era decision processes alive. You end up with a process that’s called water-scrum-fall. But there’s much to be saved - and gained from an agile approach to upfront Software Architecture activities. In this post I want to explore this idea.
Read more… -
Integrating continuously with dependencies - without breaking the build
Continuous Integration (CI) is perhaps one of the most underrated and misunderstood techniques brought to us by the Extreme Programming movement. In its essence continuous integration requires you to, well… continuously integrate. That means all the changes to an application or even multiple cooperating applications to get feedback about integration issues often and early. Changes tend to be smaller and issues easier to resolve this way, or as Martin Fowler put it: frequency reduces difficulty.
Read more… -
These five security checks are easy to automate
The web is a scary place, if you are running a server or developing a web application. Fortunately some checks to make sure your application and server is safe are very easy to automate and even execute regularly as part of your CI/CD Pipeline or post-deployment process. Although these checks will not find every possible security flaw in your application, automating these you can free up time for you or your security team, that you can spend on more thorough checks that are not so easy to automate.
Read more… -
The secret to refactoring code in baby steps
I am going to tell you a secret, that will probably make you more confident at tackling huge refactorings. It’s so simple, you probably did or saw this at some point already, but it’s easy to forget when you are knee deep into a refactoring. So here it is. The secret to doing huge refactorings in safe baby steps is: don’t immediately rip out old implementations. Instead use them as a crutch until it’s easy and safe to delete them.
Read more… -
Working with Red Hat Linux (RHEL) in a Vagrant Box
In this post I will take you through the first steps of setting up Red Hat Enterprise Linux for modern development using Vagrant. Big companies like buying Linux from other big companies. There’s nothing wrong with that, but when you start working towards treating your Infrastructure as Code the fact that you need a valid subscription with the OS vendor to install any packages makes for a rough start in infrastructure automation.
Read more… -
Using Git hooks to keep your build stable
A little known fact is that Git supports client-side hooks to execute a command line script before certain commands such as commit or push. This feature can be used to perform additional quality checks on your codebase. What’s way cool about it is that Git will actually cancel the action if the exit status code of a script is not zero. This makes it a perfect fit for automated checks making sure you’re not shooting yourself in the foot.
Read more… -
Resisting marshmallows is hard. Adopting TDD, too.
We are not as rational as we think we are. Or as Dan Ariley might put it: We’re All Predictably Irrational. The other day I read “Die Kunst des klaren Denkens” (lit: The art of clear thinking) by Swiss author Rolf Dobelli. One of the common logical fallacies Dobelli describes in this book is the fallacy of Hyperbolic Discounting - the inclination to value immediate rewards over over delayed rewards. It seems to me, this human predisposition like no other lies at the heart of many mistakes in software development, including failed attempts adopting Test-Driven Development (TDD).
Read more… -
An Odyssee of Android testing
A few days ago I started developing my first native Android App. Finally a green field project! Finally, an opportunity, to do things right! Finally, a project I could develop in a Test-Driven fashion without the weight of any legacy cruft slowing me down! Or so I thought… With a lot of enthusiasm I bootstrapped a new Maven Project and sure enough there was an Archetype with something called “Instrumentation Tests” included.
Read more…