markhneedham/blog huggingface dataset:
My dislike of Java's static import
Date: 2008-09-24 23:59:54

While playing around with http://jbehave.org/documentation/two-minute-tutorial/[JBehave] I was reminded of my dislike of the http://java.sun.com/j2se/1.5.0/docs/guide/language/static-import.html[import static] feature which was http://java.sun.com/j2se/1.5.0/docs/guide/language/static-import.html[introduced in Java 1.5].

Using import static allows us to access static members defined in another class without referencing the class name. For example suppose we want to use the following method in our code:

[source,java]
----

Math.max(1,2);
----

Normally we would need to include the class name (Math) that the static function (max) belongs to. By using the import static we can reference max like so:

[source,java]
----

import static java.lang.Math.max;
...
max(1,2);
----

The benefit of this approach is that it makes the code read more fluently but the disadvantage is that you can't immediately tell where a method lives. I want to be able to tell what is going on in the code from looking at it and anything which prevents this is a hindrance.

The http://java.sun.com/j2se/1.5.0/docs/guide/language/static-import.html[official documentation] even suggests using this functionality sparingly:

____
So when should you use static import? Very sparingly! Only use it when you'd otherwise be tempted to declare local copies of constants, or to abuse inheritance (the Constant Interface Antipattern). In other words, use it when you require frequent access to static members from one or two classes.
____

On my last project we ended up saying that import static was allowed in test code because there were relatively few places the static methods could be imported from, but when it came to production code the fully qualified path was required.
Configurable Builds: One configuration file per machine
Date: 2008-09-13 03:54:25

I've covered some of the ways that I've seen for making builds configurable in previous posts:

* http://www.markhneedham.com/blog/2008/09/02/configurable-builds-one-configuration-file-per-environment/[One configuration file per environment]
* http://www.markhneedham.com/blog/2008/09/02/configurable-builds-one-configuration-file-per-user/[One configuration file per user]
* http://www.markhneedham.com/blog/2008/09/02/configurable-builds-overriding-properties/[Overriding properties]

One which I haven't covered which my colleagues http://www.markhneedham.com/blog/2008/09/02/configurable-builds-one-configuration-file-per-user/#comment-263[Gil Peeters] and http://www.markhneedham.com/blog/2008/09/02/configurable-builds-one-configuration-file-per-environment/#comment-161[Jim Barritt] have pointed out is having a build with one configuration file for each machine.

Again the setup is fairly similar to one configuration per user or environment. Using Nant we would have the following near the top of the build file:

[source,text]
----

<property name="machine.name" value="${environment::get-machine-name()}" />
<include buildfile="${trunk.dir}\config\${machine.name}.properties.xml" />
----

We could then have one configuration for each developer machine:

machine1.properties.xml

[source,xml]
----

<?xml version="1.0" ?>
<properties>
	<property name="property1" value="onevalue" />
</properties>
----

machine2.properties.xml

[source,xml]
----

<?xml version="1.0" ?>
<properties>
	<property name="property1" value="anothervalue" />
</properties>
----

The build file can be run using the following command:

[source,text]
----

nant -buildfile:build-file.build target-name
----

The benefit of this approach can be seen (as Gil points out) in http://en.wikipedia.org/wiki/Pair_programming[pair programming] where the settings on any one machine will always be the same regardless of who is logged in. We also still get the advantage of being able to use remote resources on developer machines.

Having machine specific configuration also allows more flexibility for configurations on continuous integration for example. To quote Gil:

____
Each CI build (multiple builds per build server) get's it's own [configuration] based on the build host and build name.
____

The disadvantage again is we have to add a new configuration file every time we want to run the build on a different machine.
Easily misused language features
Date: 2008-09-25 23:18:09

In the comments of my http://www.markhneedham.com/blog/2008/09/24/my-dislike-of-javas-static-import/[previous post about my bad experiences with Java's import static] my colleague http://www.lixo.org/[Carlos] and several others pointed out that it is actually a useful feature when used properly.

The code base where I initially came across the feature misused it quite severely but it got me thinking about other language features I have come across which can add great value when used effectively but lead to horrific problems when misused.

