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.
Talks & Workshops
- Frederick Bousson: Unbeatable at Connect 4 with Wearables and Computer Vision
- Tom Verelst: Testimonial TVH MyAssetPlanner
- Dieter Hubau: Visualizing Mandelbrot fractals using Riff and Spring Cloud Function
- Pieter Van Hees: Testimonial HZIV
- Julia Müller: The 10 worst mistakes your product owner can make
- Remco Runge: Deep learning in practice
- Bart Blommaerts: Innovation without asking permission
Unbeatable at Connect 4 with Wearables and Computer Vision by 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.
Takeaway
The key takeaways of Frederick around image processing are:
- Everything is possible
- Think before you act
- Just do it
Testimonial TVH MyAssetPlanner by 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.
MyAssetPlanner
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
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.
Riff
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.
Mandelbrot
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.
Testimonial: HZIV by 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.
The 10 worst mistakes your Product Owner can make by 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.
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.
Questions
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.
Deep learning in practice by 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.
Questions
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.
Innovation without asking permission by 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.
How?
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.
Demo
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.
APIs
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.
Monitoring
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.
Maintenance
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 find the slides of his talk on Slideshare.
Thanks Kevin
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.
