Bunk and Rambling

A few months back, I converted a large set of ruby selenium tests to using selenium-rc and rspec. Unfortunately the changes didn’t stick, mainly due to a lack of ruby debugging support in our primary development environment, Intellij 6. The idea has stayed at the forefront of my mind since that time and it was great to stumble upon Kerry Buckley’s blog on selenium-rc and rbehave. In my opinion, the type of approach to testing that he discusses is an absolute necessity if we expect automated functional testing to go mainstream.

Just came across the Carnival of Agilists blog. The blog is a fortnightly summary of “Agile happenings in the blogosphere.”

It dawned on me recently that we use many different physical devices to make agile practices work for us. These devices are used in support of concepts such as story and task cards, story walls and burn down charts. When you look at the output of implementing a number of agile practices we can clearly see the benefit of index cards, large sheets of paper, whiteboards, marker pens and various other display tools. What we do not see are the things that make this stuff visible to us, the stuff that allows us to display this information on walls rather than on piles on our desks, what I am talking about is Blutack (and its various competitors in the adhesive putty market).

Having pondered upon the value of Blutack to the many projects that I have been involved in, I now believe that current Agile literature does not go far enough to describe the valuable role that Blutack has in implementing their practices successfully and hope that through the power of this blog entry that this oversight can be rectified in future articles and books. In the meantime I would like to ask you all to take some time to think about the value that Bluetack has on your project the next time you stick a story card to a wall or a whiteboard, or even as you play with a ball of Blutack while you think or try to relieve stress, and pay it the respect that it is due.

Integrated Development Environments are constantly evolving, but I have noticed that many are reaching a level of maturity that signifies a need for them to begin introducing questionable features to enable them to continue to display long term viability. For this reason, I think it is time that IDE’s such as Netbeans, Eclipse and IntelliJ look to introduce a variation on Clippy the Microsoft Office Assistant to help developers to write better code.

While pair programming helps you to write high quality code in an efficient manner there are times that a pair of programmers will end up going off on a tangent and working on something that ultimately ends up not being necessary. To counter the unbridled enthusiasm that usually causes this to occur I give you Yagni, the Development Assistant.

Yagni’s role within the IDE is to monitor a developer’s work and provide warnings and advice about bad practices and code smells. As seen below, Yagni pops up when a class is being written before the corresponding unit test.

Yagni can also step in when it thinks that you have gone off track for too long working on a development spike and try to convince you to move back on the task of writing production code.

The code intelligence of Yagni is extensive to ensure that you don’t go off track and start writing code for framework, one of the most common time wasters in software development. Here Yagni steps up and reminds you in no uncertain terms that:

Sadly, Yagni is still a work in progress so please feel free to provide some comments as to what Yagni should do to make your coding experience more fruitful. Alternatively, there might be other IDE assistants that you can think of; one example that I can think of is Microsoft Development Mentor. In the case of Microsoft Development Mentor, maybe he could sit around waiting for you to write application logic in standard code and suggest that you write it in a stored procedure instead, with a goal of helping you to keep your code difficult to understand and maintain. There is no doubt that the opportunities are endless…

When you invoke ANT from the command line, you can specify -projecthelp or -p as part of your ANT call. By adding one of these options to the command line, you will receive a list of all targets that have a description attribute defined. Often, these types of targets are referred to as top level targets. These are targets that have all of their dependencies defined and can typically be run without any issues.

Top level targets can depend upon other top level targets, but typically they will depend upon lower level targets that do not have a description or their dependencies properly defined. These low level targets do not normally define their dependencies as this creates to much of a burden on the author of the build script when adding and removing new/old targets.

When creating a new build script, I find it beneficial to define all top level targets in the same section of the file. To increase readability of the build script and to keep the intention of the build clearly defined, all top level targets should have no nested tasks within their body instead relying on the element’s depends attribute to define the implementation for each target. For example:

  <target name="build"      depends="init-build, build-compile"      description="Target to compiles all production source."/>

By following this strategy consistently it is possible to change the way a build works quickly and easily without getting bogged down in implementation details.

A common exception to this strategy is the implementation of a clean top level target. As the clean target usually has a simple implementation, I will often define a clean target at the end of my top level targets like the one below:

  <target name="clean"      description="removes the build and dist temporary directories and any files found within.">    <delete dir="${build.dir}"/>    <delete dir="${dist.dir}"/>  </target>