I've attended an Oslo Coding Dojo named "How stateless can you go?" lead by Thomas K. Nilsson. The goal was to write a toString() method for a tree structure printing nodes with proper indentation w.r.t. their depth and then to make it as stateless as possible without any other regard (such as performance or cleanliness of the code).
It was very interesting to compare the original, stateful version and the resulting stateless one and to see the solution in various languages (Haskell, Clojure, Groovy, C#, Java, Scala) - it looked actually pretty similar in all.
What I've learned is that stateless (i.e. functional-style) code looks much cleaner for you get rid of lot of noise such as local variables and loops. In practice it is important to use a language with an efficient implementation of recursion (especially tail-recursion) and with data structures that lead themselves easily to recursive processing, i.e. make it easy and efficient to process the first element of a collection and do that recursively for the rest without modifying the collection (and providing utility methods like each). It is of course best to have languages that support map/reduce.
You can check the slides and various solutions at GitHub and see our primitive and stateless implementations below. (We did it in a nearly TDD-manner, but I won't include the test here as it isn't essential.)
I'm using the term "legacy code" quite a lot, what do I mean by it? I like most the R. C. Martin's description in his foreword to the Michael Feathers' book Working Effectively with Legacy Code:
It conjures images of slogging through a murky swamp of tangled undergrowth with leaches beneath and stinging flies above. It conjures odors of murk, slime, stagnancy, and offal.
Refactoring the "Legacy" Hudson.java with the Mikado Method as a Coding Dojo
April 16, 2011
I'm preparing a coding dojo for my colleges at Iterate where we will try to collectively refactor the "legacy" Hudson/Jenkins, especially Hudson.java, to something more testable, using the Mikado Method. I've got the idea after reading Gojko Adzic's blog on how terrible the code is and after discovering the Mikado Method by a chance. Since a long time I'm interested in code quality and since recently especially in improving the quality of legacy applications, where "legacy" means a terrible code base and likely insufficient tests. As consultants we often have to deal with such application and with improving their state into something easier and cheaper to maintain and evolve. Therefore such a collective practice is a good thing.
The Mikado Method
The Mikado Method, which the authors describe as "a tool for large-scale refactorings", serves two purposes:
Continue reading →
Real-world data prove that Agile, BDD & co. work - lecture by G. Adzic
April 14, 2011
I've attended a very inspirational lecture by Gojko Adzic, organized by the Oslo XP Meetup. Many people including some respectable persons claim that Lean, Agile, and high-level testing based on specifications (whether you call it Agile acceptance testing, Acceptance-test driven development, Example-driven development, Story-testing, Behavior-driven development, or otherwise - let's call them all Specification by example) do not work.
To prove the contrary, Gojko has collected over 50 case studies of projects that were very successful thanks to using these methods. In his soon-to-be-published book, Specification by Example (download ch1, a review), he investigates what these projects and teams had in common, which was missing in the failed ones. So it's great for two reasons: It documents how great success you can achieve with Specification by Example and it shows you how to implement it successfully.
CKEditor: Hide some toolbar buttons on a per page basis
April 4, 2011
In my project we had CKEditor with a common toolbar used on many pages and we needed to be able to hide some of the buttons on some pages (e.g. email editor didn't support some functionality/content). It took me a long time to figure a way to do it for CKEditor has no methods for simply removing/hiding buttons from a toolbar. My solution uses the fact that the configuration file can see variables defined in the including page and that it can contain functions - namely there is a function which takes the default toolbar definition and removes from it all the buttons mentioned in a variable, which is expected to be defined in the page.
How to customize CKEditor with your own plugins, skins, configurations
April 4, 2011
This post summarizes what I've learned about customizing the open-source WYSIWYG rich-text editor CKEditor 3.5.2 with one's own plugins, skins, and configurations. There is already a lot of good resources so wherever possible I will link to them and just summarize and/or supplement them. However I've found no overall guide for customizing CKEditor and thus intend to fill this vacancy.
Continue reading →
Code quality matters to the customers. A lot.
April 2, 2011
Some people argue that the main taks of a developer is to deliever working, value-bringing software to the customer and idealistic concepts such as code quality should not hinder that primary task. They acknowledge that it is good to strive for good code quality but say that sometimes code quality must give way to the quick deliverance of outcomes to the customer. After having worked on the code base so rotten that it drove less resistant programmers mad I have to strongly disagree. Code quality is not an abstract concept that has a value only in the developers' world, it is a very real thing, which translates directly to money, namely if you are missing it, it translates into great financial losses over the time.
CKEditor: Collapsing only 2nd+ toolbar rows - howto
April 1, 2011
Normally CKEditor (v3.5.2) hides/shows all the toolbar buttons when you press the collapse/expand button but I needed to always show the first row with "basic tools" and only collapse the second and following rows with advanced functionality tool buttons. CKEditor doesn't have proper support for that but there is a simple workaround.
CKEditor: Scroll dialogs with the page, i.e. not fixed to the middle
March 31, 2011
Dialogs in the popular rich-text wysiwyg JavaScript editor CKEditor 3.5.2 are fixed-positioned and thus when you scroll the editor's page they always stay in the middle as you can see in its demo. That is a problem if the dialog is longer then the height of the page because you will be never able to scroll to its end (where the Ok/Cancle buttons are located).
It could be perhaps solved by adding a scrollbar to the dialog but I solved it by overriding the dialog's position: fixed with position: absolute. Here is how to do it.
Continue reading →
Introduction to ObjectTeams/Java, a Role-Based Approach to Modularity With AOP
March 27, 2011
I've recently stumbled upon an interesting Eclipse project called ObjectTeams/Java (OT/J), which promises improved reusability and maintenance and support for evolvable architectures by creating well-encapsulated bundles of behavior - modules - that can be applied to existing classes (via AOP), when they are in the appropriate context of interaction (and not simply always, as is the case with AOP). An example application is the addition of NonNull constraint to JDT via an OT/Equinox plugin, without the necessity to modify JDT's base classes. I've decided to write down my discoveries as the project is missing a clear and brief introduction (though it has otherwise very good documentation). This blog borrows heavily from [1].
Continue reading →
Why not to be afraid of 2012
March 12, 2011
You don't need to be afraid of the foretold end of the world in 2012. To end the world is a big project and I think we can easily compare it to large scale IT projects. Consequently:
Such a large-scale change certainly wont't be delivered on time. Most likely it will take several times longer, i.e. we can expect it around 2020 earliest.
Anyway it will be necessary to downsize it considerably, so don't expect a complete destruction of everything to take place.
Most likely the project will be canceled at the end.
Hidden Dependencies Are Evil - Arguing With The Clean Code (Slightly)
February 19, 2011
Hidden dependencies are evil because two pieces of code influencing invisibly each other make it very hard to understand what the code is doing. There is an example of an unresolved hidden dependency in the presumabely perfected code in Clean Code's chatper 14: Successive Refinement. When I wrote the first draft of this post I thought I´d be arguing with the author on this point but after reading the next chapter (15) I found him propagating the very same idea. Of course no code is ever perfect but anyway I believe this is something that should have been improved. The final code actually looks really well, it's short, clean, and expressive, but there is this one thing that really troubles me for I find it difficult to understand (and thus quite "unclean"), and that is the method parseArgumentStrings. Perhaps I'm not smart enough but clean code should be dummy-proof anyway :-). The problem is caused by a hidden dependency between methods of the main class Args and between this class and another one, which is modifying Args' internal state variable.
Continue reading →