Devoxx 2012 - Day 1

By Roland Huß |
Tags:

It’s time again: The ConSol gang is coming back to Antwerp. And again, we are presenting you our Devoxx impressions fresh from the movie theaters. As last year, two of use (Georgi and Roland) went ahead wereas the rest of us (Olaf, Kathrin, Christoph and Torsten) will join us on Wednesday.

Monday and Tuesday are traditionally the days for the University talks with in-depth coverage of certain topics.

Modular Architecture Today by Kirk Knoernschild (roland)

Kirk started with in a detailed introduction, why modularity matters. A module system provides a runtime environment for modules. In Java, the unit of modularity is the JAR File.

When designing apps, two competing forces: Flexibility and Complexity. The more flexible a system is, ther more complex it become. Although modularity adds to this complexity it helps in maintance over time, which traditionally gets harder and harder otherwise.

Since Kirk is known for his excellent book Modularity Pattern (highly recommended!), he briefly describes five different categories of modularity pattern, describing some of them. Unfortunately he walked very quick through this list.

He emphasises that it is not only important to think not only about class design, but also about package and, even more module design, since modularity increases architectural agility.

To summarize the first part before the break, Kirk does quite some evangelizing in order to make modularisation an essential part of every enterprise architecture. He is also emphasize the possibility, that with a rigorous module system, a very high level of flexibility can be reached. But frankly, is this extreme level of flexibility is really required in reality ? How often do you exchange the persistence layer of an existing application ? And if the answer is ’never in my career’, are you still willing to pay the price of this extreme flexibility ?

From my experience when we tried to build an enterprise application purely based on OSGi modules one year ago (resulting in 60+ bundles), we ended up switching back to plain WAR deployment (but still keeping modularity on the build level via Maven modules). Why ? There are two reasons: First, many dependent libraries like mail.jar or activation.jar don’t play well in the OSGi world, because of the way how they look up other classes (we ended up to patch them all). Next, release management was quite a disaster: How to deploy 60 bundles as a single release ? Nowadays, Aries and friends could probably help, but I don’t know. Unfortunately there was no discussion about this installation hell. I think there is an answer outside for this essential problem.

Also, what I really missed, was mentioning that there is intrinsic module support by certain build systems. All examples where done with ant and handmade target and setup of the classpath. But yes, you might hate it, but there is something like Maven (or even Gradle). Having maven for modelling modules declaratively is not only ‘syntactic sugar’ but it helps enormously in setting up IDEs properly in order to avoid ‘accidental code completion’ violating conceptual module boundaries as it happens when not using modules at all. Custom ant builds can’t provide this help. Even if you don’t use a modular runtime system, using a build system supporting modularity during compile time is a good thing.

Then Kirk shows examples how to modularize a monolithic sample application step-by-step into a modular application. First everything is deployed in a single WAR file, including classes with bidirectional relationships. Then, step by step and with the help of abstractions he modularizes this war into multiple, hierarchical dependent modules/jars.

After the break, in the second part of the talk Kirk introduces OSGi as a runtime platform for running modules directly instead of being packaged in an all-in-one war.

The second part was not much more than a basic introduction into OSGi with uServices and OSGi Blueprint. A lot of repetitions here, leaving somewhat the impression that Kirk was runing out content near the end of the talk.

All in all, the talk was very well presented by giving a basic introduction into modularity and OSGi. I hoped to hear a bit more about concrete patterns as described in his book, but well. Nevertheless it was good start into this week.

My main takeway, which I have put in my ammunition dump:

Conceptual modularity without physical modularity is nearly always
flawed because of subtle dependencies creeping in inevitably over
time.

NoSQLUnit. Testing your NoSQL databases by Alex Soto Bueno (roland)

NoSQLUnit is a test framework for testing NoSQL databases. Unit Test should follow the FIRST principles (Fast, Isolated, Repeatable, Self-Validated, Timely). Isolation is most often not possible, when testing with database. For relational databases there already exist various solutions, for NoSQL database NoSQLUnit was invented.

NoSQLUnit consists of two Junit Rules and two annotations:

  • @UsingDataSet for seeding contents
  • @ShouldMatchDataSet for verifying contents

NoSQLUnit supports redis, mongoDB, Neo4j, Cassandra and HBase. For each DB there exist two or more JUnit rules.

Two demos demonstrate how easy it is to write a unit test, in this case for Redis and Neo4J. NoSQLUnit has also support for Spring Data.

