Nick Carroll

Holy crap! I was just perusing the bin directory of my JDK installation and stumbled on a tool called VisualVM. It is a free lightweight profiling tool for the JVM. I can easily find which Java process maps to a specific Java application. Better yet the tool tells me what the PIDs are so that I can easily terminate “rogue” Java processes. VisualVM also provides visualisation tools for monitoring Java Classes, Threads, PermGen, and the Heap. It saves me from having to buy JProfiler or setting up Netbeans to profile my Java applications.

Last night at the Groovy Group we had Graeme Roche from SpringSource and lead developer of Grails give a webinar titled “Building Twitter with Grails in 40 minutes“. We were all impressed, not only with how Grails leverages Spring and third party plugins but also with the Twitter application that Graeme was building. He gave a new meaning to TDD — Twitter Driven Development. Each new feature that he added allowed him to tweet about it in the application that he was building. It was evident that he enjoys talking about Grails and connecting with user groups, even the flu wasn’t going to keep him away from giving the talk!

I am amazed with how many quality presenters we have had at the Sydney Groovy Group, and the number of project leads that have presented on their Groovy projects.

At the last meeting we got to hear about Griffon from James Williams, one of the project’s lead developers. Griffon is a Grails like framework for developing Swing based desktop applications. I was extremely impressed with Griffon, and how easy it was to create components without having to implement a bunch of event listeners or interfaces that you don’t need or care about. It was also interesting to see how the MVC pattern was applied to a Swing application. It made me wish Griffon was around 10 years ago when I was building Swing applications for Xylogy.

The May Sydney Groovy group will be meeting this Wednesday. Graeme Rocher will be giving a webinar on Grails, plus a run down on the recent GR8 Conference. So you’ll get to hear first hand on where Spring intends to take Groovy and Grails.

If you intend to make it to the meeting then please express your interest in the forums.

Hah, I knew someone would throw the navigator role at me. It maybe just a personal thing, but I certainly don’t buy into the navigator role at all. I’m sure someone that liked to hog the keyboard came up with that one.

My esteemed colleague Mark rebutted my post stating that pair programming is not about equal keyboard time, and went on to describe a case where it is perfectly alright to spend more time driving when there is a difference in experience in the pairs. A mighty good example, but really, how does his story about working with a more experienced developer trump my story about working with a more experienced developer?

Besides my thoughts on sharing the keyboard should not be taken too literally. I was not promoting equal keyboard time. I was promoting equal opportunity for both pairs to contribute, regardless of experience. Using a chess clock allows the person that has been “navigating” too long to say “look mate you have been driving for too long and here is the quantitative data to prove it”.

It sounds like Mark’s experienced pair told him how to solve the problem at hand, whereas my experienced pair taught me the thought process of going about solving the problem. This was done by having to implement code to pass my pair’s test, and to test my understanding of what was going on I had to write a test to keep the momentum going.

I don’t see the benefit where I have to write a test and then make the test that I wrote pass. Which is what happens when you hog the keyboard. The code that you produce becomes a self-fulfilling prophecy. Why not make your pair more useful by engaging her in your thought process too, by seeing if they will make your test pass the way you think it should pass? If there is a difference, then that is a good thing. That person thought of something you did not. Or your test simply wasn’t as good as you thought it would be.

A more experienced person can always steer you in the right direction with a good test. In my story, my experienced pair did just that, and if we were using a clock at the time it would show that I would have spent more time at the keyboard. I have since learned a few tricks, and I’m sure now the chess clock will indicate a more balanced reading.

Allowing one person to utilise the keyboard more than the other because of experience is flawed. If the person driving is the more experienced then forget about the less experienced pair navigating. When have you seen a less experienced developer try to influence the thoughts of the more experienced developer? More often than not the less experienced pair gets shut down the moment they pipe up, and the pair continues on with the vision of the more experienced developer that is driving. This is the classic surgeon model of software development, and it has been criticised for its lack of knowledge sharing.

