Devoxx 2012 - Day 3

Conference part of the Devoxx 2012 starts today. This means three keynotes in the morning and 60 minute talks for the rest of the day. Finally all 3400 developers have arrived in Belgium to share the 3 day Devoxx conference. Also the rest of the ConSol gang has arrived in Antwerp so we are now 6 people.

Keynote - Welcome to Devoxx by Stephan Janssen (christoph)

This year’s Devoxx conference in Antwerp Belgium started with a very cool robot dance performance. A contribution to the few robotics talks that we have in this year’s edition of the Java conference. I saw a lot of people recording this on tape so I am pretty sure you will have the chance to look at this in the internet somehow and you should do that - very cool.

So our host Stephan welcomes us to Devoxx 2012 conference with some exciting announcements around the Devoxx world. With this year’s Devoxx France in Paris the Devoxx family has already grown a new child. The conference in Paris 2012 was a full success with 1200 people but still the Belgium mother conference is pretty crowded and some people were not able to grab a ticket. So lucky I am to sit here and give you a summary of Stephans talk. And good news to those of you missing this conference. Next year in March 2013 we will have not only Devoxx France but also Devoxx UK in London! WOW, looking forward to that, Antwerp is lovely but it is London next time for me! Devoxx UK takes place in March 2013 directly before Devoxx France so if you want to you can got to London and in the same week go to Paris for a whole week of Devoxx experience.

Another new thing coming up is the new Parleys software stack. The old Flash, Flex, Adobe Air client and server stack is gone and they are heading for HTML5 with mongoDB storage. Ben from Parleys team did a great job and showed some incredible demos during the keynote. Especially the fullscreen functioanlity and the offline video editor is amazing. And all stuff runs with HTML5 in your browser, no additional plugins, no separate desktop client.

Keynote - Make the Future Java by Nandini Ramani (christoph)

Oracle talks about new things in JDK 8. Here the keywords are Lambda expressions, default methods and annotation features. And finally Oracle talks about Java FX. Again? Not again! Many times Java FX was announced as part of the future Java. This time Jasper Potts presented a very cool demo with impressive 3D support running on Java FX. But honestly I can not judge how Java FX finds its position within the future Java. And I do not know how Java FX competes with the rich client movement going on right now in the browser. I leave that question open for now.

Keynote - When Geek Leaks by Neal Ford (christoph)

For me personally the talk content was as confusing as the title of the session promised to me in advance. The talk was about presentation patterns mostly but also on continuous delivery and some more points I can not remember. Maybe I did not get the message Neal Ford tries to give in his talk. This keynote was definitely no a usual one fitting for all Devoxxians in all rooms. Guess this was some new approach. I did not like that so much.

However I am excited for the first 60 minute conference talks coming up.

Welcome to Devoxx 2012 (olaf)

Every seat was taken in the Antwerpen Metropolis cinema when the Devoxx 2012 keynote speech kicked of with five NAO robots performing a cute little dance on stage.

Stephan Janssen welcomed the participants from 41 countries, noting that this year the Devoxx conference sold out within just 6 weeks. This time, every visitor is supplied with a wristband containing an RFC chip that allows for quickly expressing their oppinion after a presentation just by holding their hand next to a thumps up or down sign. Impressively, this has been implemented using two Rapberry Pis and a few Adruinos using a MongoDB at the backend.

Next, a short movie showcased Devoxx4kids, a robotics workshop for kids held by Stephan and his crew. He pointed out how for today’s children, experimenting with robotics might start a develoment similar to what using a Comodore 64 started for a lot of today’s attendants. Devoxx4kids was attended by 25% girls, whereas today there are only about 4% female developers present at the conference.

For next year, a Devoxx conference is scheduled in both the UK and France (taking place between the 24./26. and 27./29.03). This may give the Belgian Devoxx a little relieve regarding the number of participants.

