Recently, I moved the IT Hub from Pivotal Cloudfoundry to Amazon Web Services (AWS). This article highlights some of the decisions and illustrates the resulting architecture.

Some weeks ago, Pivotal announced the end of availability (EOA) for Pivotal Web Services (PWS), effective as of January 15, 2021. As the maintainer of the IT Hub, this forced me to move the application to a different solution pretty fast.

One of the projects I work in has an uncommon tech stack, at least it differs from the standard CRUD-application-tendency many company-apps are built in. The mentioned application uses the Axon framework and a Mongo database. At first, the data often changed structurally, hence storing it in a document database accelerated development. Feature-requests for accessing the history of data encouraged the use of Axon with its events that are stored permanently in the database.

Like other applications, my main project runs through several quality gates before being deployed on the production stage. For example, there is a developer stage, which simply is the locally running version on every developer machine, and a test stage. This test stage is similar to the production setup and can be used to test features before they are merged into the main branch of your version control system. Many projects use an additional quality stage which runs the latest stable build so the customer can test, too. The deployed system behaves differently for every stage.

Yesterday, I changed all of our field-injected Spring-dependencies to constructor-injected. This

Because I recently read about this pattern, here are some words about how I use DTOs, Data Transition Objects. DTOs are used to transport data, for example from server to client and vice versa. Let's have a look at the case where you want to load data from a server to represent it in a client.

Some of the problems in everyday software development are luxury problems. Like when you work in a greenfield project and are able to choose how you implement equals() and hashCode(). However, this decision will have a major effect for the project down the road. So here are the options I found out and my decision making process.

Microservices are one of the hype topics I didn’t manage to have a look at. So this week I was lucky finding that the cover story of the Java Magazin (issue 5.16) is “Microservices – the hype in the reality check”.

This week, I practiced my first architectural kata (alternative link) with my mentor Jens Schauder and my co-mentee Thomas. These katas are meant to practice the process of designing an IT system from scratch, given a specific task. Jens picked one of the tasks for me which was to design a digital UN conference system for students. This system should serve as the technical infrastructure for hosting UN gatherings via video chat as well as one-to-one-video chats between the users. News events should be created by admins and shown to the users, which are students from all over the world who aren't meant to buy new hardware to use the system. In this article, I want to describe my thoughts about the task, the process of getting to an architecture and of course my failures in this solution.

A couple of days ago, I saw an interesting way to prohibit the use of a method from a superclass. A coworker of mine wrote a subclass of a JTextField that should display a date in a specific fashion. Before you comment the obvious: Yes, there where reasons not to use JFormattedTextField. ;)

Here's how he wrote the new class:

public class CustomDateField extends JTextField {
 
	public void setDate(Date date) {
		Calendar c = new GregorianCalendar();
		c.setTime(date);
                // the real method was a bit more complicated, but for the example that is sufficient
		super.setText(String.valueOf(c.get(Calendar.YEAR)));
	}
 
	/**
	 * @deprecated Use setDate(Date date) instead
	 */
	@Deprecated
	@Override
	public void setText(String arg0) {
		throw new RuntimeException(
				"This method is not supported. Use setDate(Date date) instead.");
	}
}

Recently, I began reading Clean Code by Uncle Bob (again). In chapter 11 ("Systems"), he writes about a "Global Setup Strategy" of an application. As I understood it, it is the master plan for instantiation of objects and the references between them. Following such a strategy should separate the construction of a system from its usage.