Spring Boot is a huge success, perhaps even more so than its inceptors hoped for. There is a lot of documentation, blog posts, and presentations on Spring Boot. However, most of them are aimed toward a feature, like monitoring or configuring. Few - if any of them, describe real-world practices. In this post, I'd like to highlight how to design a Spring Boot having multiple modules.
When I started working as a developer - a long time ago, we were under constant supervision. For example, one had to ask the architects team for every new library. I remember one of the "official" library was iText, probably because reimplementing its features was deemed to expensive. Yet, though Struts was available, we had our own MVC framework. Just like any other company at this time. Since that time, a lot has changed
Despite what a lot of conference talks might lead you to think, far from every Java developer uses Docker on a daily basis, if at all. However, chances are high they work with a couple of different Java versions. To handle that requirement, the easy approach is to set the JAVA_HOME environment variable when necessary. But you have to remember the path to the required Java version every time you need to change.
This post is part of a serie dedicated on starting development with the Ethereum blockchain. Last week, we finally developed a contract providing some value in the form of a rough-around-the-edges voting application. Ethereum comes with no tools aimed at state-of-the-art software development out-of-the-box. Since this is a huge issue, there's third-party tooling available in the form of the Truffle framework.
In web applications, it's necessary to prevent impatient users from POSTing the same data over and over again. For example, to avoid the pain of putting the same item into the basket multiple times because of a browser refresh. To implement that, there's a good practice, called the Post/Redirect/Get pattern.