понедельник, 28 июля 2008 г.

Making code review easier with Codestriker

The big brother is watching you
George Orwell


Everybody agrees that code review is crucial for any software project. I don't believe that it is possible to do good code reviews on a regular basis without a code review tool. I you are not using a code review tool, the following scenarios might happen:
  1. You have just finished with your task and want the code to be reviewed. The reviewer and you work in the same office. Unfortunately, the reviewer is not available at the moment. There are many reasons why it can happen. The reviewer might have flexible working schedule which differs from your working schedule, he might be ill, he might be at a meeting, visiting the dentist, stuck in a traffic jam. Of course, you can't wait until the reviewer appears in the office, you switch to another task instead. It is easy to forget about code review.
  2. You have a distributed team. One or two developers work in one office, the rest of developers work in another office which might be located in another country. We had this situation at my last place of work. In this case the only way to send a code review request is an email with an attached patch file which contains your changes to code. The reviewer is supposed to read your email, save the attached patch to a folder, then apply the patch to the right version, examine your code. It is time-consuming and not efficient.
Without a code review tool the team leader doesn't have the whole picture of what is going on with code reviews. How many code review requests are pending ? Which topics are the most discussed ? These questions need to be addressed, and a code review tool helps.

There are many code review tools available, most of them are commercial, some are free. The one I introduced in my team was Codestriker. It's a free tool written in Perl. Although its functionality has minimum features, it can be successfully used. Basically, it is a web appplication running on Apache. Although Codestriker has no built-in security support, you can secure Codestriker with Apache's auth module.

Learning and setting up Codestriker took me one day. Configuration is simple but requires knowledge of Linux or Unix. You tell Codestriker what database to use and where is the code repository. We used MySQL and Subversion.

Features of Codestiker
  • The creator of a topic gets notifications by e-mail when reviewers post comments.
  • You can have multiple reviewers
  • All the members of the team can post comments on any topic
  • You can browse changes to code through Codestriker's web interface
  • You can add comments to a single line of code and to a whole topic.


Even though we were using the simpliest code review tool, the quality of code reviews increased dramatically. The code became controlled better by the team lead. More members became involved in code review. Intreraction between offices improved. It turned out that it is possible to misuse code review tool. If the team lead is a dictator and willing to blame and critisize everyone, he can abuse the code review tool. Other members would feel like "the big brother is watching you".The programmers would feel that their every step is under attack, they would loose motivation or leave the company. So be careful with code review tools. Small teams with limited budget who don't want to spend money on commercial code review tools can use Codestiker fine.

пятница, 25 июля 2008 г.

Wonderful Wicket

All ingenious is simple

First, I'm going to tell you how I came across Wicket. A year ago I was working for Ciklum on a project that was basically a Java web application. The application consisted of hundreds of web pages. Although we were using Spring MVC, I didn't feel quite happy, do you know why ? The answer is "reusing a single component in different web pages is not perfect with Spring MVC". This is not weakness of Spring MVC, it's weakness of all workflow-oriented web frameworks. If you need to reuse a component with Spring MVC you need to

  1. Create a reusable tag which contains shared HTML code

  2. Create a reusable method which handles HTTP requests from the tag. It is not easy when you have many nested components on a single web page

  3. Call the method from an MVC controller for every page containing the tag

If you are intensively reusing components on GUI level , then a component framework would better suit your needs.

So I started my research on component web frameworks for Java. My first candidate was JSF. After I had read a book on JSF, I had impression that JSF is overcomplicated technology. Nevertheless I downloaded the latest release of ICEFaces and tried to write a simple "hello world" application with a singe button and a message area. I've spent two hours configuring it and six hours figuring out how to eliminate an exception. I can't remember the exact error, it was something about "invalid JSF context". I came to conclusion that I don't need such a framework. Developing GUI is probably the easiest task and definitely shouldn't be that complicated. Developing custom components for JSF is a nightmare. You would have to write three or four classes for a single component. One of the reasons why JSF is so complicated is that JSF has been designed to support different renderers' families. For example, you can switch from HTML to WML by changing a line in the config file. But I believe that in a couple of years WML will not be widely used, because the number of mobile phones capable of displaying HTML increases every year. Eventually I decided that I can't spend my precious time on mastering JSF.

So I said "No" to JSF. The two other candidates were Tapestry and Wicket. So I downloaded Wicket and started reading documentation. I was really impressed by the framework's simplicity. Configuration is very easy. All you have to do is to add Wicket's servlet to the web.xml.

Another concept I like in Wicket is separation of HTML and Java code, in other words separation of concerns. Imagine your technology is JSP and you have a team consisting of programmers and a web designer. In most cases the web designer has his own copy of GUI consisting of static HTML pages, so-called "prototype of GUI". If any changes to HTML code are required, then the web designer updates his web site and sends the new version of modified HTML files to a programmer. The programmer finds a single JSP or multiple JSP's to be modified according to the modified prototype. The programmer modifies JSP's. I believe that this approach is completely wrong. If you are using Wicket, forget about this slow and ugly way of modifying HTML. Just let the web designer to modify HTML, that's all. No programmer's assistance is needed to modify HTML, and I believe it's great !

If you are familiar with Swing, then mastering Wicket will be very easy for you. Spring and Wicket are very similar. Swing JPanel is like Wicket Panel, Swing Button is like Wicket JButton. Very simple. If you want to handle a form's submission, just add an event listener to the form's button, just like in Swing. Working example is available at http://www.wicketstuff.org/wicket13/echo

Wicket is different from javascript - oriented frameworks like GWT or Echo. GWT components are rendered with javascript, while Wicket's components are mainly pure HTML. Web pages built with Wicket components can be indexed by search engines while GWT pages can't.

Wicket integrates with Spring, has support for internationalization and security. If I were to start a new web project now, I would definitely choose Wicket.