I posted an article about displaying a gitolite-controlled Git repository in Redmine on our company development blog.
Clean Code Developer
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:
- Open closed principle: open for extension, closed for change (Object-Oriented Software Construction by Bertrand Meyer)
- Tell don’t ask
- 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.
- 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.
- Static code analysis
- Inversion of Control Container
- Pass knowledge
- Measure bugs
ambitz
I posted an article about our development infrastructure on our company blog. I explain how we setup Subversion.
ambitz
I posted an article about our development infrastructure on our company blog. I explain how we setup Redmine to have Wiki and issue tracking.
ambitz
Recently, I founded a company with four friends. The company is called ambitz. For a long story short: we’re taking a creative break (i.e., no salary, no company-income, a lot of passion) for about seven months and developing a web platform. We’ve a blog where I’ll frequently post about our technical infrastructure (server, frameworks, development process, tools, etc.) and progress.
Clean Code Developer
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:
- Interface Segregation Principle: Clients should not be forced to depend upon interfaces that they do not use.
- 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.
- 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.
- Principles of Least Astonishment: Avoid side-effects. Use, for instance, the command and query separation principle of Bertrand Meyer (Object-Oriented Software Construction).
- Information Hiding Principle: Well, that’s not a principle, that’s an order
- Complex Refactorings: See the Refactoring book by Martin Fowler, his Refactoring Web site, or the Refactoring to Patterns book by Joshua Kerievsky.
- Automated Unit Tests
- Mockups: For Java I recommend JMockit or mockito.
- Code Coverage: I recommend Cobertura (free) or Clover (commercial) which both integrate nicely into Hudson.
Clean Code Developer
Today, I replaced the red Clean Code Developer bracelet the orange bracelet. To admit, I once had to switch the red bracelet from the right arm to the left because I was unable to fully make a root cause analysis: We, some friends and I, have a Linux server that is connected to a ZyWall2 plus router. The router itself is connect in bridge-mode to a DSL modem. That also means, the router sends DNS requests to the modem and gets the answers from the ISP. With that configuration we were able to nslookup domain names but failed using telnet or other network services; the resolution always failed with the message “temporary unavailable.” After two days of Internet research we gave up and hard-coded a public name-server address in the ifcfg-eth0 file.
The new principles of the orange bracelet are:
- One level of abstraction per method
- Single responsibility principle (there should never be more than one reason to change a class)
- Separation of concerns (overlap of functionality between classes should be as little as possible)
- Coding conventions (Checkstyle ftw!)
- Use issue tracking
- Create automated integration tests
- Read, read, read
- Review
Clean Code Developer
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:
- Don’t repeat yourself (DRY); one of the pragmatic programmer tips
- Keep it simple, stupid (KISS)
- Caution with optimizing code; or à la eXtreme programming: first do it, then do it right, then make it fast
- Favor composition over inheritance
- Boy scout rule
- Root cause analysis
- Use a version control system
- Simple refactorings: rename and extract method
- 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!
Seminar on Software Testing
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.

About