Wednesday, 30 November 2011

Learning UML 2.0

Russ Miles & Kim Hamilton
ISBN: 978-0596009823

I have never been a big fan of UML or really seen the need for it. However I was told it was imperative for my latest contract, so I out my old copy of UML distilled by Martin Fowler and bought a new copy of it for my Kindle and started reading it. I had been with my new client very long when someone recommended Learning UML 2.0 by Russ Miles and Kim Hamilton. It contains the Philippe Kruchten 4+1 model that we would be using for the project so I thought it would probably make a better book to learn from (no pun intended).

Philippe Kruchten 4+1 Model
Philippe Kruchten 4+1 Model

This is a great book. Easy to read and lots of detail about the key areas of UML 2.0. It doesn't cover absolutely everything, but recommends other books that do. There are lots of code examples in Java. I'm not sure if all of these are useful or if the authors, who are programmers, were just desperate to get some code in.

The book focuses on what in my opinion are the most useful diagrams:
  • Use Cases
  • Activity Diagrams
  • Class Diagrams
  • Object Diagrams
  • Sequence Diagrams
  • Communication Diagrams
  • Timing Diagrams
  • Interaction Overview Diagrams
  • Composite Structures
  • Component Diagrams
  • State Machine Diagrams
  • Deployment Diagrams
I hesitate to include Class diagrams in the list. Along with Use Cases and Sequence diagrams, class diagrams are probably the most well known of all UML diagrams. Unlike sequence diagrams and to a certain extent Use Cases, class diagrams are of little use. Usually it's quicker to get on and write the code than it is to draw diagrams and get someone else to write it. One possible exception is where you are generating code from a UML model, but I don't really see the point in that either. Fortunately there are only two chapters on Class Diagrams.

In my opinion if you want to learn the important parts of UML in a hurry. This is the book for you.

Thursday, 17 November 2011

Review of Effective C# Item 15: Utilize using and try-finally for Resource Clean-up

The original Effective C++ Series from Scott Meyers was a real revelation for C++ programmers. It grouped together many idioms from the wildly diverse and complex language and made them understandable. It identified many of the pitfalls and made them avoidable. It was a must read for every serious C++ programmer.

Since then all the major language seems to have an effective series. You would think this was a good idea, but most languages are not as wildly complex as C++, with fewer idioms and pitfalls. They're still there, but the languages have been designed with the idioms in mind, and the introductory texts teach them, and with a lot of the pitfalls already avoided. Consequently most effective series for modern languages are smaller and contain a lot of patterns as well. For example, Effective Java starts off with the builder pattern. To my mind that belongs in a patterns book and it certainly should not be the first Java idiom described.

I am currently reading Effective C# by Bill Wagner. I've got as far as chapter 18 and so far it is full of good advice, but, in my opinion, is extremely poorly explained. Items 6 and 7 cover equality and GetHashCode. These are complex concepts in predominantly reference based languages, like C#, and after I'd finished reading the items I didn't feel I understood them much better.

Items 12 to 20 cover resource management. This is a real passion of mine, so naturally I'm quite critical of what's written here, as well as what's actually written. Luckily most of what's written is sound, but part of Item 15 gives, in my opinion, some just plain bad advice. The following item, 16, is another exceptionally badly written item, all though the advice is sound, but I'll leave that for another time.

Item 15: Utilize using and try-finally for Resource Clean-up Resource management is probably the biggest Achilles heal of garbage collected languages. As such, it should probably be the subject of the first section of any effective series, but item 15 out of 50 isn't to bad.

How and why resources need to be managed in C# is explained satisfactorily by the item, so I won't go over it again. However I was highly amused by one paragraph: "Luckily for you, the C# language designers knew that explicitly releasing resources would be a common task. They added keywords to the language to make it easy." Surely this is treating a symptom, not solving the problem and they should have found a way to encapsulate resource management within types.

