Home > devoxx > Devoxx – Day 3

Devoxx – Day 3

First day of the conference today, the keynote started at around 9.45. The whole room was packed and a guy called roxorloops did some beat boxing to entertain the attendees. Quirte impressive I’d say.

Next Stephan Janssen welcomed everyone and announced a few facts and updates about Devoxx. This is the first edition of Devoxx (after it has been renamed Devoxx from JavaPolis) which is sold out with 3.200 attendees (from 35 countries all over the world), 160 speakers, more rooms (6 rooms this times, as opposed to five in last year). There are 40 partners at the exhibition floor, 40 affiliated Java User Groups and also 400 students had the opportunity to come in for free in the first two days of the university.

Stephan said a BIG thank you to Devoxx programme committee and the to Devoxx administration team. As a side note he asked us to be gentle with the venue and take care of it. Do not litter it, do not abuse it, and keep the place clean and quiet. Also be gentle with the wireless network and do not download big files (to day for some reason the network is very fast, compared with the previous years and the fist two days. Well done). Stephan also announced that this afternoon they will be serving free beer (hope not as strong as the one I had in the jug leaders and speakers dinner last night, 10% alcohol!) and free fries.

He also said that people complain that the Belgian JUG apart from Devoxx is not organising anything else. Stephan explained that he didn’t have enough time since the preparations for Devoxx start 8 to 9 months before December. But he has quit his current job and has more time to dedicate now. As a ersult of this BeJUG will organise bi-weekly evening session for 150 maximum throughout Belgium. This is 18 meetings in total (no meeting during December and Summer holidays). Fro more info visit the BeJUG site.

After Stephan stepped down Danny Coward from Sun Microsystems stepped on and talked about JavaFX. He also announced that Sun is dedicated to always be shipping final production software only.

Next he talked about the 10 things we need to know about JavaFX

1) JavaFX is here, it was released on the 4th of December. Sun released a preview in July this wear, a preview of the SDK. JavaFX SDK (which includes the runtime for the desktop and the emulator which allows to deploy on desktop, on browser or mobile phones). NetBeans 6.5 has support for JavaFX. He also mentioned the JavaFX production suite which is a collection of tools that lets the JavaFX developer to work with graphics to create RIA. JavaFX also ships with 75+ sample applications

2) JavaFX defines a cool new language. Why do we need a new language? Languages are evolving rapidly. People in Sun learn from their experience and they put the best best features of the language they have worked so far. JavaFX script was purpose built for only RIA in mind, nothing else. It’s declarative, has a Java like syntax, supports data binding and event triggers.

3) JavaFX supports beautiful graphics. They take advantage of the Java layer for graphics. JavaFX provides support for graphics acceleration, javaFX scene graph, animations and lighting. At this point Richard Bair presented a demo of a video puzzle. The video was playing and it became a jigsaw and they had to put the pieces together. After this small video they explained the relevant source code.

4) JavaFX has a rich APIs set. They have created a simple to use JavaFX script. The API also supports scene graph, media, web services (RESTFUL) and … any Java API.

5) Greater developer tools. The NetBeans plugin for JavaFX includes first class projects, JavaFX script editing, code completion, compile and save, debugging, graphics peeview, integrated documentation, deploy to desktop/browser/mobile.

6) JavaFX integrates into graphics design tools. JavaFX production suite includes tools for developer/designer workflow, export design from adobe tools, import and integrate into JavaFX. Then they showed a demo of the JavaFX production suite.

7) JavaFX runs on multiple devices. Then one more demo followed by a JavaFX application running on a mobile phone.

8) It is built on Java. Great advantage since you can rely on 13 years of JVM implementation. You can rely on this robustness and scalability of the underlying technology.

9) Encode once, play anywhere media. Developers have been asking for years for better media support. They support the native media frameworks (mac native and windows native). The added a new cross platoform format (FXM) which means if they use this format the media will play in any JavaFX-enabled device. Another demo by Joshua Marinacci followed, the Fox Box which was basically amovie website with several movies playing at the same time and Joshua could play with video properties and the video could be dragged outside the browser to watch it as standalone application.

