The Irish Times wrote a story last Thursday about how an air traffic controller used SMS to guide a plane down safely.

He then lost audio telephone contact but the air traffic controller switched to texting and told the pilot that he had a primary radar signal on the aircraft and that Cork would allow them to land there. He then used texts to guide the 30-year-old plane in.

So maybe rethinking the usage of phones on planes needs revisiting? SMS might be small but it can be powerful. A bit like the Twitter story of the guy whose one word triggered a whole community response to his arrest in Egypt.

Mobile post from the Esendex BlogIt service

Mobile post from the Esendex BlogIt service

This week Andy and Drew were wanting to test a method which had both a return value and an out parameter. A quick look through the NMock Quickstart, Tutorial, Advanced or Cheat Sheet pages didn’t show any way of achieving this. Thankfully the Blogosphere came through once again to prove that you can do this with NMock.

Say you have a method in your mockable class called:

public string AddGreeting(string userName)

you could expect to write a Stub declaration such as

Stub.On(mockObject)
.Method(AddGreeting)
.With("World")
.Will(Return.Value("Hello World"));

If your method has an out parameter as well, such as:

public string AddGreeting(string userName, out int characterCount)

then your Stub declaration will need to look like this:

Stub.On(mockObject)
.Method(AddGreeting)
.With("World", Is.Out)
.Will(new SetNamedParameterAction(["characterCount", 11), Return.Value("Hello World"));

The Is.Out is setting the expectation that one of the parameters you’re specifying is an Out parameter. The SetNamedParameterAction object is undocumented and has been found using reflection. This is a useful feature which hasn’t been documented. The NMock project appears to being built using continuous integration these days but that obviously doesn’t happen with the project documentation.

1. Copy the nant.xsd file from inside your NaNt schema directory.
2. Paste it into your Visual Studio XML Schemas directory (e.g. C:\Program Files\Microsoft Visual Studio 8\Xml\Schemas\
3. Restart Visual Studio

When you next load up an existing .build file, Visual Studio should detect it correctly as an XML document. To get the Intellisense to work, you will need to add the XML Namespace to the <project> tag. Start typing the additional attribute ‘xmlns=’ within the opening <project> tag and Visual Studio should offer you the following auto-complete option:

xmlns=http://nant.sf.net/release/0.85/nant.xsd

So your full project tag should look something like :

<project xmlns="http://nant.sf.net/release/0.85/nant.xsd"
name="Your Build Name"
default="all"
basedir=".">

For new .build files, you can select the Schema you want to base your new XML document on by browsing in the Schemas box in the Properties window. You should find xml\Schemas expanded and the nant.xsd entry able to be selected. Tick the nant.xsd box.

As you can probably see, there’s not much cork left in view! Saying that, I’ve just seen the inch-thick pile of cards that Nicholas has just removed from the current release. Whilst electronic methods of project tracking might offer lots of improvements, there’s something satisfying about hearing the riffle of all our hard work!

One of the parameters allows you to specify a DateTimeStyle and as I knew the time was going to be in UTC time I chose the AssumeUniversal DateTimeStyle. The MSDN information for DateTimeStyle defines AssumeUniversal indicating

“that if no time zone is specified in the parsed string, the string is assumed to denote a Coordinated Universal Time (UTC). Cannot be used with AssumeLocal or RoundtripKind.”

It seemed to be exactly what I wanted until I started testing it. The time I was getting back was an hour ahead so it was being converted to local time as we’re currently in British Summer Time (GMT+1) here.

The solution was to use the AdjustToUniversal DateTimeStyle instead. I’ve tested this with my system time in British Summer Time and without the local adjustment and it works fine for both.

Here’s the small console application I wrote to test the TryParseExact() method. Try it with AssumeUniversal instead of AdjustToUniversal if you want to see the difference for yourself.

class Program
{
static void Main(string[] args)
{
DateTime requestExpires;
DateTime.TryParseExact(”23/05/2008 08:30:49″, “dd/MM/yyyy HH:mm:ss”, null, DateTimeStyles.AdjustToUniversal, out requestExpires);
Console.WriteLine(requestExpires);
Console.ReadLine();
}
}