JOIN is back!

As has become tradition, Ordina JWorks organised the annual JOIN conference on Oct 4th. This edition was the 6th and once again it was bigger and better than the previous editions.

JOIN is a free conference hosted every year by Ordina JWorks, by and for our own employees. External colleagues, and basically anyone interested in Ordina JWorks, is also invited to come over and indulge themselves in the JWorks atmosphere. To learn about new technologies, trends and best practices in our domain.

Join 2018 Food

Join 2018 crowd

Talks & Workshops

Unbeatable at Connect 4 with Wearables and Computer Vision by Frederick Bousson

Frederick Bousson

Frederick Bousson kicked off the technology track with his talk about wearables.

Wearables are becoming more mainstream every day as proven by the prevalence of fitness trackers and smart watches. Smart glasses on the other hand are still very rare. Mainly because they still look awful. But improvement is on its way here as well: better looking sets are starting to appear like the Vuzix Blade. This is important as humans are very vision-oriented: 90% of the information on the internet is processed via the eyes.

Connect 4

To really demonstrate the power of smart glasses, Frederick was looking for an interesting case he could use as a demonstration. The result of this quest was a way to help you become unbeatable at Connect 4.

Connect 4 is a “solved game”, which means that there’s an algorithm that can’t be defeated (provided you get to go first). Frederick went hunting in the Open Source community and discovered a program written by Brian Borowski which contained this algorithm.

4 years ago, Scott Bouloutian added visual processing code on top of that and yet another person ported the result to Google Glass. Nice to see how, with open source, you have people who build upon each others’ work.

Image processing

If you want to have your smart glasses solve your game of Connect 4, you’ll need to do some image processing. And since the game revolves around colour which means your program doesn’t just need to see, it has to reason about these colours as well.

Reasoning in colour is a pain in the ass though.

OpenCV, Open Computer Vision, is a great library for image processing and it’s available for a lot of programming languages. Unfortunately it doesn’t use RGB (Red-Green-Blue) as a color space, it uses BGR (Blue-Green-Red) instead. If your brain is conditioned to think in RGB, switching to BGR is not an easy task.

Before you can start solving the game you need to know the position of the pieces that were already played. And before you can find those pieces you need to know where the board is. In order to find the board you’ll need to look for a large, blue rectangle. Then you draw lines around it and find the corners. Now your application “sees” the board.

The next step is to look at the location of the played pieces. For this you need to look inside the board for concentrations of the right color. If you’re using a board that has a tray for the game pieces this tray is also part of the board and you’ll need to cut off a bit from the bottom.

Of course if you’re using a different light source, colours are perceived differently by the camera (e.g. the same colour in fluorescent lighting is green while it will be matched to yellow when using a light bulb). This means that the colours found by openCV might no longer match the ones you programmed in so you’ll also have to take the white balance into account.

The resulting data is then mapped into a 2-dimensional array which then can be fed to an Minimax AI solver. This solver will use a decision tree and you can define the amount of positions it needs to think ahead.

This process also takes advantage of alpha-beta pinning. It uses a binary tree to decide which option is the best, but as soon as it sees that one branch scores too low it will no long check that part of the tree.

All in all it’s a pretty performant bit of code: OpenCV can take the image, process it and spit out the results in about 50ms.

Everything is possible

AR/VR can do anything, but that makes you wonder why it is not everywhere yet.

There are quite a few reasons for this: first of all you need a business case. Companies won’t invest a lot of money into something that doesn’t have a return on investment. And even if there’s money to be made in it you still need customers. People actually have to want your product.


The key takeaways of Frederick around image processing are:

  • Everything is possible
  • Think before you act
  • Just do it

You can rewatch his talk on our channel on Youtube.

Testimonial TVH MyAssetPlanner by Tom Verelst

Tom Verelst

Tom spoke about the application MyAssetPlanner he has been working on at TVH.

TVH is a company which rents out equipment and can provide you with spare parts for a lot of tools and vehicles.