10) JavaFX deploys itself. Anywhere there is a JRE the JavaFX runtime will deploy. JRE is installed on 9/10 new PCs. More than 30-50 million downloads per month. Full FX mobile release will be in March.

At this point there was another break with the beatboxing guy again doing some amazing sounds.

Next was Bart Donn, Christophe De marlie, Robin Mulkers from IBM. They talked about RFID @ Devoxx 2008 (this is I think the same technology used in JavaOne last year).

RFID is a new project installed at Devoxx. But why do we need a project during Devoxx? Instead of giving goodies during Devoxx they decided to spend this money to start a project and benefit everyone. The partners of this project are: IBM, Intermec and SkillTeam.

Then they showed the followingvideo that gives an introduction to the RFID concept. Nice ad.

The rest of the talk was spent by talking about the RFID technology and how IBM has developed it.

From Concurrent to Parallel (by Brian Goetz)

This was actually the same talk Brian Goetz gave at JavaOne in May. I won’t go into details since I have written about that in this post.

Effective pairing: the good the bad and the ugly (by Dave Nicolette)

This was an interactive session again when people started pairing in front of the audience and played different pair-programming scenarios. This session talked about pair programming, its problems and how we can overcome them.

We started with a pair-programming scenario where one impersonated a senior developer and the other a junior developer. The problem demonstrated was that the senior developer didn’t want to let the junior do anything. The senior always had the upper hand and didn’t let the junior do anything and was always picking on the junior guy.

Teams are most affective when everyone can learn about the technologies and the problem. If the senior guy just holds the keyboard and does his own stuff it’s not a good thing. Junior developers learn by typing and practising. The junior should do the typing and the senior the driving. But the senior thinks that sometimes the project goes a little snow and wants to take over things. But the slowing of the project is a normal thing if you want the junior developers to learn. You loose a bit in project time but you gain later in the project. The tip is to have the less experienced person on the keyboard

Another scenario is the soloist. People who want to do this themselves because they think they know the problem ad thus the solution and can work better on their own. Everyone in the team has difficulty learning the problem they’re dealing with. The solution is everyone to know the problem and know how the system works and how to deal with it. This is the bus and team problem, if the lead developer is hit by a bus, how many people can take over the project?  Everyone in the team should try to have equal knowledge of the problem and the system in use.

Another scenario, one doesn’t follow the other while they’re discussing ideas. This can be because one has far more knowledge than the other or because one always changes his mind about ideas and software patterns. Problems arise because one might feel stupid. Another problem is that when someone changes always his mind, they might step away from the problem the customer needs solved. People need to learn how to work with different types of personalities. In pair programming one should make the other stay in touch with the original problem. And both of them can cancel each other’s problems and/or expose their abilities. Also we should need to give emphasis on the simplest design (this is agile development). Sometimes when we have many ideas and we change our mind all the time we make the solution more complex than necessary.

Fourth scenario, one of the persons in the pair has additional responsibilities and can make pairing difficult because he can be interrupted all the time. The team should be dedicated to the project, it should not be interrupted because one of the members of the team is assigned to other things. This usually when the testers are also the business analysts. There is another form of interruption too: when someone outside the team comes in and starts taking about nonsense that is not related to the project. This disrupts the pair when they try to work.

Pairing is really a kind of a discipline art. It’s not just sitting there talking with your friends. It really is work.

Fifth scenario. Physical working conditions in the team room. Pairing is usually done in an agile manner. The team is located in the same room, pairing wheer the team is located in different locations is not a good idea. Or the way the office is laid out. For instance desks and chairs for pairing might be laid out correctly but they there might only be one monitor. By doing this the pairt is loosing time because the second person cannot follow the code. A solution is to ask the manager to buy more monitors (monitors are less expensive than people). As a logical conclusion the working environment should be set up as to be easy for people to pair.

Scenario six. How to maintain the system and fix the bugs if the original application was not developed in an agile manner. If the application was developed by using agile methods there are probably test suites. The pair can check out the application and their test (the first step to fix the bug). Then they have to reproduce the bug. If the bar is green then it means that someone forgot to write the tests, or that someone put code into production without testing it. They can use the same techniques that the development team used. But if the bug refers to some kind of legacy application where there are no test cases the approach is different. In this situation you have to send someone in who knows the system and can fix the bug. This is not really a pairing scenario but good to mention in the pairing context.