Stephan also demonstrated Parley’s upcoming HTML5 implementatation (his web site project to host presentations that already has received the “Duke’s Choice” award). The demonstration was impressive, showing the sites ability to record audio and edit movies, all without the help of Flash. Expected to be available in March next year!

How to make good teams great by Sven Petrus (torsten)

1. It’s flowtime

Its really important to get programmers comming into the “flow”. That’s highly productive development time. If this flow is interrupted e.g. by mail it takes 10 minutes to get into this productive state again. So the goal is to avoid interruptions. On the other hand development requires a lot of collaboration. A closed door environment is perfect for getting into the flow but not very good for collaboration. Open Space environments on the other hand are perfect for collabaration but not a good thing for working productively.

  • In a closed door env. you could define a “no disturb time” for productive development but this is impossible in an open space environment.
  • At Atlassian they introduced a daily rotating “support guy” who acts as a proxy to the team and prevents his colleagues from being disturbed.

2. Feed your brain

How can we constantly learn?

  • Visit conferences that one is easy but it might be a budget problem for some companies
  • organize regular coding sessions - sit together and code good thing but not for everyone. It might conflict with spare time, familiy time, etc.
  • organize “brown bags” - meet during the lunch break and have somebody talk about a topic doesn’t cost spare time but needs some preparation time for the one giving a talk.
  • watch a conference or some other talk together and talk about it doesn’t need any preparation

3. Say: well done!

Appreciate small things and make it public. This keeps people happy and motivated.
At Atlassian everybody can publicly give twice a year give “KUDOS” to a colleague in the intranet without required approval from somebody else. A KUDO might be movie tickets or something similar. The company is taking care about the KUDOS and of course is paying for that.

4. Report Robot

Atlassian is collecting all kind of data such as features completed, code reviews done, builds, build time, lead time, web traffic, ad click rate, support calls, etc. This data is stored to the central “green zone database”. Real time reports can easily done against this database. The reports are displayed on “information radiators” which is big tv screens all over the place.

This reminds me of the LIG extreme feedback panel. We should think about “expanding” the use of it.

5. Eat your own dogfood

Alpha test your own software accross your whole organization.

This enables you to understand your customers and it gives you fast feedback. Although it can be sometimes painfull when the feature you developed gets critizised by a colleague.

What I ask myself: How comes that JIRA sucks although they eat their own dog food at Atlassian?

6. Do a special day

Introduce a special day to get unpleasant things out of your backlog. At Atlassian this is for example a doc-sprint where the developers are writing documentation with the help of technical writers for a whole day. A clean up day for refactoring or a Test day for testing things.

7. Experimentation time

They have “Shipping Days” where the whole team is trying out things for 24 hours. They collect ideal 2 weeks before the event. 2 Days before they make a sprint planning and then they hack for 24 hours. Usually it starts in the afternoon, lasts for some hours and continues in the morning. After that there is a voting for the winner. This happens quarterly at Atlassian

Another thing they have is that every developer has 20% of his time for doing product related experiments on his own. This turned out not to work because of conflicting things like sprint goals, workload, dependencies. In reality they only use 5% of their time for experiments.
Reminds me on the ConSol R&D Budget which is never used!

So Atlassian introduced the innovation week where a whole team spends its 20% experimantation time together. This week is planned ahead and therefore works much better.

Wrapup:

Try it out, be prepared to fail and don’t be stupid (?)

Personally I got some ideas I might try to introduce at ConSol but of course a lot of his 7 things are obvious. All in all a good talk with some useful takeaways.

Vert.x by Tim Fox (christoph)

Vert.x is a general purpose application platform running on the JVM. The framework outlines asynchronous APIs as the primary goal supporting multiple languages like Java, JavaScript, CoffeeScript, Ruby, Groovy and Python.

What is it good for?

Vert.x solves similar problems as Node.js, Akka and Play Framework do. The core APIs are

  • TCP/SSL clients and servers
  • HTTP/HTTPS clients and servers (incl. WebSockets)
  • Event bus
  • File system
  • 100% asynchronous

