Archive: October 2018

Securing Spring Microservices with Keycloak - Part 1

Posted on by  
Joost van Weenen

These days companies gather and manage vast amounts of user data. Loss of this data will expose companies to financial/legal liabilities or damages to their brand. This is because over the last years, governments have introduced new regulations like the General Data Protection Regulation (GDPR). Because of this, security is a major cross-cutting concern for application architecture. This two-part blog post explains how you can leverage Keycloak to secure your Spring microservices. The first blog will focus on how to install and configure Keycloak. The second blog will show how to use Keycloak to secure your Spring Boot microservices.

Keycloak is a modern open source Identity and Access Management solution. It enables us to secure all sorts of frontend applications (apps) / services and offers the following features:

  • Single Sign-On

  • Identity Brokering and Social Login

  • User Federation

  • Client Adapters

  • Standard Protocols

  • Admin Console

  • User Account Management Console

A corporate version, known as Red Hat Single Sign-On (SSO), is also available from (and supported by) Redhat. The support and the ability to connect to existing identity systems make it a good fit for large organisations.

Continue reading →

Easily build your own tech radar

Posted on by  
Sander Smeman

The Thoughtworks Technology Radar is well known for showing technology trends and choices. For my project I wanted to have the same thing, not use the hosted public version from Thoughtworks, but a selfhosted option. Therefore I choose to base it on the Zalando opensource tech radar, and create a way to use a CSV file as input so updating would be an easy thing to do. To accomplish that I took the following steps:

  1. Create a folder to put the tech radar into: ${project-folder}.

  2. Start with the HTML5 Boilerplate index.html file and put it into the ${project-folder} file.

  3. Insert the snippets as documented at Zalando Tech Radar, with one adjustment. I don’t fill the entries array with entries, but will do that later on, from the input in the CSV file. Note the names of the rings and quadrants, as they will be used in the next step, the CSV.

  4. Create a CSV file (${project-folder}/data.csv) as input for the tech radar. It has columns for the ring and quadrant where a technology should be put, and an indicator for movement. The names of the rings and quadrant should equal those in the configuration copied from the Zalando example. If you changed them, use those names instead. The movement indicator is (up, none, down) and in the next step translated in to value understood by the radar. The CSV will be translated into entries for the radar.

  5. Add the following D3.js library to parse CSV:

    This library provides functions to parse CSV file(s) into a map structure per row in the file.

  6. Create a function to transform a row in the CSV into an entry for the tech radar:

  7. This is the diversion from the steps in the Zalando tech radar description. Wrap the radar_visualization() function a custom one, that takes an array of entry, to render the transformed rows, e.g. draw_radar(entries).

  8. Finally glue everything together to fetch the CSV, parse and transform it, and draw the entries. The code below uses the functions I defined in the previous steps

    When you have followed the above steps, the result should look like this:

Continue reading →

TestContainers project can make your (integration) test life easier

Posted on by  
Tom de Vroomen

There are those moments you wish you could just start up a real database or system for your (integration) test. In many tests I’ve written I used H2 or HSQLDB to have a data storage for my tests. It starts up quickly and almost supports everything you need to do your repository test or any other test needing data storage. But when your project progresses you start using other ways to store your data other than standard SQL or you use dialect specifics to create your database. This is the moment you discover H2 or HSQLDB is not supporting your database vendor specific features and you can’t get your test running. For example the support for PostgreSQL in H2 or HSQLDB isn’t great, using TIMESTAMP in a SQL script already makes H2 or HSQLDB break. Yes, there are workarounds, but you rather not apply them to keep your code clean and simple. This is the moment you wish it is cheap to start up a real database instance you can test against, so you’re sure your code works in your production environment. You could install the database software locally, make some scripts to initialise the database and clean up afterwards. Or you can make scripts to do this in a Docker container. But what if there’s something which makes this even cheaper to setup?

