Thanks codehaus and all the best!

It's a wonderful life, isn't it? Well, not exactly...

Well, maybe.

Maybe there's something true about what Joel writes and it reminds me a lot about many situations that I have experienced directly. Hypothetical examples really suck because they are never contextualized and characterized well enough, but loosing a lucrative deal or, even worse, loosing an existing customer in order to stick to the plan very rarely seems a good call to me. Agile or not.

Well, if you know me you may probably think that I'm just a sarcastic bastard, but I swear, that's not the case. If you hate me, you may probably think that, as a typical XP obtuse zealot that has spent every single day of his last 5 years by implementing, studying, refining all that agile crap without selling 1 single day of consultancy, I've just got what I deserve... maybe you're right, I don't know, I'm not that enlightened like Steve, but that's not the point.

I gave a talk on the 7th Java Developers' Conference in Korea yesterday. The conference is annually held and it is one of the biggest IT conferences here. This time about 3000 people attended.

This is an amazing report, worth to read and many things to remember if you want to propose a lively talk to your next conference.

Each team has a 4' x 6' rolling white board on one side with cork board on the other side, plus we have a couple of spares when needed. Some of the teams use XPlanner, some use Excel, some use cards, most use multiple methods to maintain stories. Most of our charts and graphs are on the intranet, so our remote customers can see them.

I am following the Erdos model and have decided to donate my brain to the XP board. I have posted a message on the board offering my free services. I cannot find a position as a developer so might as well give it for free in order to do what I enjoy the most.

I'll keep and interested eye on it.

I have collected all the different versions of the code that I was developing during my session, I have cleared them a bit (ie: I have removed insignificant steps, typos, etc.) and I have written a small comment for each step. What I have obtained is a sequence of 49 steps, made by 42 live steps and 7 offline to complete the work. What's interesting is that first file was saved at 3:40:48 PM, while the last file at 4:41:06 PM ==> it means 42 steps in 62 minutes. Steps have not all the same length of course, but I can assure you that there are always less than 3 minutes between one step and the next one.

	def is_old_ruby?

	  VERSION < "1.8.0"

	end

	

	require is_old_ruby? ? 'ftools' : 'fileutils'

	

	if is_old_ruby?

	  def pwd

	    Dir.pwd

	  end

	  def mkdir_p(path)

	    Dir.mkdir(path) if !File.exist? path

	  end

	  def cd(path)

	    Dir.chdir(path)

	  end

	else

	  include FileUtils::Verbose

	end

Ugly, but it saved my day.

It took me some more minutes to understand that I needed to invoke shell commands or external programs differently between Windows and linux. Therefore, with a little help from the following method, I've simply modified a few invocations accordingly:

	def is_win?

	  is_old_ruby? ? PLATFORM =~ "mswin" : PLATFORM.match("mswin")

	end

I know I could have done it the same way with other languages, but believe me when I tell you that backward compatibility with statically typed language is a lot more harder, even in the simplest case like this one.

This is another good reason why choosing ruby for your everyday tasks at the border of your programming environment may be a good idea. Even when java pays the bills.

But is this really true?

The third time around, after the Ruby DSL hype had been going around for a while, I decided to use Ruby. This time, I was able to create the DSL in about five minutes. It was readable, and I was able to focus on the end users frame of reference.

The moral of this story is, don't write a mini language if you don't have too. And, don't settle for a simple DSL when a full featured one is needed. Consider extending a GPL into a DSL. Particularly an expressive language that is good at creating a readable DSL -- like Ruby.

Let's put it simple: there is no TDD without refactoring, that is refactoring is a constituent part of TDD, not something beyond TDD that I can consider as an option. TDD micro-cycle is: test => red bar => code => green bar => refactor => green bar. If you don't refactor you are not following TDD.

Period.

Let's consider now that refactoring is OO. There is no refactoring without OO. The smells that you recognize into code are another symptoms for rigidity, fragility, immobility. Every refactoring move is justified by 3 criterias:

• enhance code readability
  
• reduce coupling between classes/modules
  
• enhance cohesion of classes/modules
  

Apart from readability, every refactoring move if correctly applied brings to OO design. What means correctly applied? It means if applying that move is appropriate, that is if it doesn't increase rigidity, fragility or immobility, that is if it doesn't introduce new smells. Refactoring means applying ex-post OO design principles.

Because of these reasons design is typically decomposed in several classes and responsibilities are fine-graned assigned.

Another period.

Is it possible to apply TDD following the functional paradigm? I don't know, my lisp reminiscences are too old. Today I would tend to write OO lisp code, merging together the good of both functional and OO paradigm. I'm quite sure that I would end doing something that is not TDD, probably closely related to, but not exactly TDD for what is commonly meant.

Simple and easy to follow steps to run Fitnesse inside the container:

We want the FitServer class to be invoked inside the web container. Then we can setup remote debugging on the web container and easily debug the fixture, business delegate and actual EJB code. This also helps us to avail all the EJB ref look ups and other container provided services.

