Delusional plan

Stephen Conroy is not renown for making any intelligent contribution to Australian society and definitely not renown for possessing a great deal of knowledge on anything - including Intenet, Digital Media, and now traffic management. His latest delusional contribution to his vast collection of bloopers (mind you tax payers funded bloopers) is:

he was confident that placing speed humps every 100 metres on all Australian freeways would protect children - reducing accidents by 100 percent with a "negligible" impact on traffic congestion and travel times. The plan was supported by traffic management trials which had only been conducted in suburban back streets.

Anyone with a shred of intelligence will immediately asked why would children, or to matter any human or animals, be allowed onto a freeways. All freeway entrances have big signs declaring what are permitted to go onto a freeway. 

Is Conroy deluded into thinking freeways are synonymous with suburban back streets?

Is he confused with children inside a car in an accident that could harm them? May be he should ban cars carrying children to use freeway. Or banning children riding in a car at all. That will definitely reduced children injured in car accident by 100%. Banning thing is a widely practice by our authoritarian politicians who lack communication and persuasive skill. This is equally a stupid idea and may be that is Conroy's plan B. Who knows and I will not be the only one surprise if it turned out to be.

Wrong assumption and big blunder

This would be funny if not deadly serious. How can a company producing military drones can be so stupid:

The problem was uncovered in July 2009, when the US military found files of intercepted drone video feeds on the laptop of a captured militant, intelligence and defense officials told the Journal.

They discovered "days and days and hours and hours of proof," an unnamed source said.

"It is part of their kits now."

Some of the most detailed examples of drone intercepts have been uncovered in Iraq, but the same technique is known to have been employed in Afghanistan and could easily be used in other areas where US drones operate.

The US government has known about the flaw since the 1990s, but assumed its adversaries would not be able to take advantage of it, the Journal said.

Adding encryption to a decade-old system requires upgrading several components of the system linking drones to ground control.

One of the developers of SkyGrabber, which is made by Russian company SkySoftware, told the Journal he had no idea the program could be used to intercept drone feeds

Even your mobile phone has more security and encryption from the handset to the base station than something meant to perform the task stealthily. It is just arrogant and stupid to assume your adversaries is dumb. I am wondering who is dumber now.

Applied equally to software

Software development tools and languages are progressively automated with heavy layers of encapsulation in the guise of freeing the developers from needing to know the underlying principle. This heavy layer of automation is fine until problem strikes and that is when people's knowledge of its underlying principle is needed to dig oneself out of the problem. I am not anti-encapsulation or things like that but I am a strong advocate of the importance to dig deeper to learn the principle behind a framework or class library so that one knows precisely what is underneath.

The situation has many similarity to this pilot's encounter with an automated plane:

The irony, she said, is that the more advanced the automated system, the more crucial the contribution of the human operator becomes to the successful operation of the system. Bainbridge also discusses the paradoxes of automation, the main one being that the more reliable the automation, the less the human operator may be able to contribute to that success. Consequently, operators are increasingly left out of the loop, at least until something unexpected happens. Then the operators need to get involved quickly and flawlessly, says Raja Parasuraman, professor of psychology at George Mason University in Fairfax, Va., who has been studying the issue of increasingly reliable automation and how that affects human performance, and therefore overall system performance.


”There will always be a set of circumstances that was not expected, that the automation either was not designed to handle or other things that just cannot be predicted,” explains Parasuraman. So as system reliability approaches—but doesn’t quite reach—100 percent, ”the more difficult it is to detect the error and recover from it,” he says.
And when the human operator can’t detect the system’s error, the consequences can be tragic.

Pouring cold water on 'hacked' Climate Research Unit's E-Mail

I am skeptical that the recent publication of the collection of e-mail exchanges between scientists in the Climate Research Unit is the work of a hacker. My skepticism is now supported by a forensic analysis by a Unix System Administrator.

The only reasonable explanation for the archive being in this state is that the FOI Officer at the University was practising due diligence. The UEA was collecting data that couldn't be sheltered and they created FOIA2009.zip.

It is most likely that the FOI Officer at the University put it on an anonymous ftp server or that it resided on a shared folder that many people had access to and some curious individual looked at it.

If as some say, this was a targeted crack, then the cracker would have had to have back-doors and access to every machine at UEA and not just the CRU. It simply isn't reasonable for the FOI Officer to have kept the collection on a CRU system where CRU people had access, but rather used a UEA system.

Occam's razor concludes that "the simplest explanation or strategy tends to be the best one". The simplest explanation in this case is that someone at UEA found it and released it to the wild and the release of FOIA2009.zip wasn't because of some hacker, but because of a leak from UEA by a person with scruples.

 It is most likely an inside job.

