frozen zone

We’re again in frozen zone – project is going to production ;-)

So I have a lot of spare time to improve my other skills, like learning GWT, studding books – Tony Buzan’s The Mind Set and so on.

I have a tricky question for you: why James Cameron made the Titanic ? Just watch his talk on TED and grab the answer

Another thing is GWT – sadly I discovered that not all widgets are presented with Widget Gallery, you have to look through API documentation to find them all – for example CaptionPanel :-(

beautiful code

Yesterday I had to help a younger team mate to solve a simple problem with persisting data with HTTP session. Case was quite simple but proposed solution wasn’t the best. We discussed other possibilities and found that what we had done is the best one for given circumstances. He did the work and has committed changes to source repository and then informed project architect.

As I said, solution wasn’t prefect but was the simplest one and easy to understand in the future when someone else who will take a care for the project. I took a look on the code and it was beautiful! Separated meaningful method name, named constants for String literals, null safe – beautiful! And all that was achieved without any comment from my side regarding how a code should looks like!

weird or just different

Nice presentation about how people are different and why we should always be aware of that – for us it can be normal for other weird :D

Derek Sivers: Weird, or just different?

If you never had chance to watch TED presentations, you missed a lot and you should grab a few, I specially recommend that one about “rules” and “values” and any followed by that speaker

Barry Schwartz on our loss of wisdom

open code review policy

I would like to share with you our internal policy we use to do Open Code Review, feel free to adjust it to your needs. I will be very glad if you share any experience, comments and thoughts you have!


Open Code Review process:

  1. What is needed:
    1. Two Moderators – one for each team to build team spirit – if team cooperates , it isn’t needed
    2. Moderators only guard the process, time-boxing and at the end gathering a summary, publish it on a Wiki
    3. Conference room booked for 1 hour (45 minutes for review, 15 minutes to summarize)
    4. Class source code printed out on A3 sheets (x2 sets) – less than 300 lines of source code – for largest class it will take more than one hour
    5. 6 attendees (conference room limit)
  2. Introduction:
    1. We are doing review of a code and not the person who wrote that code (!)
    2. Attendees should play role of maintainers of the code, are they able to find and solve a bug
    3. Split people for two teams, each of three persons
    4. Attendees should focus on:
      • Structure of a class
      • Readability
      • Are there any positives? – point that hard on the beginning
      • Testability
      • Are there any undocumented tricks / hacks?
      • JavaDoc comments are adequate to what class / method is doing
      • Is class intuitive to understand?
  3. Go:
    1. Allow to review the source code for 45 minutes, make notes (in English is preferable)
    2. Moderator should help to focus on above topics – if they stuck ask about above topics
    3. Finish the review after 45 minutes (definitively) – cut down any following discussion
    4. Summarize attendees ideas for 15 minutes – prioritize them
    5. Make recommendation / suggestion regarding coding style for the rest of team mates
  4. The end:
    1. Moderator should write down all the suggestions, recommendations and publish them on a Wiki with the source code
    2. Send an e-mail to all with the summary and with the link to the Wiki page
Posted in: dailylog by Lukasz No Comments

bugs, gwt and appengine, ocr

At last I got a new task – I mean new bugs to solve ;-) Yea all were related  to a print layout. Many simple text changes, it took me around half a day to solve them all. I still have some bugs to solve but first I need to investigate how they will impact application – the changes I made to layout till now were safe, they will not brake application.  So it’s a bit boring but better than nothing :D

Another thing, I started learning Google Web Toolkit – as a member of Warszawa Java User Group I have access to group’s bookshelf and free books from many publishers – you know “book for review”. Anyway I had a copy on my PC and started reading it.

In the same time when I’m reading GWT in Action I started working on Maven2 archetype to work with Google AppEngine. You can find some over the Internet but they are not really suitable to what I want. After two day I had stable environment to work with GWT and AppEngine. I’m using my good old IntelliJ IDEA instead existing plugin for Eclipse ;-)

The last thing, I’ve presented my idea about Open Code Review on Design Patterns Study Group’s meeting, I explained what it’s about, how to steer the whole activity and how to solve problem with “gurus” :D I hope they will be able to introduce it in their teams! I’m waiting for feedback!