My real issue with this item is what the author describes as an ugly construct. There is an implied using example that uses both a SqlConnection and a SqlCommand:
public void ExecuteCommand(string connString, string commandString)
{
using (var myConnection = new SqlConnection(connString))
{
using(var myCommand = new SqlCommand(commandString, myConnection))
{
myConnection.Open();
myCommand.ExecuteNonQuery();
}
}
}
The author points out that you've effectively written this construct:
public void ExecuteCommand(string connString, string commandString)
{
SqlConnection myConnection = null;
SqlCommand myCommand = null;

try
{
myConnection = new SqlConnection(connString);
try
{
myCommand = new SqlCommand(commandString, myConnection);

myConnection.Open();
myCommand.ExecuteNonQuery();
}
finally
{
if (myCommand != null)
myCommand.Dispose();
}
}
finally
{
if (myConnection != null)
myConnection.Dispose();
}
}
As he finds it ugly, when allocating multiple objects that implement IDispose, he prefers to write his own try/finally blocks:
public void ExecuteCommand(string connString, string commandString)
{
SqlConnection myConnection = null;
SqlCommand myCommand = null;

try
{
myConnection = new SqlConnection(connString);
myCommand = new SqlCommand(commandString, myConnection);

myConnection.Open();
myCommand.ExecuteNonQuery();
}
finally
{
if (myConnection != null)
myConnection.Dispose();

if (myCommand != null)
myCommand.Dispose();
}
}
I have two problems with this. The first is that if the Finally For Each Release pattern, as described by Kevlin Henney in Another Tale of Two Patterns, is correctly implemented, the null checks, which are a terrible code smell and often the cause of bugs if they get forgotten, would be completely unnecessary:
public void ExecuteCommand(string connString, string commandString)
{
var myConnection = new SqlConnection(connString);

try
{
var myCommand = new SqlCommand(commandString, myConnection);

try
{
myConnection.Open();
myCommand.ExecuteNonQuery();
}
finally
{
myCommand.Dispose();
}
}
finally
{
myConnection.Dispose();
}
}
If the nested try blocks are a problem for you, another method can be introduced:
public void ExecuteCommand(string connString, string commandString)
{
var myConnection = new SqlConnection(connString);

try
{
ExecuteCommand(myConnection, commandString);
}
finally
{
myConnection.Dispose();
}
}

private void ExecuteCommand(SqlConnection myConnection, string commandString)
{
var myCommand = new SqlCommand(commandString, myConnection);

try
{
myConnection.Open();
myCommand.ExecuteNonQuery();
}
finally
{
myCommand.Dispose();
}
}
However, the real problem is that you are only effectively implementing this construct. If you stick with the original nested using blocks, the compiler creates the construct for you and you don't see it. Which means that it really doesn't matter how ugly it might be and ditching the using blocks and writing your own construct just creates the ugliness. Maybe the root of the authors aesthetic objection is the nesting. Again, this is easily overcome by introducing another function:
public void ExecuteCommand(string connString, string commandString)
{
using (var myConnection = new SqlConnection(connString))
{
ExecuteCommand(myConnection, commandString);
}
}

private void ExecuteCommand(SqlConnection myConnection, string commandString)
{
using (var myCommand = new SqlCommand(commandString, myConnection))
{
myConnection.Open();
myCommand.ExecuteNonQuery();
}
}
Finally
In conclusion, the final part of the summary advice given in the chapter which states, "Whenever you allocate one disposable object in a method, the using statement is the best way to ensure that the resources you allocate are freed in all cases. When you allocate multiple objects in the same method, create multiple using blocks or write your own single try/finally block." should be ignored in favour of "... When you allocate multiple objects in the same method, create multiple using blocks."

A PDF version of this review can be found here.

Tuesday, 15 November 2011

First Agile East Anglia Meeting

It’s a little later than I was planning for but I’ve fixed a date, time and venue for the first Agile East Anglia meeting:

Date: 5 December 2011
Time: 6.30pm to 8.30pm
Venue: Coach & Horses, Thorpe Road, Norwich

I’ll aim to get there between 6pm and 6.30pm and will be there until at least 8.30pm. There are at least two Coach & Horses in Norwich. Please make sure you come to the one on Thorpe Road near the Railway Station in Norwich. Please try and let me know if you intend to come. Either by replying to this message or emailing me: paul.grenyer@gmail.com.

As with XTC in London, there’s no agenda or format. It’s just an opportunity for those interested in or practicing Agile to get together for an informal chat. In the future if people would like to have more structure or speakers, that can be arranged. Please feel free to bring anyone else interested along with you.

