java

Validation – Operation – Notification

Daniel, 2 Comments

Given When Then – short intro

Have You ever heard about Given-When-Then approach to create tests? It’s an approach to separate tests structure into three parts:

  • Given – Test preparation. We should ask ourselves a few questions here (depending on approach):
    • What I need to execute before tested operation?
    • Do I need some specific beans?
    • Do I need to mock something?
    • Do I need some particular data?
  • When – this is our operation under test.
  • Then – this are our expectations. Basically – test assertions.

Of course not every code can have such structure, but as an ideal approach it can increase overall readability of our source code.

Example:

This test checks if newly created issue will invoke some sort of notification. We can read this test like this:

  • With given title  and description
  • When I create new issue
  • Then one notification has been published.

Of course sometimes, some parts can not be that obvious. Take a look:

Now you can see that given part is hidden. But it’s still there!

There are a lot of good articles about this topic. Some of them:

Validation – Operation – Notification approach

I would like to propose similar approach, but for production source code. Let’s call it VON (Validation – Operation – Notification).

  • Validation – all prerequisites which need to be checked or done before you can do particular command. Such as validations, security check rules etc.
  • Operation – our business command. The heart of the method. We start writing our method because of this. This is our main purpose.
  • Notification – what happens after successful operation. Often it will be just some return statement, but it could be more. It’s a part of business method that did not exist to do primary operation, but invoke some other command (which very often can be done asynchronously. For example using CompletableFuture).

Let’s see a basic example:

Now, look at this method using 3 steps defined above:

  • Validate – if title and description is not null,
  • Create issue (our operation),
  • Notify about newly created issue and return it.

Of course sometimes it will not be such straightforward. Above method in real world can look more like this (using lombok):

Still – you can see all 3 parts of VON approach.

Error handling

Depending on step, we should think about errors and problems differently. Lets try to check possible scenarios when we use VON code structure.

Imagine that something happen on validation step – the only thing you have to do is to throw an exception, return specific error message or maybe send error information to some notification queue… You didn’t start any operation- so you have no problem (within this method).

When something happen during operation part- then you have a problem. If your validation was well prepared then any error within this step will be related to technical or network issues (database downtime, no network connection, etc.).

Finally when something happen during notification phase then you should know two things- operation went well, so main purpose of this method was finished without problems. The only problem you have now is that some notification was not published. Question is what can you do about this? Maybe you should not do anything, maybe you should send information to technical error queue that some message was not sent. Maybe just log this situation? It depends.

As you can see separating your method to VON structure helps you identifying error type that can occurred. It’s one of the advantages of this approach.

To “Enter” or not to “Enter”

As you can see in above examples “enter key” change step in VON approach. In general “new line” in source code should inform us about context change. This principle goes well with whole VON approach as every step is different context. We can look at source code and with a single glance focus on most important part for us at the moment. If every team member use the same approach, then source code starts to look more clear and well structured. The faster you can focus on important things, the faster you can solve the problem you are currently working on.

Of course this doesn’t mean that we should create long methods 🙂 Ideally our methods will have 2-3 lines- each line for single step. Then we can omit all enters.

Lets start some cleaning!

Caution - Wet floor

Refactor to VON – example

Imagine a method that delete contract from some old system. Contract can be deleted when it’s not started and any of its conditions are not started yet as well (for example, there can be specific condition which will limit that resignation from contract can be made two or more months before contract is started). Delete operation is made using SoftDelete (BTW. I hate soft delete). Of course before we start making any changes we should have proper unit tests!

Our example:

First let’s try to find our steps:

  • validation 
    • our contract and any of its conditions can not be started- this is in the code
    • we don’t have validation that contractId  is null …
    • we don’t have validation that particular contract exists in repository..
  • operation
    • delete all contract conditions
    • set contract as non active (soft-delete)
    • save in repository
  • notifications
    • cancel payment disposition for deleted payment

I would start with preparing above steps. Problematic part is that deleteAllContractConditionsByContract method is at the same time in validation and in operation phase. Let’s split it to two methods (for now).

As we don’t want to change too much outside this method let’s just extract both assertions to particular methods:

Much better 😉 Now lets fill the gap with our validations:

Ok. We should hide this whole optional stuff:

Now some small refactoring with operation part:

Now we need to take a look at the notification part. There are two things possible:

  1. Add a new method to paymentsService  which will cancel payment disposition. Simple and safe operation, however we will still have direct relation between contracts and payments.
  2. Add some queue in the middle between payments and contracts modules/components. We can use queue or just simple implementation of Producer/Consumer pattern. It’s a bit more complicated, but this gives us a more loose connection between the modules.