Tomorrowland is quite a big event and for setting up and tearing down they rent up to 160 machines (or “assets”). For every asset a contractor will need to schedule it to be available at a certain time, resulting in more than 300 phone calls which need to be handled by the asset planner.

TVH wanted to improve the customer experience and decided they were going to develop a new application to help with the planning of these assets: MyAssetPlanner was born.

First there was a design sprint by Clockwork in order to come up with a prototype and the most important business needs which needed to be implemented. This part took about two weeks.

After this prototype, TVH started with the implementation of the first version which was put into production two months later. This first version has currently been in use for four months including for the last iteration of Tomorrowland.

For development, the Spotify model was used which is focussed around:

  • autonomous squads
  • do it yourself

The architecture is driven by events and uses Kafka as a backbone allowing you to just consume what you need, the events in which you are interested.

The entire CI/CD pipeline is fully automated thanks to Spinnaker. This allows a developer to commit a feature which gets automatically deployed to an acceptance environment. As soon as the product owner approves the feature it will be rolled out to production.

The teams work with Scrum Agile, it was interesting to hear about how they handle the sprint review. After every sprint, different business stakeholders receive a scenario and one person of the team is present for assistance. All the stakeholders must go through the scenario themselves. This forces your stakeholders to work with the application instead of just watching a demo, resuling in a ton of valuable feedback.

What is next

For the moment there are a 17 customers using the tool. Very soon this will scale up to 5% of all TVH customers which amounts to 3.000. After that there will be a gradual ramp up towards 20.000 customers.

You can rewatch his talk on our YouTube channel.

Visualizing Mandelbrot fractals using Riff and Spring Cloud Function by Dieter Hubau

Dieter Hubau

Function as a Service

Pivotal Function Service (PFS) is a pretty new addition to the Pivotal landscape.

Riff, an open source project, is the base of PFS. The idea behind Riff is to easily create functions and move these to the cloud. Its name is derived from the guitar world as you can see here, the project lead is Mark Fisher.

Initially Zookeeper and Kafka were used to send messages between functions but this did mean a lot of extra overhead to set up.

Google found out about Riff and came to Pivotal with Knative which runs on Kubernetes. You can find its repository on GitHub.

Knative allowed Pivotal to remove a lot of the boilerplate needed to run with Kafka and Zookeeper.

Knative has four components:

  • Knative Serving: request/reply messages.
  • Knative Build: auto-detect your code and create the required containers and sidecars.
  • Knative Eventing: replaces Kafka and Zookeeper providing channels and subscriptions.
  • Fourth Knative block: makes it run really well on Google Cloud.


A new version was released a couple of weeks ago. Since this is a very fresh and new project, this did mean a lot of late nighters to migrate the code of the demo. Experimental projects like this do tend to make frequent API changes during their initial development phase as backwards compatibility is currently not (yet) a requirement.


One of the simplest mathematical functions which creates the most complex objects is the Mandelbrot set.

You can keep zooming in, resulting in more calculations the deeper you go. It also tends to create pretty graphics which is nice for a demo.

The code

For a 400 x 400 image we will send a request to the backend to calculate the result for every pixel.

This means that around 160.000 calls will be sent to do the calculation. It is not the most efficient way to do the calculation but this demo is about using functions and not about calculating a Mandelbrot really fast.

Riff uses containers to package your business logic. There are two kinds:

  • UserContainer: actual container contains the actual function
  • InitContainer: they run before your container. You can use these to instantiate a database.

For one function you need about 200MB of memory as it spins up a slimmed down Spring Boot in the backend. All in all it is still pretty performant. Dieter mentioned a talk of Dave Syer about performance in Spring which is very interesting to watch: link.

It was a nice talk showing what you can do with Riff but also a warning that it still is under development and using it might have you encounter bugs. If that does happen do not hesitate to reach out to the Riff team. When working on his talk, Dieter also raised several issues.

You can rewatch his talk on our channel.

