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
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!
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
Published at: 12:02 pm - Thursday February 04 2010
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
Published at: 09:02 am - Wednesday February 03 2010
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!
Published at: 11:01 am - Wednesday January 27 2010
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
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.
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
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
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
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
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
The rest is just a history…
Have nice Christmas! I’m taking long vacation so see you in New Year!
Published at: 03:12 pm - Thursday December 17 2009
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
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
it's a simple log, a dairy, about my daily work as software developer, I was inspired by the book My Job Went to India: 52 Ways to Save Your Job by Chad Fowler, you can treat this as a experiment to confirm his thesis - we will see ;-)
this is the first goal, the second is to improve my written English skill, it was also mentioned in that book, to be a good software developer, you have to be good in writing, so I will be very glad for any comments to point my mistakes, I will be very thankful if you help me to improve my English