If on the other hand both pairs have an equal opportunity of influencing the other through code, then the process of churning out code becomes a more engaging one for both people. If I were to give a name for this style of pair programming, then I would call it the Sudbury model of pair programming, named after the Sudbury model of education, which promotes a democratic structure for learning which is experiential based.

I have also been told in my last post that I should deliberately take control of the keyboard for extended periods of time, as this will make me a better pair. I’m sorry but how does this benefit either pair? Are you even aware of the average attention span of a human being? Why do you think that the Roads and Traffic Authority (RTA) advise you to rotate drivers every two hours? Or that class times are limited to 50 minutes? Or that stand ups should only last a few minutes. Or that a micro-sleep kills in seconds? The mind cannot stay focused on a particular task for long periods of time without some form of stimulus. The same goes for watching someone code for extensive periods.

I have also been told that the pair should play an “active” part by holding the vision for the work being done and doing the strategic thinking. What is the strategic thinking that you have to do during development? You should have already done the strategic thinking before you even started the story. The strategic thinking occurs when you are sizing up the story, and writing technical tasks that you think will need to happen in order to complete the story. If you are doing your strategic thinking during development then maybe your story is too big and can be broken down further.

Pair programming should be more like chess. Each person has to think a few moves ahead. The more experienced developer is capable of thinking several more moves ahead than the inexperienced developer, and when it is their turn they are able to lead the other down a path in discrete steps. When my pair has the keyboard I am thinking about the next test to write, possibly the next couple. Then when I get the keyboard I get to solve my pair’s test, then immediately move on to writing one of my tests for my pair to work on. This is how I like to work, and I shouldn’t need to rely on a chess clock to work this way. The chess clock is simply a tool for exposing the rocks and making it glaringly clear that the conversation has been one sided for too long.

Finally, hogging the keyboard is bad when you are working with someone that has never pair programmed before. They will never see the benefits of it as they will walk away from the experience feeling less productive. Or feel that they are not worthy enough to touch the keyboard. Constantly swapping the keyboard between pairs is more inclusive and allows for dialogue. Hogging the keyboard on the other hand is more of a monologue that trumpets “this is how you do it…”. Engaging the client developer and treating them as an equal goes a long way with relationship building.

[EDIT] Mark does a better job of explaining how to make a test pass quickly and why it is a good thing. My idea of using a chess clock was aimed to keep this in the minds of developers during a pair programming session.

It had to happen, someone has finally mass produced the IR pen so that you can use your Wiimote as an interactive whiteboard. You can buy an IR pen from http://penteractive.us/ for about $8. I sure hope Johnny Chung Lee is getting a cut of this action. Of course if you want to make your own then read my blog posting about making your own IR pen.

Penteractive also sell stands, which makes setting up the Wiimote whiteboard so much easier! Speaking of which, check out IDEO’s multitouch system (at code.google.com) which also supports the Wiimote and IR pen interaction.

I am excited about all this because it makes a Mingle projected story wall so much easier to setup and interact with.

There is nothing more boring than sitting and watching your Pair hack away at the keyboard during a “pair programming” session. You lose interest in the problem and drift away to LaLa land.

Sharing the keyboard means engaging both Pairs in solving the problem. If you aren’t sharing the keyboard and allowing your pair to interact with the story being developed, then you may as well be coding by yourself.

Keyboard hogging is generally symptomatic of a lack of test driven development (TDD). TDD is a good practice to get into when pair programming. It allows for one person to write a failing test, and the other to make the test pass. Then the roles are reversed so that each person takes it in turn to think of a test to write, so that the other can make it pass. This is sometimes called ping pong programming because the keyboard goes back and forth quite frequently.

How do you know if you have a keyboard hogger on your team? Well that was the question that I’ve been pondering on for a while. Some people just don’t know they are keyboard hoggers. So you need something visual and metrics based to expose the problem. Something like a chess clock.

I used to play chess competitively and to prevent people taking forever with their move you had to clock-in when it was your thinking time, and clock-out when you finally made your move. The clock added that extra bit of pressure to get a move on.

When the opposition is clocked-in you still have to remain actively engaged in the game as you have to work out a strategy to counteract a number of possible moves that your opponent could make.