Scenario seven, the Fearful Freddie, someone who’s afraid to change the code or can’t be bothered (too much of a hassle). This is a legacy scenario from old legacy systems where they had no tests cases and if you changed something you most certainly had broken it as well. Now things have changed. Even if you break something you can always reverse it by using the version control system. You don’t have to be afraid to change things. It’s better to change small things at once rather than do a big change. Like banks and bill payments, you don’t pay the bills at once but with small installments. Don’t let the complexity of the code build up over time, because you have problems maintaining the code and fixing it. You make the application’s life less. Because of the complexity of the code you actually need to implement a new one. And all this because people don’t want to modify the code and they are afraid to touch it.

Eighth scenario, the disengaged. One person that does the work and the other person is disengaged. The engaged person tries to get the other person  interested in the code they are working on. In this situation you have to remove the option from the other guy, just put the keyboard in front of him and ask him to do the job. What if the partners decide to do a major refactoring that will take 20 minutes and only one can use the keyboard? You don’t have to both use the keyboard, you just have to put your mind into work. Only one can type at the same time, but both of them can think. What if they want to do refactoring but they both have different ideas of how to refactor? A good idea is to ask the other team members about their opinions. You might disrupt them a bit but the benefits you gain are more.

Ninth scenario, the stubborn pair, when they both want to follow their ideas and they won’t change their mind. Another aspect of agile development is self-organisation. Every time there is a little dispute from the team you cannot run up to the manager to solve it because pretty soon the manager is going to take control. That might not be desirable, it might not be what you want. You take it to the manager and one person wins and the other looses (or both loose). The best thing to do when you have a problem like that is to take a break and clear your mind. A second solution is to change partner. Don’t let things become personal.

The Siamese twins scenario. Part of pair programming is that you change pairs (the original authors of pair programming called it promiscuous pair). Different pairs work differently, when one pair is finished the other pair is still working. So they have to take advantage of the spare time. There is a Pomodoro technique; a pair works together for a specific period of time and then they stop. Then take a break and start another time period with different partners.

The Siamese twins scenario kick in when two people are really engaged in the store they’re working on and they don’t want to separate. They work together well and they don’t want to switch. People should be able to switch, if they can’t they are probably stuck and they need a new pair of eyes to look in the problem they are looking into, a fresh pair. Sometimes people know they have problem, they know that the project falls behind but they don’t want to give up. The manager should not ask “how much longer will it take to solve the problem”, but assign new people to look into the problem.

The Ping pong scenario. One person writes the unit test and the other person writes the code to make the test pass. The person who writes the test leaves and lets the other guy to write the code. They are not talking about design, he just pushes the burden of design to the other person. This approach encourage single programming, but sometimes you can make it for a while in order to make the experience of programming a little bit different.

Q&A:

What’s the bets way to learn pair programming? If never done it before then get mentors, outside people who have done it before

Should people pair all the time? No, there are some tasks that don’t really benefit from it. Sometimes the best way for the team to solve the problem is to have one person go and think about it and figure out how to do it. In an 8 hour day the pair should be around five-five and a half.

Behaviour driven development in Java with easyb (by John Ferguson Smart)

This was a talk about the easyb framework and behaviour driven development.

The talk started by explaining that TDD is not about tests, but about wring good software. In the same manner behaviour-driven development is not about behaviour, it’s about delivering software that helps the end-user. TDD in general tends to make better code, by the application being more flexible, more better designed and more maintainable.

BDD is a recent evolution of TDD. The idea is to help to determine what to test. In order to test use cases it uses words like “should” to describe the desired behaviour of the class, eg should verify that client can repay before approving loan, should transfer money from account a to account b. As with TDD you should also focus on requirements not on implementation.

The framework to do BDD is easyb which is an os testing framework for Java (but written in Groovy). It makes testing clearer and easier to write. It makes tests self-documenting and it enhances communication between the development team and the end user. There is another BDD test framework for Java called JBehave but on the speaker’s personal opinion it’s cumbersome to use. easyb is based on groovy but it has Java like syntax, it’s quick to write and you have full access to Java classes and APIs.