Fit has parsing facilities built-in for java scalar types and a few others (ie: java.util.Date). Therefore when you specify values of custom types you have a few alternatives:

• don't use custom types in fixtures, but rely on some other standard representation (ie: a date may be decomposed in 3 integer fields) ==> this seem somehow unnatural and cunning
  
• the fixture can override method public Object parse(String s, Class type) , which will be called polymorphically by TypeAdapter while parsing table contents ==> this is very good when you want to confine parsing facilities in fixtures only, but has the drawback of being limited to one hierarchy line only (unless duplicated in many fixtures, of course)
  
• the custom object T may define a static method like public static T parse(String s) , which will be called via reflection by TypeAdapter ==> this is best choice when you want to reuse the parsing facilities among different fixtures, but has the drawback of pollute application code with parsing services just for testing purposes
  

Third option was perfectly suited for the situation I was facing. As a side-effect I have redefined toString method such that for every T t instance t.equals(T.parse(t.toString())) .

Some months ago there was a discussion on the Fitnesse group concerning the possibility of having pluggable custom TypeAdapter classes, so that every fitnesse project can define its own parsing rules, common for all the fixtures, without polluting domain objects: I think it would be the best possible option, but we have to wait until a plug-in architecture will be defined in Fit for that.

In the end the message is: you can put a lot of extension points (or flexus points) in your design, especially if you are developing a framework. Nevertheless there will always be situations that your design is not able to tackle out of the box. That is to say, your design cannot be closed (in OCP sense) against any changes no matter what. This is true whether you are developing in a traditional, prescriptive manner or if you are an agile, evolutive follower.

Eric Kidd makes a few fair and thoughtful points about ruby and lisp.

1. LISP is a dense functional language.
2. LISP has programmatic macros.

This post has been recognized as well in one of the most important blog of the lisp community. Very good news for ruby diffusion!

Credits to cas for mentioning it.

He's a friend of mine, so the conversation was without any limitation and absolutely confidential. Of course, I cannot disclouse his name, nor company's one.

He is responsible for all factories production. He was helding a similar position at a local level in a much bigger US multinational company, a very very well known one, where he had the opportunity to see lean manufacturing in practice. Before that, he had just studied about lean, but nothing beyond that.

I was asking him: "How much is lean adopted in Italy?"
"Not that much", he said. "There are managers that don't know about it, even if the majority probably knows it. But the problem is that in reality it is not put in practice. There are companies that talk about lean concepts, but they are keeping it only at the surface."
Me: "Does it mean that almost all manufacturing companies are still sticking to Fordism and Taylorism? Or better, are they imitating Taylorism?"
Him: "Yes, sort of. If you are lucky you find somebody who has read something about lean, but not more. To give you an example, I'm looking for 2 Quality Managers for 2 factories, one here in Italy and the other one in [CLASSIFIED]: I'm not able to find anybody with practical experience in lean manufacturing. Only talking about it, trying to picture themselves in good shapes because they have read a couple of books. By the way the position is lucrative, the role is ambitous, but that doesn't help either!"

This situation is pretty common in Italy. There are many sectors where we are simply following many steps back behind other leading nations. This is sad, because there are capable people, willing to try new things, but not enough entrepreneurs or venture capitalists willing to take some risks. In theory we are prepared. In practice we are sleeping. We don't risk that much, but we are constantly declining away. There's an atmosphere that reminds me the fall of an empire, but without any imperial heritage. Well, not recent anyway.

If you are developing software for a living you typically know who he was and how important his contribution to software design has been in the past.

Try to guess who is the actor acting the part of Karol Wojtyla: got it? It's Jon Voight!

I was just thinking how curious is Jon Voight's career, from Midnight Cowboy to the Pope... :-)

This time it was different. We were using Fitnesse like a tool for writing executable specifications (more on this in further posts). It is not interesting here to discuss why we were doing that, but in the end it meant writing tens of AT without even a single line of code. The project itself was just a brainstorming about a possible product, therefore there was no intention (yet) to really code anything. But writing executable specs helped understanding the different areas and functionalities that we eventually need to address.

Whatever the reason, I now have many AT, some of which are really similar to each other. Even more: some of those tests are slightly equal, they look to be different instances of the same pattern. For example: whenever we have forms used to enter new entities (ala DDD), there is always a test that tries to insert duplicated data, check that it fails and check the actual error.

This is just a simple example, but it already contains all the elements that are typical of a pattern language, expressed in the vocabulary of functional elements.

While I'm pretty sure that this concept isn't really new, it seems that it is different from what specified for example with the BuildOperateCheck pattern: this pattern works at the Fit level, and it is so general to comprise almost any Fit test that doesn't follow the other well-known pattern represented by flow-style actions in FitLibrary.

To put it simpler, what I'm trying to say is that there seems to be emerging patterns at the functional level, working at a lower level than general-purpose Fit/Fitnesse patterns. It may also be that specific domains will have their own (even more) concrete patterns.

This opens interesting possibilities.