Reek for Ruby

Kevin Rutherford's Reek is a great code analysis tool for Ruby.

It's available as gem:
$ gem install reek

$ reek file_or_directory

More info at http://wiki.github.com/kevinrutherford/reek/

HTML Emails: Design like it's 1996

The guys over at mailchimp have some great tips for coding HTML email newsletters.

http://www.mailchimp.com/articles/how_to_code_html_emails/

Email newsletters can be a design nightmare based on the wide number of programs that may render it (Outlook, Outlook 2007, Outlook 2003, Outlook Express, Thunderbird, Apple Mail, Eudora, Lotus, Gmail, Yahoo!Mail, AOL, AOL Web, Hotmail, MSN, Comcast, Earthlink, and on and on and on).

Basically they summed up "as design your pages like it's 1996".

Definition of Done

Kent Beck is the master of abstraction, capturing the essence of complex topics in stunningly simple soundbites. I'm a commited follower of his definition of good code.

Recently on the XP Programming List, Kent provided his current definition of done...

requires no further investment to get the return I anticipated

The full context of Kent's post:

I'm curious who you had in mind as the audience for your definition. My definition of done is "requires no further investment to get the return I anticipated". This definition covers something ugly I throw together to answer a business question and something carefully crafted to provide reliable, efficient shared infrastructure.

http://tech.groups.yahoo.com/group/extremeprogramming/message/152068

Code Coverage Metrics and TDD

I am wary of metrics as a "Done" marker. The most common is something like "code coverage must be at least 75%". That is a strange position to take:

• We are happy with a quarter of the entire codebase remaining untested;
  
• there is no consideration of what should be tested (the hard stuff or the easy stuff).

"I know that half of my advertising is wasted—I just don't know which half."--John Wanamaker

I prefer to use metrics simply for insight into my mastery of practices.

With Test Driven Development (TDD), one should always write a failing test before adding production code. Thus, if I practice TDD perfectly, my code coverage should be 100%.

I never manage to practice TDD perfectly.

Undoubtedly within a programming session, I'll inadvertently add a loop, conditional or exception block without first writing a failing test. This may be because of the language, the IDE or simply a lapse in concentration or an ingrained idiom.

The Coverage metric gives me some visibility of those events. This enhanced awareness may improve my TDD practice.

Agile SOA: WSDL Generated code is not Domain Model code

Over the last 5 years I've worked with companies attempting to combine Agile software development with SOA. From the software development point of view, one of the biggest challenges I've seen is dealing with the conflict arising from "WSDL First" generated code and the reliance on "good code", simple design and automated testing central to Agile software development.

Strategic Service Oriented Architectures (based around WS-* specifications) are usually created "WSDL First". Helper code (normally Java) is generated from the WSDL to allow programmers to build and interrogate service messages programatically.

In an SOA, the WSDL contract is normally based on a solution wide canonical data model. It is tempting to think of the generated code as domain entities. This results in an anemic domain model where domain logic normally residing in domain entities must live in other objects. The reduced cohesion, increased duplication and test complexity results in brittle services that don't cope when service contracts change (they invariably will).

Instead, we should recognize that from the service implementation perspective the generated code represents data transfer objects. When we completely isolate those DTOs (in an anti-corruption layer) we are free to evolve simple (POJO) domain objects resulting in simple, flexible and easy to test service implementations.