Thursday, 5 November 2015

J-Fall 2015

“Once you stop learning, you start dying.”
- Albert Einstein

I just got back from J-Fall 20151.

Seeing as the location had been changed from Nijkerk to Ede, I was unable to attend the Early Bird sessions, much to my dismay. I did manage to hitch a ride with a colleague of mine, but in the future, I will try and get a train. The connection seems to be quite good and once more there is a shuttle bus riding between the location (Cinemec) and the trainstation.

What with traffic (congestion) and my colleague sleeping late, I did miss the first keynote (The Experimental Enterprise - Keynote ING), only arriving at the destination at around 09:45.

The list of sessions I witnessed:

Pushing the limits of Continuous Delivery - Keynote Quintor

Provided by Rene Boere and Pascal Snippen

A fascinating view on what Quintor uses to provide Continuous Delivery (CD) using Docker, Apache Mesos, Marathon and Consul combined with HAProxy. The use of container ships to emphasise Docker was inspired and probably is starting to be overused by now. The microservices landscape is large and you can no longer see the forest for the trees, test environments are hard to set up, deployments are complex and timeconsuming.

Automation of Continuous Delivery is the answer.

Microservices for Mortals

Provided by Bert Ertman

This lecture could be construed as a big, huge, warning if you wish to use Microservices. It had a metaphore comparing coding practices with Italian food. The old way of coding compares to Spaghetti. Then SOA (Service Oriented Architecture) was introduced and those layered coding practices compare to Lasagna. Now the new Microservices compare more to Ravioli (tight independent containers of code bundled together) with sauce. The main idea behind microservices seems to be the ability to easy adapt to change. There is no hard definition on what microservices are. Apparently, microservices are small enough to just replace them with a completely new implementation, or just run 10 instances of one easily. They do away with a lot of items we are software developers have gotten used to:
  • synchronous programming models
  • ACID
  • code reuse
  • using abstractions
Instead, because of the characteristics of Microservices, you get:
  • asynchronous programming models
  • any constraints need to be taken care of at the application level
  • code duplication, each micro service is independent of the others, so code reuse between microservices doesn't make sense
  • separate data storages (one data storage per microservice)
  • passing data using websockets or binary protocols or messaging (REST is too much overhead, I don't want to even mention XML. It's all fine for a public API though.)
  • prefer conventions over abstractions (see code reuse)
If you have not been doing Devops, you cannot get started using Microservices without getting into a world of hurt.

Code for failure. Microservices are brittle, the distributed asynchronous models make them so. Design for this! Use fail early, use resilience patterns, use redundancy, etc.

10 Awesome Tips for Enterprise Javascript - Oracle

Provided by Geertjan Wielenga

This lecture provided an excellent overview of the current JavaScript landscape. I especially liked the fact that he mentioned that at the end of the lecture the landscape will probably already have changed. The JavaScript ecosystem is in that much flux.

Nowadays we have multiple devices, all with different screensizes requiring responsive design. One common factor in all these devices, is that all of them possess a browser. And the Single Page Application (SPA) is becoming the internet-enabled "application" of choice. Page navigation is irrelevant when it comes to Single Page Applications, yet for most Java-based Web Frameworks, page navigation is still an important part of their programming model.

Also, resist the hype. Apparently most managers make bad architecture decision based on hype. And you, as a developer, shouldn't want that.

For some applications, Javascript actually doesn't make any sense. The example provided was air traffic controllers. But different architectures can play different roles, even in those applications where Javascript doesn't make any sense. for example:
mobile apps
notifications
web apps
reporting to (upper) management
application itself
what users actually need and use in day-to-day work

NetBeans provided really nice point-and-click programming of the new HTML 5 components. The new HTML 5 components look very snazzy. Apparently, every new HTML 5 component is itself composed of sub-html-components, called the Shadow DOM and can therefore be styled appropriately. CSS has been split up into approximately 50 CSS modules. JavaScript can be used to avoid having to hide HTML using CSS, because hiding certain HTML components still makes the browser get the linked resources contained in those HTML components. Especially on mobiles this can make a huge difference.

In the Java world, the acronym WORA (Write Once Run Anywhere) is very well known. In the JavaScript world its WONTA (Write Once, Never Touch Again). The projects are so small, and the evolution of the Javascript ecosystem is so quick, it makes more sense to re-design and re-write everything from scratch when required.

Oracle has defined a Javascript framework, which is basically a bundling of common javascript libraries, into what is called the "Oracle Javascript Extention Toolkit"2.

“Javascript is the assembly language of the web.”

Then there's, if you really do not want to touch JavaScript with a ten-foot pole, the transpilers:
Dukescript
write Java, but also HTML and CSS. Combine those.
GWT/Vaadin
provides a Java backend similar to the Swing toolkit, and translates your code into HTML,CSS and JavaScript for the frontend.
Dart
separate programming language for the web/mobile/desktop.
Typescript
provides static typing to javascript, a sort of superset of JavaScript following ECMA recommendations that is transpiled to JavaScript
Coffeescript
programming language that translates to javascript

The Java renaissance continues - Keynote Oracle

Provided by Sharat Chander

A motivating speech on the fact that Java is still a success primarily because of the community. And a personal appeal to every person there to connect to at least two in the audience during the conference.

Devops - Are you walking or still talking? - Keynote Capgemini

Provided by Remko Reinders

A lecture on Devops, more importantly, what it takes for an organisation to become a success at Devops and what you can do to help your organisation and yourself to become a success as well.

“Most people will talk the talk. Few will walk the walk. Be amongst those few.”
- Steve Maraboli

“Software is eating up the world.”
- Marc Andreessen, Wall Street Journal

Building Asynchronous and Non-Blocking HTTP Applications with Ratpack

Provided by Hubert Klein Ikkink

My first introduction to Ratpack3, which I had never heard of before. It is a small webserver, that can be programmed using Java 8 and Groovy. It uses Netty for the HTTP IO, has a very small footprint, is very fast and is asynchronous. Does not provide JEE, does not follow the Servlet API and can be started by running a Jar file. Spock is used for testing.

If you want a quick webserver to dish out some REST stuff in a distributed environment, this is it. Check his webblog4 for more information.

Java modularity, life after Java 9 - Luminis

Provided by Sander Mak & Paul Bakker

“Good fences make good neighbours.”
- Proverb

An excellent talk about the upcoming Jigsaw in Java 9. It provides a faster startup and a smaller footprint, essential for small devices. It compared what little information there is about Jigsaw to the existing implementation of OSGI. Modules are allowed to talk to other modules only by the service contract each module provides. Modules are defined in a module-info.java file. The segregation is looked after by the VM itself and cannot be circumvented. Layers are used to prevent different versions of the same module interfering with each other. Versioning isn't really built into the new system. There is a linking tool called jlink and module maker tool called jmod. Jdebs can provide your program with which modules it needs. Identification of a module is done using a newly defined namespace specific for modules.

Classpath scanning for annotations is going to be a problem. It is going to have to be service-oriented in the future.

Especially application servers are going to need a major overhaul, as well as several annotation-crosscutting concerns frameworks as REST and JPA implementations.

See http://bit.ly/java9demo for more information.

References

[1] NLJUG - J-Fall 2015
http://www.nljug.org/jfall/2015/
[2] Oracle JavaScript Extention Toolkit
http://oraclejet.org
[3] Ratpack
https://ratpack.io/
[4] Mr Haki's Webblog
http://mrhaki.blogspot.nl/



No comments:

Post a Comment