Google Transit for Adelaide

Tuesday, 2 December 2008

I saw this mentioned on Australian IT today – if you open up Adelaide in Google Maps, you now get the option of listing directions by “public transit”.

So for example, if I wanted to get from “Westbourne Park to Glenelg”, just enter exactly that phrase and search, then click on the ‘public transit’ link


View Larger Map

As you can see from the map, it indicates the bus route (216), then you change to a tram (), then finally you walk (). The directions panel contains bus stop details and the service times.

Ever since I owned an Apple Newton MessagePad and more recently a few Windows Mobile devices I’ve had an idea for an application that would allow you to interactively find out when the next bus was, and tell me what time I would arrive home – taking into account that I used to catch two buses and a train to get home. Well it looks like Google has pretty much implemented that idea for me!

Useful PowerShell snippets (part 1)

Monday, 1 December 2008

Some things I’m finding useful:

Processes running on a machine

Get-WmiObject Win32_Process -ComputerName mymachine | Select { $_.Name }

Currently logged in user on a machine

Get-WmiObject Win32_ComputerSystem -ComputerName MyMachine | Select { $_.UserName }

Does a machine have .NET 3.5 SP1 installed

function Get-Net35SP1([string] $machineName)
{
    $reg = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey('LocalMachine', $machineName)
    $regKey= $reg.OpenSubKey("SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.5" )
    if ($regKey -ne $null) {
        Write-Output $regKey.GetValue("SP", 0)
        $regKey.Close()
    } else {
        Write-Output "Doesn't have .NET 3.5"
    }
    $reg.Close()
}

Log4net’s SmtpAppender with multiple email addresses

Monday, 24 November 2008

Log4net is a popular logging framework, and amongst the various logging “appenders” it includes one for sending emails – the SmtpAppender. The documentation for the SmtpAppender’s To property says it contains a semicolon-delimited list of email addresses.

However if you try to do that, you won’t see any emails being sent. Add the following to your app.config file to enable log4net’s debug logging:

  <appSettings>
    <add key="log4net.Internal.Debug" value="true" />
  </appSettings>
  
 <system.diagnostics>
  <trace autoflush="true">
   <listeners>
    <add name="textWriterTraceListener" 
     type="System.Diagnostics.TextWriterTraceListener"
     initializeData="C:\\tmp\\log4net.txt" />
    </listeners>
   </trace>
 </system.diagnostics>

You’ll then see this internal error message in the log4net.txt file:

System.FormatException: The specified string is not in the form required for an e-mail address.
   at System.Net.Mime.MailBnfHelper.ReadMailAddress(String data, Int32& offset, String& displayName)
   at System.Net.Mail.MailAddressCollection.ParseValue(String addresses)
   at log4net.Appender.SmtpAppender.SendEmail(String messageBody)
   at log4net.Appender.SmtpAppender.SendBuffer(LoggingEvent[] events)

This shows that the SmtpAppender is leveraging the .NET Framework’s System.Net.Mail.MailAddressCollection class. The ParseValue method is not public, but Add(string) is, and if you scroll down to the remarks, you’ll see the following text:

If multiple e-mail addresses separated with a semicolon character (";") are passed in the addresses parameter. a FormatException exception is raised.

So it turns out log4net’s documentation is misleading, or at least out of date. Change your email addresses to use the comma and everything comes good again.

Drought breaks..

Thursday, 13 November 2008

I’m pleased to report that it appears the biscuit drought has broken. We’re seeing good falls of assorted creams as well as the good old family assorted again.

That is a relief!

One of the nice things about my current workplace – they provide tea, coffee, Milo (but not Bonox!) and usually once a week if you’re lucky you’ll find some bickies in the kitchen, presumably left by the biscuit fairy.

Death March by Edward Yourdon

Wednesday, 12 November 2008

Death March (2nd Edition) (Yourdon Press Series) - published by Prentice Hall, 1997

When I first began reading this book, I thought it would be all about the team that came before us… the one that spent a lot of time delivering something that didn’t work. But the more I read, the more I found myself identifying our current team with the descriptions in each chapter. Curious as the title doesn’t sound that positive! As Wikipedia defines it, a death march project is one that is destined to fail.

One point that comes out repeatedly is that while in some ways “Death March” projects are not intended to be the norm, more often than not they end up being the de facto way that many IT projects are run.

In Ch. 1, characteristics of a “Death March” project are listed as including:

Hmm.. that sounds familiar!

In subsequent chapters he goes on to cover topics such as Politics, Negotiations, People, Processes, Tools & Technologies and finally the idea of “Death March” projects as a way of life.

In Ch. 3, the topic of Estimation is examined, and the value of having an experienced project manager who can estimate slightly better than just “gut feeling”, and that there are software estimation tools that can improve forecasting accuracy. I reckon Steve McConnell’s Software Estimation: Demystifying the Black Art (Best Practices (Microsoft)) could be worth a read to learn a bit more about this topic. I’ll add that to my wish list!

People can make all the difference, and our team certainly bears this out. I can’t agree with the comment that 80 hours a week is ok though.

Yourdon also espouses the importance of good workplace conditions – in particular quietness and privacy (eg. separate offices). There’s certainly empirical evidence to reinforce the productivity benefits, which flies in the face of the current trend of “open” office space, cramming as many people into tiny cubicles as possible.

Triaging tasks/bugs are critical, and allows you to prioritise what is important.

When this book was first published, there wasn’t much in the way of “Agile” development practises, but I think Yourdon is alluding to this when he makes mention of using RAD tools (refactoring), mini-milestones (iterations) and daily builds (continuous integration).

One thing I did find annoying was Yourdon’s use of a monospace font when listing the emails in each chapter’s list of references. This made them very hard to read and I mostly ended up skipping over them as a result.

Overall I came away inspired by this book. Yourdon highlighted the many pitfalls that await a team who are engaged in a “Death March” project, but does offer hope that under the right conditions, you can achieve success.