Well, there is something to help you: the TestContainers project. With TestContainers you can startup your favourite database from a Docker container. TestContainers made a wrapper around docker to have an easy setup for your tests. And even better, is doesn’t only work with your favourite database, it works with any docker container you need in your test. Okay, I have to admit, the startup time for your test is longer in comparison with H2 or HSQLDB, but on the other hand you get a fully functional database instance.

Continue reading →

Get your application version with Spring Boot

Posted on by  
Ties van de Ven

There are a few ways to get your application version with Spring Boot. One approach is using Maven resource filtering to add the version number as an enviroment variable in the application.yml during the build. Another approach is to use the Implementation-Version stored in the manifest file.

First of all, you need to enable resource filtering for your application.yml

Then you need to add a maven parameter to the application.yml. @ is used here instead of the standard ${} notation to prevent conflicts

And we can then retrieve it using @Value

The upside of this approach is that you always have a version number even when you start your application from your IDE, also by putting your variable in info.app.version, if you use Spring boot actuator, your version will be automatically available under the /info endpoint. However, this approach does require quite a bit of configuration.

Continue reading →

Shift left thinking applied to the full software delivery cycle

Posted on by  
Jasper Bogers

After the success of agile transformations that gave organisations the ability to respond to a change in the market more quickly and frequently, the last decade saw DevOps emerge as another magic wand. While valuable by itself, DevOps should actually be treated as one of many aspects of the Shift Left paradigm applied to the full software delivery life cycle. Patrick Debois, Andrew Shafer, John Allspaw and Paul Hammond coined the word DevOps around 2008. It comes down to the insight that combining the disciplines of development and IT operations by removing the thresholds between them allows for the elimination of waste and improvement of quality and speed of software delivery. The concept of Shift Left comes from the field of testing and boils down to the idea that the earlier in the software life cycle a fault is found, the cheaper it is to fix it. The accompanying model for this concept is that the process for delivering software goes from left to right as it goes from concept to cash.

Traditional left to right view of a software delivery pipeline

Continue reading →

Micronaut Mastery: Running Code On Startup

Posted on by  
Hubert Klein Ikkink

When our Micronaut application starts we can listen for the ServiceStartedEvent event and write code that needs to run when the event is fired. We can write a bean that implements the ApplicationEventListener interface with the type ServiceStartedEvent. Or we can use the @EventListener annotation on our method with code we want to run on startup. If the execution of the code can take a while we can also add the @Async annotation to the method, so Micronaut can execute the code on a separate thread.

In our example application we have a reactive repository for a Mongo database and we want to save some data in the database when our Micronaut application starts. First we write a bean that implements the ApplicationEventListener:

Continue reading →

Lightweight Architecture Decision Records

Posted on by  
Niels Dommerholt

As a software engineer you make architectural decisions all the time. Neal Ford calls these software engineers 'accidental architects'. I personally prefer the term implicit architects because I don’t think software engineers doing architecture is in any way an accident or even something you would not want. You’re the expert after all. Decision making is one thing though, how do you document these decisions?

In my current project my function title is Software Architect. I have mixed feelings about this. While it definitely looks good on a resume I actually don’t feel software architect is a function title. Software architect is in my opinion a role, and one that can’t be handled by someone that doesn’t have his or her’s boots on the ground where the software development happens.

This is reflected in many teams where there is an 'architect' that, every now and then, comes down from his golden throne in his lofty ivory tower to enlighten the code monkeys software engineers with his architecture. After enlightening the engineers he again ascends the thousand stairs to his throne to work on his next perfect work.

Another word for this is a seagull architecture; architects that, like seagulls, fly down cover everything with shit and then fly off again. Leaving the software engineers wondering what they did wrong in a previous life to deserve all this. And if you’re lucky you don’t have a single seagull to deal with, but a whole team of them with conflicting ideas on the direction your teams should take.

Continue reading →

Start your next web-application in the browser with CodeSandbox