Testimonial: HZIV by Pieter Van Hees

Pieter Van Hees

Pieter is currently on a project at HZIV, a government health agency which offers its members legal health and disability insurance.

The old situation

A lot of old applications still run with the almighty Cobol.

10 years ago, HZIV wanted to rewrite these using Java 5 and Swing but that rewrite didn’t go so well. So they are still using these old beasts.

A new start

With more time comes more insight and it was decided to do a new rewrite and also to give the teams more freedom in how to set up their development environment and choosing the technologies that are best suited.

Chosen technologies are, most notably:

Currently the teams are working in an agile way, delivering fancy new features.

Working @ HZIV

What is great?

You have great freedom to choose and test out new stuff. At the same time the atmosphere is relaxed, allowing you to explore without pressure.

What is bad?

There is the risk of Developer Anarchy, where developers just introduce fancy new stuff without properly ironing out the edges.

Some managers like to micro-manage. The same managers also tend to introduce frequent scope changes which does not combine well.

Why should you want to work here?

Appearantly working at HZIV feels like being in a spy HQ. The combination of some old furniture and modern technology create a very particular atmosphere.

Very interesting to hear about an organization who has embraced a new way of working and is currently in the process of finding their way around it. To see what goes well and what does not.

It is also surprising that this can happen in a government agency as most of them in Belgium are not known to be very innovative.

You can rewatch his talk on our channel.

The 10 worst mistakes your Product Owner can make by Julia Müller

Julia Müller

A product owner

Is responsible for maximizing the value of the product and the work of the development team.

1. PO doesn’t know his/her product

Having no knowledge of your product is fatal, because you are responsible and accountable for the success of your product.

A good tip is that as a product owner you should be able to explain your product in 3 minutes.

Use a product canvas to help you understand your product.

2. Team doesn’t have a product

If a team does a lot of little tasks, it will miss context and will have to endure frequent scope changes.

This means that the team will have very little focus which is not very effective.

3. There is no vision for the product

It is bad when user stories describe solutions like: The user needs a button to be able to ... This causes the team to stop thinking about what would be the best possible solution. Do not forget that a team of people has more knowledge than one individual.

Scrum is developing towards a goal and is about autonomous teams. The vision which you as production owner provide must provide direction and guidance for the team.

A helpful tool is a “postcard from the future”.

4. The non-economic dreamer

Every feature adds complexity, increases the chance of failure, and makes future changes more expensive.

A product owner must be able to reason economically as every feature should add a clear benefit.

A product owner should also not hide behind ‘something’ the tech team does. As those ‘things’ also determine the cost and business value of your product.

5. Tech Debt not my Problem.

A good technical design is important for the success of your product. XX

For example: Investing in delivery speed might not add a direct business feature but will reduce development cost and allow you to provide new features faster in the future. Customer value is different to business value. An investment can also lead to business value.

6. The YES-sayer

If you always say ‘yes’ to every feature request then your product may become a Frankenstein monster.

It is better to discuss more upfront instead of implementing features you might need to remove later.

Wishful thinking

Don’t fall in the trap of wishful thinking. Do not just assume that your product will be a success.

Know how to validate your assumptions and make sure that you have a good feedback loop so that you know that the features you provided fulfil the business requirements.

Ignoring the facts

Ignoring the obvious signs that you are not going to meet your goal.

So many demos are made with Powerpoint, a real sprint review should be the user starting the application and using it themselves. If they get stuck you need to ask them why, as these situations will give you great feedback.

7. Obsessing over details

The product owner who used to be an analyst.

A huge backlog is not good, a good exercise is to take the top 50 and delete the rest.

In a huge backlog there is a lot ‘relevant’ information in the stories, however this information tends to become stale. Later on it will also become increasingly difficult to implement these stories as there is no certainty that the information they contain is still correct.

Another big no-no is having a ‘definition of done’ being more than one page long for a user story.