E-Voting system opened for public scruntiny

Ed Felton's effort has finally paid dividend and Sequoia has opened up their Frontier e-voting system source code that is still in development for public scrutiny.

Yesterday, Sequoia made good on this promise and you can now pull the source code they've made available from their Subversion repository here:
http://sequoiadev.svn.beanstalkapp.com/projects/

They should be applauded to ensure full confidence in their product. I just wish many companies, particularly those producing ERP and critical software, are that inclined.

What is of great interest to me is the fact that this system is developed using MS .Net Framework V2/3.5 and the projects are developed using C# in VS2008.

A quick scan of the projects revealed some issues:
1) The solution failed to be self-contained. In other words, the solution should contains all the third party supporting DLLs and then projects needing it are then referring them in relative path. In this way, the source control and solution will contain everything a developer would need when the solution is checked the solution out. Perhaps they are not included in the public code because of licensing issues.

2) Many classes should be marked static but are not. There are signs showing the code may have been migrated from .Net 1.x, which does not have static class. For example, the Contract class in Core solution.

3) Projects have not turned on Code Analysis. May be they do not use Visual Studio Team System.

4) The System.Data.IDataReader that is returned by Sequoia.EMS.Core.DataServices.BaseDataService or Sequoia.Ems.Data.Custom.BaseEntrySet does not appear to have been disposed after entries are added in Sequoia.Ems.Data.Custom.BaseEntrySet.Load(). IDataReader is derived from IDisposable.

5) Good to see the use of the Workflow engine.

6) Use of NUnit is evidence in the code but does not appear to be widespread usage of the Unit Test or TDD.

7) It is also using Microsoft Enterprise Library but it appears that it is using its own implementation to do logging.

8) Some project for example, the Core, is set to use .Net 2.0 but it contains references to .Net 3.5 specifics namely System.Xml.Linq. Very strange. Just wondering if it is in the process of upgrading all project to .Net 3.5. There are currently 10 projects in .Net 2 and 12 in .Net 3.5. Altogether there are 22 projects.

9) Personally I am not too keen on the way the Core project is organized. Essentially Core is a project containing 34 files which are grouped into pseudo-sub-projects using solution folders. This kind of design can encourage tight coupling because each sub-project's internal artifacts are available to each other. May be that is their intention. Preliminary review does not support this.


This kind of organization also makes partitioning the module to be managed by several developers difficult. It is most unfortunate that VS2008 does not support netmodule in the IDE otherwise, partitioning Core into several netmodules is a better organization.

Treat String containing '\0' with care

Recently I had to decode a sequence of octets representing the UCS2 of some data and the sequence contained the C-Style string's null terminator. The sequence of octets were represented in C# as Byte[] naturally and Encoding.Unicode.GetString() was used to decode the sequence into a Unicode string.

The decoding process did not trim off the terminating '\0'. So it produced a Unicode string like this "Hello World\0".

During testing, several interesting things were discovered that could have significant impact on your code and the validity of your Unit Tests:
1) If you write out the string to console like this:

String s = "Hello World\0"; 
Console.WriteLine( "This is the Unicode String = '{0}'", s );

Your output will not contain the trailing '.

2) If you use write out several lines like this:

String s = "Hello World\0"; 
Console.WriteLine( "This is the Unicode String = '{0}'", s );
Console.WriteLine( "See anything strange?" );

It will produce a line like this:

This is the Unicode String = 'Hello WorldSee anything strange?

The Console.WriteLine() removes the ending ' and the newline.

3) Make sure you use the correct version of String.Compare() and use the correct comparison type as specified by the StringComparison enumeration:

String s0 = "Hello World"; 
String s1 = s0 + "\0";

Assert.IsFale( s0.EndsWith( "\0" ); // Just to check 
Assert.IsTrue( s1.EndsWith( "\0" ); // Just to check
Assert.IsTrue( s0.Equals( s1 )==false ); 
Assert.IsTrue( String.Compare( s1, s0 )!=0 );     // Fail but should Pass
Assert.IsTrue( String.Compare( s1, s0, false )!=0 ); // Fail but should Pass
Assert.IsTrue( String.Compare( s1, s0, StringComparison.Ordinal )!=0 );
Assert.IsTrue( String.Compare( s1, s0, 

   StringComparison.InvariantCulture )!=0 ); // Fail but should Pass

The lines in red are incorrectly processed.

Be careful when using NUnit's Assert.AreEqual(). In version 2.4.x, the AreEqual() incorrectly handles this case resulting in passing the comparison. This mistake has been fixed in ver 2.5. MSTest's AreEqual() correctly handles this case.

This illustrates the need to exercise care when comparing strings.