Getting data in JSON format via REST services from the backend server is common practice. In the simplest case a JSON provider like Jackson translates your Java objects into a JSON string and back into Java objects automatically.
However, this does not cover cases where the data model (e.g., implemented as JPA entities) is different from the view model. For example, if you have BLOBs in your model it does not make much sense to transfer them as BASE64 encoded strings. Mostly, because BLOBs tend to be large and may not be needed at once.
In this article we will show how to provide different JSON “views” or dialects of the data using the same REST service.
When we began a new project recently the team thought about using Kotlin over Java to implement the backend. The project lead had issues with this because there was no clear information on how Kotlin would be supported by tools like Sonar and Jacoco. Since these tools deliver important information about code quality and potential issues we decided to spend some time on evaluating how these tools would collaborate with Kotlin.
Almost every application writes log files. Where organizations differ (vastly) is in how and to which extent these logs are used. Aside from the ultimate no-go of not checking them at all, this takes discipline and effort, especially for timely reactions. This post shows how to automate the tedious task of checking log files (especially those from Java backends), how to consolidate them into existing infrastructures (like the Windows Event Log) and how to effortlessly generate alerts for serious incidents.
We know our dataset inside out (Part I), the data is immaculately clean (Part II) and we’ve engineered some powerful and informative features. Finally, in this third and final part of our tutorial series, we are ready to proceed to the guts of the data science process: the modelling itself. Given the abundance of excellent machine learning libraries available, we will not delve here into developing the algorithms themselves. Rather, we will discuss how one might go about choosing and fitting one of the models already available, and how to verify whether the solution we end up with is up to task.
Functional reactive programming (FRP) is a variant of reactive programming for the development of user interfaces based on the functional paradigm and a strict set of basic operators. In contrast to reactive frameworks, such as RxJs, using FRP enables a developer to define a pure area in her code in which some error classes, typical for event-based architectures, do not occur. Sodium is an FRP-framework, which is independent of a specific GUI-framwork and supports several different programming languages. Here, we describe how to use Sodium together with Angular.
Deploying a Docker container on Azure ‘Web App for Containers’ can be done fairly easy. In this blog post, I will provide a step by step guide to get you started. Some basic knowledge of Azure and Docker definitely helps. But why should you care in the first place? You will get:
- a managed runtime (for a single image)
- scaling to multiple instances
- a simple deployment model
- easy integration with App Insights (Azure’s Monitoring system for Web Apps)
- use any Azure SaaS like CosmosDB, MSSQL, …
In No more Ifs I wrote a little bit about the new Optional class in Java 8. It enables the developer to work with optional values without a complex nested structure of if-then-else expressions. A colleague of mine, being a big fan of Kotlin, dropped a hint that using Kotlin, it would be much easier. He could even prove it. 🙂
Java 8 introduced with
Optional a functional datatype that enables the developer to work with optional values without nested if-statements. This can simplify your code a lot.
Apache Camel is a powerful routing and conversion engine use in many projects. In this article we present some best practices when integrating Camel into the JBoss application server aka WildFly/EAP7. Most of this is straight-forward, yet we also faced some problems with the thread pool management.