Pomme::TAB

My team works in short iterations at the end of which we should be able to release a new version of the software with added value.

To facilitate the generation of release notes, another team I was observing is using markups in their version control commit message: they add [R] in the commit message to denote the addition new features to the repository.

I thought it was a good idea and introduced it as a version control standard in my team.
After a couple of iterations, there weren’t many [R] in the commit messages.

We found ourselves sometimes shying away from adding an [R] to the commit message, as we’re not always sure a feature is done or not. Also we do commit often, I’d say compulsively, at various steps of our work: it’s easy to commit the last chunk without realizing it’s the last. It is also easy to mark a commit with [R] on a chunk of code for which some files are accidentally missing from the commit.

After further investigation, I discovered a difference in branching strategy between the two teams:
In my team we branch on ad-hoc basis when we are about to start a risky task, but keep working on trunk for work with limited scope and impact. The other team is systematically creating branches for ANY new work they are doing, which means that merging branches (after running the test suite on that branch) to trunk define what is a completed feature and the [R] mark tends to be found on commit message for merges.

Since we are not applying a branch for every feature policy we need to find other ways to identify task done in an iteration. What we are doing though is acceptance test driven development.
It starts with a user story, then the associated acceptance tests. We use fit to write FIT tables for acceptances and write the fixture code for the automated test. The Fit infrastructure is held in Fitnesse which is a wiki-on-steroids with an integrated FIT runner.

Each user story is en entry in the wiki, and Fitnesse allows you to create virtual wiki links on wiki entries which allow easy creation of indexes (dynamically or statically updated).
We are already using these facilities to regroup all completed and validated stories on a page called RunningTestedFeature which is then executed as a suite as part of our continuous integration process for regression testing.

The interesting bit is that in a similar way, for each iteration we can also create a page linking to all stories planned for that iteration at the end of which the suite is executed . The stories whose acceptances tests passed become the bullet point item in the release note if we decide to release.

And there is an added bonus: by keeping these iteration index pages over time, it will help the calculation of velocity as it becomes easy to count how many stories are completed per iteration.

Can you imagine yourself doing your grocery shopping and when you arrive at the till, you pay only by putting your finger on a finger print reader?

According to this spanish article, there is a trial in Germany that seems successful enough to be extended to hundreds of stores.

Apparently the system is found useful by elderly people who don’t have to memorize pin number, or fiddle with coins and notes.

The drawback is that it is one more company to hold your payment details.
In other hand, being brick and mortar, they are not going to disappear the next day.

Source: faq-mac

In response to Chris’ comment about “OO=Evil” and his perl program that he said would have been easier to change had it been written in Java:

by saying “…much easier to alter if it were written in java.” , I think you meant to say ”much easier if it was properly encapsulated, layered with  clearly defined interfaces between components and recognizable abstractions and design patterns”

Object Orientation paradigm is all about that:

• Modularity through encapsulation, abstraction, interfaces
• Re-usability through polymorphisms, inheritance, interfaces

The existence of documented and proven design patterns for OO further helps build and refactor  OO programs.

These are characteristics of OO programming in general, not specific to a language.

You can write proper Object Oriented Programs in perl (see Damian Conway’s PBP or better, the recent effort around Moose)

You can apply the OO design patterns to such perl programs (e.g:  see Object::PerlDesignPatterns)

and they will have the same benefits as properly written Java programs (easy to refactor and to reuse code).

It’s just that:

• Java was designed for Object Orientation, therefore if you write java you are forced into this paradigm. Because of that  they are more tools for java to assist OO programming (especially for refactoring).
• OO in Perl 5 has too many unsatisfactory way to do it and a too verbose syntax

Regarding the talk on Perl’s Worst Practices and the seemingly controversial  “OO=Evil”:

what Mark Fowler  meant is that, OO is not only the paradigm in computing and it’s not always the best way to solve a problem.

You’ve got OO programming, procedural programming, functional programming,  aspect oriented programming,…

The nature of perl doesn’t force you in any of these (”There’s More Than One Way To Do It”), and each of these paradigms are better than the others for their own class of problems.

In other words,  a skilled programmer should use the paradigm that suit best the domain of problems it tries to solve.

Of course, all programmers involved in writing or changing such programs need to have the same understanding of the domain and the best suited paradigm otherwise …

Mark Fowler also hinted at the multiple unsatisfactory ways along with heavy syntax when doing OO with perl 5 as a reason for OO=Evil.

Perl 6 has a new object system which is very good and it is being ported on perl 5 as Moose.

Regarding my views on OO=Evil

I’m a big fan of Object Orientation as implemented with Objective-C or Small Talk.

Java OO is less elegant than
ST/Objective-C’s.

Perl 5 OO implementation upsets me more, but at least I can choose not do OO in perl.
Also, the prospects of Perl 6 and the influence it had on Perl 5 (Moose) is starting to make OO in perl more interesting and desirable.

I think OO is not always the best paradigm, and I’m liking Functional Programming more and more.
Mark Jason Dominus’ High Order Perl  is the  “FP design patterns” reference for perl programmers.

I found it difficult to get my head around (I’m still in the first chapters of HOP) and also I don’t know
the best practices for unit testing FP programs.

I can restrospectively see a bunch of code of mine that might have benefitted of FP. Conversely, I have also unappropriately applied FP to some code. My current project though is better served by using OO.

Going back to OO, Ruby’s OO is close to Small Talk, and Perl 6 is also borrowing things from Small Talk (ST traits will be known as roles in Perl 6) among other languages.

So, OO in Perl 5 is the devil, but often you have to sleep with it and at the end you get used to it.
If I can identify problems in code I create or change that are better solved by FP (I really need to make progress with HOP), I’ll go for it.
In Perl 6,  OO (and FP too) will be dramatically improved.

If you can’t wait, go for Ruby or Perl 5+Moose.