In Vert.x a Verticle is the execution unit which can be written in Java, Groovy, JavaScript, Ruby, etc. (Scala and Closure integration is coming soon). The threading model is based on event loops and the reactor pattern. The reactor pattern describes event loops as a single OS thread. In Vert.x you can have multi reactors which means one event loop per server core.

Unfortunately there are problems with event loops. The essential rule is to not block or slow down the event loop! Using blocking APIs (e.g. JDBC) or long running calculations inside an event loop causes the trouble. The Vert.x solution is to not force everything to run on an event loop. Vert.x introduces so called worker Verticals for blocking things to do. These are then not executed within the event loop thread.

Vert.x shippes with automatic scaling mechanisms. You create several Verticle instances that use message passing to communicate with each other. Vert.x will automatically load-balance all instances out of the box.

The possible major feature in Vert.x is the built in event bus. Verticles communicate over the event bus, which provides an ultra simple API to work with. The bus supports all common message communication patterns such as

  • Point to Point
  • Publish/Subscribe
  • Request/Response

As message payload you can pass simple strings, numbers, other primitives and mostly preferred JSON. The event bus enables Vert.x to connect multiple Vert.x JVM instances forming a large distributed event space. You can easily extend this putting the client side to the browser as consumer and producer of events on the bus. Behind the curtains Vert.x is using SockJS which is a WebSocket-like transport API handling the communication between the browser and the server.

Summing up I would say that Vert.x is pretty similar to Node.js on the Server side. The event bus with the simple API looks pretty nice and I think this opens some new doors for asynchronous event processing within JavaScript. But there are also some things to improve. Persistent messages on the bus is still open as well as a good IDE support and management tool integration.

Java EE 7 by David Blevins (olaf)

David Blevins, among other merits member of the Java EE 7 and EJB 3.2 expert group, highlighted two of the upcoming features in Java EE 7: easier usages of Message Driven Beans/Connector API and resuse of annotations.

His observation is that currently MDB connectors are not really embraced by developers, possibly because of the large documentation and overall complexity: Connectors implement an ActivationSpec class and supply a MessageListener interface; MDBs implement the MessageListener interface and also declare an ActivationConfig via XML.

In Java EE 7, connectors will access the full MDB directly, allowing them to invoke any MDB method. A lot of configuration will be moved into annotations.

The second area of Java EE 7 innovation highlighted was the extended reusability of annotations: currently, the same bundles of JEE annotations typically show up again and again in code (@RolesAllowed, @TransactionAttribute, @Interceptors). With Java EE 7, they can be bundled into user defined annotations, leading to cleaner code and a central place to change attributes if necessary.

Interestingly, after EJB 3 moved away from XML configuration files to annotations, Java EE may later reintroduce XML to define annotations, but in a way that will not specify the beans entitled to use them. The idea behind this is to again separate configuration from the code.

Using Spring in Scala by Arjen Poutsma (georgi)

The goal of Spring Scala is to make it easier to use Spring in Scala. It is build on top of the Spring Java Framework.

Here some of the features which have been introduced:

  • wiring scala beans in XML
  • wiring scala beans in scala
  • support for scala collections
  • scala-friendly versions of spring templates
    ** JdbcTemplate
    ** JmsTemplate
    ** RestTemplate

Arjen has shown a lot of examples and live demos, but nothing fancy so scala newbies can also understand them.

First milestone should come before the end of 2012.
If you want to use Spring in your scala code, this is your tool.

Behaviour driven development (BDD) by John Smart (kathrin)

Behavior driven development takes test driven development further.
The great advantage over test driven development is, that business and developers share a common
language. This ist the result from writing a specification, which directly translates into an
executable testcase (principle of executable specification).

How to do behavior driven development:

  • write a executable specification
  • specifiy the minimum feature set to achieve the feature. (=feature injection)