Posted on by  
Sjoerd Valk

Starting your next Javascript project can be frustrating or overwhelming when you have to set up your local development environment. The most of the new Javascript techniques and frameworks are dependent on node and NPM. Especially when you want to create a tutorial, blog post or prepare a workshop. The setup for each type of operating system can take to much time and your audience can lose the focus on the message you are trying to send. For this problem, CodeSandbox can help you out! On codesandbox.io you can start your next project with just one click and demonstrate, experiment or build cool stuff.

Continue reading →

Grasping Java 8: open source Java 8 workshop

Posted on by  
Chiel van de Steeg

Although Java has always been awesome, Java 8 has brought the language several features the language was in dire need of. Apart from the long-awaited improved DateTime-API and the introduction of Optionals, Java 8 finally gave behaviour the attention it deserves by incorporating (a form of) functional programming into the language using lambdas.

The opportunities that Java 8 brought the language and the platform have long since been taken and functional styles of programming are part of our day-to-day routines as Java Developers. For-loops are a thing of the past for most of us, and although it had quite the learning curve, passing streams around and chaining operations on them to create some very readable code is common sense for us now.

Continue reading →

Combining Spock and JUnit 5 tests

Posted on by  
Sander Smeman

Great projects keep moving forward. JUnit5 is available since September 2017 and Spock 1.2 is already complete. Since Spock is based on JUnit4, I wondered what it would take to use Spock 1.2 together with JUnit5.

As it turns out, it’s quite easy to make that happen. JUnit5 comes with the vintage engine to run JUnit4 based tests. If that is available on the test classpath, your Spock tests run like on JUnit4.

Continue reading →

Using QueryDSL annotation processor with Gradle and IntelliJ IDEA

Posted on by  
Tom de Vroomen

Making IntelliJ understand your QueryDSL generated classes needs some work. QueryDSL has an annotation processor to generate Q-classes from your entities. Just running the annotation processor doesn’t mean your IDE will understand where to find the generated classes. I was struggling to get IntelliJ IDEA picking up the generated classes. Probably there are more ways to get this done in Gradle, but I found out one that’s pretty easy to configure, without any adjustments to you IntelliJ settings. Because you could configure the annotation processor via the IntelliJ settings in the Annotation Processor screen (Build, Execution, Deployment → Compiler → Annotation Processors). It would be easier if you can achieve the same just using Gradle. With the following in your Gradle build file, it generates the classes and instructs IntelliJ where to find the classes:

If you’re using Lombok in your entities, generating the QueryDSL classes will fail, as it won’t understand the Lombok annotations. To solve this you have to add the Lombok dependency to the annotationProcessor block.

Continue reading →

My Move to Kotlin

Posted on by  
Niels Dommerholt

Back in '98 when I started with my CS education Java was the first programming language we were taught. Before I had experimented with QBasic, C and assembly but that was the moment where I started to really grow into being a software engineer. While I made something excursions to other languages; PHP, C#, JavaScript and even ColdFusion, Java always was my 'base' where I returned to. My great love as it were. But now she’s fallen out of fashion and I’m moving on to greener pastures: Kotlin.

You might notice quite a big gap between this post and the previous one. There are multiple reasons for this (a project taking up a lot of my energy is one of them), but a big reason is that in my personal projects I don’t really feel like using Java anymore, but on the other hand Java is the common theme in most of my posts here. This is also reflected in the traffic my blog is getting; the "how to do X" type posts are the most popular.

My definitive move towards Kotlin started in November last year with the (awesome, check them out!) Advent of Code contest of 2017. I use these to challenge myself to learn new things. Back in 2015 I used the challenge to learn Scala and last year I started using Kotlin to solve the 2017 challenges (link if you want to check them out).

While doing the 2017 challenges I was actually having so much fun with Kotlin that I started working on the 2016 challenges as well!

Continue reading →

shadow-left