Apart from import static some other features which I can see easy potential for misuse are:

* C#'s http://www.dotnetjunkies.com/WebLog/richardslade/archive/2007/03/26/218656.aspx[automatic properties] which seem to make it even easier to expose object's internals than it already is but perhaps could be useful for something like Xml serialisation and deserialisation.
* C#'s http://www.markhneedham.com/blog/2008/08/15/first-thoughts-on-using-var-in-c-30-with-resharper/[var keyword] which helps to remove unnecessary type information and can lead to shorter methods when used well but completely unreadable code when misused.
* Ruby's open classes which give great flexibility when working effectively with 3rd party libraries for example but can lead to http://avdi.org/devblog/2008/02/23/why-monkeypatching-is-destroying-ruby/[difficult debugging problems] if overused. The same probably also applies to C#'s http://msdn.microsoft.com/en-us/library/bb383977.aspx[extension methods].

I have no doubt there are other features in other languages and probably more in the languages I listed but those are some of the ones that stood out to me when I first saw them.

I like this quote from Nate in the comments about import static, referring to being able to being able to tell what the code is doing just from looking at it:

____
The rule is simple (and somewhat subjective... if you aren't sure, just ask me what I prefer. :) ) -- if it helps the code to communicate better (especially contextually!) then use it.
____

Maybe a similar type of rule is applicable when using other language features as well and there is no feature that we should be using all the time - only if it makes our code easier to read and understand.
The Information Wall
Date: 2008-08-20 00:22:27

Sometimes the simplest things can provide the greatest value to project teams. We often look for a technical solution to problems where something simpler would achieve the same aim.

The Information Wall is as its name may suggest a place where you can put information that people in the team need to know but which they have not (yet) committed to memory.

Examples of things that you could put on an information wall could be:

* Wiki url
* SVN repository url
* Remote machine names & credentials
* Build server url
* Useful phone numbers
* Anything else that's needed!

Although it may seem to add very little value I think it's a really good tool for making information accessible to people. It also means you avoid the valueless conversations where team members keep interrupting each other to ask for these details.

Having the wall as close to the development team area as possible is ideal.
Building in release mode with no pdbs with msbuild
Date: 2008-08-20 18:50:18

I've been having trouble trying to work out how to build our projects in msbuild in release mode without creating the customary http://msdn.microsoft.com/en-us/library/yd4f8bd1(VS.71).aspx[pdb] files that seem to be created by default.

I tried calling msbuild.exe with the 'Release' configuration:

[source,text]
----

'C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.Exe ( Proj.csproj /p:OutputPath=\output\path\ 	/p:Configuration=Release)'
----

To no avail. It still created the pdb file. Next I tried setting the 'DebugSymbols' property to false:

[source,text]
----

'C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.Exe ( Proj.csproj /p:OutputPath=\output\path\ 	/p:Configuration=Release /p:DebugSymbols=false)'
----

Still it created the file. Finally I found http://forums.msdn.microsoft.com/en-US/msbuild/thread/59d636b2-0cf3-4434-b7b9-c20f2e38fb18/[this post] which suggested that you actually needed to make the change in the Proj.csproj file itself.

I changed this part of the file so that DebugType is now 'none'. It had a value of 'pdbonly'  when I opened the file.

[source,text]
----

  none
  true
  bin\Release\
  TRACE
  prompt
  4
----

The pdb is no longer created.

_Update_
This can also be done by passing /p:DebugType=none as a command line argument as link:2008/08/20/building-in-release-mode-with-no-pdbs-with-msbuild/#comment-67[Tim points out] in the comments.
From Prototype to Delivery
Date: 2008-08-18 22:39:49

Projects often reach the interesting point where the prototyping and development phases intersect and there are some interesting decisions to make.

From a development point of view the biggest decision is what to do with the code that has been developed.

When developing http://en.wikipedia.org/wiki/Software_prototyping[prototypes] the focus tends to be on getting something to work quick and dirty. Not a lot of time is put into considering edge cases or error conditions or any of the other niceties that are needed for software to be usable in an enterprise environment.

There are generally three choices with regards to what to do with the code:

== Throw the code away

This would be the favoured choice all things considered as it means that the team can get the dual benefit of writing good quality production code TDD style while also taking on the lessons learnt during prototyping.

If this approach is to actually happen then expectations of the client need to have been set extremely well. It needs to be made clear to them during the prototyping phase that what's being written is throwaway code and is not production quality.

It is very easy for the client to see the output of prototyping and believe that functionality has been implemented and can now be rolled out.

From their point of view what they would see (from a UI level for example) from code written as a prototype or as production quality code may be no different, and they may think that you are just wasting their money by writing the same thing twice unless this is well handled.

== Keep the code and retrospectively refactor it

This option is the middle ground between the two extremes. We keep the prototyping code but add some tests and refactor the code in retrospect.

The code produced probably won't be as clean as if it had been written with a TDD approach, but it will allow the project to be delivered more quickly in the short term at least.

Edge cases probably won't be investigated as thoroughly as if the code is written from scratch with complete analysis, but more cases will be considered than if it was not tested at all.

== Keep the code as it is

The final option is to keep the code written during prototyping and add edge cases and error conditions around it.

This is the most risky approach because although we have working prototype code we lose the set of regression tests that we would have if it had been developed in a http://en.wikipedia.org/wiki/Test-driven_development[test first] approach.

Our mind set will now also be more inclined to think that a piece of functionality is complete and we may end up missing important edge cases which only rear their ugly head when the code is in production.

In a perfect world every  prototyping session would result in the code being thrown away and then rewritten using the lessons learned in the initial attempt.

As it is not, it does make me wonder whether it would be best to sacrifice some of the speed in the prototyping phase to write better code and remove some of the pain that will otherwise be felt later on.
Resharper templates
Date: 2008-08-27 11:58:03

One of the first things that I do when I go onto a project is setup a http://www.jetbrains.com/resharper/[ReSharper] http://www.jetbrains.com/resharper/features/code_templates.html[template] for writing tests.

I generally set this up so that when I type 'should' I can press tab and it will automatically create an outline of a test method for me.

Creating a template is as simple as going to 'ReSharper > Live Templates' from Visual Studio.

I have attached several templates that I seem to end up writing over and over again.

To import these go to 'ReSharper > Live Templates' and click on the Import button on the menu.

* link:{{<siteurl>}}/uploads/2008/08/should.xml[should Resharper template]
* link:{{<siteurl>}}/uploads/2008/08/NUnitTestFixture.xml[NUnit Test Fixture template]
* link:{{<siteurl>}}/uploads/2008/08/ClassImplementingInterface.xml[Implement interface template]

To make class creation templates available on the 'Add New Item From Template' menu right click on the project, 'Add > New From Template > More' then select the appropriate template and tick the box which says 'Add to quicklist'
Handling balances in systems
Date: 2008-08-27 21:47:15

On one of my previous projects one of the problems that we had to solve was how to handle balances - we were working on a cash service for a financial services company.

The main discussion often centres around how often the balance should be updated. From my experience there are two main ways that we can go about this:

== Real time update after every transaction

This is perhaps the most obvious approach and the implementation is fairly simple. After every transaction is executed the appropriate accounts should be debited/credited as part of that http://martinfowler.com/eaaCatalog/unitOfWork.html[unit of work].

The benefit of doing it this way is that when we want to get the latest balance for an account we can easily do it without the need for any calculations. The balance stored in the database is always accurate.

The problems begin when the number of transactions being executed starts to increase. The likelihood is that most transactions will involve one of the bank's house accounts which means that you very quickly end up with severe database locking issues.

These can theoretically be solved by using row level locking but it's only a matter of time before the performance of the system is completely non existent.

== Batch updates at varying intervals

The alternative is to not store the balance in real time and instead have a batch job running each night (for example) that updates it until the end of that day.

This approach was first shown to me by http://blog.halvard.skogsrud.com/[a colleague] who also pointed out http://blogs.msdn.com/pathelland/archive/2007/06/14/accountants-don-t-use-erasers.aspx[this article] by http://blogs.msdn.com/pathelland/default.aspx[Pat Helland] on the benefits of bringing the ideas of accountancy into software design.

The trade off that we incur as a result of taking this approach is that we now need to create a batch job to calculate how the balances have changed each day and update these in the database.

Finding the current balance for an account also becomes more difficult as we now need to take the previous day's balance and apply the impact of today's transactions to come up with a real time balance.

The problems with database locking are removed, however, and this approach scales much more easily.

There are other interesting challenges around handling data like this in financial systems but balances strike me as particularly interesting since the most obvious solution is not necessarily the best one.
C# Thrift Examples
Date: 2008-08-29 01:39:52

As I mentioned in my http://www.markhneedham.com/blog/2008/08/29/thrift-as-a-message-definition-layer/[earlier post] I have been working with Facebook's http://incubator.apache.org/thrift/[Thrift] messaging project.

Unfortunately there are not currently any C# examples of how to use the Data Transfer Objects the Thrift compiler generates for us on the http://wiki.apache.org/thrift/ThriftUsage[official wiki].

We managed to figure out how to do it by following the http://wiki.apache.org/thrift/ThriftUsageJava[Java instructions] and converting them into C# code. Before writing any code we need to import Thrift.dll into our Visual Studio project.

Assuming that we have the following Thrift definition file:

[source,text]
----

namespace csharp Test.Thrift

struct FooBarMessageThrift {
1: string Foo
2: string Bar
}
----

When we run the http://wiki.apache.org/thrift/ThriftInstallationWin32[Thrift compiler] we will end up with the FooBarMessageThrift class. I won't post this class here as it's all codegen.

The easiest way to transport this class around is by converting it to a byte array and transporting that:

[source,csharp]
----

var fooBarMessage = new FooBarMessageThrift {Foo = "foo", Bar = "bar"};
var stream = new MemoryStream();

TProtocol tProtocol = new TBinaryProtocol(new TStreamTransport(stream, stream));

fooBarMessage.Write(tProtocol);

byte[] content = stream.ToArray();
----

To read the byte array back into FooBarMessageThrift we do this:

[source,csharp]
----

var stream = new MemoryStream(content);
TProtocol tProtocol = new TBinaryProtocol(new TStreamTransport(stream, stream));

var barFooMessageThrift = new BarFooMessageThrift();
barFooMessageThrift.Read(tProtocol);
----

'content' in this example is the byte[] created in the first example, and that's all there is to it!
Getting latest tagged revision in SVN from DOS/Batch script
Date: 2008-08-16 00:10:51

The way we have setup the build on our continuous integration server, http://www.jetbrains.com/teamcity/[Team City] is configured to create a new tag every time the functional tests past successful on that machine.

We then have a QA and Showcase build that we can run to deploy all the artifacts necessary to launch the application on that machine.

Originally I had just written the batch script to take in the tag of the build which the user could find by looking through http://tortoisesvn.tigris.org/[repo-browser] for the last tag created. This quickly became very tedious so I started looking for a way to get the latest tagged revision from the command line.

We thought it would be possible to get this information using svn info but it turned out that the information returned by svn info about revisions doesn't necessarily refer  to the latest created tag. We ended up using svn log and then parsing through that data. It's a bit messy but it does the job (I name each tagged version of the code as 'build-\{TeamCity-Build-Number}):+++<table class="CodeRay" border="0">++++++<tbody>++++++<tr>++++++<td class="line_numbers" title="click to toggle" onclick="with (this.firstChild.style) { display = (display == '') ? 'none' : '' }">++++++<pre>+++1+++<tt>++++++</tt>+++2+++<tt>++++++</tt>+++~~~
</td>
+++<td class="code">++++++<pre ondblclick="with (this.style) { overflow = (overflow == 'auto' || overflow == '') ? 'visible' : 'auto' }">+++FOR /F "Tokens=2" %%i in ('svn log /tags/path --limit=1 -v {caret}| find "build"') do set TMP=%%i+++<tt>++++++</tt>+++FOR /F "Tokens=2 delims=/" %%i in ('echo %TMP%') do SET TAG=%%i~~~
</td>
</tr>
</tbody></table>
The for loop uses a space as its default delimiter so that's what the 'delims=/' is doing on the second line, the 'Tokens=2' allows us to get the second token after the string is split and the '{caret}' in the first command is being used to escape the pipe.+++</pre>++++++</td>++++++</pre>++++++</td>++++++</tr>++++++</tbody>++++++</table>+++
Querying Xml with LINQ - Don't forget the namespace
Date: 2008-08-28 10:15:45

I've been working with a colleague on parsing a Visual Studio project file http://weblogs.asp.net/scottgu/archive/2007/08/07/using-linq-to-xml-and-how-to-build-a-custom-rss-feed-reader-with-it.aspx[using LINQ] to effectively create a DOM of the file.

The first thing we tried to do was get a list of all the references from the file. It seemed like a fairly easy problem to solve but for some reason nothing was getting returned:

[source,csharp]
----

XDocument projectFile = XDocument.Load(projectFilePath.Path);

var references = from itemGroupElement in projectFile.Descendants("ItemGroup").First().Elements()
                 select itemGroupElement.Attribute("Include").Value;
----

We are selecting all the occurrences of 'ItemGroup', taking the first occurrence, getting all the elements inside it (i.e. all the Reference elements) and then selecting the value of the 'Include' attribute. A fragment of the csproj file is as follows:

[source,xml]
----

<ItemGroup>
	<Reference Include="System" />
	<Reference Include="System.Core">
		<RequiredTargetFramework>3.5</RequiredTargetFramework>
	 </Reference>
...
</ItemGroup>
----

After several hours of trial and error it turned out that we just needed to include the namespace of the file when querying. The new and now working code looks like this:

[source,csharp]
----

XNamespace projectFileNamespace = "http://schemas.microsoft.com/developer/msbuild/2003";
XDocument projectFile = XDocument.Load(projectFilePath.Path);

var references = from itemGroupElement in projectFile.Descendants(projectFileNamespace + "ItemGroup").First().Elements()
                 select itemGroupElement.Attribute("Include").Value;
----

There are two quite clever things going on with the way this is done

1) There is an http://msdn.microsoft.com/en-us/library/z5z9kes2(VS.71).aspx[implicit type conversion] defined on XNamespace which allows us instatiate it using a string.
2) The addition(+) operator has been overloaded on XNamespace so that it can combine the namespace with the local name ('ItemGroup'). This is described in more detail http://msdn.microsoft.com/en-us/library/bb669152.aspx[here].
Hiring Developers - not just about the code
Date: 2008-08-10 01:23:38