And basically we can stop now as this finish whole VON approach. Using this approach we did find 2 possible problems with particular method, however- now probably we have redundant checks – in our method we must assert that all contract conditions can be remover, and probably within contractConditionsService  the same check will be made.

Despite this, its look like a good start to further source code refactoring. Finally we can finish with something like this:

Summary

This technique nicely apply mostly to more complicated business methods and for legacy code refactor. Its biggest advantage is shown when every team member use this technique for all business operations. Then these methods starts to look consistent and much more straightforward. Also it helps to look at different parts of method differently (for example in case of potential errors that could happen).

Please note that this approach should not be used at every cost. It’s a convention that nicely applies to legacy code methods as in our example, but also to shiny newly created operations.

Have fun and comment below what you think about this approach!

Validation – Operation – Notification

Do not make these mistakes! @ Chillout meetup #6

Chillout Meetup #6 Agenda

  1. Paweł Młynarczyk, “The Programmer’s Diary – there and back again“,
  2. Daniel Pokusa, “Java: Do not make these mistakes!“

Both talks have one shared concept – journey. We will try to share our knowledge on different abstraction level. Paweł wants to share his journey as a professional developer and explain how evolve, how learn continuously. In the other hand I want to share my observations from last 4 years of teaching young colleagues how to “write in java”. I will point out most popular mistakes which are made by trainees and junior developers.

Below you can find more details with meetup url where you can find full description.

Do not make these mistakes! @ Chillout meetup #6

Asynchronous call using CompletableFuture

Daniel, , Leave a comment

Intro

Imagine that you have to use external systems to retrieve data or you deal with communication in distributed architecture (communication between modules within application). In this article I would like to tackle one possible problem, but please note that this approach can be used in a many different scenarios.

Please note that I don’t want to provide another “CompletableFuture guide”. If you are interested in specific options and possibilities of CompletableFuture  I recommend you great article by Tomasz Nurkiewicz.

Problem

We would like to write simple application that will provide us best possible exchange rate from public exchange rate systems (let’s assume that bigger exchange rate value is better as we want to sell). What we want is to convert from our “local” currency (in my example it will be PLN) to selected one (using simple rest call). Response should inform us only about highest rate.

So if I run my application on localhost:8080  and I would like to check lowest exchange rate for GBP then it can looks like:

(In example above I used httpie. I also recommend postman if you prefer more GUI-oriented tools :))

Another example (USD):

In our example we will check 3 external services for exchange rates:

Concept

First of all as you can imagine we will make a few external calls to described above systems (every call will take some time). Best option is to call asynchronously to every exchange rate API and after receiving all rates just check which one is the highest and finally make a response.

Asynchronous call to external exchange rate services

We don’t want to make every request synchronously, because we will increase response time from our application.

Solution

Basic solution

Let’s start with some general interface for every API call:

Then let’s provide some implementation for one of calls:

As you can see there, it’s very simple standard code. I use Spring’s RestTemplate  to prepare and make external call. What’s important here – so far we don’t use any CompletableFuture  so we can test this kind of classes as usual.

What I want to show is that you can provide functionality without thinking about async invocations. You can add this after finishing basic implementation.

Lets go async

Let’s look what we can achieve by using CompletableFuture . This class provides you possibility of creating object that will do some operations “in background” (We will talk about executors which do this operations later in this article). This gives you possibility to create non blocking operations (such as external calls) for future usage. Once you want to use information from CompletableFuture  it start blocking until Future  is completed. However, if operation is already completed then it will not block thread at all.

This can help you in a couple of scenarios:

  • You want to do some expensive operation and use it later. Then you can create CompletableFuture  at first, make other required operations and then use completed Future . In case it’s not completed your app will just wait for it
  • You want to do some expensive operations concurrently and then combine them in some way (this is what we want, and this is most popular scenario)

How do you create CompletableFuture ? The easiest way is to use static factory methods provided by this class. For example:  CompletableFuture.supplyAsync(Supplier<u> supplier)</u> . Supplier  class is a @FunctionalInterface  so you can use lambdas 🙂

Lets try then to provide some Factory for creating our asynchronous calls. This is not the best option, however in this case it can be a good starting point:

I also added exceptionally  here for each created CompletableFuture  – this means that in case that some exception will stop completion of particular Future then provided method will return value as a result. Receiving Throwable t  gives you possibility to adjust result to situation. In this simple example it will return 0.