Developers test code, but they usually test the code does what it is supposed to do, which might
not necessarily add to what the application is supposed to do.
With BBD each line of code is written
to mathc a specific test, therefore match a specific requirement. The behaviour tests have to be
automized, so in writing test cases for behaviours, BBD is also valuable for documentation.

Benefits of BBD:

  • only features which provide business value are build
  • less waste effort
  • better communication (inter teams)
  • hiqh quality. better tested product
  • traceabilty

How to analyse requiremtns:
Every application is build to match a specific goal.
* Define the features to achieve the goal.

  • Define the stories to complete the feature
  • Define scenarios and examplems for the stories.
  • Define the acceptance criteria for the storeis.

TDD vs BDD:
Do it both!
Acceptance tests for hiqh level features
Developer tests for low level features.
Development process:

  • define the acceptance test
  • define how to make the test work
  • define the features
  • write development tests

So in the end everybody should have a understanding of “This acceptance criteria is used for that
feature, which adds to that goal”

How to define goals:
A good goal adds value to the business. Goals of applications are usually about

  • increase revenue
  • reduce costs
  • prevent future costs
  • protect revenue

Customers usually order a solution instead of explaining the problem they want to be solved.
Good teams should always ask “Why”? (I think there is a 5-why rule, which states that you have to
aks 5 times why until you`ll get the customer to state out the problem, but the speaker did not
mention that.)
Once the developer know the context, he is capable of suggesting solutions, which might even be
better than the customer first had in mind. Also, once the problem is know, it is easier to priorize
requirements.

Examples and scenrios in stories help to explore the feature: The feature is implemnted with
minimal effort and then systematically improved.
Acceptance criteria illustrate and validate stories and are a good way of communication between tester
and developer.

Frameworks for BDD:
## jbehave: Java framework ##

Stories are expressed as annotations:
public class TraderSteps {
private Stock stock;

@Given("a stock of symbol $symbol and a threshold of $threshold")
public void aStock(String symbol, double threshold) {
    stock = new Stock(symbol, threshold);
}

@When("the stock is traded at $price")
public void theStockIsTradedAt(double price) {
    stock.tradeAt(price);
}

@Then("the alert status should be $status")
public void theAlertStatusShouldBe(String status) {
    ensureThat(stock.getStatus().name(), equalTo(status));
}  }

Good for code documentation, but bad as a common reference for testers and developers.

easyb: Java framework

bases on groovy, uses groovy when, then else notation.

Thucydidis

generates ducumentations of BBD tests creates nice test reports
very good for a living documentation and also for audit, because the steps to insure quality becomes
very clear

Spock

Spock is a testing DSL (Domain Specific Language) that transforms the
Groovy programming language into a language specifically targeting testing.
Spock can be used to test Java, Groovy, or any JVM language.

Spec2: BDD for scala

Pretty cool Scala integration for BDD.

Jasmin BBD for javascript

Jasmin is a testing framework for JavaScript and even comes with maven integration.

Chrome Dev Tools can do that by Ilya Grigorik (christoph)

My favourite talk of the day. Ilya shows some incredible profiling, debugging and analysis features in dev tools for Chrome browser. It is very hard for me to give you a deep dive in all those features presented here, because it was really lots of stuff. I just have to say: try this out yourself or see the talk on Parleys, because it was so cool to see what is possible with Chrome dev tools.

Here is what I am talking about:

  • Timeline waterfall profiling (request/response times)
  • CSS style analysis (identify unused CSS)
  • Setting DOM model breakpoints
  • Media optimizations (identify uncompressed images)
  • Remote debugging!!!
  • Continuous build integration
  • Chrome dev tools API
  • Dump HAR (Http Archive) data for later use

That’s it for Day 3 with our Devoxx experience. Up to now we had very interesting talks and good presentations. Tomorrow we will have some JBoss announcements, Google Keynote and some more 60 minute talks. So stay tuned!

Author: Christoph Deppisch
Categories: devoxx, development