It seems programmers are taking a bit of a hammering this week!

Kris Kemper talks about the http://blog.kriskemper.com/2008/08/07/preventing-the-net-negative-producing-programmer/[Net Negative Producing Programmer] referring to a http://www.pyxisinc.com/NNPP_Article.pdf[paper] linked to by http://blog.jayfields.com/2008/08/elitist-or-optimist.html[Jay Fields], concluding that the code submission is very important in helping to distinguish between good and bad candidates.

Now I probably haven't done as many interviews at ThoughtWorks as Kris has but from what I've seen of the recruitment process it seems to be more focused on ensuring that potential hires culturally fit into the organisation rather than that they write the best code that anyone has ever seen. Clearly a level of ability in coding is important for a Developer but I believe that the ability to communicate and collaborate with your colleagues is even more important. It's quite a rare situation in software development where you have to develop something completely on your own, and even if it were to happen you would still need to communicate with your customer even if the development effort was solo.

Bruce Eckel has an http://www.artima.com/weblogs/viewpost.jsp?thread=228097[interesting post] about hiring technical talent where he lists several criteria for hiring people, ending on the note that organisations should not hire people he terms as 'toxic'. A toxic person according to his description is someone who has some kind of quirk that causes destructive behaviour. In other words someone who is likely to destroy the morale of any team they are placed in by their actions.

I think ThoughtWorks are getting the balance right in hiring very talented people who are able to collaborate with each other to solve problems. One client even said to me that they did not understand how every single ThoughtWorks person they met was so nice. I think that is a glowing recommendation for looking at the overall personality of candidates and not just raw coding ability.