Monday, October 19, 2009

Crowd at Java Developer Day (JDD) in Krakow

Last Friday, I attended JDD in Krakow.
This was my first time at this conference and I my general impression is really positive. Good place, decent logistics, a lot of people (I believe that around 400 folks), good speakers. And of course a pack of beautiful Polish hostesses you will never see at conferences outside Poland.

Scott Davis' presentation about Groovy was good (charisma, great slides, real coding demo), but I found it too beginner-level. Hey, we really know what unit testing is and how to do it. You could have skipped almost entirely the first 20 minutes and start from more advanced topics.
Anyway I am somewhat sold to the idea of introducing Groovy as a testing platform (with production code remaining in Java). Especially the ability to examine private fields and generally far more compact language are tempting. Still, without good tooling (and generally Groove as weakly typed language will never have such refactoring support as Java has), I'd rather stay by Java in the production code.

Mark Richards' talk about messaging was really good too. Rather nothing new to me as seasoned guy in using JMS systems, but a lot of valuable advice for beginners or people astray. Especially the anti-pattern of using multiplexed single queue instead of several queues just do to communication/collaboration problems with admins makes me think... Mark highlighted well misconceptions around priority queues and work balancing.

The talks about jBPM was also interesting, but I did not like recorded movies instead of real-time demos. After all we are all developers, we know that Demo God may strike at any time.
Definitely jBPM is something I would take a closer look at, if I was about to decide which business process management platform to use.

I liked the talk about the exception handling by Tomasz Skutnik. Good speaker, a lot of real code samples (we love it), much valuable advice given from the person who seems to suffer a lot from screwed up exception handling in the production code.
I don't agree with every single rule provided by Tomasz (especially I don't like tagging with some magic string every single place the exception may be thrown - famous ORA XYZ, I am talking to you ;)). Still, he raised a lot of valid points about very popular mistakes made to exception handling in Java EE.

Waldemar Kot gave supposedly interesting talk about using concurrency in Jave EE application servers which generally do not like managed components to use any kind of extra threading. I learnt about Work Manager API and current problems related to including it in Jave EE spec.
I am sure this talk could have been better, if Waldek better managed his time. Fortunately I feel we get only to about 50% of the presentation, when we ran out of time.

I said JDD was good. Still there is always space for improvement. What could be better:
  • more strict time-keeping. I had to start my session 10 minutes late, as I was waiting for my predecessor who had did not finish on time. Then I overran by 2 minutes, which means that I not only consumed the whole break, but also immediately delayed Scott Davis by several minutes. Sorry Scott! I wish there was some kind of bell or the organisers were gently interrupting talks at scheduled time.

  • probably 3 or 4 parallel tracks in smaller rooms. I hope that we can find in Poland many more decent speakers

  • lunch could have been served by more people. Queues were enormous and actually one had to wait c.a. 20 minutes for their food.

At JDD I presented myself a 45-minute talk (including demo of Atlassian IntelliJ Connector, Crucible & JIRA) about effective code review in agile teams. Although I used slides from our previous presentation at Agile2009 in Chicago, this time I targeted the talk (especially demo part) more for Java developers and purely technical audience.
I tried to present my stance of how code review relates to agile spirit and common practices (including pair programming).
I estimate than more than 200 people were present at the session. As nobody left before the end, there were a lot of questions and I get some applause, I tend to believe than the presentation was not awful.

Here are slides from the presentation I gave.


Sorry for all these folks whose questions to this presentation remained unanswered due to lack of time. Feel free to mail me or questions here at this blog.

On the side note: Last week I received on more spam e-mail inviting my from TSS conference in Prague.
Having read this sentence:

TheServerSide Java Symposium-Europe is where the community learns, shares and prepares for the future of enterprise development. Register now to join 300 of your peers from across Europe in Prague this October.

I tend to believe that with its 400 attendees JDD became this year bigger Java conference that TSS. Congrats folks!
Try next year to be really English conference (still too many talks were in Polish), aim for 2 days and, who knows, JDD may become really 1-st class pan-European conference.

2 comments:

  1. Hi Wojtek.

    I'd like to clarify what I believe is a small misunderstanding of the point I made during my presentation on exception handling. I assume that I wasn't clear and sharp enough during the presentation, so I'll try again here, hopefully with better result.

    What I proposed (and what we at e-point put in our error handling code) is that on every exception handled by global exception handler application should do the following:

    1. Generate "unique enough" exception identifier. You don't need proper uniqueness (as in e.g. UUID). Using org.apache.commons.lang.RandomStringUtils.randomAlphanumeric(20) is good enough.

    2. Log exception with this identifier and any additional information in application log for future inspection.

    3. Generate error page, with identifier prominently displayed. No stack traces, no ORA-XXXX internal codes or any other technical stuff. These should go into log during step 2. Only error message, explanation what to do next, and our freshly generated identifier.

    This way users are not overwhelmed with technical details (also, as a bonus you don't leak "security sensitive" information about your internal implementation). However, if a user reports an error to our service desk and provides us with that generated identifier, that basically solves for us the problem of pinpointing in the logs the exception corresponding to this exact ticket.

    Not everything is rosy of course. Users often do not report errors, just leave the site. Or hit refresh button a few times and then call a hot line. Or attach a screen shot with error page instead of copying identifier as a text. That's why you should consider putting little JavaScript on your error page, that implements "One-Click-Via-eMail-Error-Report(tm)" feature. Basically just generate proper "mailto:" link that contains generated identifier in e-mail title or body.

    Hope that makes my position clear. If you don't agree and/or have other suggestions I'd like to hear about them.

    Thanks for your time.

    Tomasz Skutnik

    ReplyDelete
  2. @Tomasz,

    Thanks for the explanation.
    Still, I am not convinced.
    I am neither objective nor representative here, as I am a (somewhat highly) technical guy. However I personally would prefer a sentence or two of the explanation what is going on including the stack trace on demand (in a separate collapsible details section or a popup) - I don't believe in security which is based on hiding underlying technology ;) - rather than just a beautiful page with a totally cryptic 20-character-long string. Thus, you deprive your users from guessing what is wrong on their own.
    I believe that in some environments it is desirable. I live though is somewhat different area.

    WRT logging such identifier - I can understand it, especially if you cannot have line information in production. In most of the circumstances though I'd rather see full stack trace info with line numbers.

    Error reporting directly from a web page is something really great. We start here often from implementing this as the first feature of the app (the second being auto-update for desktop apps ;)).

    Anyway your presentation was really good and your advice priceless for many folks.

    ReplyDelete