The latest issue 11.2016 of the “Java Magazin” has been published. It contains my article about the testing of RESTful services. If you don’t speak German, don’t panic. The article is more or less a translation of my blog post “Testing RESTful Services in Java: Best Practices”.
Developing with Python was a refreshing and pleasant experience. After working with Java for a while, you may forget how verbose and clumsy this language is sometimes. But Python shows how simple and powerful a programming language can be. Let me show you some examples.
Auto increment IDs are not working well when it comes to distributed databases. Instead, we should use UUIDs. Let’s consider the pros and cons of UUIDs and how we can use them with Hibernate and MySQL.
Dealing with version numbers is an important challenge on the way to Continuous Delivery. The classical versioning approach (“8.2.0”) and release workflow is inappropriate, because it can’t be automated properly. This post shows how we can leverage the Git commit hash to get rid of manual workflows and automate the Continuous Delivery pipeline. At the end, every build will produce an artifact which is potentially shippable. We’ll implement this solution with Maven and Docker.
Extracting common code to a library seems to be developer’s best practice. Reuse boosts the development, doesn’t it? However, in a microservice architecture shared libraries tightly couples microservices together. You lose a huge benefit of microservices: independence. In this post I like to point out why shared libraries are not a good idea and present alternatives.
Testing RESTful Web Services can be cumbersome because you have to deal with low-level concerns which can make your tests verbose, hard to read and to maintain. Fortunately, there are libraries and best practices helping you to keep your integration tests concise, clean, decoupled and maintainable. This post covers those best practices.
In the last blog post I shared my personal experiences with the course “MongoDB for Java Developer” (M101J). The second part revolves around the content. I summarize my personal takeaways and add some personal assessment in terms of the content.
I attended the course “MongoDB for Java Developer” (M101J). It was fun and I learned a lot about MongoDB. I like to share my gained knowledge and experience in a two-part series. In this first part I assess the course and state, whether or not the course is worth the time.
When we apply Model-Driven Software Development (MDSD) we write a generator which produces code out of a model. The promise is that among others, we can reduce the boilerplate code and accelerate the development. However, MDSD is not a cure-all and should be applied with sound judgment. In this post I cover some drawbacks of the generator approach, anti-patterns and present an alternative to generators: frameworks.
Does your Vaadin application scale well? As Vaadin holds the UI state of every user on the server-side, the used server memory increases with every active user. So can our Vaadin application deal with an increased amount of users in terms of the used memory? We will find out! In this post I present tools and approaches to investigate the memory footprint of our Vaadin application.