Microservices, Laziness and Self-driving cars

It’s not every day you get to go on a conference so it was a real boost to go to Devoxx in London. You may think that all the information you get at conferences is already available for free online. Why pay a lot of money for travel, hotel and conference ticket? For me it is obviously the inspiration and sense of community when an entire aula sighs in agreement when a problem that all have faced is addressed.

Oracle and Java

Initially, Mark Reynolds from Oracle spoke about Java releases and what major changes have occurred since JDK9. It feels as we have just begun to use JDK 8, but now 9, 10 and 11 (beta) are out. There is no time to rest.

The biggest difference is that Oracle cleaned up classes and methods that are rarely used. They have simply downloaded the code that people posted on GitHub and checked! They have cleaned up among the internal dependencies, some parts like JavaEE have been completely separated from java core and they have organized the classes into modules. Modules were generally a term that came back many times in different contexts.

Micro-services and Laziness

A recurring buzz word was “micro-services”. In short it means that applications are built up by several independent smaller components, each of which only has a simple task in life. By calling and combining different microservices, you put together your application. The idea is appealing. Maybe it’s just simple components that answer a rest call, maybe they’re tied together differently? Many speakers put this “technology” in opposition to “monolithic” architecture. Most of our applications are just monoliths, i.e. they handle everything from retrieval, processing, and further transportation of data.

This is nothing new to us – we have talked modules for several years. Now it’s time to see how we can implement that thought. As a speaker so figuratively described … Adapt or Die!

Two of the most frequent concepts raised was “Laziness” and “pure-coding”. In practice, it’s about coding nicely – use streams that come with JDK 8,9, 10 etc., but to do it right. Do not call code unless needed! Sounds obvious, but it also means, for example, being able to write “passive” features in Lambda that are triggered only if it really is needed.

Speaking of Laziness … I have recently switched from Eclipse to IntelliJ, which seems to be the idea that applies to trend-sensitive developers nowadays. No matter what you use, there is always a built-in type-ahead support so the editor takes care of all “overhead” code written for you. For example, if you create a new class, the editor adds getters and setters so you do not have to write so terribly much yourself. On the other hand, this can entail quite a lot of code which can make the code complicated and messy for a succeeding developer to understand.

But, if you program in Kotlin or Groovy, you’ll lose all of this extra code that Trisha Gee calls boilerplate code. Both of these languages ​​run on JVM and can coexist with regular Java.

You are also slightly affected by walking around in groups consisting of guys. You can say the smell of the halls degraded as the day progressed. But I was definitely not the only woman attending. So a hot tip – by the end of the day when the air begins to end … Sit next to a female participant. Chances are that it will be easier to breathe.

By the way, there was one session that was about women in the industry. Skipped that one, in favor for something more hard-core. Just for the sake of it

IT organization and self-driving cars

A couple of sessions were about how companies handled both application / architecture and organization to ensure their respective needs and requirements. Tesco had a very good session where they described how they restructured the entire (IT) organization, and coordinated their many different “monoliths” from different parts of the organization and broke them into micro services. Interesting how they set up pop-up teams to handle new projects. These were more or less autonomous groups who could decide on their own if they would write code with java, kotlin, scala or what-not. The main reason was that they delivered a service that received and returned what it was supposed to do.

Finally I ended the conference with a session far beyond my own skill-set. The session was “Build a self-driving car” with Tim van Eijndhoven. A fun project that started as a challenge for the employees at a software company. Reason was to make them become better programmers! The company was divided into four teams, and all they got was a model car kit + €150. To be honest, when the employees with such a life and desire went for this, I think the company regretted that they started this challenge. Not much else could have been done during this period.

If anyone is interested in knowing more from the conference, then I’ll tell you more.