from my work as a developer
Archive for February, 2010
weird or just different
Feb 23rd
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
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
open code review policy
Feb 4th
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:
- What is needed:
- Two Moderators – one for each team to build team spirit – if team cooperates , it isn’t needed
- Moderators only guard the process, time-boxing and at the end gathering a summary, publish it on a Wiki
- Conference room booked for 1 hour (45 minutes for review, 15 minutes to summarize)
- 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
- 6 attendees (conference room limit)
- Introduction:
- We are doing review of a code and not the person who wrote that code (!)
- Attendees should play role of maintainers of the code, are they able to find and solve a bug
- Split people for two teams, each of three persons
- 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?
- Go:
- Allow to review the source code for 45 minutes, make notes (in English is preferable)
- Moderator should help to focus on above topics – if they stuck ask about above topics
- Finish the review after 45 minutes (definitively) – cut down any following discussion
- Summarize attendees ideas for 15 minutes – prioritize them
- Make recommendation / suggestion regarding coding style for the rest of team mates
- The end:
- Moderator should write down all the suggestions, recommendations and publish them on a Wiki with the source code
- Send an e-mail to all with the summary and with the link to the Wiki page
bugs, gwt and appengine, ocr
Feb 3rd
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
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”
I hope they will be able to introduce it in their teams! I’m waiting for feedback!
