An image of the Artemide Tolomeo lamp

Last week I not only finally managed to get my beloved reading lamp repaired, of course an Artemide Tolomeo ;-) , but also to utilize the newly provided cozily, brightly, and energy-savingly lit space to finish the book I had started the week before. And because I am excited about it, let me share my excitement with you:

The book title “Scrumban” is the combination of Scrum and Kanban, two management methods. Scrum is one of the predominant inhabitants of the Agile management method zoo, while Kanban originates from the lean management revolution attributed to the car manufacturer Toyota. >> more…

Refactoring as one of the methods of agile development is part of our everyday practice. It consists in well-defined (often small) changes to the code without altering functionality. One goal is to make the code more clearly saying what it does. Refactoring in this sense is often done while exploring the code before its going to be changed. It shows once more the advantages of bottom up approaches, as small steps are less likely to break the code, while nevertheless in the long run not only leading to better local understandability but to better global structure.

Martin Fowlers “Refactoring: Improving the Design of Existing Code” from about 10 years ago is considered the canonical reference on the topic. And yet with this long history its fun to read, especially if one likes to know exactly whats going on inside those magic refactoring functions from our modern IDEs. All those refactoring methods are shown broken into small steps. By expressing them this way Fowler laid the groundwork for our today’s fancy refactoring tools. >> more…

Do you know those books that make you want to grab a computer and start coding – and you only hold off, because there are more interesting things to come?
Those books, that confirm your “I always thought it should be like this” feelings and add a lot of new thoughts and knowledge to that?
Those books you somehow need to tell others about?
This is one of them.

It starts with an overview what Clean Code is and how to achieve it, neglecting not even the simplest things like naming, formatting or comments. I liked the Boys scout rule best which says: “Always check-in the code a little cleaner than you checked it out” (of course, originally it’s about campgrounds). >> more…

While looking up some svn commands, I recently stumbled upon this free book. After skimming over it one cloudy Sunday afternoon, I’d say it’s a really nice introduction. I especially recommend it to Subversion users who didn’t consider it necessary to read any documentations on Subversion – just like me. After reading the book I gained a lot of confidence using SVN, not being afraid to break something any more.

The book was written by members of the Subversion development team and focusses on the command line usage of SVN on unix. It’s style is enjoably matter-of-factly, but never boring. >> more…

The thing I used to hate most in books about programming are typos in the code. Now that I have read “Hardcore Java” I have a new most hated thing: “best practice” tips that are in fact “bad practice” (or worst?). And the book has plenty of errors in the code and in the text as well.

The author’s suggestion to speed up internationalization is to use a java file which contains all the properties again as String constants (so you have another place to forget, when you insert new properties). Those constants are filled at compile time – no chance to switch languages after the build.

He also suggests to make methods protected instead of private, because some day, maybe, someone might want to inherit from that method. >> more…