Once again the EclipseCon Europe was (for its tenth edition) a big success. There are many reasons to attend the ECE.. First you can meet great people: the developers of your favourite tool, reknown experts, and other users like you, who have similar problems. Second it's a gold mine of technology updates, to discover new tools that will just make your like easier from now on, or learn to better use your existing toolset. In this blog entry I will list some of the talks I have attended, with links and comments.
The Software Engineering Research Group at TU Delft developped a program (TestRoots) and an associated Eclipse plugin (WatchDog) to analyse the behaviour of developers regarding testing. By measuring the time passed on production and test code, time of JUnit execution and results, and many other characteristics, they could produce a bunch of interesting facts and lay down a landscape of testing habits. Conclusions are not what you could imagine.. Here are a few numbers/facts:
This is a collection of tips to enhance your testing skills. Definitely worth a read, either to be a better and more efficient tester when you are fresh and sharp, or at least to take better advantage of these times when the head is so full that you don't even remember on what scenario you were working on. Here are a few of these secret shaolin techniques:
The Workshop on Life-cycle Interoperability – OSLC In Practice was a really cool meeting with various kind of people involved in OSLC: developers, users, and writers of the specification. Various issues were discussed, from reference implementation (which are open-source) to the evolution of platforms running OSLC and the dead link problem (when resources vanish).
OSLC (for Open Services for Lifecycle Collaboration) is a standardised, public REST specification that describes a set of common fonctions for all tools involved in the Application Lifecycle Management. Process areas defined include architecture management, requirements management, asset management, reporting, change and configuration management, quality management, and performance.
One aspect of the OSLC philosophy is to propose links between the various artefacts of the ALM. These links need to be weak (in order to not overload the information database) and the coupling must be lose (to match any tool capability). Which means that for some cases (e.g. to use specific tool features, or really tight integrations between tools) a firm link should be created, if the information is not available in the OSLC specification.
Also, because the set of feature has to be common to all tools, the specification covers only a subset of quite basic features, and is losely defined to not interfere with the various implementations. A set of reference implementation is provided for many languages, and some help would be appreciated to work on a reference test suite.
The standard is spreading in the ALM tooling world, and the various working groups have delivered most of the process areas.
Tycho is a build tool that makes Maven understand how to build Eclipse plugins. Most Eclipse projects use it to build their product, but it has a few drawbacks (nobody is perfect, hey). One of them is the need to maintain several pom's in the various sub-modules (plugins and features) of the project, including a potentially huge list of dependencies, which is redundant with the OSGi manifest file.
So there was a big crowd attending the POM-less Tycho builds talk, presented by Jan Sievers. The idea developed by the developers of Tycho is to reuse as much as possible the parent pom.xml information wherever it can be inherited in the sub-poms, and parse the OSGi metadata to complete the needed information model. In some cases however, one may want to have a specific sub-pom for a module. The proposed feature will in that case use the pom.xml of the sub-project if it exists.
The 0.24 version of Tycho, including this much-awaited feature, has been made available in November. Note that the functionality needs Maven 3.3 or better to run.
There is a growing interest for visualisation of software -- may it be for code metrics, dependency analysis, project activity (e.g. the eclipse dashboard) or most used languages (see e.g. githut.info). From a practical perspective, software visualisation is a very useful way to analyse and understand a code base.
Stefan Rinderle has developped a tool named Code City to visualise various metrics in a 3-dimensional plot. Each package is pictured as a box in a town-map fashion, and the height of the buildings is determined by the metric's value. The tool has been integrated in the SonarQube platform as a plugin, using WebGL to render the map -- which can be swapped right and left, zoomed in, and much more. Here is a (static) example: (click on the image for a bigger view)