Although XTC meet weekly I think that might be a little optimistic for Norwich at this stage. So if all goes well I’ll plan the next meeting for early January.

I look forward to seeing you all.

Sunday, 13 November 2011

Opeth

O2 Academy Birmingham
Saturday 12th November 2011

The last time I was a the Academy in Birmingham was February two years ago for Lamb of God and Dimmu Borgir. Both were very good, but the people there were rude and inconsiderate. Last night was very, very different. Lots of friendly people and the staff were great. In fact London venues have a lot to learn.

Opeth did not play a single song that I would have asked for! Having resisted the urge to play their new album all the way through, they instead opted for a more progressive, less death metal approach, playing both some new and old songs. There's was no Blackwater Park and no Daemon of the Fall. Mikael Ã…kerfeldt was on fine form. Talking to the audience for long periods between songs, even getting the audience to participate in a Napalm Death cover. I loved it! Can't wait to see them again.

The Devil's Orchard
I Feel The Dark
Face of Melinda
Porcelain Heart (with drum solo)
Nepenthe
The Throat of Winter
Credence
Closure
You Suffer (Napalm Death cover)
You Suffer (Napalm Death cover)
You Suffer (Napalm Death cover)
You Suffer (Napalm Death cover)
Slither
A Fair Judgement
Hex Omega
Folklore

Thursday, 10 November 2011

Working Effectively with Legacy Code

by Michael Feathers

ISBN-13: 978-0131177055

This is my second read through of Working Effectively with Legacy Code. I don’t usually read books twice, but it was being used as the material for an ACCU Mentored Developers project I was running.

Working Effectively with Legacy Code is almost as relevant now as when I read it in 2007. The only real thing that dates it are some of the links to pages that have moved on and some of the techniques which were new then, but are far more widely understood now. A credit to the book in a lot of ways.

Both times that I read it I felt that it didn’t teach me much that I hadn’t already learned during my career. I have been exceptionally fortunate to have worked with or been associated with some of the best developers in the world, so it was inevitable that I would pick this stuff up. Many developers are not so fortunate and that is why this book remains in my top ten.

All of that aside, this book contains surprisingly practical advice. I remember seeing Michael Feathers presenting at an ACCU conference and the room, including myself, being up in arms about using inheritance to mock out the methods of a class under test. Now I’ve read the book I understand that is just a first step to get the class under test before you refactor.

Singleton is a pattern that comes up again and again in all sorts of books (I’m reading a UML book at the moment and it’s even there!). One of the problems with singleton is that it is difficult to test. Feathers shows how you can get a singleton in existing code under test before you refactor it out. This is not the same as advocating singletons.

Feathers describes techniques for getting code under test that I had considered in the past and dismissed as far too complicated to be useful, but he makes them simple and straightforward. I could go on and on with example after example but the bottom line is that even if you’ve been fortunate in your career, you should read this book to get even the smallest bits that you haven’t considered.

Wednesday, 9 November 2011

Catalina-Ant for Tomcat 7

