Applications querying datasources can run into it. And perhaps you've seen it already: Custom built queries:

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.

Since today logstash-gelf supports log4j2. The experimental support allows dynamic field since log4j2 provides a very flexible configuration.

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.

Recently I gave logstash a try. logstash is a log management tool (processing, storing). It can push log messages also into elastic search. This setup is ideal for central logging. The easiest way to push log data into logstash seems to me to be gelf (Graylog Extended Log Format). It is a JSON-style format which can be GZIPed using UDP connections. There are a few implementations for GELF using Java (gelfj, gelf4j) which work nicely with Graylog itself. If you try to use them with logstash you’ll run into a few problems, which are caused mainly due the chunk size. gelfj has a fixed chunk size of 1420 bytes. Maven Central contains none of them (only some reassembled artifacts).

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.

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.