Finally NoSQL is also usable for testing DBs provided as PaaS in various clouds. In a demo it is shown, how a MongoDB in OpenShift is easily accessed from within NoSQLUnit.

For the future, more databases will be supported and integration into more build systems and testing frameworks.

The talks was very well structured and despite having only 30 minutes, Alex managed to give a very good introduction in writing tests for NoSQL databases.

Beside that I didn’t know NoSQLUnit (which was obvious why I attended this talk ;-), JUnit Rules themselves where also new for me. Time to revisit JUnit again, after doing tests exclusively with TestNG for quite some time.

Weld-OSGi in action by Mathieu Acnelin and Matthieu Clochard (roland)

After a short introduction to CDI and OSGi, Weld-OSGi was introduced. It provides a CDI programming model for OSGi, hiding all the nifty details of OSGi service handling. This is done by exposing CDI beans as OSGi services.

Weld-OSGi is implemented as an CDI extension and provides a handful of new annotations: @Publish tells the CDI container to register an OSGi service. Services can also be registered programmatically. The consumer of an OSGi services uses @OSGiService for getting to the service. This annotation is evaluated only during startup. In order to get all services during runtime, a list of services can be injected. Also @Filter can be used with an OSGi filter in order to get a specific implementation. Alternatively, this can be nicely done with CDI qualifiers which gets translated to OSGi filters for the publisher as well as for the consumer.

OSGi events can be observed with the CDI @Observes annotation. Events can be filtered with @BundleName or @BundleVersion. Service Events can be observed as well and restricted with @Specification and/or @Filter.

“Inter-bundle events” is a Weld-OSGi specific feature for broadcasting events among multiple bundles. Listeners for events use the @Observer CDI annotation for registering for certain InterBundleEvents.

The demo was very well crafted demonstrating all features with a nice demo app (and someone finally was not stating um, you see, I’m not a Web designer .. when presenting his web based demo. Thank you, Bootstrap ;-)

Weld-OSGi looks quite similar to Spring Dynamic Modules, with Spring injection replaced by CDI. However, as the programming model of CDI is very elegant, Weld-OSGi fits very nicely into this space with its own annotations. Very well done, Weld-OSGi will definitely in my toolbox for my next OSGi based project.

CRaSH an extensible command line for the JVM by Julian Viet and Alain Defrance (roland)

CRaSH is a CLI shell framework. It has a similar client interface like a Unix shell (history, completion, command line editing, pipes, …), but is hosted by a JVM instead of the OS.

CRaSH can be emmbedded or can be run out of the box. It can even run in a browser or attach to an existing process.

The demo was very impressive. I.e. you can connect to a running JBoss (or supposedly any other JEE server), examine the deployed datasource and connect to the DB via these datasources directly. So, no need for an external SQL client anymore for examing and manipulating the database on production systems !

JPA can be examined as well, and JPA queries can be executed from within the Shell.

Next, it was shown how to embedd the shell in own applications. This will open a telnet port which can be used for a remote shell. (However, I wonder how this communication can be secured beside user and password transported as plain text, SSH should probably also possible).

For monitoring purposes, a VisualVM plugin exists. This plugins opens the shell within VisualVM, which can use some quite simple JMX related commands. JMX commands can be chained in pipelines. What I’m missing here a bit is a help in navigating the JMX namespace as j4psh does.

Version 1.2 will offer a dashboard with custom defined commands with Groovy. Cool demo !

To summarize, this quite packed session was really impressive. Since up to now I sticked to something different than Java when writing a shell (j4psh or osgish). Now I’m currently seriously considering CRaSH for an Java based implementation, especially because I hope to be able to embedd it into a single jar file which is a huge advantage compared to the installation marathon when it comes to Perl modules.

HTML5 and JavaScript Web Apps by Wesley Hales (Georgi)

It is my first Devoxx and i was and i am still pretty exited about it. There were a lot of talks today, some of them were really good. And i have to say, that i do not regret my decision to attend not just the conference but also the Devoxx university days. The first talk I want to talk about was about the new black, HTML5.

This talk was about mobile web development with HTML5 and JavaScript. O’Reilly has shortly released a new book about HTML5 by Wesley Hales. In this talk he has introduced the new important ‘mobile’ features in HTML5 and has tried to pass on his experience with UI mobile development. The interest on the topic was quite big and the room was really full. Fortunately we have got some seats and didn’t need to spend the next three hours seating on the stairs :)