I recently upgraded from Tomcat 6 to Tomcat 7 and all of my Ant deployment scripts stopped working. I eventually worked out why and made the necessary changes, but there doesn’t seem to be a complete description of how to use Catalina-Ant for Tomcat 7 on the web so I thought I'd write one.
  1. To start with, make sure Tomcat manager is configured for use by Catalina-Ant. Make sure that manager-script is included in the roles for one of the users in TOMCAT_HOME/conf/tomcat-users.xml. For example:
    <tomcat-users>
    <user name="admin" password="s3cr£t" roles="manager-gui,manager-script"/>
    </tomcat-users>
  2. Catalina-Ant for Tomcat 6 was encapsulated within a single JAR file. Catalina-Ant for Tomcat 7 requires four JAR files. One from TOMCAT_HOME/bin:

    tomcat-juli.jar

    and three from TOMCAT_HOME/lib:

    catalina-ant.jar
    tomcat-coyote.jar
    tomcat-util.jar


    There are at least three ways of making the JARs available to Ant:

    1. Copy the JARs into the ANT_HOME/lib folder. Then Ant will just find them.
    2. Copy the JARs to a folder within your project that you check into your source control system. Ant then needs a path id to find them:
      <path id="catalina-ant-classpath">
      <fileset dir="${catalina-ant-dir}">
      <include name="catalina-ant.jar"/>
      <include name="tomcat-coyote.jar"/>
      <include name="tomcat-util.jar"/>
      <include name="tomcat-juli.jar"/>
      </fileset>
      </path>
      Where catalina-ant-dir is the directory with the JARs in. This way you don’t need to modify the Ant installation on every machine you build on.
    3. Access the JARs directly from your Tomcat 7 installation. Ant then needs a path id to find them:
      <path id="catalina-ant-classpath">
      <fileset dir="${appserver.lib}">
      <include name="catalina-ant.jar"/>
      <include name="tomcat-coyote.jar"/>
      <include name="tomcat-util.jar"/>
      </fileset>
      <fileset dir="${appserver.home}/bin">
      <include name="tomcat-juli.jar"/>
      </fileset>
      </path>
      Where appserver.lib is the path to Tomcat 7’s lib directory and appserver.home is the path to Tomcat’s top level installed directory. This way Tomcat 7 is required on every box you build on.

    My personal preference is for 2 above.

  3. Now that your Ant script can see the Catalina-Ant JARs you need to tell it what tasks are available. These are most if not all of the tasks that are available to Ant.
    <taskdef name="catalina-deploy" classname="org.apache.catalina.ant.DeployTask" classpathref="catalina-ant-classpath"/>
    <taskdef name="catalina-list" classname="org.apache.catalina.ant.ListTask" classpathref="catalina-ant-classpath"/>
    <taskdef name="catalina-reload" classname="org.apache.catalina.ant.ReloadTask" classpathref="catalina-ant-classpath"/>
    <taskdef name="catalina-findleaks" classname="org.apache.catalina.ant.FindLeaksTask" classpathref="catalina-ant-classpath"/>
    <taskdef name="catalina-resources" classname="org.apache.catalina.ant.ResourcesTask" classpathref="catalina-ant-classpath"/>
    <taskdef name="catalina-start" classname="org.apache.catalina.ant.StartTask" classpathref="catalina-ant-classpath"/>
    <taskdef name="catalina-stop" classname="org.apache.catalina.ant.StopTask" classpathref="catalina-ant-classpath"/>
    <taskdef name="catalina-undeploy" classname="org.apache.catalina.ant.UndeployTask" classpathref="catalina-ant-classpath"/>
  4. Finally you need a set of tasks that actually do the work. Although, as you can see above, there are a few tasks I only tend to use the following ones:
    <target name = "stop-webapp">
    <catalina-stop url="${tomcat.manager.url}"
    username="${tomcat.username}"
    password="${tomcat.password}"
    path="/${webapp.name}"
    failonerror="false"/>
    </target>

    <target name = "start-webapp">
    <catalina-start url="${tomcat.manager.url}"
    username="${tomcat.username}"
    password="${tomcat.password}"
    path="/${webapp.name}"/>
    </target>

    <target name = "undeploy-webapp">
    <catalina-undeploy url="${tomcat.manager.url}"
    username="${tomcat.username}"
    password="${tomcat.password}"
    path="/${webapp.name}"
    failonerror="false"/>
    </target>

    <target name = "deploy-webapp">
    <catalina-deploy url="${tomcat.manager.url}"
    username="${tomcat.username}"
    password="${tomcat.password}"
    path="/${webapp.name}"
    war="file:${war.file}"/>
    </target>
    tomcat.manager.url is the URL where Tomcat manager lives. This is another of the changes from Tomcat 6 to Tomcat 7. Usually this will be: http://:8080/manager/text.

    Tomcat.username and Tomcat.password are the user name and password for Tomcat manager.

    webapp.name is the name of the Tomcat application that you are deploying.

    war.file is the path the Tomcat application you are deploying’s WAR file.

    The stop-webapp task has the failonerror attribute set to false as on most occasions you don’t want the Ant build to stop if a Tomcat application you’re trying to stop isn’t running.

    I usually define all of these properties in a properties file that Ant can read. That way local settings can be picked up more easily if builds are run on different machines.