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
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.
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.
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.