Part 1 - The web browser is the platform!

The first part of the talk was about the importance of the web apps for mobile devices and about the mobile browser. Wesley has tried to point out what have to be taken in consideration when starting developing a mobile web app. Here are some of the points:

  • mobile first = offline first - web apps should also be available offline
  • different hardware - some of the html5 features are supported only on newer devices
  • whole bunch of web browsers which should be supported
    • webkit (mobile safari, default android browser, chrome etc.)
    • firefox mobile
    • opera mobile
    • ie mobile
  • browser compatibility with older versions
  • worry about battery life when writing css

HTML5 and W3C APIs have been introduced

  • Geolocation
  • WebSocket
  • Web Storage
  • Device Orientation
  • Web Workers

‘One billion html5 capable mobiles will be sold in 2013’. And with all this new ‘mobile’ features introduced within html5 you could develop web apps which are competitive with native apps.

Wesley has demonstrated slidfast.js, which is a learning framework created for his book. This example shows that page transition (in particular sliding) on the mobile device implemented with css and javascripts feels almost like native sliding. For the fast sliding the CSS3 accelerator has been used. The 360 degree flip on the contact page of the test app has been implemented only with css. You can test it on your own :)

‘mobile web is not write once run anywhere’ - i don’t think that a web developer has expected something else here :)

Some other html5 features has been introduced like

  • online/offline events
  • network detection
  • app cache
  • link prefetching - preloading the page content, so you get a native feeling after you are clicking on a certain link

Part 2

Almost the whole second part was about HTML5 and W3C APIs and demonstrating how they are working

  • websockets
  • webstorage - it was a bit tricky, since webstorage performance differ depending on how you are using the webstorage api! and it depends on the browser too. This is one more thing which you have to think about during developing of cross browser web apps.
  • orientation api - this was really funny demo, you can try to change the orientation of your phone on the slide test app ;)
  • geolocation
  • web workers - an example with multi threading in the browser

Part 3

The third part was not so long, it took just 15 minutes. It was about performance in the browser and a comparison between Client and Server UI. Here are some of the pros and cons of client side generation.

  • Pros:
    • Reduces server load
    • JSON uses less bandwidth than presentation ready HTML
    • CDN Bandwidth (jQuery, BackBone, etc…)
    • Offline capability
  • Cons:
    • Can reduce performance of device/browser
    • Parsing JSOn and generating HTML uses more memory
    • Hardware access === battery drain
    • The most notable client side Con is security!

There were also some interesting examples about optimizing web apps such as: “CNN removed jquery and protoaculous from concatenation and added to cdn => improved site performance by 17% and reduced almost 1TB of bandwidth per day” - really impressive

At the end there was a really cool demo with loadreport.js. “This handy little script uses phantomjs to build a report of DOM and resource load times. The reports are created one-at-a-time to deliver the most accurate results - that’s why it takes a few seconds.” Loadreport also generates a filmstrip, a bunch of png files, which are illustrating the loading behavior of the tested web page. Loadreport.js could be quite useful.

Blast your webapp with Gatling by Stéphane Landelle and Romain Sertelon (Georgi)

Since my last summary about HTML 5 has become quite long, i will try to keep this short :)

The question is: Why yet another stress test tool if there are already so much such as JMeter, JCrawler, Siege, LoadUI, etc.?

The intention behind implementing a new stress tool was, that the current available test tools didn’t meet the needs of the Gatling-Developers due to

  • Performance issues, such as blocking IO and problems with a lot of threads e.g. 2000
  • Usability
  • Maintainability

Here are some of the features of Gatling

  • High performance
  • Simple concepts
  • A DSL to describe scenarios
  • HTTP support
  • A scenario recorder
  • Meaningful reports

Gatling is written in Scala. It is based on the Akka-Framework. It has no GUI.

It comes with a custom DSL based on Scala, which provides

  • Checks (regex, css, xpath, jsonPath)
  • Scenarios describing the user behavior
  • Feeder definitions used for injecting data in a scenario

Gatling is extendable and provides an expresion language. It also provides a Recorder, which acts as a proxy to record the https requests. It helps writing scenarios for Gatling. The recorder comes with a GUI. It generates scala code which can be modified and reused later. There is also a maven plugin available for it. The project website is looking quite informative and i think it is worth trying it.