A nice concept is the three C’s:

  • Card (post it - fat pen): a story is just a single card. This is a reminder that we need to talk about this.
  • Criteria: Only Acceptance Criteria on the story.
  • Conversation: During refinement there will be a conversation with the team and then you will expand the story.

Also be careful not to be a perfectionist. No first release is going to be perfect. Being fast in the market beats having a complete product.

8. No presence, no communication

Communication is one of the most important factors of failure in an organization. A product owner must be with the team and not communicate from the sidelines.

9. Crossing competences

This is not a 13, but it is much smaller

If your team says it is a 13, it is a 13. They have the knowledge to estimate and implement a story.

10. Product owner is the only one filling the backlog

Let the team bring their own ideas to the backlog. This will help them focus and deliver a better solution.

Focus on what truly matters for your product.


The product owner has a lot of hats, how can he manage all this?

The product owner is indeed responsible for a lot of stuff.

But being responsible does not mean that you need to deliver everything yourself. Learn to delegate.

The product owner should also not be the only one who meets the stakeholders and not everybody should have to be a stakeholder. Learn to remove stakeholders who do not contribute to the business value. Remember the Frankenstein monster.

Can a product owner ignore stakeholders wishes?

A Product Owner should be able to take his own decisions and decide to run some tests on customers and collect the resulting data.

It is sometimes better to ask for forgiveness later.

If the product owner has no trust of the organization making him/her unable to take decisions, then that person should not be the product owner.

You can rewatch her talk on our channel.

Deep learning in practice by Remco Runge

Remco Runge

Machine learning: you try to get the good algorithm to find the stuff you want to find.

Deep Learning is based on biology, about how people thought the brain functioned. The assumption was proven wrong but the basic principles still work.

Tensorflow has a nice playground where you can see these effects live in action.

Deep learning has two flows:

  • Forward propagation: feed data through it.
  • Backward propagation: update weights so the next iteration will be better.

You can define weights on input in order to make certain inputs more important.

Deep learning requires a very large network with a large amount of nodes and a lot of hidden layers.

The early layers allow your network to distinguish basic structures within your data. Further down in the layers the network will learn more detailed features like; eyes, ears, …

It is cool that the network learns these features about how to recoginize a person just by providing it with pictures of faces. We did not provide it with the concept eyes but eventually, in one of the iterations the network started to take eyes into consideration.

Deep Learning at Ordina

Workshop: hack a drone.

A small drone was equiped with deep learning to detect and identify objects by using the Deep Learning for Java. In a short demo we saw it could identify a notebook.

Tic Tac Toe

In contrary to Go, Tic Tac Toe just has 360.000 possible moves making it easier to use for a demo.

The network for this demo learned by playing against some random opponents without any real strategy, this made it quite dumb. You could improve this by letting it play against itself.

Digital Railway Survey

The idea is to recognize signs next to the railway and verify if these have been installed at the correct place.

You Only Look Once is a very cool algorithm which gives you very nice bounded boxes around the objects on the images making it easier for your network to know where it needs to look and thus preventing you from processing unrelevant pictures.

It was also nice to see that with deep learning the system can distinguish signs from a passing train even when we would be unable to see these signs, let alone see what has been written on it.


How long does it take to get started?

If you work with existing data sets and known algorithms, 15 lines of code is enough.

Remco mentioned that for a brand new project it can easily take up to 55 days just to show that deep learning is possible for a specific business case. It takes a long time to gather the required data. You need to label it and make sure it is diverse enough so your model is not too focussed on one specific subset of input.

You can rewatch his talk on our channel.

Innovation without asking permission by Bart Blommaerts

Bart Blommaerts

Service decomposition

When you want to split up a monolith into smaller applications there are three patterns you can follow.

  • Split: define vertical functional boundaries. This does not happen to be possible in all old applications.
  • Strangle: extract and re-implement logic in new components.
  • Extend: new functionality in new microservices. Do pay attention to not create a distributed micro-**** fest, also known as a distributed monolith.

Generally you will not just use one pattern but all three.

