Lots of companies I know tend to work still in a plain old style. Top-down bosses, either water-fall, ad-hoc or chaos-driven development. Long term release cycles and inefficient, expensive style of development. Continuous Delivery: What’s that, do they ask, why do we need such fancy things?

Many „something as a service“ companies are agile and deliver updates to their services seamless, without any down-time. As soon as they would go down for maintenance a lot of people would stop using it. Imagine Amazon or Google would go offline every day or week for a couple of hours.

In contrast to that, the least other companies go for efficient development, Continuous Delivery and all that other „fancy“ stuff. Some sort of agile development is the most you can expect from german companies. If you’re lucky, they’re doing Test-Driven development or Clean Code, but that’s it. So I started to investigate why this is.

For quite a long time I was seeking for a reasonable explanation of software architecture. Nobody could provide a sufficient description. Developers and software architects would describe their architecture perhaps this way: We use Model-View-Controller for the Web, EJB as Controller, havin Hibernate as persistence framework.

Layering, multi-tier, Hibernate, Java Server-Faces aren't an architecture. They are ideas for code organization, tools or somewhat, but for sure not an architecture.

Some weeks ago SEMAT hit me: Somewhere Uncle Bob said something about Ivar Jacobson’s book „The Essence of Software Engineering: Applying the SEMAT Kernel“. This was reason enough to sneek peak and after a couple of minutes I bought that book.

Integration Testing describes every test, which integrates more than one component that is tested.

Lots of developers are writing test using JUnit, PHPUnit, NUnit and so on. These tests invoke some piece of code, that do something. This „something“ can be a in-memory calculation, access to databases or even accessing remote services. Unit tests are tests which test a single unit, a method, a class. As soon as this method or class tries to access something, which is outside of your working memory, it's most likely an integration test. Integration tests are very valuable, but in most cases you perform integration testing without knowing it. In most cases you'll notice it, as soon as you run your tests without network or somebody kills the database. And then you might be screwed. This example gives some impression what the difficulties are: External systems, services you can't contol (yet), shared databases. Because of these and sometimes because the benefit is not seen integration tests are not automated.

A couple days ago I wrote about Clean Architecture. I was also excited, how it will look like within code. How does it feel? How can I progress.

Do you know Puppet? Puppet is a system management/provisioning tooling. It's intended to specify a set of resources (files, software packages and many more) to be in a certain state. This is very hand for all the cases, where you need for example Apache and PHP, you want to apply an own php.ini, have a customized logrotate.conf, some cron jobs... All this can be specified using Puppet. The first time your system boots, all the specifications are applied and you don't have to copy config files anymore. Puppet runs also every 30mins (by default) to check for new/changed rules.

Branching by Abstraction is a common approach now when trying to keep a software system functional though all the changes. Imagine, you would like to change your persistence framework, from iBatis to Hibernate to JPA back to something different. One approach is, just doing it. This will break your application immediately and you will need hours/days/weeks until it runs again. No matter whether you’re on a branch or within the development head (trunk/master). A no-go, especially when you’re into Continuous Delivery.

Some time ago I got in touch with one of my 2006 written applications. I got flashed at the moment I looked into my code.

My intention was to perform some improvements. 2006 had very few frameworks to deal with HTTP interfaces. The most common interface types were GUIs (JSP/JSF) and some SOAP Services. Writing HTTP interfaces for API use (calls from JavaScripts and so on) was still a hard way in Java applications. In most cases servlets were used. Those servlets received either Query- or Form-Params to perform the processing. Sometimes they even accepted/produced some XML. Let me show you some examples and how to solve them using current technology.

Java is currently the one and only language having checked exceptions. More and more frameworks switch to unchecked exceptions over time, moving them out of focus, making them invisible. Therefore exceptions become an aspect of modern software and should be treaded in an adequate way: Don't let your code be exception driven.

Prior to this article I wrote about testing SOAP WebServices locally. This was accomplished using JAX-WS. Lots of projects still use Axis or Axis2. Therefore I created a simple Axis2 setup to demonstrate JUnit-Testing of WebServices.