At devoxx12

At devoxx12
november 15, 2012 Fredrik Sandell


The first keynote was by Oracle. A couple of Oracle employees started of talking about some of the new features in java 8, most of which I think you are already familiar with. They also showed of a 3D view version of the JavaFX library that is due to be launched soon.

The second keynote speaker, Neil Ford from ThoughWorks, talked about something he referred to as geek leaks. A name for a phenomenon where solutions that are usually applied to one domain easily can be transfered onto another, essentially leaking through to another domain.

One of his most interesting point spawning from applying geek leaks was the insight that ”if something hurts, do it more often”. An example of when this should be applied was when merging code. Doing it often reduces the total pain of merging. He argued that this would be true for many programming tasks. An example of this was the TDD movement. Forcing yourself to run tests often meant they had to be automated to make it practically viable. Continually doing something encourages automation and the entire burden of that task is thereby reduced. Having automated tests allowed for the development of continuous integration and subsequently continuous delivery.

He also had a very witty definition of software architecture: All the stuff which are hard to change later. Which is a description that Kirk Knoernschild largely seem to agree with in his talk ”Architecture all the way down”.

Securing the client side, Mike West, Google

Mike argued that the foundation of a secure web application was HTTPS. Without it all other efforts of security was in vain. This statement was something that was repeated several times from different members of the Google team. Mike also argued that the use of the Least Privilege Principle (e.g. Linux file system) should be applied to web applications. To accomplish this the new HTTP header Content Security Policy(CSP) could be used. Among other things the CSP lets a site define which URI’s content may be fetched from, removing a large source of XSS problems. Mike also displayed the usage of advanced iframe(and html5 communication) features to compartmentalize JavaScript code within the browser. Doing so lets potentially insecure code run without compromising the end users data.

Home Automation OpenHAB, Kai Kreuzer, Thomas Echstädt-Engelen,

The OpenHAB project is an open source platform for home automation. It is architecture does however not support entire units, but it rather defines smaller subsets of devices which are denoted items. An example of such an item is an on/off toggle or a dimmer (0% to 100%). Each item has a state and a number of commands which can be applied to it. A device is then composed of several items grouped together. The OpenHAB is built on top of a OSGi container and currently have an entire DSL(implemented in XText) for writing rules that can instruct connected devices. The setup of the project was rather interesting with a OSGi container running on a RasberryPi controlling external units and in turn controlled from within another OSGi container running on normal server hardware. The presentation was however far from perfect and they spent more time trying to toggle a light bulb that explaining the implementation and lessons learned.

Vert.x, Tim Fox, VMWare

After some wandering between presentations i found a presentation about Vert.x. I’m glad I did, because Vert.x seems to be a fresh take on web development. An application is divided into so called Verticles. A verticle is simply a module within the application. Tim compared the a verticles internal structure to that of the Event Loop used within nodejs. i.e. a nonblocking single threaded loop handling all calls. The comparison was not perfect however since Vert.x allowed Worker Verticles to be spawn to handle long running processes. In effect Vert.x uses what Tim called a Hybrid threading model.

Verticles within an application communicate with each other in a way very similar to that if Erlang. Simply enter a global unique id and fire away a message to anyone listening. Several options such as point-to-point or publish-subscriber patterns exist. Heres the punchline: A verticle can be in any supported Vert.x language. Java, JavaScript, Python, Groovy and Ruby currently. They are working on Scala and Clojure support. Messages passed between verticles can be serialized using any method, but it was currently customary to use JSON.

Since vericles can be written in any language it means that a server written in Java can seamlessly communicate with JavaScript running in a users browser. To accomplish this the ”vert.x client” in JavaScript uses the SockJS library which uses Socket.IO when available but resorts to other methods the browser lacks html5 support. What vert.x does is to apply an actor model like that of Scalas Akka or the Erlang to the web-domain. In my opinion this is the right way to go. No more server/client AJAX boilerplate! I think the principle is sound, but I am by no means certain that vert.x is the vehicle by which this technique will delivered. Time will tell.

Architecture all the way down, Kirk Knoernschild

This was another great presentation. Kirk seemed to agree with Neil Ford about the role of architecture in software development. Architecture is put in place to facilitate change, which according to Kirk also meant in was in itself hard to change at a later date. Therefore he advocated that big architecture decisions in a project should be made as late as possible to allow the maximal amount of information to be accumulated. Quite the opposite of the normal approach in which architecture decisions are takes as early as possible to simplify smaller design decisions later.

Kirk also argued that limiting complexity within a software system was one of the essential roles of architecture. This should be done by adding flexibility in the system where is was likely to change in the future. But also by not adding flexibility to the system where it was unlikely to change since flexibility in it self adds complexity.

To accomplish flexibility without adding too much complexity it was essential to modularize the system all the way down to the individual classes. Hence the title of the presentation. To modularize Java systems meant not only considering dependencies between classes, but also between packages and modules (e.g. OSGi). Flexibility in the system should therefore exists in the connections between different packages and modules, not within a module itself. Kirks goal with architecture was elegantly summed up as ”Minimize impact and cost of change”.

Effective Scala, Josh Suereth