open code review

I was too lazy to write something interesting or even not ;-) This is over! I want to share a great idea we* introduce in our office – Open Code Review.

What’s that? It’s a quite simple process to have some fun and learn how a code should looks like. We’re spending one hour analysing and commenting a class source code from a open source project. We always have two teams (conference room doesn’t allow more ;-) ) that are working with piece of paper – yes, the source code is printed out, no IDE’s, no fancy tools support. All you have is your brain, piece of paper and a pen.

It can be a bit odd at the beginning but it gives you lot of fun, when you are able to make real comments, crossing the code and so on. The whole exercise is about building team spirit and in mean time you can grab a knowledge from more experienced collogues – knowledge spreading :D

Till now we did two code reviews – the first one we called prototype to check if it’s make sense doing it. The second was the real exercise – with random attendees, with real code (maybe a bit to hard ;-) ), but all the reviewers were happy and they made lot of comments for future. So we have another good idea to introduce, stay tuned!

I forgot to mention that at the end all the comments and the code is put on our internal Wiki and announcement is sent to all office employees with some suggestions how to improve our work ;-)

* we – I used “we” because I’m member of Architect board in the office.

a new year

Yap, the New Year became ;-)

I’ve came back to work to rest ;-)

I had fixed my “last three bugs” and have nothing to do ;-)

I had started playing a flash game and I got pain in my neck – the Flash is an evil :P

I started preparing Javarsovia 2010 conference :D

I’m thinking to participate in GeeCON 2010 conference as a presenter – first I must have some good topic to present ;-)

Yap, the old year had gone, New Year became :D

reanimation

Last time I had been writing about merging branch to trunk just before deployment to production. Business side wasn’t happy about that, so we had to clean up the mess ;-)

It’s very weird how merge can replace whole files with older versions – by older I mean that were formatted on branch – no other changes. In such case it’s very hard to find what was changed. The only hope is in Subversion’s history. It’s the only place where you can find how it was before, though if you have history :D

Anyway, the problem was solved quite fast and we were able to deploy a new version to test environment and business were able to test it also. The last step was to prepare deployment to production and hope that everything will go smoothly – we will see next day morning!

I also discovered superb future in IntelliJ IDEA – Productivity Guide – you can open it with ALT + H + P

Productivity Guide

BTW the new version of IDEA was release few days ago – Ulimate 9 – I already have it! Hurraaa!

PS. You can be surprised but I’m working remotely from my new home ;-)

operation has gone but the patient died

Yap, that how it was with our project deployment to production. Everything went smoothly but application is not running, even worse – running without problem but it’ giving wrong results :D

I had to quickly investigate the roots of evil and I found them quick – once again it was a merge – CVS merge to be precise. There was a branch to integrate with other project and few days before deployment everything was merged down to main. Nobody was testing it after all, just we went ahead to production :P

The rest is just a history…

Have nice Christmas! I’m taking long vacation so see you in New Year!

Posted in: dailylog by Lukasz No Comments , ,

release

The “Frozen Zone” was still On, so I had lot of time to contribute to Open Source project – in my case Apache Struts. I’ve been working for few weeks with Maven 2 archetypes, to updated them to latest Strust 2 version. It was quite easy task, I even wrote a simple bash script for automatically testing them.

Nevertheless, became the time when I had to release them – or to be more precise – prepare staging release. I never had been doing that, so always is the first time :D

I’ve read some tutorials about releasing projects with Maven and there is also a great documentation entry on Apache Struts site about releasing the project. It was the most helpful information. Equipped with knowledge I started the release process. The first three archetypes were released very fast and without any problems (except conflict between Cygwin and Subversion client – next time I will use Linux box ;-) ).

Yap, I thought I’m on the road and then I got problem with checking out tagged project from Subversion. I don’t remember what was the message, but I spent more than hour to solve that problem! Another experience for future.

The whole release process took mi around 5-6 hours so it was enormous achievement in my opinion. The next time it will be faster ;-) And the last thing – the Vote! I started it and was able to relax with cold beer :D