Beat Fluri's Blog

It took me quite some time to replace the Clean Code Developer bracelet; it took me way more time than the usual three weeks because 1) the principles are fundamental and 2) I didn’t have much opportunity to use them all. But, now, I think it’s definitely time to switch from the yellow to the green bracelet. The principles and practices of the green bracelet are:

1. Open closed principle: open for extension, closed for change (Object-Oriented Software Construction by Bertrand Meyer)
2. Tell don’t ask
3. Law of Demeter: Personally, I don’t think this principle can be used steadily nowadays. If you work with frameworks, you seldom have a chance to follow this principle striclty.
4. Continuous Integration: I recommend the article of Martin Fowler for a very good introduction and the Podcast fom se-radio.net For our project, we use Hudson as the continuous integration server.
5. Static code analysis
6. Inversion of Control Container
7. Pass knowledge
8. Measure bugs

It’s time to replace the Clean Code Developer bracelet again. The next color, and grade respectively, is the yellow bracelet. Now, the principles become more interesting; The yellow bracelet principles are the foundation of clean object-oriented design. Although they are not that easy to fulfill every time, they should be followed as eagerly as possible. The principles and practices are:

1. Interface Segregation Principle: Clients should not be forced to depend upon interfaces that they do not use.
2. Dependency Inversion Principle: a) High level classes should not depend upon low level modules. Both should depend upon abstractions. b) Abstractions should not depend upon details. Details should depend upon abstractions.
3. Liskov Substitution Principle: a) subclasses have to fulfill the invariants of the superclass. Post-conditions of methods in the superclass have to be fulfilled by overriding methods in subclasses.
4. Principles of Least Astonishment: Avoid side-effects. Use, for instance, the command and query separation principle of Bertrand Meyer (Object-Oriented Software Construction).
5. Information Hiding Principle: Well, that’s not a principle, that’s an order
6. Complex Refactorings: See the Refactoring book by Martin Fowler, his Refactoring Web site, or the Refactoring to Patterns book by Joshua Kerievsky.
7. Automated Unit Tests
8. Mockups: For Java I recommend JMockit or mockito.
9. Code Coverage: I recommend Cobertura (free) or Clover (commercial) which both integrate nicely into Hudson.

Today I gave a seminar on software testing for PhD students and professionals at the University of Zurich. During the seminar, I used the uDoo demo application to show how to use Maven and Hudson for automated testing.

The continuous integration server Hudson knows several ways to trigger a build. If you’d like Hudson to build your project when the source-base changes and you don’t want to let him poll your Subversion periodically let Subversion trigger the build upon commit. To do that, first, configure your job in Hudson (Job -> Configure -> Build Triggers) with “Trigger builds remotely (e.g., from scripts)” (”uDoo” is the job name, so replace it with your job name):

Second, configure a post-commit hook in your Subversion repository: In the repository directory of your Subversion-server, a directory hook exists. In this directory you may already have a file post-commit with 744 permissions. If not, a file post-commit.tmpl exists. In that case, copy the file and change the permissions:

$ cd path/to/your/repository/hook
$ cp post-commit.tmpl post-commit
$ chmod 744 post-commit

To trigger the build via Subversion, just put the following line at the end of the post-commit file.

wget -b http://HUDSON_URL/job/JOB_NAME/build?token=my_automated_build > /dev/null

That’s it.