Finally. we are ready to use it!

Completable Futures are being created in lines 12-14, then (lines 16-19) we take nbpRate  as our basic value, combine result with fixerRate  and select better option (higher), then again we combine this result with yahooRate . This will create another CompletableFuture  – let’s call it  best. 

Finally, as we don’t have anything more to do we use get() method on our Future . This method as I wrote before is blocking- so we will wait until our Futures  will complete and we will have our solution. Then we will just return it as a result.

Now you can see why I said that previous fabric its not our best option. If you have to add new service (and its very likely in our problem) then you will have to add here new lines and implementation which breaks Open/Close principle. I use this approach for sake of simplicity of explanation.

Executors

You can run CompletableFuture  by using default Executor  (as in all examples in this article) what can be fine for simple solutions. But for real world complex requirements this probably will be not effective and can lead to serious problems. If you want to learn more about default executors, Oleg Schelajev did great article about choosing right executor for your tasks.

However, if you are using spring you probably should provide TaskExecutor which has similar interface as java.util.concurrent.Executor , but Spring provides a few nice and configurable implementations of it.

Take an example:

This configuration provides ThreadPoolTaskExecutor  which uses  CustomizableThreadFactory . One can set max pool size (max number of threads that will be created), core pool size (base number of thread that should be in use) and of course more options.

Don’t use default executor. If you use spring, just go with your own configured TaskExecutor . If you use JEE or other frameworks pick up one of available executors in java.util.concurrent  package. Concurrent programming is very challenging so if you can keep something under control then definitely you should do it 🙂

To use particular executor just use second implementation of supplyAsync  method:

Afterwords

There are more problems around this topic, for example,  you need to figure out how to deal with situation when external service is down. We also need to consider how to test our solution and how to simplify future maintenance. There is always a need of providing a good balance- we should always provide sufficient, smallest and simplest possible solution- it’s not easy task to do though 🙂

Most important criteria that should be considered before providing final solution:

  1. Reliability
  2. Resilience
  3. Maintainability
  4. Testability
  5. Performance

 

Asynchronous call using CompletableFuture

Aware recruitment. Part 1: Introduction

Daniel, , , , 2 Comments

This article is for you if you work as a recruiter, have to find some Java developers, but have totally no idea what these buzzy words means: JDK, JPA, JSF, EJB, etc.

First of all – the topic is huge. So please note that this article doesn’t cover all answers for all questions and all technology relations. Still – it should cover basics and I hope that you feel much better while talking to developers 🙂 Please remember that I have to simplify a lot of things!

Why is this important?

When anybody starts asking you about technologies or anything tech-related it’s probably easier just answer that it’s not within your competences. But… using this approach you can lose some good candidates. Out there are a lot of similar technologies. Your client can ask to find someone with experience in Hibernate. Hibernate is just an implementation of JPA  so you can check every candidate that have JPA in CV (there are other implementations of JPA). Knowledge about these relations can boost your productivity. Lets be more aware of Java world!

Typical (simple) web application

First thing that you have to be familiar with is basic concept about what kind of developer you are looking for. Look at these terms:

  • Frontend – everything that application users can see,
  • Backend – everything what is “behind” frontend,
  • Fullstack – frontend + backend.

Frontend-Backend

Generally, creating web application, you can see 3 different blocks: frontend (basically this is a web page that user sees with buttons, links and text), backend (this part generates all data for front end and can make some other things – like sending scheduled newsletter, choose some random promotion for every day, check our daily balance and a lot more) and DB (Database – this is a place where we store all persisted data like our clients, products, invoices).

Is that all?

It looks like there is not too much to talk about. BUT in fact there is much more. Developers have their own environment with special tools to build their applications, there are a lot of infrastructure around application and around development environment as well. So if we want to hire developer we will have to check not only technologies that are connected to application. All tools that are used on daily basis by client’s team are also very important. Imagine that you want to hire an accountant and you have a perfect candidate. He have very good knowledge about current law and have experience in similar company to yours. Seems like ideal. Now imagine that this particular person has never seen a computer and any accounting software. In his previous job they do everything in old-school way on paper and he personally has never used computer so far. It could change your mind I think. And that kind of problems occur very often in software industries. Companies use very different set of tools and these tools are not always up to date.