Anti-corruption layer

The anti-corruption layer translates to and from different models. It allows you to enforce loose coupling between contexts.

You can use different patterns for it:

  • Shared repository: just share the same repository between various services.
  • Data-synchronized repository: each microservice has one database asynchronously synchronize the data.
  • Event-driven synchronised repository: the main idea behind events, do not wait for data to be asked but just publish it.

An event happened in the past and it contains three types of data:

  • Data it owns: this is data tied owned by the publisher in the event
  • Data it needs: this is data which can originate from other services but which is necessary to handle the event
  • Referenced Data: data which might be relevant for the event. For example when booking a holiday, the reference temperatures of the location to where you want to travel to.

The event should contain enough information so that consumers do not need to query for additional data. Otherwise you will not think properly about your bounded contexts and you will not be able to build a loosely coupled system.

In an ideal world you can talk with your business stakeholders about how these events should look like.

Bounded contexts

Bart indicated that it is very interesting to look at the DDD lite movie from Greg Young.

It may look complex and after watching it the first time you might decide that you don’t ever want to do Domain-Driven Design, but make sure to watch it a second time and things will definitely become more clear. ;-)

Identify the domain

Where does your microservice start?

Identify domains and subdomains. These subdomains tend to correspond with your bounded contexts.


Look at the data model:

  • Talk to business stakeholders. Make the list of subdomains explicit.
  • Look at the data.
  • Look at the code, both existing and historically. If two files always get committed together, they most likely belong to the same bounded context.

Integration patterns

Between bounded contexts there can be lots of integration patterns. A great source of information about these patterns can be found on the site of Gregor Hohpe: Enterprise Integration Patterns.


The previous concepts were then shown in a short live demo providing a real implementation.

What was interesting to see was that Apache Avro was used as a schema for the events. This shared schema repository is then the only coupling between your services. Using a schema allows your consumer services to see if they can process an event or not.


There exist a lot of API guidelines which you can use as baseline for your own, for example: Paypal, Zalando, …

This talk is not about API design but when you design an API please keep Postel’s law in the back of your head. Postel’s Law: Be conservative in what you do, be liberal in what you accept from others.

Do make sure that you have documented your API using: Swagger, Avro, HAL, RAML.

Without asking permission?

Continuous experimentation is the first thing to introduce. You should really try to introduce that culture. Microservices are small and thus can be easily thrown away.

Use feature toggles and monitor your users in order to gather user feedback about which business features are the most interesting for your stakeholders. With traffic routing you can make sure that only certain users get access to certain features allowing you to experiment with a very low risk.

Use this data, these metrics you gathered, to convince your business stakeholders.

Distributed systems

Are hard, see the eight fallacies of distributed computing.


See the hard nature of distributed systems as a way to introduce monitoring and logging (Grafana, Prometheus)

You can also provide this monitoring data to your users to give them more insights in the application, giving them direct feedback of their actions.

Which can give you new opportunities. For example: They will see failures and they will want this to be resolved.


Do not forget to take maintenance into consideration before adopting some new technology. Because you should not forget that you will still need to maintain it.

You can rewatch his talk on our channel.

You can find the slides of his talk on Slideshare.

Thanks Kevin

Kevin Van den Abeele Many thanks to our colleague Kevin for organizing the JOIN event. Without all of his work it would not have been as great as it was.

There is much more

This was just summary of some of the talks we had on JOIN, there were many more as you can see on YouTube.

Next Year

Hope to see you around next year. Keep an eye out for future updates on our JOIN site.

Tom is a Senior Developer at Ordina Belgium, passionate about all software related to data. As competence leader Big & Fast Data he guides his fellow developers through dark data swamps by giving workshops and presentations. Tom is passionate about learning new technologies and frameworks.

Tim is a principal Java Consultant at Ordina who is interested in security, cryptography and privacy. As Compentence Leader Application Security, he keeps his colleagues up to date on the latest security news and works to broaden their understanding by giving workshops and classes.