Josh is currently responsible for the next release of Scala and seemed to know all there was to know about the language. I must however admit that I don’t and most of the presentation was beyond my understanding. What I did understand was the fundamental difference between statements in Scala and Java. Java is declarative, basically telling the machine what to do step by step, while Scala is expressive. Telling the machine what needs to be done, but not how to do it. The use of ”for”(very different from Javas for) statements to control execution flow within a program reminded me of Haskell courses I had during my first year in Chalmers.

Another thing that I grasped is that Scala has native support for something similar to Maybe objects in Haskell. It wraps an object in a container which forces the user of the data to unwrap it, and in doing so implicitly checking for null. According to Josh this rather simple feature prevented the majority of null pointer exceptions from ever occurring.

Josh talked about a bunch of other stuff, but nothing that I feel comfortable relaying without running the risk of corrupting the message due to lack of background knowledge.


The keynote on Thursday was by Google. A couple of guys talked about many different things related to Google projects. Among the things they mentioned was a cool new feature introduced in Android 4.2 called photosphere, which allowed you to take panorama images with any android 4.2 device. They also talked about some new features in the Android development environment, nothing major as far as I could tell. Apparently the Google app engine now also has integration with maven and Jenkins. Code is pulled directly from a git repository and processed by Jenkins in the app engine.

Some Chrome developers also showcased new hardware support in chrome, e.i. access to web cam and microphone directly through JavaScript. The also mentioned that in the very near future support for css shaders will be added to chrome.

Effective Dependency Injection, Jerome Dochez & Nicholas Behrens, Google

A great presentation about lessons learn when developing DI applications at Google. They essentially talked about do-s and don’t-s when writing DI.

* The first thing they mentioned was to be explicit when binding objects. All sorts of problems comes from using implicit binding functionality.

* Prefer constructor injection, this allows private final on the fields. Immutability is king.

* Don’t do work in the constructor, have a separate create method for that. Exceptions thrown from a constructor can be hard to handle when building the object graph.

* Avoid dependency on injector. I.e. don’t pass a reference to Guice or spring bean factory!

*Don’t bind to general types, e.g. Integer. It is ambiguous and easy to confuse at a later date.

* Use Null object pattern (which to me seems like more of a general guideline.)

* Don’t use context objects! The a very, vary hard to handle and makes the code unpredictable since their state is often unknown/hard to determine when they are passed to methods in real application.

Jerome and Nicholas also argued that DI can be used to increase modularity, in a way consistent with what Kirk described in his talk “Architecture all the way down”. In contrast to Kirk, Jerome and Nicholas did not seem to see OSGi as good general tool for achieving modularity. Due to the complexity introduced with OSGi they argued that it is really only was two valid reasons to use it: Runtime extensibility and Runtime versioning. For all other reasons the cost of the complexity outweigh the benefits.

To achieve modularity they advocated only exposing interfaces from a package and keeping all the implementation classes package private. One implementation class still needed to be public to allow DI. The interfaces(API) and implementations should be places in a separate jars and the API jar is the only one that should be used for dependency resolution by other packages. This ensures decoupling of the API and implementation.

For Butter or Worse, Chet Haase & Romain Guy, Google

This was a presentation from two guys that have been working on Android 4.2. Both of them worked on the UI part of the operating system and their focus during this latest iteration of the system was to reduce ”jank”. Jank was what they called sudden drops in frame rate, more commonly known as lag. The reason for much of the unexplained jank in the old versions of android could be traced to that the update frequency of the display was not completely synchronized with the frame renderer in android. This sometimes caused rendering to ”spill over” into the next frame which effectively lowered the frame rate to half for a short period of time. Whats worse is that this increases the likelihood of the next frame also causing a jank. The simple(at least in theory) solution to this is to let the display frequency trigger the rendering process in the android system. That was pretty much it. Interesting problem but rather narrow for a full presentation. They also mentioned a bunch of tools which are great when profiling Android applications such as traceview and allocation tracker.

JavaScript unit tests & build integration, Wouter Groeneveld, Cegeka

Wouter presented a rather neat way of integrating JavaScript unit tests with the rest of your Java build system. He argued that to be able to really unit test JavaScript it needs to be properly separated from HTML and CSS. To organize the JavaScript code in modules also significantly helped when creating tests from JavaScript. The best way of ensuring this was simply to apply TDD to JavaScript development!

To do the actual unit testing Wouter used Jasmine which conveniently provide equals and assert methods for tests. Instead of using Selenium Wouter advocated the use of an ”artificial” DOM tree on which the test can operate.He proposed a couple of different techniques but seemed to settle on using PhantomJS for simulating the DOM. He then showed how to integrate this in maven and how to convert Jasmine reports to JUnit result XML’s readable by Jenkins. If a JavaScript failed during continuous integration Jenkins would complain! A in all a nice presentation on the state of JavaScript unit testing.


1 Kommentar

  1. Peter 6 år sedan

    Interesting topics and a great review!

Lämna ett svar

E-postadressen publiceras inte. Obligatoriska fält är märkta *


Denna webbplats använder Akismet för att minska skräppost. Lär dig hur din kommentardata bearbetas.