Before we try to go deeper let’s try to describe all kind of “groups” that we will have to cover:

  1. Frontend technologies
  2. Backend technologies
  3. Databases
  4. Operating systems
  5. Infrastructure elements
  6. Building Tools and dependency management
  7. Testing libraries and frameworks
  8. Virtualization solutions
  9. Management methodologies
  10. Management systems
  11. Code Version Control Systems
  12. Continuous Integration and Continuous Delivery Solutions
  13. Other

That’s a lot. And thats why I must split this story to few articles.

 Backend overview

Basically, when we are talking about Java applications we can separate concepts by its “size” or by its purpose (please note that this is how I try to categorize them for You). When we try to categorize concepts by size we will got these 3 elements:

  • Standards – some abstract concepts or standards that developers need to obey while doing particular things. Standards are very important – if particular developer know some library that follow some standards then he or she can quite easily start working with another library that follow same standard. Some examples: JPA, JAXB, JAX-RS, JAX-WS, JMS. Need more? Look here.
  • Frameworks – big things. Imagine that frameworks are some big blocks that cover a lot of problems (In the same time they create a lot of new problems :)). Choosing one particular framework pushes developers to make specific choices within their architecture. Frameworks sometimes covers only one part of application needs, sometimes a lot of them. Examples: Spring, Play, Jersey, CXF, JUnit
  • Libraries – smallest part. You need to know what the most popular libraries are used out there, but remember that a good developer can learn using a new library within a few days. For example: Guava, Lombok, JodaTime.

If we try to categorize them by purpose, we will have something like this (don’t worry if you are not familiar by these names):

  • Endpoint services – these are elements that have to serve “answers”. Endpoint as the name suggests, is a place in the code that will give calculated answers. Imagine that you are just about to buy some books online. This application frontend will have to connect backend and get your current list of books in your basket from particular endpoint. Developer will have to create some “point” that will have to calculate this result. For example: Jersey, Struts.
  • Database services – these elements just simplify developers to work with persisted data (like orders or availability of books in our imaginary store). So every application that use a database also have to use some database services. Examples: Hibernate, MyBatis, Spring-Data
  • Middle services – these elements connects endpoints with database services. Examples: Spring-Security, EJB

Frontend overview

We have few kinds of applications today:

  1. Desktop applications – These are programs that works on your computer directly. For example Word® or Outlook®. Also Browsers are desktop applications 🙂
  2. Web Applications – Works in your browser. For example Amazon®, Gmail® or Facebook®.
  3. Mobile Applications – Apps that works on your mobile phone. There is a lot of web applications that have their own mobile apps and a lot of “only mobile” apps as well.
  4. Console Applications – Apps with very simplified user interface.
  5. No-frontend Applications – Applications that don’t have any frontend.

Desktop applications

There are a lot of technologies that are able to provide particular kind of application. For example Java desktop applications are created mostly in javaFX technology today. A few years ago Swing was the most popular library. There is also AWT– its ancestor. So if you see that someone knows Swing and your client want a developer with JavaFX knowledge you can try to ask if this particular developer have some knowledge about JavaFX or ask your client if Swing knowledge is sufficient. Unfortunately these two don’t have a lot in common. But if you see in clients requirements that he wants Swing and JavaFX you can for sure ask why- because it doesn’t make any sense to write any application in these two at the same time. They are mutually exclusive.

Web applications

Every web page is just:

But, this is a bit more complicated because everything can be generated or delivered in a lot of different ways.

Mobile applications

There are a lot of mobile devices that give possibility to use Java. Almost every device has its own library and approach so it’s quite hard to cover them all. I will try to give a little overview about Android world as it’s most popular platform today.

DB overview

Database is just a container for data. If you don’t want to lose some particular file you store it on your hard drive. In application world database works similar but its far more complicated. There are a lot of different databases:

  • RDBMS – Relational Database Management System. Most popular conception where data can have relations. For example Your basket has one-to-many relation to products. So You have one basket while shopping and you can put as many products as you like in it.
  • NoSQL – Databases that have different conception than tabular idea used in relational ones. If we want to use NoSQL database, we need to choose one as there are a lot of them:

 Summary

The purpose of this intro is to show spectrum of issues that every recruiter should be familiar with in my opinion. I have choosen three most important topics for this article – I hope now its a bit more obvious how this “java world” works. From now on- when you get your client’s expectations try to classify them as suggested above and then try to find similar technologies that can possibly cover same principles or standards. This will help you looking at particular technologies in candidates resumes.

Next chapter will be a bit different we will cover one topic and then I will give you some example requirements from real-world job offer and show how to look at this offer and how used technologies are connected to each other.

Aware recruitment. Part 1: Introduction