Message Delivery Characteristics First some theory about delivery semantics in messaging systems. When a system wants to communicate via a message broker the developer needs a clear understanding of the delivery semantics. At first one needs to know if and how often a message will be delivered to the broker (and potential consumers): At most once - the message is delivered at most once but also not at all.

83,9% - what does that even mean? Conversations about unit test coverage usually sound like this: A: “What’s your coverage?” B: “About 83,9%” C: “Meh. Solid.” A: “Solid? That’s incredibly high!” D: “Ours is 40% but we have a lot of generated code so it’s still high.” This shows that the perception of code coverage is highly subjective and most of the time does not have the informative value that a precise percentage indicator like '

This is the story of my team creating something awesome within one day. It begins in November of 2017 at 'Hack your Office', a 24-hour hackathon hosted in cooperation by my employer synyx and our customer dm-drogerie markt. Although it was an excellent hackathon, this is not the day I am refering to but it was on this day when the idea was born. Several of my team members from dm where participating in the hackathon, even Matthäus - one of our product owners - joined us.

Creating static web sites with Hugo is fun and fast but providing a convenient shortcode to smoothly cross-fade an unknown number of images in a blogpost gets a bit tricky… So let’s go!

This post outlines the steps needed to simultaneously deploy to Maven repositories and to GitHub Releases. Every time a tagged commit is pushed, a Travis CI build will be triggered automatically and start the release process. This blog post uses Sonatype Nexus as an example for a Maven repository manager. Preparing GitHub Releases Sergey Mashkov has written a Maven plugin that allows us to create a new release on our project’s releases page and upload our build artifacts to a release.

Giving fast feedback to users has been improved by single page applications over the request response cycle. However, there is one serious downside with this approach. Elements are popping out of the wild on various sections everytime. Particular data loading indicated by a waiting animation is affected with this phenomenon. In this blog I’d like to present you our solution of a UI component that takes care about delaying the rendering of the animation.

It was not our primary goal to use Behaviour Driven Development (BDD) in the project at a customer, but while finding and optimizing our agile software development process we recognized that we established the building blocks of BDD. It works quite well and offers a lot of space and flexibility for our future plans, switching our architecture to microservices. The project setup But let us start at the beginning of the project.

In this blog I will outline why we used Hazelcast for queueing messages in-memory distributed over a cluster and how we achieved higher resilience by persisting the queue’s content. I will explain the pitfalls and difficulties that we encountered and how I constantly switched between praising and condemning Hazelcast. The problem to solve I’m currently working in a project for a large customer data backend. The prod system consists of a load balanced cluster of five VMs each running two Tomcat instances hosting our application.

Am 22.5. habe ich zum ersten Mal die Karlsruher Entwicklertage besucht. Insgesamt war die Veranstaltung gut organisiert, man bekam schnell und unkompliziert seine Badge und die obligatorische Info-Tüte. Es gab eine große Auswahl an verschiedenen Talks, die auf 6 parallele Tracks aufgeteilt waren. Die einzelnen Tracks wurden unter anderem von einigen Usergroups wie z.B. der Java Usergroup, der .NET-Usergroup und dem lokalen OWASP-Chapter organisiert. Danke an die ehrenamtlichen Helfer für das Engageme