Tuesday 13 November 2018

Devoxx 2018 - Deep Dive - Day One

Just writing down the sessions I followed, and some notes regarding the sessions.

Implementing Microservices with Jakarta EE and MicroProfile

The one point of issue that I had with the talk, is that it decided to tackle two issues. The talk was regarding JakartaEE and how to get about moving JavaEE over to Open Source, and what it takes. The talk was also about Eclipse MicroProfile. For me as a novice it is very hard afterwards to separate the characteristics of the two. I'm likely to mix it up.

It might have been better, if possible, to split the two items up into two talks.

JakartaEE

What I heard was that they are attempting to have an Eclipse Glassfish 5.1 version available on December 15th of this year, build from Open Source JavaEE specification 8.

There is already a staggering amount of building taking place of the different components in JakartaEE, see the EE4J CI/CD Progress2.

They're looking into getting JCP Standards Process replaced by "Something Else" called "Specification Process 1.0", because obviously they need some sort of process in place for JakartaEE. Hopefully without any of the problems that made JCP too slow.

The JNoSQL project is the guinea pig for the new Process.

They have TCK - test cases suites - to determine if application servers follow the specs.

Code First Mentality is what seems to work. Like Hibernate and Spring prove that something works very well, then standardize it and include it in Jakarta EE.

JakartaEE is apparently moving away from reference implementations.

It's going to be Community driven.

Eclipse MicroProfile

The project started as a way to easily move forward with JavaEE, without waiting for standards to catch up and to see what is possible. To get something quickly, the things implemented first was CDI+JAXRS+JSONP, in order to get some microservices running.

So we are already familiar with the Full Profile and the Web Profile regarding Application Servers. The MicroProfile is kind of like that, but without the whole application server behind it.

It's for quick progress and less about standards. The speed is quite impressive, 7 major releases in 2 years of existence. Features based on the "the honour system". If you say that it works, and that you've tested it, that's good enough.

This in stark contrast with Jakarta EE, a (future) standard with 1-2 major releases per year.

He did mention a cool article1 about what MicroProfile is bringing to JakartaEE.

Microservices

Now I am a novice when it comes to using microservices, how, when, where, etc.

Some interesting examples on how microservices are implemented:

Netflix
is running hundred and hundreds of microservices.
another company
could get by without with only 20 microservices that by definition might be a little more bulky.
third company

A good example of the use of microservices, is a company in Prague that computed hashes for passwords for people logging in. Apparently there were peaks in the system, for example when a new feature was announced, and people wanted to check what it did. It causes peaks, so the simple microservice for computing password hashes was deployed on every machine imaginable across all the branches of the company.

It's an excellent example of a very simple microservice that is computation intensive, without a lot of state required.

Java Streams vs. Reactive Streams: Which, When, How, and Why?

Venkat Subramaniam is a great speaker, and this was the first time I encountered him. The talk was amazing about the difference and common ground about the two. But also why you should use it, and when. Highly recommended.

Functional Exception Handling in Java with Vavr

A short talk but insightful. It basically boils down to using a Tuple to indicate success (the result value) or an error (the exception value) as a good work around of the fact that we cannot throw exceptions in lambdas.

Seems to be like the pattern used by Optional.

A Dozen Ways to Hack Your Brain to Write Fluently

It boils down to write a little bit, as soon as possible, and build it out from there.

There was a lot mroe to it than that, but I did not manage to follow the entire talk.

Exploring Java Heap Dumps

It was great. Apparently the Netbeans Java Profiler provides an API that makes it possible to drill down into the heap dumps you get to find out what the problem is. This way you can actually write a software application specifically for your problem and your application and attuned to your data model.

It can analyse the heap dump for you, but the javadoc specifically states for all functions in the API whether it can complete in normal time, or that the method you are using may require a long time (because it needs to access the entire heap dump).

It was actually not that big of an API. Apparently it is just a single package directory in the Netbeans Profiler source.

References

[1] How The MicroProfile Community Will Shape Jakarta EE
https://www.lightbend.com/blog/how-the-microprofile-community-will-shape-jakarta-ee
[2] JakartaEE CI/CD
https://ci.eclipse.org/
Getafix: How Facebook tools learn to fix bugs automatically
https://code.fb.com/developer-tools/getafix-how-facebook-tools-learn-to-fix-bugs-automatically/

No comments:

Post a Comment