easyb in action test requirement by writing easyb stories which:

  • use a narrative approach
  • describe a precise requirements
  • can be understood by a stakeholder
  • usually made up of a set of scenarios
  • use an easy to understand structure

Lets look at an example user story: opening a bank account. “As a customer I want to open a bank account so that I can put my money into a safe place”. We come up with a list of tasks. Open account, make initial deposit etc. Lets concentrate on the initial deposit requirement:

Make initial deposit:

  • given a newly create account
  • when a deposit is made
  • then the account balance should be equal to money deposited.

You implement the scenario in a test test case written in Groovy which can use all Java APIs.

If we had to compare easyb to JUnit

  • more boilerplate code required in JUnit
  • not very self-explanatory
  • the intention is less clear.

With easyb you can have multiple post and pre conditions.

In easyb you have shouldBe syntax instead of assert. Variations of the shouldBe syntax include shouldBeEqualTo, shouldNotBe, shouldHave etc. Also there is another way to verify outcome, the ensure syntax, which is much like Java assert.

Fixtures in easyb; you can use before and before_each (similar to @Before and @BeforeClass in JUnit). Very useful for setting up database and test servers. You an also use after, after_each (similar to @After and @AfterClass)

Fixtures are good at

  • keeping infrastructure code out of the test cases.
  • making test cases more readable and understandable.

As for easydb plugins, only one is available, the dbunit. But more to come for Grails and Excel.

easyb produces test specifications in user-friendly format and flags pending (unimplemented) stories. Also provides readable error messages. When tests fail easyb will tell you why by a more readable manner than JUnit.

As for IDE support for easyb. There are three option options: IntelliJ, Eclipse, NetBeans, but only IntelliJ has a very good support for Groovy.

Some upcoming easyb features

  • html reports
  • grails plugin
  • CI integration
  • Easiness – a fitnesse style web application (stake-holders create stories in normal text)

The talk closed with an easyb demo and stepping through the source code of the test cases.

What’s new in Spring Framework 3.0 (by Arjen Poutsma and Alef Arendsen)

New features in the upcoming 3.0 release and also some that already exist in 2.5 release.

@Controller for Spring MVC.

@RequestMapping methods.

@RequestMapping(“/vets”)
public List<Vet> vets()
{
return clinic.getVets();
}

Constantly simplifying, LoC for sample application PetClinic over time, it dropped significantly from Spring 2.0 to Spring 2.5.

Spring integration now in 1.0 version. released last week in SpringOne.

@PathVariable

@RequestMapping(“/pets/{petId}”)
public Visit visit{
@PathVariable long petId

..

New Views with new MIME types:

  • application/xml use MashallingView in 3.0M2/SWS 1.5
  • application/atom+xml use AtomFeedView 3.0M1
  • application/rss+xml use RssFeedView 3.0M1
  • application/json use JsonView Spring-JS

ShallowEtagHeaderFilter

  • introduces in Spring 3.0M1
  • creates ETag header based on MD5 of rendered view
  • saves bandwidth only
  • Deep ETag support comes in M2 (through @RequestHeader)

At this point they presented a demo with URI support and ATOM feed by using Spring MVC.

Introducing expressions Spring 3.0 will include full support for expressions.

Spring 3.0 will only be available for people who use Java 5. It will support the Portlet 2.0 specification. And depending on specs finalising (if they are released on time) it will support Java EE6, the Servlet 3.0, JSF 2.0, JAX-RS and JPA 2.0. It will also support Web Beans annotations.

Spring 3.0 will deprecate/remove several stuff:

  • traditional Spring MVC controller jierarchy
  • Commons Attributes support
  • Traditional TopLink support
  • Traditional JUnit 3.8 class hierarchy.

but it will still be

  • 95% backwards compatible with regards to APIs
  • 99% backwards compatible in the programming model.

Spring 3.0M1 released last week.
Spring 3.0 Milestones Janurary/February 2009
Spring 3.0 Release Candidates March/April 2009

Advertisements
Categories: devoxx Tags:
  1. No comments yet.
  1. 9 May 2014 at 12:51 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: