<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <parent>
        <groupId>com.company.product</groupId>
        <artifactId>parent-artifact</artifactId>
        <version>1.0-SNAPSHOT</version>
    </parent>

    <properties>
        <gmaven.version>1.3</gmaven.version>
        <groovy.major.version>1.7</groovy.major.version>
        <groovy.minor.version>4</groovy.minor.version>
    </properties>

    <artifactId>child-artifact</artifactId>
    <packaging>jar</packaging>

    <name>My artifact name</name>

    <dependencies>
        <!--
          Groovy runtime is needed when running unit tests written in Groovy using the Maven Surefire Plugin. 
        -->
        <dependency>
            <groupId>org.codehaus.gmaven.runtime</groupId>
            <artifactId>gmaven-runtime-${groovy.major.version}</artifactId>
            <version>${gmaven.version}</version>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <build>
        <!-- 
          Remap the source directories for this project. 
          This is not strictly needed for Maven builds as the gmaven plugin correctly recognizes the groovy directories.
          But unless we do this the maven-eclipse-plugin won't generate the correct src classpathentries in the .classpath file,
          and the Groovy-Eclipse plugin won't correctly recognize Groovy source files, and syntax-highlighting, autocompletion
          etc. won't work.
        -->
        <sourceDirectory>src/main/groovy</sourceDirectory>
        <testSourceDirectory>src/test/groovy</testSourceDirectory>
        
        <!-- Plugin configuration -->
        <pluginManagement>
            <plugins>

                <!-- Tweak the generated Eclipse project to please the Groovy-Eclipse plugin -->
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-eclipse-plugin</artifactId>
                    <configuration>
                        <projectnatures>
                            <!-- Ensure that the Groovy nature is the first one so that the project is recognized as a Groovy project -->
                            <projectnature>org.eclipse.jdt.groovy.core.groovyNature</projectnature>
                            <projectnature>org.eclipse.jdt.core.javanature</projectnature>
                        </projectnatures>    
                                            
                        <classpathContainers>
                           <!-- Add Groovy libs (from plugin) to Eclipse classpath -->
                           <classpathContainer>GROOVY_SUPPORT</classpathContainer>
                        </classpathContainers>

                        <sourceIncludes>
                            <!-- Force the inclusion of Groovy sources in the generated src classpathentries in .classpath -->
                            <sourceInclude>**/*.groovy</sourceInclude>
                        </sourceIncludes>
                    </configuration>
                </plugin>

                <!-- Configure the gmaven plugin -->
                <plugin>
                    <groupId>org.codehaus.gmaven</groupId>
                    <artifactId>gmaven-plugin</artifactId>
                    <version>${gmaven.version}</version>
                    
                    <executions>
                        <execution>
                            <goals>
                                <!-- Add this if Java sources are needed for joint compilation.
                                <goal>generateStubs</goal>
                                -->
                                
                                <!-- 
                                  Don't necessarily need this since Groovy is compiled to Java classes on the fly
                                  at run time, but it helps to catch syntax errors in the scripts at build time
                                -->
                                <goal>compile</goal>
                                
                                <!-- Add this if Java sources are needed for joint compilation.
                                <goal>generateTestStubs</goal>
                                -->
                                
                                <!-- 
                                  Don't necessarily need this since Groovy is compiled to Java classes on the fly
                                  at run time, but it helps to catch syntax errors in the scripts at build time
                                -->
                                <goal>testCompile</goal>
                            </goals>
                        </execution>
                    </executions>
                    
                    <dependencies>
                        <dependency>
                            <groupId>org.codehaus.gmaven.runtime</groupId>
                            <artifactId>gmaven-runtime-${groovy.major.version}</artifactId>
                            <version>${gmaven.version}</version>
                            <exclusions>
                                <!-- 
                                   Ensure we always use the latest groovy version, 
                                   rather than the one that happens to come with gmaven
                                 -->
                                <exclusion>
                                    <groupId>org.codehaus.groovy</groupId>
                                    <artifactId>groovy-all</artifactId>
                                </exclusion>
                            </exclusions>
                        </dependency>
                        
                        <dependency>
                            <groupId>org.codehaus.groovy</groupId>
                            <artifactId>groovy-all</artifactId>
                            <version>${groovy.major.version}.${groovy.minor.version}</version>
                        </dependency>
                    </dependencies>

                    <configuration>
                        <providerSelection>${groovy.major.version}</providerSelection>
                    </configuration>
                </plugin>

            </plugins>
        </pluginManagement>
 
        <!-- Activate the gmaven plugin -->
        <plugins>
            <plugin>
                <groupId>org.codehaus.gmaven</groupId>
                <artifactId>gmaven-plugin</artifactId>
            </plugin>
         </plugins>
    </build>
</project>

I love training. I love getting in a room, with smart passionate people who are looking for an edge, and collectively finding better ways to serve our customers.

That’s why I am so excited to offer a brand new course this year called the Art of the Kickstart.

Focused 100% on agile project chartering and inception (something most agile methods are silent on) the Art of the Kickstart is a quick, no-nonsense way to build your first agile project plan.

Attendees will be ask to bring an idea for a project they’d like to deliver, and over the course of the day they will create their very own agile project plan based on the material covered in the course. How cool is that?

If you start projects, or or just looking for a better way to set expectations going in, check out the Art of the Kickstart.

As I briefly mentioned in this post I founded a company called OSWay – The Open Source Way – back in 2000 with a friend of mine, exactly 10 years ago!

A bit of history: in 1997 I went live with my first ever website on Geocities, it was called C++Warriors and it was all about…C++ News, articles and tutorials were in Italian and that was a scarse resource at the time so much so that it got featured on a few magazine (the physical ones!) and got quite some traction. That’s when I met all kinds of interesting people like Alex Martelli of Python and Google fame (at the time he was able to spit out a 30-part tutorial on Win32 programming in a matter of days) and Ugo Landini to name a few.

In 1998 I started thinking about the success of C++Warriors and decided that if a little amateurish website about C++ was so successful it was due to the sheer lack of programming resources in Italian and I started planning what would then become Programmazione.it in 1999 (although I have nothing to do with it since 2003 it still exists and it’s 11 years old now!): the first Italian website about programming with news, articles, tutorials and soft dev product reviews all in Italian.

To do that I needed to find people willing to write and publish material in Italian about as many programming languages as possible and that’s when I met Filippo on the #programmazione IRCNet channel in 1998 who will then become my business partner in both Programmazione.it and OSWay (I now regret a lot letting osway.com, .net, .org and .it expire a few years ago )

At the end of 1999 Filippo and I also started working together for a few customers and came up with a product idea around “making information free”, sharing and collaborating on-line, etc, etc (all pretty common stuff nowadays), founded OSWay S.r.l., sold part of it to a public company to get some capital and invest it into the product development. We eventually froze the product and kept working as a software house specialised in the use of Open Source. We did all sorts of things from partnering with SuSe Italy, to developing the world first Kylix enterprise-grade POS application (there used to be our case history on Borland‘s website before the CodeGear split), community websites in Java and PHP (Freestation.it), Linux-based embedded software for touch-screen, industrial-rugged appliances and more.

We started working on the product a few months before incorporating but we eventually incorporated in September 2000, exactly 10 years ago!!

There are many noteworthy things about that venture, including the fact that Open Source was at the center of everything we did, starting from the company very own name 3 years before the Open Source Initiative adopted bylaws and applied for recognition as 501(c)3 nonprofit in 2003 but I just wanted to celebrate the 10th aniversary with a post and this is it

UPDATE: Filippo dug out the flash teaser that we prepared in 2000 for OSWay and the product. Yes, it’s flash and yes it’s heavy but it’s still beautiful!

Warning: there is sound and at the end it tries to redirect you to a page that clearly doesn’t exist anymore….

In this part lets write our own middleware.

From part4 you will remember,

“Middleware are functions that could be chained together to process a request. Middleware functions can take any number of arguments, but the spec stats that first argument should be a handler and function should return a handler. An example for middleware is logging all requests that comes to your webserver.”

1) Create a namespace for middleware

Create src/address_book/middleware.clj

(ns address-book.middleware)

(defn- log [msg & vals]
  (let [line (apply format msg vals)]
    (locking System/out (println line))))

(defn wrap-request-logging [handler]
  (fn [{:keys [request-method uri] :as req}]
    (let [resp (handler req)]
      (log "Processing %s %s" request-method uri)
      resp)))

Our wrap-request-logging is a middleware which takes a handler and returns an handler.

2) Add our middleware to our chain of handlers

Edit routes.clj

(ns address_book.routes
  (:use [compojure.core])
  (:require [address-book.address :as address]
            [address-book.middleware :as mdw]
            [compojure.route :as route]
            [clj-json.core :as json]))

(defn json-response [data & [status]]
  {:status (or status 200)
   :headers {"Content-Type" "application/json"}
   :body (json/generate-string data)})

(defroutes handler
  (GET "/addresses" [] (json-response (address/find-all)))
  (GET "/addresses/:id" [id] (json-response (address/find id)))
  (POST "/addresses" {params :params}  (json-response (address/create params)))

  (route/files "/" {:root "public"})
  (route/not-found "Page not found"))

(def address-book
     (-> handler
         mdw/wrap-request-logging))

3) Test our middleware

Now start your server and you can see all requests are getting logged. This is very powerful feature. We can do security etc using middleware. Ring and Compojure comes with some useful middleware. Check them out.

In next part we will implement edit  and delete functionalities.

Source code is now available at github. Created branches for each part.

• Hacker News | Ask HN: Are there any good online communities for UX design?
  Links to good UX communities

Courtesy of Brian Winquist, the Manifesto for Half-Arsed Agile Software Development.

Last year I wrote about how we are doing planning all wrong, or rather, how we seem to focus on the wrong things when we do planning. We obsess about stories and story points and estimation, because that’s what we’ve been taught to do. It reminds me of the story about a man who comes across a drunk standing under a street lamp at night time, staring at the floor. The drunk says he’s looking for his lost keys, and the man says: well they are obviously not here under the lamp or we would see them. No, replies the drunk, I dropped them over there, but it’s dark over there so I decided to search over here instead.

Our street lamp is the Planning Game, which involves writing Stories and Estimating, using Planning Poker or other Estimation Techniques (everything in caps appears in the Agile Literature, and so has been deemed Official).

I suggested we are failing to use the planning time effectively, and that we should be devoting the time to finding out as much useful stuff as we can while everyone was in the same room, and I called this Deliberate Discovery. Marc McNeill commented: “Deliberate discovery. As opposed to accidental discovery? Or any other sort of discovery? Why add the extra word ‘deliberate’?”

Accidental discovery

If you do something a bunch of times, you will learn more and more about it. Probably. Potentially. Maybe. Ok, if you do something a bunch of times and unexpected things happen you will learn. If you just do the same thing over and over again, you will probably get better at performing that sequence, but you won’t learn anything new. The pragmatic programmers describe this as the difference between ten years’ experience vs. one year’s experience ten times.

Learning comes from experiencing the unexpected. As the saying goes: “Good judgement comes from experience. Experience comes from bad judgement.” When you receive an unfamiliar outcome you have to alter your model of the world to accommodate it (or dismiss the encounter as a fluke and only seek out reinforcing data – this is known as confirmation bias and is a great way to not learn). In Zen teaching this moment of enlightenment – of evolving your model of the world – is known as satori, and Zen students strive to induce these moments of satori by the use of koans. Similarly, the Dreyfus model of skills acquisition describes an Advanced Beginner as someone who is starting to put rote-learned rules into context – understanding where they do and don’t apply. This again can only happen when the learner experiences situations outside what they already know (which is why artificially constraining Best Practices can stifle learning).

This implies the student can accelerate their learning by actively seeking out encounters where they are likely to learn. This is the difference between accidental and deliberate discovery.

“Learning is the constraint”

Liz Keogh told me about a thought experiment she came across recently. Think of a recent significant project or piece of work your team completed (ideally over a period of months). How long did it take, end to end, inception to delivery? Now imagine you were to do the same project over again, with the same team, the same organisational constraints, the same everything, except your team would already know everything they learned during the project. How long would it take you the second time, all the way through? Stop now and try it.

It turned out answers in the order of 1/2 to 1/4 the time to repeat the project were not uncommon. This led to the conclusion that “Learning is the constraint”.

Edit: Liz tells me the thought experiment and quote originated with Amr Elssamadisy and she heard about it via César Idrovo.

If we assume the only difference is that the second time round you have learned about the problem, this would suggest that the biggest impediment to your throughput was what you didn’t know. That’s not to say you spent all the extra time busily learning stuff. Heck that’s fun and what’s more it’s even useful! More typically you probably spent it thrashing around trying to find a way forwards, or mired in meetings where you were trying to figure out the other guy’s agenda so you could get past another roadblock, or going down a path that was always destined to be a dead end had you only known it. Or trying to work out for the umpteenth time how stupid Java NIO sockets work. So it’s not really learning that’s the constraint – it’s ignorance. More accurately, it’s ignorance about specific aspects of the problem at hand. In other words:

Ignorance is the single greatest impediment to throughput.

Ignorance is multivariate

Ignorance applies along multiple axes. You can be ignorant of the particular technologies you are using, ignorant of the breadth of technology options available to you, ignorant of the domain, ignorant of the ways in which you could address the problem or opportunity, ignorant of a better way of articulating the problem – a better model – that would make the solution obvious, ignorant of the people in the team – their aspirations or fears, their motivation, their relationships with one another and out into to the wider organisation, ignorant of organisational constraints, ignorant of third party integration risks, ignorant of who are the people you should be building relationships with, ignorant of the delivery methodology, ignorant of the culture of the organisation. I’m just scratching the surface here – I’m sure you can imagine many other factors that could affect our ability to deliver and about which we will be more or less ignorant.

More insidiously, you are usually ignorant of how ignorant you are, and rather than making you more wary, this second-order ignorance actually makes you more likely to rush in like the proverbial fool. This is beautifully summed up in this quote from IRC snippets site, bash.org:

<Pahalial> "ignorance more frequently begets confidence than does knowledge" - Charles Darwin
<kionix> wtf? begets isn't a word. quit trying to make up words [...expletive...]

Discovery is non-linear and disjoint

Now, think back to that project you just completed. Did your ignorance decrease consistently and linearly along all these axes? It’s fairly unlikely. What probably happened was that at various points – some more memorable than others – you had sudden insights or realisations, that either came to you or were thrust upon you by circumstance. Chances are that a lot of this unplanned learning happened fairly late in the day, accompanied by much disbelief, anger, and probably all the other stages of grieving too, as you come to terms with the death of your strongly-held model of How Things Ought To Be.

So for any single factor, you start the project with a particular level of ignorance, and it decreases in “bumps” – in a disjoint fashion – with each learning episode, until at the end of the project it is at another, lower level. Of course many of these factors are interrelated, so in a single episode you will typically learn about several different things – your ignorance of various factors will decrease by different amounts simultaneously. In reality much of this learning is at the whim of the Project Gods, and largely out of your control. How could you have possibly guessed that the third party API would be that different from the spec? Who knew Dave’s wife would choose that weekend to have the baby?

Well actually you could have. Ok, you couldn’t have known that those things would happen, but you would be insane – or rather “normal” – not to think something would happen, and this is the crux of Deliberate Discovery.

What if you assume something bad will happen?

We have a built-in mechanism for mindless optimism. It’s called attribution bias, and we use it to protect our fragile egos from the big bad reality out there. You can read more in Cordelia Fine’s fascinating book A Mind of Its Own, but in short, it means we assume when bad things happen to other people, they probably deserve it. They screwed up, or they didn’t plan ahead, or, well, any number of reasons. But when bad things happen to us, well that’s different. We couldn’t possibly have seen that coming! That could have happened to anyone. Poor us.

We are susceptible to attribution bias when we estimate (as Linda Rising has pointed out), and when we assess risk, and we are therefore constantly amazed – and let’s face it, a little disappointed – when bad things happen on our projects. Here’s another thought experiment: What if instead of hoping nothing bad will happen this time, you assumed the following as fact:

• Several (pick a number) Unpredictable Bad Things will happen during your project.
• You cannot know in advance what those Bad Things will be. That’s what Unpredictable means.
• The Bad Things will materially impact delivery. That’s what Bad means.

How would this affect your approach to the project?

Finally, deliberate discovery

So, I think we’ve been looking in the wrong place. Methodologies, practises and patterns for delivery are all well and good, but they don’t take into account the single biggest limiting factor to successful delivery. Let’s assume that during the life of the project our ignorance will reduce across a number of axes that are relevant to our project. Let’s also assume that ignorance of certain factors right now are the things currently limiting us the most. Let us further assume that we probably don’t know which ones those magic enabling factors are: we are second-order ignorant of which factors are currently the most constraining. Once we realise what these are, we can apply methodology to consistently move forwards, but until we do, we’re shooting in the dark.

Surely it makes sense to invest effort in firstly discovering which aspects of delivery we are most critically ignorant of (i.e. both where we are ignorant and where that ignorance is hampering throughput), and further to invest in reducing that ignorance – deliberately discovering enough to relieve the constraint and allow us to proceed. And all the way through the project, day by day, we should be trying to identify where and how ignorance is hampering us. Ideally we want to create as steep a descent as possible for each axis on the curve of ignorance, so we deliberately reduce the degree to which we are constrained by that ignorance, rather than being a victim of circumstance.

This is a skill, and as such is subject to the Dreyfus model. Which means that initially we’ll be rubbish at it. Then we’ll start to figure out how we are rubbish at it, and work on that. Then we’ll figure out some Best Pracises (I’m sorry – it’s inevitable. That’s what Competent people do to “protect” Advanced Beginners), and, hopefully shortly after, figure out ways to subvert those Best Practises to continue getting work done. The hardest part is going to be the damage to our egos as we realise just how systemically poor we are at delivering projects, and how we’ve been staring straight past the problem, because our methodology is always under the street lamp, and we feel safe under the street lamp.

What next?

This then comes back to my original premise last year, which is that during an inception, when we are most ignorant about most aspects of the project, the best use we can possibly make of the time available is to attempt to identify and reduce our ignorance across all the axes we can think of. (Arguably one of the first exercises should be to take a first stab at identifying these axes, and trying to figure out just how ignorant we are. How’s that for an exercise in humility!) Sure, if we stick to the traditional Agile planning model, we will do some discovery as we break down epics into features into stories into scenarios, but how much more could we accomplish if we put that to one side and instead focused on the real deal?

Domain-driven design inventor Eric Evans describes up-front analysis as “locking in our ignorance.” He’s got a point, and it doesn’t just apply to old-school requirements analysis. The death-by-stories planning exercises I’ve seen on many Agile projects bear testament to the same problem.

I hope this has given you an idea of where my head has been at. There is much more to say about deliberate discovery. Think about applying the principle to learning a new language, or picking up a new technology, or a new domain. What could you do to identify and reduce your ignorance most rapidly? Why are rapid-feedback teams so much more successful than long cycle teams? How can we measure ignorance? I’ll be writing more on this topic over the coming weeks and months, and I’ll be talking about Deliberate Discovery at QCon, San Francisco in November.

Thanks to Liz Keogh, Lindsay North, Joe Walnes, Chris Matts, Steve Hayes, Kevlin Henney and numerous others for helping to grow the ideas in this article. And special thanks to Glenn Vanderburg and Mike Nygard for the conversation at JAOO Australia about a unit of ignorance. (That will have to wait for a future article.)

The sentiment in the UX community is pretty clear, that usability thing, yeah we got that. For example, Dana Chisnell recently wrote an article for UX Magazine called Beyond Frustration: Three Levels of Happy Design, while Chris Fahey talked about The Human Interface at the IA Summit, and let’s not forget Kathy Sierra’s thoughts on What comes after usability?

So what does come after usability? This is my initial stab at the answer. I thought that perhaps I should approach it from the psychological point of view by using Maslow’s hierarchy of needs, we are designing for people after all. Here is the (draft) diagram that I came up with:

At the base is functionality – the product must be able to perform a function, otherwise everything else is meaningless.

Then, usability – people should be able to learn/understand how to perform the function

Sociality – here is where things get murky, according Maslow, the third level in the hierarchy is love/belonging. Perhaps a product should provide a sense of belonging. This does not necessarily mean embedding facebook into every system, it could just be aligning with a brand (such as Apple), or surfacing interesting aggregate behaviors.

Self-Fulfillment – I am not sure if perhaps self-fulfillment comes before or after sociality, in some ways they are a bit linked to each other, so the categories aren’t so clear cut. Here I am talking about truly helping the end-user kick ass (channeling Kathy Sierra here), by enabling flow, happiness, personal growth, self-awareness, or behavioral change. In some respects, this is what it truly means to create a place where a user can have an experience.

Generativity – At this point the user feels a sense of ownership and has internalized the value of the product. Its important to provide a feedback channel that helps generate new ideas and excitement, and enables the product an the user to continue to evolve together. This is what it truly means to be viral.

I don’t have all of this worked out in my head yet, so I know that I will be revisiting this concept again in the future. Thoughts?

You can hear my dulcet tones at Ruby5 eposide 106 hosted with Jon “Lark” Larkowski.

It was great fun – he made me do the accent at the beginning and we had a lot of laughs over the “it’s gonna rain” part.

Hope you find it of use and if you have some Ruby news, please do submit stories to Lark.

Handover like a pro

Recently I started to read a book, the one that Christian was praising so many times. I’m just through the first few chapters but already one of the sentences sounds in my head all the time. John Seddon, in “Freedom from Command and Control” writes how there was an improvement made to a process in one of the call centres. He said that “all the information was filed in the form so it was never coming back from the downstream person with the request for missing information”. This one off step was making improvement as it was never coming back.

John explained that it was possible to realise the impact once someone took a step back a took a look at the system and the flow through it as a whole.

This made me think about something that my other colleague, Pat did at work. When he was rolling off the project, he WIKIed all the information about it and left the Spike (proof of concept) code in the repository. He also made some comments in a code, whenever it was not entirely clear of its intention. It was one of the best handovers with no direct contact I was ever involved in.

I realised that the handovers should be looked at from a different perspective.

Typical approach is to … drop whatever at someone and let him finish the work. Whenever more information is necessary, it could be chased.

Instead, I should prepare handover in a way that would make it possible for a person who will pick up the work after, to have a brief look (at the code in my case), realise where the info is (wiki, tests, some comments) and move on with the flow.

Funny enough it encourages some good coding and work practices, like:

• simplicity
• clean and understandable code
• less time context switching and interruptions (own and others)
• tests that ensures functionality and quality
• lack of outdated and non-maintainable documents

Handovers are a problem and should be avoided when possible. When programming is involved, Pairing reduces the danger of the need for them. If not, all the members should concentrate on the most important thing, make sure the work keeps flowing through the system and what could I do to make it happen.

Cheers, Greg

Reading Steven Pressfield’s blog this week I came across a few great quotes and ideas from Erik Proulx on personal motivation.

Steven: Once you find the idea, how do you move forward? In what form does your personal kick in the butt arrive?

Erik: My friend Adam Kuhr told me about a JFK quote, and it pretty much sums up how I confront the Resistance:

“The Irish writer Frank O’Connor wrote how, as a boy, he and his friends would make their way across the countryside. When they came to an orchard wall that seemed too high and too doubtful to try and too difficult to permit their voyage to continue, they took off their hats and tossed them over the wall—and then they had no choice but to follow them.”

Kennedy concluded,

“This nation has tossed its cap over the wall of space, and we have no choice but to follow it.”

Here’s another about what got Erik motivated enough to make a movie after having been laid off:

Steven: When you decided to make “Lemonade,” you had just been laid off, and said “not doing it wasn’t an option.”
What drove you to knock down Resistance, leave your safety zone, and go after something that wasn’t a sure thing?

Erik: Catholic guilt. Let me explain.

I’m not a very devout churchman these days. As an adult, I’ve either come to question most of what I learned in Catholic school or simply dismissed it outright. But there was one lesson that always stuck with me, and it was when Sister Claire told our 4th grade class that we were all endowed with unique talents, and that wasting them was a sin in the eyes of God.

These are just two of many good quotes from Steven’s interview with Eric (full transcript here)

So the next time you find yourself looking for that little extra nudge, you can always burn the boats, or you try throwing your cap over the wall.

Iterable is one of my favorite interfaces in Java. I love the for-each construct:

for (final Type item : iterableOfItems)
    doSomethingWith(item);

Notice what cannot go wrong:

1. I cannot run off the end, or forget to go far enough (no off-by-one bugs)
2. I cannot forget to call hasNext() before calling next() (iterator misuse)
3. I cannot make the wrong cast or pick the wrong container type

I could go on. It is also concise and conveys programmer intention clearly, both wonderful virtues.

How can I make more use of Iterable?

Here is an example of transforming input into Iterable. First the base class:

public abstract class ResourceIterable<T, R extends Closeable>
        implements Closeable, Iterable<T> {
    private final R resource;

    private volatile boolean closed;

    protected ResourceIterable(final R resource) {
        this.resource = resource;
    }

    protected final R resource() {
        return resource;
    }

    protected abstract T getNext()
            throws IOException;

    @Override
    public final void close()
            throws IOException {
        closed = true;
        resource.close();
    }

    @Override
    public final Iterator<T> iterator() {
        return new Iterator<T>() {
            private T next;

            @Override
            public boolean hasNext() {
                try {
                    next = getNext();
                    return null != next;
                } catch (final EOFException ignored) {
                    next = null;
                    return false;
                } catch (final IOException e) {
                    next = null;
                    if (closed)
                        return false;
                    throw new UndeclaredThrowableException(e);
                }
            }

            @Override
            public T next() {
                if (null == next)
                    throw new NoSuchElementException();
                return next;
            }

            @Override
            public void remove() {
                throw new UnsupportedOperationException();
            }
        };
    }
}

And a sample using class:

public class LineIterable
        extends ResourceIterable {
    public AmpsResponseIterable(final BufferedReader reader) {
        super(reader);
    }

    @Override
    protected String getNext()
            throws IOException {
        return resource().readLine();
    }
}

The example is trivial (my actual uses are hiding sophisticated readers of data structures from network connections) but clear:

for (final String line : new LineIterable(someBufferedReader))
    process(line);

However, all use of Iterable is similarly trivial: that's the point if it. The complexity is in extracting objects from the input (though not in this example).

I prefer hard-to-write-easy-to-use code when I make libraries; easy-to-write-hard-to-use just feels lazy (the wrong kind of lazy).

Professor Berri ( of The Wages of Wins fame ) breaks down the previously linked to story about the Pittsburgh Pirates & their incentive to improve.

Meanwhile, over at Slate, Phil Birnbaum ( of Sabermetric Research fame ) really nails the crux of the issue with his take. Especially telling is this quote:

As a result, Tampa Bay’s regular-season operating income declined from $22 million in 2007 to less than $1 million in 2008—which means it cost the team $21 million to transition from cellar dwellers to World Series participants. As amazing as it seems, even after adding in $11 million in postseason earnings, the Rays were more profitable when they went 66-96 than when they went 97-65.

Sobering.

It's not new news, but it was new to me: Maven is switching to Guice to wire itself and plugins. From Sonatype:

1. From Plexus to Guice (#1): Why Guice?
2. From Plexus to Guice (#2): The Guice/Plexus Bridge and Custom Bean Injection
3. From Plexus to Guice (#3): Creating a Guice Bean Extension Layer

The plugin framework is named spice inject and glancing through it's straight-forward glue between Guice and OSGi within a Maven object domain.

It looks very clean. Nice.

CoDe Magazine (for whom I do a back-cover editorial every other month) has been running a different kind of column recently, one which has not only been generating some good buzz, but also offers a unique opportunity for those who are interested in maybe dipping their toes into the technical writing game. This message was posted by Markus Eggers, the publisher of CoDe, on several different mailing lists, and he asked me to spread the word out:

As you may know, each issue of CODE Magazine has a PostMortem column, where the author discusses a .NET related project and points out 5 things that went well, and 5 things that didn’t (we call them “challenges” ;-) ). This column has been pretty popular and provides some great visibility for the author and the companies involved in the project.

We are looking for more authors for upcoming issues. If you are interested, please don’t hesitate to contact me.

For more info on PostMortems, check out this writer’s guide:

http://codemag.com/Write/PostMortem

For an example PostMortem, check out this recent article:

http://www.epsdownloadsite.com/downloads/d1392e8a-ddcc-4507-95e7-5d933574d997/PostMortemExample.pdf

As an added incentive, if you think you have an interesting project that would work well for a PostMortem, but don’t feel like your writing is quite “up to snuff”, feel free to loop me in on the conversation, and at the very least I’ll offer a “pre-editorial review” of the article and offer up some suggestions on how to make it stronger. (But Rod Paddock, CoDe’s editor, is also a pretty good editor, and so you might just submit it to him first to get his take on it.)

In any event, take the shot and see if you’ve got some writing chops in you. :-)

One of my favorite techniques for building trust and demonstrating intent when starting out with a new client is to build them the first version of their application in two weeks.

No it doesn’t have every bell and whistle, and it definitely wouldn’t when any design awards, but putting that first version of working software in their hands after a single iteration can do wonders for you project.

What this does for your team

For your team it sends a message. We are going to move fast.

No time to sit around and naval gaze. The first version of our shippable product needs to be ready two weeks from now.

• That means coding.
• Testing.
• Analysis.
• Design.
• Feedback.

It’s all got to be there for this one thin slice of functionality (usually their most important user story).

That means we are going to have to travel light and drop anything that doesn’t add value.

And if we are going to be adding new features confidently as we go (without paying an exorbitant amount) we are going to need to some practices and discipline around how we change our software.

• Continuously integration.
• Automated builds.
• Automated unit testing.
• Regular feedback.
• Aggressive refactoring.
• Rhythm and ritual.

It’s all got to be there.

This is good because you want your team used to the idea of regularly making changes to a production ready system.

That’s how agile (XP in particular) likes to view systems under development. They are meant to be kept in a state of continuous production readiness. We are simply adding new features every week (starting with the first version after two week).

What this does for your customer

Most customers are blown away when you tell them you are going to delivery the first working version in two weeks.

It gets their attention.

It shows an intent, and fierceness around delivery sorely lacking in our industry.

Regularly producing shippable software changes the game and relationship with your customer. It shows them the importance of their role and highlights the fact they are first class citizens and needed for a successful project.

What this does for you

While I can’t promise you’ll lose weight or it will improve your sex life, I can tell you delivering fiercely will raise your profile and get you noticed where ever you choose to work.

People are going to want to know how you got business to the table.

They are going to want to know how you built a system for them which is exactly what they wanted.

They are going to want to know how you made going live a non-event.

And they are going to want to you do it again, and again, and again.

Look, I get that there may be thousand reasons why may not be practical to deliver your first working version in two weeks.

If this is the case, then think of it more as an attitude.

But you’ll never know unless you take that first step.

Like Henry Ford said: ““Whether you think that you can, or that you can’t, you are usually right.”

Time magazine has a great article about Brazil as the new VC hotspot. The tech sector in Brazil is absolutely scorching hot. In fact, ThoughtWorks just opened a Brazilian office in my girlfriends hometown of Porto Alegre.

The IMF projects that Brazil’s economy — now the eighth largest in the world — will grow by 7.1% this year and soar throughout the decade. A confluence of factors will contribute to growth: abundant natural resources, stable government policies, a sophisticated banking sector, a rapidly growing middle class that now comprises about half the population of 190 million and a surge in real estate and infrastructure development to prepare for Brazil’s hosting the 2014 FIFA World Cup and the 2016 Summer Olympics.

Last year I was able to visit the country for the first time and see just how incredible the growth has been. It’s really amazing to see how the entrepreneurial spirit has grabbed a hold of people down there and is pushing them to make advances in all sorts of industries. It’s really amazing to see them follow in the footsteps of the US.

Of course, they are leaving the US in the dust in some areas:

In Brazil you need to have a strong payback model right at the beginning. VCs won’t wait to see if one day there is an exit for your company since they don’t want the risk. In the U.S., a start-up is cut some slack. It can operate for two years without any revenue. We don’t have that luxury.

It seems as though many are starting off with the idea that profitable & sustainable is the way to go. If this mentality takes hold and spreads, one could easily see Brazil becoming a real profit center and a power in the global marketplace. It should frighten the US to think about what a country the size of Brazil could do with a zero-debt, profit driven focus compared to our concept of debt and bailouts.

In this part we will start implementing Add,  View and View all functionalities.

The services we are going to build are

View All Addresses – GET – http://localhost:8080/addresses
View single address – GET – http://localhost:8080/addresses/:id
Add Address – POST – http://localhost:8080/addresses

Interactive Development using slime

I mentioned in last part that after every change to our code we need to restart our server for our changes to be reflected. This is a pain and against clojure (lisp) philosophy . It would be great if we could eval our modified buffers in emacs and those changes reflected immediately in our jetty server. Thankfully there is very easy way to do this.

In core.clj we are starting jetty adapter. We can start this jetty server in background using future and reload the namespace that we changed. This way we can do interactive development without restarting our server.

PS: Make sure you have emacs setup with slime. I feel emacs is the best IDE for clojure. Again this is my opinion. There are lot of information on how to do this.

I talked about jetty adapter. It is time for us to look at some what little deeper in Compojure.

Compojure

Compojure is based on a library  called Ring. In fact most of clojure web frameworks are based on Ring. So to understand Compojure, it is important to understand Ring.

Ring has three components.

1) Handlers:

Handlers are main functions that  process a request. We define handlers using defroutes macro.

2) Middleware:

Middleware are functions that could be chained together to process a request. Middleware functions can take any number of arguments, but the spec stats that first argument should be an handler and function should return an handler. An example for middleware is logging all requests that comes to your webserver.  Ring and compojure comes with some standard middleware. We will see in next part how to create our own middleware.

3) Adapters:

Adapters are functions could adapt our handler to a web server. We are using jetty adapter to tie our handler to jetty server.

Refactor code to make it easy for interactive development

Edit core.clj

(ns address_book.core
  (:use [compojure.core]
        [ring.adapter.jetty])
  (:require [compojure.route :as route]))

(defroutes example
  (GET "/" [] "<h1>My Address Book!</h1>")
  (route/files "/" {:root "public"})
  (route/not-found "Page not found"))

(future (run-jetty (var address-book) {:port 8080}))

1) Add swank-clojure to our project

swank-clojure comes with lein plugin which will allow us to start a swank server and from emacs you can connect using slime. There are lot of documentation about swank-clojure and slime. Let me know if you need more information. If I see enough interest, I could blog about it or at least point to some good resources.

Edit project.clj

(defproject address_book "1.0.0-SNAPSHOT"
  :description "Address Book"
  :dependencies [[org.clojure/clojure "1.2.0"]
                 [org.clojure/clojure-contrib "1.2.0"]
                 [compojure "0.4.1"]
                 [ring/ring-jetty-adapter "0.2.3"]]
  :dev-dependencies [[swank-clojure "1.2.1"]])

and run

lein deps

Now you should be able to start swank server using

lein swank

2) Break core.clj into different namespaces

Current core.clj is doing two things. Setting up routes and starting jetty server. Lets break it into web_server.clj and routes.clj

rm src/address_book/core.clj

create src/address_book/routes.clj

(ns address_book.routes
  (:use [compojure.core])
  (:require [compojure.route :as route]))

(defroutes address-book
  (GET "/" [] "<h1>My Address Book!</h1>")
  (route/files "/" {:root "public"})
  (route/not-found "Page not found"))

create src/address_book/webserver.clj

(ns address_book.webserver
  (:use [compojure.core]
        [ring.adapter.jetty]
        [address_book.routes :as routes]))

(future (run-jetty (var address-book) {:port 8080}))

3) At last lets create our Address namespace

In this code, I am going to use atoms for persistence. In future I will probably show how we can persist in mysql db using clj-records.

create src/address_book/address.clj

(ns address-book.address
  (:use [address-book.utils number])
  (:refer-clojure :exclude (find create)))

(def STORE (atom {:1 {:id :1 :name "Siva Jagadeesan" :street1 "88 7th" :street2 "#203" :city "Cupertino" :country "USA" :zipcode 98802}}))

(defn create [attrs]
  (let [id (random-number)
        new-attrs (merge {:id id} attrs)]
    (swap! STORE merge {id new-attrs})
    new-attrs))

(defn find-all []
  (vals @STORE))

(defn find [id]
  ((to-keyword id) @STORE))

(defn update [id attrs]
  (let [updated-attrs (merge (find id) attrs)]
    (swap! STORE assoc id updated-attrs)
    updated-attrs))

(defn delete [id]
  (let [old-attrs (find id)]
    (swap! STORE dissoc id)
    old-attrs))

Create utils/number.clj

(ns address-book.utils.number)

(defn to-keyword [num]
  (if-not (keyword? num)
    (keyword (str num))
    num))

PS: I am not writing tests to keep this blog short. But I would advice everyone to write tests.

4)   Lets update routes for add, view and view all functionalities

</span>
<pre>(ns address_book.routes
  (:use [compojure.core])
  (:require [address-book.address :as address]
            [compojure.route :as route]
            [clj-json.core :as json]))

(defn json-response [data & [status]]
  {:status (or status 200)
   :headers {"Content-Type" "application/json"}
   :body (json/generate-string data)})

(defroutes handler
  (GET "/addresses" [] (json-response (address/find-all)))
  (GET "/addresses/:id" [id] (json-response (address/find id)))
  (POST "/addresses" {params :params}  (json-response (address/create params)))

  (route/files "/" {:root "public"})
  (route/not-found "Page not found"))

(def address-book
     handler)

Compojure comes with GET, POST, PUT, DELETE, HEAD and ANY macro to define routes. These macros are self explanatory. Currently we have used GET and POST to define our routes.

Parsing Parameters

Compojure binds request parameters to params.

To get all parameters from request you can destructure map like we did in

POST "/addresses" {params :params}  (json-response (address/create params)))

To get particular parameters from request you can use Compojure sugar syntax like we did in
[sourceode](GET “/addresses/:id” [id] (json-response (address/find id)))[/sourcecode]

5)  Lets build our front end
PS: front end code is a hack. Please don’t follow these codes as a good practice.

Edit public/index.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
        "http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
<head>
	<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
	<title>My Address Book</title>
        <link href="/css/address.css" media="screen" rel="stylesheet" type="text/css" />
        <script src="/js/jquery-1.4.2.min.js" type="text/javascript"></script>
        <script src="/js/jquery-ui-1.8.1.custom.min.js" type="text/javascript"></script>
        <script src="/js/jquery.form.js" type="text/javascript"></script>
        <script src="/js/address_book.js" type="text/javascript"></script>
        <script src="/js/address_list.js" type="text/javascript"></script>
</head>
<body>
<div id="wrap">
	<div id="header"><h1>My Address Book</h1></div>

	<div id="main">
          <table id="address">
            <tr><td>Name</td><td id="name"/></tr>
            <tr><td>Street1</td><td id="street1"/></tr>
            <tr><td>Street2</td><td id="street2"/></tr>
            <tr><td>City</td><td id="city"/></tr>
            <tr><td>Country</td><td id="country"/></tr>
            <tr><td>ZipCode</td><td id="zipcode"/></tr>
          </table>
	  <table id="address-list" border="1" width="100%" rules="rows" align="center">
            <tr>
              <th>Name</th>
              <th>Action</th>
            </tr>
            <tr>
              <td >row 1, cell 1</td>
              <td align="center">row 1, cell 2</td>
            </tr>
          </table>
	</div>
	<div id="sidebar">
          <form id="address-form" class="formular" method="post" action="/addresses">
	    <fieldset class="login">
	      <legend>New Address</legend>
	      <div>
		<label for="name">Name</label> <input type="text" id="name" name="name">
	      </div>
              <div>
		<label for="street1">Street1</label> <input type="text" id="street1" name="street1">
	      </div>
               <div>
		<label for="street2">Street2</label> <input type="text" id="street2" name="street2">
	      </div>
              <div>
		<label for="city">City</label> <input type="text" id="city" name="city">
	      </div>
              <div>
		<label for="country">Country</label> <input type="text" id="country" name="country">
	      </div>
               <div>
		<label for="zipcode">ZipCode</label> <input type="text" id="zipcode" name="zipcode">
	      </div>

              <input class="submit" type="submit" value="Create"/>
	    </fieldset>
          </form>
	</div>
	<div id="footer">
	  <p><a href="TechbehindTech.com">TechBehindTech</a> -- Siva Jagadeesan</p>
	</div>
</div>
</body>
</html>

Create public/css/address.css

body,html {
    margin:0;
    padding:0;
    color:#000;
    background:#a7a09a;
}
#wrap {
    width:970px;
    margin:0 auto;
    background: #fffeff;
}
#header {
    padding:5px 10px;
    background: #054477;
	text-align: right;
	color: #fffeff;
}
h1 {
    margin:0;
}
#main {
    float:left;
    width:580px;
    padding:10px;
	background-color: #fffeff;
}
h2 {
    margin:0 0 1em;
	background-color: #fffeff;
}
#sidebar {
    float:right;
    width:350px;
    padding:10px;
    background-color: #fffeff;
}
#footer {
    clear:both;
    padding:5px 10px;
    background: #fed47f;
}
#footer p {
    margin:0;
}
* html #footer {
    height:1px;
}

form * {margin:0;padding:0;} /* Standard margin and padding reset, normally done on the body */

legend {
	color:#000; /* IE styles legends with blue text by default */
	*margin-left:-7px;
	font-weight: bold;
	font-size: 20px;
}
fieldset {
	border:1px solid #dedede; /* Default fieldset borders vary cross browser, so make them the same */
}
fieldset div {
	overflow:hidden; /* Contain the floating elements */
	display:inline-block;
	padding: 10px;
}
fieldset div {display:block;} /* Reset element back to block leaving layout in ie */
label {
	float:left; /* Take out of flow so the input starts at the same height */
	width:8em; /* Set a width so the inputs line up */
}

Create public/js/address_book.js

$(document).ready(function() {
    $("#address").hide();
    $("#address-list").showAddressList();

    $(".address-link").live("click",function(e){
        $.getJSON($(this).attr("href"), function(json) {
            $("#address").showAddress(json);
        });
        e.preventDefault();
    });

    $('#address-form').submit(function(event){
        event.preventDefault();
        var $this = $(this);
        var url = $this.attr('action');
        var dataToSend = $this.serialize();
        var callback = function(data){
            $("#address-list").addAddress(data);
        };
        var options = {
            success:   callback,
            url: url,
            type:     "POST",
            dataType: "json",
            clearForm: true
        };
        $(this).ajaxSubmit(options);
    });

});

Create public/js/address_list.js

function action_links(data){
    var link = "<a href=\"\">edit</a> ";
    link += " | <a href=\"\">delete</a>";
    return "edit | delete";
}

$.fn.showAddressList = function(){
    return this.each(function(){
        var that = this;
        $.getJSON("addresses", function(json) {
            $(that).html(" <tr> <th>Name</th> <th>Action</th> </tr>");
            $.each(json,function(i,data) {
                $(that).append("<tr id=\"address-"+ data.id +" \"><td><a class=\"address-link\" href=\"addresses/" + data.id +"\">" + data.name + "</a></td><td align='center'>" + action_links(data) + "</td></tr>");
            });
        });
    });
};

$.fn.addAddress = function(json){
    var data = json;
    var that = this;
    return this.each(function(){
        var that = this;
        $(that).append("<tr id=\"address-"+ data.id +" \"><td><a class=\"address-link\" href=\"addresses/" + data.id +"\">" + data.name + "</a></td><td align='center'>" + action_links(data) + "</td></tr>");
    });
};

$.fn.showAddress = function(json){
    var data = json;
    var that = this;
    return this.each(function(){
        $(that).slideDown('slow');
        $(that).find("#name").html(data.name);
        $(that).find("#street1").html(data.street1);
        $(that).find("#street2").html(data.street2);
        $(that).find("#city").html(data.city);
        $(that).find("#country").html(data.country);
        $(that).find("#zipcode").html(data.zipcode);
    });
};

Download jquery-1.4.2.min.js, jquery-ui-1.8.1.custom.min.js and jquery.form.js to public/js folder.

6)  Start the web server

[/sourcecode]lein repl src/address_book/webserver.clj [/sourceode]

Wow that was lot of stuff. We will look more into writing our own middlewares in next part.

Source code is now available at github. Created branches for each part.

Part 5 is posted.

Vikas Hazrati has a nice post on large-scale refactoring on InfoQ. I'm a strangler. You?

Do you like learning languages? Maybe you’ve always wanted to learn a language? Maybe you’d like to get better at teaching languages? Maybe you don’t care about languages but you’re a trainer or teacher or a student?

If any of these are true for you and could be in Seattle on Sep 4th & 5th, then read on…

Where Are Your Keys, Seattle?

Where Are Your Keys? (WAYK) is an amazing community language learning game which is great not only for learning and teaching language, but also for learning techniques that are good for learning / teaching, period.

Karissa and I went to a weekend workshop in Portland early this year and we were both blown away by it. We’ve gotten the creators to come up to Seattle to do a workshop here, at our house, on Sep 4th & 5th, and I want to invite you.

It’s $125 for 2 intense days with a light breakfast & lunch provided on each day. But trust me, at the end of 2 days, you will be a badass . And you’ll have the skills to learn the basics of any language. From anyone.

We have till the end of the weekend to get enough interest to make the workshop happen, so if you’re interested, PLEASE

Sign Up Here

Applying WAYK…

Karissa & I have applied techniques from “Where Are Your Keys?” to both our dance teaching and my consulting, and would love to have a larger community to help us discover other ways to apply it to teaching & learning. We’re planning on starting a local monthly game, and we’re hoping to use this workshop to kickstart the Seattle WAYK community.

For my part, WAYK has changed the way I organize classes. Techniques like “Start Over”, “Setup”, “Full”, “Limit”, “We all get there together”, are just some of the techniques that are now part of virtually all my classes.

If you teach people anything, I recommend you check it out.

Like I said, we still need to get a few more people registered so that this workshop happens, so please forward this to anyone you think might be interested!

I recently had the pleasure of attending the June meeting of Dublin chapter of the Bootstrappers Breakfast. After the meeting there was a Q & A session with the remaining attendees. I remarked to Sean Murphy that I’ve recently moved to a new pricing model for consulting. I’ve started to adjust my pricing based on my current capacity. That is, as my schedule becomes fuller and I become busier, my hourly rates increase. That way clients can decide for themselves how important their project is. If it can wait, we push the project back a bit, my price goes down and the clients get a price break. If there is an immediate need, they will need to pay a premium and it will be a rush job.

I do this because the last few hours of my week act as a buffer for anything unexpected that should come up. If I pack my schedule to the brim, I run the risk of all sorts of chaos if/when anything unexpected comes up.

In lean terms, I’m increasing costs as my capacity decreases.

Why? A few reasons:

First, it provides an incentive to prevent me from becoming overtaxed and taking on too much work. This regulates the flow of work into my 1530 schedule and provides a sort of cadence for new work. This allows me to plan more efficiently.

Secondly, by stabilizing the work in and out, I stabilize my flow. This helps me churn out better work quicker. If you take on everything that comes your way for the same price, there’s no doubt that that you would begin to resent those last few pieces of work that you’re cranking away on any given Sunday night. With the rate increase, at least there is ability to look back and see that there is increased compensation for working later at night and into the weekend.

I should note that this obviously this can alienate clients and cause you to lose work. However, part of managing a successful service based business is to know when and how to control clients. If you simply say ‘Yes’ all of the time to everyone, you’ll quickly find yourself taking on much more work than you’re capable of. That will lead to you not being able to deliver consistently excellent work and you’ll lose clients anyway. I would rather have a healthy relationship with a client and be able to say ‘No’ as often as I say ‘Yes’. Those are the kinds of clients you’ll be able to build a sustainable business from.

BTW, this isn’t a new concept. The concept of cadence and queue management is applied in a lot of different places. For example, Chicago is entertaining the idea of rolling out congestion based pricing for its tollways that’s similar to several other tollways across the US. Comed and other electric companies employ Real-Time Pricing. These are just two other examples and there are many more.

Take a look at your own life and see if you can figure out ways to employ a form of cadence to help stabilize things.

In his recent article You’re Cuking It Wrong, Jonas Nicklas compares the following scenario which was submitted in a Cucumber issue :-

Scenario: Adding a subpage
  Given I am logged in
  Given a microsite with a Home page
  When I click the Add Subpage button
  And I fill in "Gallery" for "Title" within "#document_form_container"
  And I press "Ok" within ".ui-dialog-buttonpane"
  Then I should see /Gallery/ within "#documents"

With an improved version which he has written :-

Scenario: Adding a subpage
  Given I am logged in
  Given a microsite with a home page
  When I press "Add subpage"
  And I fill in "Title" with "Gallery"
  And I press "Ok"
  Then I should see a document called "Gallery"

Levels of Abstraction

Jonas says :-

there’s one crucial difference: the first feature is code, the second isn’t

Although I see what Jonas is getting at, neither of them are actually Ruby code – both are written in Cucumber’s Gherkin DSL. The key difference is really the level of abstraction – the first version has a test that is less abstracted from the implementation than the second version. As Jonas correctly points out, the test in the second version is consequently more readable and is less coupled to the underlying implementation.

Readability

Jonas also says :-

The argument against cucumber that’s often presented is that as a programmer, plain text is unnecessary, because we can all read code.

However, it’s a mistake to think that making a test readable necessarily means that it has to be written in a natural language. We could equally well write something like this :-

scenario "adding a subpage" {
  given {
    i_am_logged_in
    a_microsite_with_a_home_page
  }
  when {
    i_press "Add subpage"
    i_fill_in "Title",:with=>"Gallery"
    i_press "Ok"
  }
  then {
    i_should_see_a_document_called "Gallery"
  }
}

While I would agree that my version isn’t as pretty as Jonas’ version, I’d suggest it’s almost as readable. The difference being this is all valid Ruby code. I once saw someone (Nat Pryce or Steve Freeman, I think) do a neat trick where they changed the syntax highlighting in an editor to make some characters invisible and as a result made the code more readable. We could probably do something similar to make braces, underscores, etc invisible, and end up with something as good as Jonas’ version :-

scenario "adding a subpage"
  given
    i am logged in
    a microsite with a home page

  when 
    i press "Add subpage"
    i fill in "Title"  with  "Gallery"
    i press "Ok"

  then 
    i should see a document called "Gallery"
  

Overhead

It seems obvious to me that Cucumber adds an overhead in writing tests. It requires me to use regular expressions to convert natural language into code. While I recognise that the overhead is often small, it does still exist and I’ve definitely spent time debugging this aspect of tests. Given that I think it’s possible to write nicely abstracted readable tests in Ruby, it’s not obvious to me that the overhead of using Cucumber is worthwhile.

I’m going to try and find the time to look at frameworks like Coulda and Steak which seem to be more in line with my favoured approach.

Update

I thought it might be useful to include a quote from and a link to James Shore’s article on The Problems of Acceptance Testing

My experience with Fit and other agile acceptance testing tools is that they cost more than they’re worth. There’s a lot of value in getting concrete examples from real customers and business experts; not so much value in using “natural language” tools like Fit and similar.

Thanks to the benevolent JetBrains, I now have an OSS license for IntelliJ IDEA to develop an Android app. I first started using IDEA at ThoughtWorks where it quickly became my favorite development tool.

And thanks to Turbine, I have my data.lotro.com developer key! So I am ready to start an LOTRO Android App. And I've already been getting encouraging words from the LOTRO forums. Go, community!

Movie might be a bit of stretch. Heck trailer might be a bit of a stretch.

But when the Prags asked me to make a short promotional video for the Agile Samurai I immediately said: “Hell ya!”

The first cut of the video (the one I really wanted to use) looked something like this:

But for obvious copyright infringement purposes, it ended up looking more like this.

Making short clips like this is super easy with iMovie. All you need are some jpgs of slides you’d like to present and video of stuff you’d like to edit.

Slides you can create with PowerPoint, KeyNote, or Illustrator. You just need to be able to export and save them somewhere as jpgs.

Video you can get from youtube, and download and import into iMovie (as mp4s) using keepvid.com.

And once in iMovie everything else is a snap. You simply cut the scenes you want, order the slides, add and remove audio, and in no time you’ll have a fun one to two minute video of something you’ve always wanted to create.

Happy moving making!

Fantastic interview with David Zirin, author of ‘Bad Sports’.

You socialize the debt of a stadium project, but the profit goes to private hands. In a lot of ways you can look at sports as being a kind of Trojan Horse for enacting a set of policies that nobody would agree with it if were about any other business or entity. On the other hand, you could see it as a harbinger to the bank bailouts that have just taken place and to the entire economic recovery plan that has been enacted over the last couple of years.

And lest you think it’s just about the money:

Donald Sterling, owner of the Clippers, just had to write a check for the largest racial housing discrimination suit in the history of the United States, and NBA commissioner David Stern doesn’t say a damn thing, even though his league is more than 80 percent African-American. And now he’s being sued by NBA Hall of Famer Elgin Baylor — inarguably the greatest player to come out of Washington, D.C. — for racial discrimination, and once again Stern saying nothing.

This is the same commissioner that mandates a dress code for players.

Revenue sharing is one of the hallmarks of baseball. Small market teams get to reap the financial benefits from larger market teams. They get a guaranteed payout every year regardless of team performance. Given that, I can’t imagine why the Pittsburgh Pirate owners wouldn’t want to increase payroll to win. From The Sports Economist:

If they won and were forced to increase their payroll from $34 million to $75 million or $80 million … how profitable would they be? There’s a ceiling in terms of gate revenues, ” said Dave Berri and Roger Noll, a Stanford University economist, follows with, “Probably the Pirates would be less profitable if they tried to improve the team substantially.”

Ah.

Once again, people, true incentives dictate behavior.

When jumping into any company, people will immediately begin to ask that you finish things BY FRIDAY! Monday is another typical choice for deadlines. The end of the week and start of a new week is the perfect time to pick for delivering.

Why?

Well, for starters, Friday is the end of the work week and Monday is the beginning. It’s a simple concept to grasp. It doesn’t take too much work to remember when, in relation to today, things are due. “It’s Wednesday, so my project is due in two days.” Simple.

But is it the best? Is Friday/Monday really the ideal delivery dates for things? Obviously, if you’ve read this posts title, you know that I would argue that it isn’t. Why?

Frankly, every single person sees the two days between Friday & Monday as cushion. “It’s really ok if it’s not done until Friday, I can just put in a few hours over the weekend.” Wrong. By thinking like that, most people develop Student Syndrome. They’ll let things slip and slip and slip until the deadline is staring themselves in the face. When that happens, the best way to ensure you’re doing sub-par work is to try and cram it into a weekend.

Second, have you actually ever tried to get something done on a Friday? Also, forget about getting other people to help you. In most offices, by 3pm Friday afternoon, the place will be a ghost town. Monday mornings are almost worse since those that ARE there will likely be lethargic and “catching up” on things that they themselves didn’t do on Friday.

It’s also easier to miss Mondays & Fridays. 3-Day weekends, holidays, vacations and plain ‘ol “sick days” are more likely to fall on Mondays and Fridays than any other days.

Be sane. Always pick either Tuesday, Wednesday or Thursday for deadlines. Preferably Wednesdays, since they’re right in the middle. It gives two days from the weekend either way. You can start the week refreshed knowing nothing is due immediately and it gives you two days to get into your zone for deliver. Same goes for Thursday and Friday. You can usually get substantial work done on a project on Thursday and Friday and not worry too much about forgetting where you were on Monday morning.

Ryan Freitas on 35 lessons he’s learned in his 35 years. The title should certainly resonate with anyone who’s spent more than 5 minutes talking with me about startups and funding.

My second favorite lesson:

Your reputation is more important than your paycheck, and your integrity is worth more than your career.

Amen to that.

Interesting economics spin around the unadvertised short cappuccino at Starbucks by Slate.

The practice is hundreds of years old. The French economist Emile Dupuit wrote about the early days of the railways, when third-class carriages were built without roofs, even though roofs were cheap: “What the company is trying to do is prevent the passengers who can pay the second-class fare from traveling third class; it hits the poor, not because it wants to hurt them, but to frighten the rich.”

I continuously maintain that we should be introducing basic, basic economic lessons to our kids earlier and earlier. It’s so critical to understand incentives. Especially how people manipulate things in response to to said incentives.

Gruber nails my feelings with this critique of Eric Schmidt.

Thus begins Cinematicals review of Piranha 3D

It turns boys into men, cleaving their life into two distinct periods: Before Piranha 3D, a time we shall refer to as The Darkness, and after Piranha 3D, also known as The Awakening. Now that I have thankfully awoken in its glorious elysian fields of excessive gore and outrageous nudity, I never want to return to horror films that require fewer than 800,000 gallons of fake blood spilling forth from 500 bikini-clad extras. Anything less is an insult and, frankly, a malicious waste of my time.

Sounds like quite a time.

Two types of people you often find on software projects are samurai and rice pickers.

Samurai are the ones who:

• say what needs to be said
• call BS when they see it
• laugh in the face of unrealistic schedules and expectations
• tackle all the hard, complex, thorny stuff no one else wants to wade into
• are technically excellent at their craft
• take pride in their work
• and are comfortable in their own skins

They are usually the people you see project managers and companies fist fighting over to get onto their projects.

Every project/team needs a couple samurai.

Then there are the rice pickers.
If samurai are the pioneers, rice pickers are the settlers.

Rice pickers are the people who:

• like to collect a pay cheque, keep their heads down, and quietly go home at the end of the day.
• aren’t necessarily lazy, they would just rather be told what to do and not have to think for themselves.
• have opinions but aren’t big on taking the initiative
• generally they just like to be left alone and are quite happy sitting in the maze nibbling their cheese
• they also form the bulk of our workforce

Now, I’m not saying everyone can or should be a samurai.
The world needs rice pickers and people to keep the lights on.

But if you find you aren’t getting the opportunities, promotions, or things you feel entitled too, take a look in the mirror and honestly ask yourself:

And are you a samurai, or a rice picker?

Thanks to Jason Calacanis for acting as the inspiration behind this post.

These days, computers made multitasking a doodle. In the same minute you can read this blog post, chat with friend on IM, check your email, Facebook or Twitter account, perhaps even do some work. We can switch our attention quickly from one task to another. But … is it good for our brain? Is it good for the work we are doing? Are we really more productive?

It’s been few weeks since I started to talk to people about context switching and multitasking. Most of them recognize it as an issue. Many agree that it is counter-productive. I decided to take closer look at the problem and do a little research. Here are the results.

Human brain

According to many Neurologists and Psychologists our brain was not designed for multitasking. In 1999, Jordan Grafman used MRI to scan people brain. He discovered that frontal cortex of brain of people engaged in multitasking was more active than any other. This part of the brain is the least known to science, it is said that this is “what makes us human”.

Psychologist René Marois discovered that there is a bottleneck in the brain, when it’s being stimulated to perform more than one task. David Mayer thinks, that rather than a bottleneck, brain has a process that helps to select and prioritise tasks and obey any instructions that are not on that list.

Russel Poldrack, a psychology professor found that “multitasking affects the way you learn”. He discovered that people who multitask while learning, use the part of the brain responsible for learning new skills (striatum). Rather, they should be using part of the brain responsible for storing and recalling information (hippocampus).

There is a dozens more of scientists that have done research in brain and psychology area that will confirm the fact, that we work better if we focus on a single item.

I like the words of American novelist Walter Kirn who summarises multitasking phenomena:

This is the great irony of multitasking–that its overall goal, getting more done in less time, turns out to be chimerical. In reality, multitasking slows our thinking. It forces us to chop competing tasks into pieces, set them in different piles, then hunt for the pile we are interested in, pick up its pieces, review the rules for putting the pieces back together, and then attempt to do so, often quite awkwardly.

Multitasking or context switching

It is easiest for me to talk about multitasking or the process of switching tasks (context) when talking about software development. During our development process quite often we are getting in the state which is defined by Mihály Csíkszentmihályi as the Flow . If we are getting interrupted or interrupting others it’s the Flow that suffer.

Receiving end of the stick

Think of the number of times that email, phone, IM chat, news ticker or anything else that interrupted your work. Very often we drop whatever we are doing and we answer an email. We are voluntarily destroying our context, switching to another one, just to get it back on track minutes later. This comes for a cost. It cost time and your focus. It is a typical distracter that actually we have control of.

We can also get interrupted by other people. Project manager, team leader etc. comes to us asking to stop working on whatever we are doing and do something else instead. Something small and quick, that is only going to take you 5 minutes. So we do that, and then we consume our mental energy on getting the entire context of interrupted task back on track.

As a developer I always work in the teams. My fellow developers always have some questions, problems that they might need a help with. I can’t tell them to buzz-off. I will be helpful and pay the cost of interruption later

The trouble maker

When we are in a despair and need answers we are not worrying about anyone else. The goal is to ask or tell to achieve whatever we are after. We are not taking into consideration that we might be disturbing someone else Flow.

It is the same when we aren’t using contact in person but electronic medium, like email, telephone or IM chat.

Too many things at the time

Almost 10 years ago, Joel Spolsky wrote on his blog:

As it turns out, if you give somebody two things to work on, you should be grateful if they "starve" one task and only work on one, because they’re going to get more stuff done and finish the average task sooner. In fact, the real lesson from all this is that you should never let people work on more than one thing at once. Make sure they know what it is. Good managers see their responsibility as removing obstacles so that people can focus on one thing and really get it done.

Getting tasks under control

When I started my short research on multitasking it became more and more obvious to me how Agile, Lean and XP methodologies are actually trying to bring the software development process to the state where individuals are focused on single task, complete it in full and move on to the next one. With no interruptions comes better quality as well. I would like to mention and shortly describe some of the techniques that could help team members to achieve the Flow and Focus and produce results.

Pair programming

You might think that having other person next to you means a constant interruptions, and impossibility finishing anything. Nothing more wrong. The positives that are coming from pair programming in the context of help with multitasking issue:

• having another person next to you and focusing on a work, limits you to NOT respond to email, chat invitations and cutting short phone conversations or generally do anything else not related to work
• engaged in a work you need to keep constant focus, follow your colleague and check (improve) the quality of result
• when you think you stuck on something, you have a mate next to you that can give you a helping hand (that limits the interruptions to others as well). Also with switching and rotating pairs you have constantly a fresh source of knowledge on the project areas you have never worked on
• it might be harder for someone to come over to you and ask about anything or ask to switch task to do something, as it is more obvious that he/she will be interrupting

There is more positives coming from pair programming but I will not write about it as it is a story for separate article.

Pomodoro technique

I was writing about the Pomodoro Technique in one of my previous posts “How can Pomodore help you shave a Yak?” Technique used will help with:

• keeping focus on a task for period of time
• adding short breaks to refresh the brain and take a step back to look at the task from a perspective
• when interrupted by other person or own thoughts, writing the interruptions on a piece of paper makes you assure that the issues won’t be forgotten and ease your thoughts of it. This in turn helps you concentrate back on a task
• if you make people aware that, while you are in pomodoro you would rather be uninterrupted, you will be more effective

For more info on Pomodoro, you can look at my previous post or visit Google

Kanban

It could potentially take few more posts to describe Kanban. As simple concept as it is, it actually creates a wide range of improvements to development process. It is a great tool to be introduced by Project Managers for use by the entire team. Few upsides:

• working on a single item makes you focusing on a single task. The single story/task/functionality flow
• creating only quality results means that the actual task is not finished until QAs and BAs are happy with the result. This means that testing needs to come early into the process, even better – during the process (read this article by Christian Blunden, it will show you how)
• testing brought earlier, means also that you can help testers creating automated tests and keep in the same context until it is finished

Finally

It is in the basis of Agile techniques that work should be divided into small deliverable chunks (stories) that can be picked up and work on. If the chunks are small and team is disciplined, everyone will work uninterrupted until quality result is delivered. Project managers can employ techniques that help team members focusing on a single task and deliver it in full. I’m sure those techniques can save us many frustrating moments

This article is only a short introduction and brief summary of my little research project. I’m also preparing the talk and presentation with much wider explanation of the concepts and techniques mentioned in here.

Greg

Some of the sources if you would like to research more:

• http://www.thenewatlantis.com/publications/the-myth-of-multitasking
• http://eebatou.wordpress.com/2007/10/24/qotd-walter-kirn-on-multitasking/
• http://www.joelonsoftware.com/articles/fog0000000022.html
• http://www.wikipedia.org

Experience some of the most popular sessions from this year's BCS SPA conference, for free, at miniSPA2010 on Friday September 10th at BCS London (near Covent Garden).

The miniSPA2010 one-day programme features five sessions, in two streams, that give an excellent guide to the variety and quality you'll find at every SPA conference.

We hope that attending miniSPA will encourage you to submit a session proposal for SPA2011, which will be taking place from June 12-15 (also at BCS London).

For more information visit http://bcs-spa.org/minispa-2010.html. Booking is essential. Places are limited so reserve yours now.

See http://bcs-spa.org/ for details of our programme of regular events.

©2010 BCS SPA | 5 Southampton Street | London | WC2E 7HA

I always have so much fun at Agile 20XX conferences that it sometimes feels anticlimactic when they end. This year, however, I was lucky enough to get one of the last few tickets for Corey Haines’ latest CodeRetreat in Orlando.

The CodeRetreats are focused on having fun while learning, and follow a simple formula: 45 minute sessions of pair-programming on Conway’s Game of Life, then deleting all the code written and taking a 15 minute break. As well as giving up his time, Corey organises a storming lunch. Thank you Corey!

Deleting the code, for me, is the magic. I didn’t fully understand until Corey tutored me out of my outside-in, BDD habit at the last Code Retreat in Bletchley Park. “Why did you start with the Grid?” he asked.

“Well… because that’s how I’ll know I’ve solved the problem.”

“Are you trying to get things done?” Corey asked. “Don’t try and get anything done. 45 minutes isn’t long enough, and we’re going to delete the code anyway. Why not pick something interesting and see if you can find a different way to do it? Why not look at the rules, or a single cell, or the number of neighbours?”

I got it. CodeRetreat isn’t about solving a problem or getting something done. It’s explicitly the opposite. It’s about learning, even if that means you never solve anything or get anything done. The 45 minute period is just long enough to learn significantly but not quite long enough to make any real headway, unless you already know the Game of Life backwards.

As part of teaching BDD and driving out various BDD tools, I’ve produced multiple implementations of the Game of Life in Java and C#, to the extent where I already have a good idea of the classes I’m going to use. That can actually be a handicap in the CodeRetreat, because it makes it hard to learn anything new. I often find myself letting my pair take the direction, just to see if any other interesting patterns emerge.

In Orlando, we were lucky enough to have several great programmers amongst us – including Michael Feathers, Brian Marick and Uncle Bob. Having already experienced a cage match between Michael’s Haskell and Brian’s Clojure implementations of the Game of Life, I was excited by the opportunities to learn a new language. Brian was kind enough to show me some of the language features in Clojure. We didn’t really get very far with the problem, but that’s OK – the object was not to solve the problem, just to learn. Thank you Brian!

For the last session of the day, we voted to use a bit of extra time to conduct a longer session, and Bob kindly volunteered to help me continue exploring Clojure. We started with a function which would find all the potential candidates for life in the next generation, and worked from there.

10 minutes before the end of the session, we had a working copy, which Uncle Bob has kindly blogged here. The code is a little tidier and a lot more readable than the version we ended up with. I need to find out what conj and % do! We should also have deleted it, but since we had already gotten something done, it was too late.

Clojure turns out to be a very beautiful language, and Uncle Bob is a lot less scary in real life wonderfully patient mentor. Thank you, Bob!

Came across this twice in the past two weeks.

How NOT to do it:

$('form :submit').click(function() {
    $(this).attr("disabled", true);
    $(this).val("wait...");
    $(this).addClass("disabled");
});

Doing it the above way, the click event will indeed fire, but on some browsers the submit event will not.

The event to bind to is submission of a form, not clicking of a submit button.

How to do it:

$('form').submit(function() {
    $(":submit").attr("disabled", "disabled");
    $(":submit").val("wait...");
    $(":submit").addClass("disabled");
});

Also, the :submit selector is a jQuery cross-browser selector for input and button elements that could submit the form, used in preference to input[type="submit"]

In part2 we saw how to setup a skeleton project with Compojure. In this part we will see how to add static files to a Compojure project.

For our application, we will use JQuery as front end and Clojure as a backend. I will concentrate more on Compojure.

1) Create folders for static files.

mkdir public
mkdir public/css
mkdir public/js

It is better to have static files under a seperate directory that way you could use your webserver to serve these files. For now we will use Compojure to serve these files.

2) Create index.html under public folder

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
	<head>
		<meta http-equiv="content-type" content="text/html; charset=utf-8" />
		<title>My Address book</title>
		<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>
	</head>

  <body id="main">
    <p>
      My Address Book
    </p>
  <body>
</html>

3) Start your server

lein repl src/address_book/core.clj

4) Access index.html

Go to http://localhost:8080/index.html . You will get “Page not found” instead of “My Address Book”. This is happening because we have not told compojure about our static files folder.

Route helper functions in Compojure

In Compojure we have two route helper functions. We have seen one already in core.clj file.

1) not-found :

This function is used to capture all other routes that are not defined in Compojure. As we still have not defined index.html we got “Page not found”.

2) files :

This function is used to inform Compojure where static files are present.

Lets change our core.clj to handle static files

(ns address_book.core
  (:use [compojure.core]
        [ring.adapter.jetty])
  (:require [compojure.route :as route]))

(defroutes example
  (GET "/" [] "<h1>My Address Book!</h1>")
  (route/files "/" {:root "public"})
  (route/not-found "Page not found"))

(run-jetty example {:port 8080})

Restart your server (there is a way to avoid restarting using futures. I will show that in a later blog) and access http://localhost:8080/index.html . Now you should see “My Address Book”.

In this part we saw how we can handle static files. In next part we will implement Add , View and View All functionalities.

PS: Using Hiccup you can create HTML and css in clojure. I will try to cover this in future blogs.

Source code is now available at github . Created branches for each part.

Checkout PART4 …

In Growing Object-Oriented Software, Guided by Tests, we advocate starting development by writing a system test (or tests). This caused more controversy than I expected. System tests have the reputation of being slow (not entirely avoidable, I admit), difficult to automate reliably and difficult to diagnose when they fail. However, I find that many teams follow a TDD process at the unit-level, but do post-hoc testing at the system level, and so don't use system tests as a source of design feedback.

For me, the key feature of the TDD process is that when something is hard to test, that's a driver to go back and adjust the design until it is easy to test.

At the system-test scale, tests become unreliable when they cannot observe the activity of the system well enough to reliably synchronise their execution with that of the system. Failures are hard to understand if the tests cannot gather and filter information about the activity of the system during execution of the test. Defects will break test isolation and cause cascading failures if the tests cannot wait until the system becomes passive and restore it to a known good state when the system fails a test.

To reliably test a system, we must be able to...

• determine what the system is doing.
• detect when it has stopped doing it.
• detect when the system has failed.
• explain why has it failed.
• restore the system to a known good state.

If our system tests are unreliable, that's a sign that we need to add interfaces to our system through which tests can better observe, synchronise with and control the activity of the system.

Those changes turned out to be exactly what we need to better manage the systems we built. We used the same interfaces that the system exposed to the tests to build automated and manual support tools.

It seems obvious in hindsight: to reliably test manage a system, we must be able to...

• determine what the system is doing.
• detect when it has stopped doing it.
• detect when the system has failed.
• explain why has it failed.
• restore the system to a known good state.

Design Feedback from TDD

TDD at the unit scale guides the design of the code to make the system easier to modify, because it is easier to test code that is organised into loosely coupled, cohesive units that have clear responsibilities.

My hunch is that TDD at the system scale works in a similar way, guiding the design of the architecture to make the system easier to manage, because it requires the system have machine-readable interfaces through which tools can observe and control its activity.

In part 1 I introduced the address book application that we are going to build.

In this part we will setup our skeleton project with compojure.

1) Install Leiningen

http://github.com/technomancy/leiningen/blob/master/README.md

2) Create a new project using Leiningen

lein new address_book

3) Add Compojure to our project:

a) Edit project.clj

(defproject address_book "1.0.0-SNAPSHOT"
  :description "Address Book"
  :dependencies [[org.clojure/clojure "1.1.0"]
                 [org.clojure/clojure-contrib "1.1.0"]
                 [compojure "0.4.1"]
                 [ring/ring-jetty-adapter "0.2.3"]])

b) Install dependencies

lein deps

This should install all dependencies of compojure

c) Test whether our setup is working

Edit src/address_book/core.clj

(ns address_book.core
  (:use [compojure.core]
           [ring.adapter.jetty])
  (:require [compojure.route :as route]))

(defroutes example
  (GET "/" [] "My Address Book!")
  (route/not-found "Page not found"))

(run-jetty example {:port 8080})

Run the server

lein repl src/address_book/core.clj

Goto http://localhost:8080 and you should see “My Address Book!”

In next part we will start implementing our functionalities.