Beat Fluri's Blog

Yesterday, I received the Clean Code Developer bracelets. Clean Code Developer is an initiative of two German software engineers, Stefan Lieser and Ralf Westphal, to improve software quality in general and source code quality in particular. The foundation of this initiative is the book of our Uncle Bob (Robert C. Martin): “Clean Code.”

To raise the awareness for developing clean code, Stefan and Ralf provide bracelets in different colors. In short, each color represents a particular level of clean code development experience and a certain set of principles to consider in your daily work. That means, you bear a bracelet for 21 days and try for applying the corresponding development principles. After the 21 days you switch the bracelet to the next color, i.e., next level. If you have not been consistent in applying the principles over a day, you should bear the bracelet on the other arm the next day. That should motivate you to apply the principles even more.

Although some of the principles I already use are distributed over different bracelet colors, I started with first level: the red bracelet. Its principles are:

1. Don’t repeat yourself (DRY); one of the pragmatic programmer tips
2. Keep it simple, stupid (KISS)
3. Caution with optimizing code; or à la eXtreme programming: first do it, then do it right, then make it fast
4. Favor composition over inheritance
5. Boy scout rule
6. Root cause analysis
7. Use a version control system
8. Simple refactorings: rename and extract method
9. Reflect your work every day

I encourage you in taking part in the Clean Code Developer initiative. Clean code reflects the passion of the software development craftsmanship. Happy clean coding!

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.