Pair programming should be more like this. It certainly makes it a lot more enjoyable. I remember the best programming sessions I’ve had was with Stacy Curl, now an ex-thoughtworker and whom I believe was also a chess player. He would always look to quickly make my tests pass, even if it was to just echo the output that my tests would sometimes expect. This often forced me to think about triangulating my tests so that my pair had no choice but to do some heavy lifting and implement the code.

If you have a keyboard hogger on your team, then try and introduce a chess clock. The timed metrics should make it obvious that only one person is engaged in developing the story, and the other is just pondering about the meaning of life.

I’ve been using a JQuery tooltip plugin called QTip on my current project. It has that wow factor that blows users away. I highly recommend it.

I really like Django. It is not bloated like a lot of other frameworks, and it has a healthy balance between convention and configuration. As a developer I want to be able to use the tools that I want to use, and not be forced into a specific way of doing things. An example of this in Django is the comments framework that is part of django.contrib. The comments framework provides the infrastructure for attaching comments to any domain model in your Django project through content types. It also provides a few spam prevention features that you should consider leveraging, such as a security hash or a hidden honeypot field. However, the default comments form is rather bare, and the workflow for posting a comment requires too many clicks and redirects.

There are some solutions that try to improve the user experience, and do a good job of it, but require hacking the comments framework. I personally don’t like hacking the internals of any framework. Not because I’m scared to, but because I don’t want to inherit any unnecessary maintenance overheads.

Besides, I believe the comments framework does the right thing. It doesn’t try to do too much, and by that I mean the HTML that it generates for the default rendered form and corresponding responses can easily be mashed up as part of the submitting pages DOM. So with a bit of JQuery and AJAX knowhow you can post comments without refreshing or being redirected away from the submitting page.

First I use the utility methods from the comments framework to list all comments for a particular discussion content type, and to display the default comment form immediately after. Note that the comment form is wrapped in div tags with the id “comment_form”. The div will be used to override the block with responses from the server after an ajax post.

Comment

    {% load comments %}
    {% get_comment_form for discussion as form %}

    {% render_comment_form for discussion %}
    

In my template (discussion.html) in which I want to allow people to comment on something I add the following to a script block that will insert the JavaScript into the head element of the base template (base.html).

In line 2 I define a method called bindPostCommentHandler() which performs the ajax call to post a comment and to handle the response when the form submit event is triggered.

In line 3 I remove the preview button from the form as I do not want this functionality. Rich text plugins generally have a preview mode, so I don’t see the need for the server to process a preview request.

In line 4 I bind the ajax post call to the submit event of the comments form. This means when I click on the Post button to submit the form I will trigger an ajax post instead of a normal post to the server.

Line 7 serialises the data from the form input fields using the JQuery serialize() function.

Line 8 specifies the URL to post to. I use the utility method from the comments framework to retrieve this for me, so I don’t need to hard code it to a specific URL. The comment_form_target should retrieve the correct URL for the comments application that you should have configured in your urls.py file. If not then add the following URL route to your urls.py file.

    (r'^comments/', include('django.contrib.comments.urls')),

Line 10 specifies that the response will be HTML. This is necessary so that JQuery knows how to parse and handle the response.

Line 11 details the success callback, which is the function that calls when the response is successful. The callback simply replaces the form in the div wrapper with the response. A successful response could either be a “thank you” message for posting a comment, or a form displaying fields with invalid fields. Line 13 is necessary to rebind the bindPostCommentHandler() function to any new form that appears in the div wrapper. If you omit this rebinding, then you will lose ajax posts on successive submits.

Line 15 defines the callback that gets called when the server responds with an http error code. I just override the div wrapper block with an apologetic message.

Finally, line 23 binds the bindPostCommentHandler() function when the page is ready.

As you can see from the above, all you need is some JavaScript to improve the user experience for posting comments using Django’s comments framework. No framework hacking necessary. Note that if you want to further improve this solution, then you can add sliders, fade ins, and fade outs for displaying the responses from the server. I left these out for brevity. I also left out appending the submitted comment to the list of comments, as the above solution will only display the submitted comment after the user performs a GET request after the submit.