I was following a Hong Kong mini-van, which has a reputation of being a speeding maniac. Suddenly I noticed, through its rear window, a large LED display inside its cabinet hanging from the roof above the dashboard on the passenger's side.
It was displaying a number and was changing. Initially it seemed very meaningless to me but curiosity got better of me and a quick guess and comparison with my car's speedometer revealed that the figure being displayed was the actual speed of the van.
According to the local, this allows the passenger to keep the driver honest or at least giving them a hint when to hop off to safe their life.
I guess it can also allow citizen arrest or unmarked police car a clear idea if the driver of the van is speeding.
What a good idea! Instead of having radar trap, the driver is advertising its speed for all road users - driving or not - to make the decision. With so many mobile phone with camera around, it is not hard to take a snap and upload that to the police website to report offender.
It is a brilliant idea and country with road speed problem should adopt this.
A site devoted to discussing techniques that promote quality and ethical practices in software development.
Saturday, December 30, 2006
Asia Internet Disruption - still no messenger
On the 4th day after the earthquake off the southern coast of Taiwan, the Internet service is still not working properly.
Still can't get MSN Messenger going and naturally the Hotmail is down. Thankfully GMail is back.
According to the officials, the damages are worse than first thought of.
WSJ and NY Times are still working.
Still can't get MSN Messenger going and naturally the Hotmail is down. Thankfully GMail is back.
According to the officials, the damages are worse than first thought of.
WSJ and NY Times are still working.
Thursday, December 28, 2006
How robust is the Internet to Natural Disaster?
I have always wondered how robust is the Internet in the face of natural disaster? At the moment I am visiting Hong Kong and is experiencing the first hand the reaction of the Internet in the face of a natural disaster. Many may have already read that on Boxing day, the southern part of Taiwan has experienced a very severe earthquake.
While the damages in terms of loss of life and properties have been minimal as it happened under the sea of the island, the damages to the Internet communication to the US and Southern hemisphere have been very severe.
Internet Banking, gmail, hotmail and messenger have been off the air and if not the services are limping along. Some local Chinese newspaper puts the loss to ask high as 60-70% of normal performance. There have been 6 fibre optic submarine cables being affected.
So far I can only reach GMail today and it was off air totally yesterday. Ping of www.microsoft.com are www.hotmail.com are not recognised. Probably the local ISP just took these sites off their DNS servers to avoid a kind of DOS as people trying to reach them.
It is amazing I could get to my Gmail but I cannot get to my Hotmail accounts. Of course the MSN Messenger's status stite is useless as I cannot reach that site. I could not reach my web mail.
Not happy at all.
Traffic to the west appears to be fine as I can reach bbc, a UK site, and a company in Germany with the normal Internet speed. Tracert to Australia sites, like news.com.au and ABC meet with extremely long times and often with sequences of timeout.
Strangely, I can reach the Google Australia, ANZ Bank , The Commonwealth Government's Department of Immigration but not the Commonwealth Bank.
If 6 cables damages are enough to bring down the Internet traffic this way, it does not take much to cause severe financial damages to many places and some companies may even been driven to the wall. I guess this is the price to pay to become connected without an effective geographic diversity route to cater for this kind of disruption.
Let's hope this instance will cause the Internet community to rethink and to provide sufficient geographic diversity strategy to deal with this kind of 'attack'.
While the damages in terms of loss of life and properties have been minimal as it happened under the sea of the island, the damages to the Internet communication to the US and Southern hemisphere have been very severe.
Internet Banking, gmail, hotmail and messenger have been off the air and if not the services are limping along. Some local Chinese newspaper puts the loss to ask high as 60-70% of normal performance. There have been 6 fibre optic submarine cables being affected.
So far I can only reach GMail today and it was off air totally yesterday. Ping of www.microsoft.com are www.hotmail.com are not recognised. Probably the local ISP just took these sites off their DNS servers to avoid a kind of DOS as people trying to reach them.
It is amazing I could get to my Gmail but I cannot get to my Hotmail accounts. Of course the MSN Messenger's status stite is useless as I cannot reach that site. I could not reach my web mail.
Not happy at all.
Traffic to the west appears to be fine as I can reach bbc, a UK site, and a company in Germany with the normal Internet speed. Tracert to Australia sites, like news.com.au and ABC meet with extremely long times and often with sequences of timeout.
Strangely, I can reach the Google Australia, ANZ Bank , The Commonwealth Government's Department of Immigration but not the Commonwealth Bank.
If 6 cables damages are enough to bring down the Internet traffic this way, it does not take much to cause severe financial damages to many places and some companies may even been driven to the wall. I guess this is the price to pay to become connected without an effective geographic diversity route to cater for this kind of disruption.
Let's hope this instance will cause the Internet community to rethink and to provide sufficient geographic diversity strategy to deal with this kind of 'attack'.
Tuesday, December 12, 2006
A Borland feature or bastardation of CLR? Continue...
Further to my previous blog questioning the wisdom of this 'feature', I have adjusted the demo and test out some of the scenarios mentioned.
Here I want to clear up a few things and to posit that this 'feature' creates more trouble than is worth.
I have removed the use of any C# assembly in my demo as it is always safer in highlighting problem in Delphi.Net to leave out C#.
Delphi.Net prevents one to use static linking when building DLL package (Delphi's term for .Net Class library) and only allows VCL.Net application to use static linking.
I will show below that while this is a good move but it will still create a confusing situation and that the compiler should have a switch to flag missing referenced assembly when building application.
It is worth noting that the normal CLR probing algorithm will look for this type "MyDemoLib.MyClass, MyClassLib" in MyClassLib.dll, MyClassLib\MyClassLib.dll, MyClassLib.exe and MyClassLib\MyClassLib.exe before it throws a type load exception, in the absence of any PrivateBinPath specification.
In other words, as far as loading a type is concern, it does not matter if the type is packaged in a DLL or executable assembly. I therefore argue that because of this added flexibility, Borland's porting of their static binding from VCL32 to VCL.Net not only creates an assembly in violation of ECMA-335 but also prevents the assembly from being exploited fully. This will be demanded below.
Moreover, Delphi.Net's prevention of DLL Package from using static binding while permitting application to use static binding destroys the symmetry that is part of CLR standard as demonstrated in the CLR Probing algorithm.
Incidentally when a type is loaded from a Delphi.Net executable, the initialization section in the DPR is completely by-passed. Using .Net executable assembly as a stand alone as well as publishing features that others can load, as an assembly, saves one from distributing executable as well as dll assembly. It also allows one to unit test types inside an executable without having to package them as DLL assembly.
At the moment, Delphi 2006 does not support adding a reference to an application or application project to another .Net project and hence any runtime interaction has to be done using late binding using technique such as System.Activator.CreateInstance(). Visual Studio 2005 is the only one that supports this. So you can effectively directs a VS2005 project to reference a VCL.Net application to use the type inside. In fact, this capability has been exploited to construct NUnit assembly to unit test types inside Delphi.Net application.
Because Delphi.Net/Pascal does not have qualifier to restrict types declared in the interface section to have CLR assembly visibility, all those types, that have to be declared in the interface section so that they can be accessed by types in other units, are free for anyone to use and this makes unit test very easy but creating a very loosely control design in .Net.
Now let consider some scenario.
App1.exe (dynamically linked) using types in App2.exe (statically linked)
This situation will prevent types that depends on VCL in App2 from being used in App1 for reason disclosed in my previous blog.
App2.exe (static bind) using types in MyDemoLib.dll
While Borland tries to make their DLL package to conform to the standard CLI, the MyDemoLib.dll is now prevented from being used in App2 because the above situation would result in two sets of distinct VCL classes.
I suppose in Vcl32 world, one cannot use types in an executable the same way as in .Net supports and as a result, the IPC mechanism insulates the difference.
I am also wondering why Borland or CodeGear prevents DLL Package from using static linking. In Win32, DLL is allowed to use either static or dynamic binding. If Borland is to maintain compatibility with Win32, it should support static binding in DLL. May be VCL32's dll does not have static linking.
As shown, because of the flexibility of the CLR Probing algorithm that does not distinguish DLL assembly from executable assembly as far as type loading is concern, the support of this so-called static binding in Delphi.Net gains nothing but creating compatibility issues for assemblies generated by Borland and ignoring the ECMA-335 standard.
Here I want to clear up a few things and to posit that this 'feature' creates more trouble than is worth.
I have removed the use of any C# assembly in my demo as it is always safer in highlighting problem in Delphi.Net to leave out C#.
Delphi.Net prevents one to use static linking when building DLL package (Delphi's term for .Net Class library) and only allows VCL.Net application to use static linking.
I will show below that while this is a good move but it will still create a confusing situation and that the compiler should have a switch to flag missing referenced assembly when building application.
It is worth noting that the normal CLR probing algorithm will look for this type "MyDemoLib.MyClass, MyClassLib" in MyClassLib.dll, MyClassLib\MyClassLib.dll, MyClassLib.exe and MyClassLib\MyClassLib.exe before it throws a type load exception, in the absence of any PrivateBinPath specification.
In other words, as far as loading a type is concern, it does not matter if the type is packaged in a DLL or executable assembly. I therefore argue that because of this added flexibility, Borland's porting of their static binding from VCL32 to VCL.Net not only creates an assembly in violation of ECMA-335 but also prevents the assembly from being exploited fully. This will be demanded below.
Moreover, Delphi.Net's prevention of DLL Package from using static binding while permitting application to use static binding destroys the symmetry that is part of CLR standard as demonstrated in the CLR Probing algorithm.
Incidentally when a type is loaded from a Delphi.Net executable, the initialization section in the DPR is completely by-passed. Using .Net executable assembly as a stand alone as well as publishing features that others can load, as an assembly, saves one from distributing executable as well as dll assembly. It also allows one to unit test types inside an executable without having to package them as DLL assembly.
At the moment, Delphi 2006 does not support adding a reference to an application or application project to another .Net project and hence any runtime interaction has to be done using late binding using technique such as System.Activator.CreateInstance(). Visual Studio 2005 is the only one that supports this. So you can effectively directs a VS2005 project to reference a VCL.Net application to use the type inside. In fact, this capability has been exploited to construct NUnit assembly to unit test types inside Delphi.Net application.
Because Delphi.Net/Pascal does not have qualifier to restrict types declared in the interface section to have CLR assembly visibility, all those types, that have to be declared in the interface section so that they can be accessed by types in other units, are free for anyone to use and this makes unit test very easy but creating a very loosely control design in .Net.
Now let consider some scenario.
App1.exe (dynamically linked) using types in App2.exe (statically linked)
This situation will prevent types that depends on VCL in App2 from being used in App1 for reason disclosed in my previous blog.
App2.exe (static bind) using types in MyDemoLib.dll
While Borland tries to make their DLL package to conform to the standard CLI, the MyDemoLib.dll is now prevented from being used in App2 because the above situation would result in two sets of distinct VCL classes.
I suppose in Vcl32 world, one cannot use types in an executable the same way as in .Net supports and as a result, the IPC mechanism insulates the difference.
I am also wondering why Borland or CodeGear prevents DLL Package from using static linking. In Win32, DLL is allowed to use either static or dynamic binding. If Borland is to maintain compatibility with Win32, it should support static binding in DLL. May be VCL32's dll does not have static linking.
As shown, because of the flexibility of the CLR Probing algorithm that does not distinguish DLL assembly from executable assembly as far as type loading is concern, the support of this so-called static binding in Delphi.Net gains nothing but creating compatibility issues for assemblies generated by Borland and ignoring the ECMA-335 standard.
Saturday, December 9, 2006
More Trouble with Programming
The the second part of the interview with Bjarne Stroustrup can be found here. Several of his observations reported in this interview are worth noting.
When he was asked to comment on the "coolest" program, this is what he had to say:
"What is common to these examples of code is that they cleanly separate concerns in a program, allowing separate developments of parts. That simplifies understanding and eases maintenance. These basic language techniques allow separate "things" to be separately represented in code and combined only when needed."
When he was asked to comment about the desire to "dumb down" programming languages so that more people can develop program, his observation is spot on:
"I think that would be misguided. The idea of programming as a semiskilled task, practiced by people with a few months' training, is dangerous. We wouldn't tolerate plumbers or accountants that poorly educated. We don't have as an aim that architecture (of buildings) and engineering (of bridges and trains) should become more accessible to people with progressively less training. Indeed, one serious problem is that currently, too many software developers are undereducated and undertrained.
Obviously, we don't want our tools--including our programming languages--to be more complex than necessary. But one aim should be to make tools that will serve skilled professionals--not to lower the level of expressiveness to serve people who can hardly understand the problems, let alone express solutions. We can and do build tools that make simple tasks simple for more people, but let's not let most people loose on the infrastructure of our technical civilization or force the professionals to use only tools designed for amateurs."
I know of some manager's view of being a competent programmer is to know the tool's IDE. In the manager's view that's the amount of training they need.
He further remarked that,
"Most applications involve standards, operating systems, libraries, and tools that far exceed modern programming languages in complexity. What is difficult is the appreciation of the underlying techniques and their application to real-world problems.
... We need relatively complex language to deal with absolutely complex problems."
Not only many developers lacks proper training, many lack sound understanding of the underlying techniques or mechanism. This often produces very fragile solution and they lack the skill and knowledge to explain things when they do not work.
The rest of the interview is on his view about .Net and C#.
It's worth a read.
When he was asked to comment on the "coolest" program, this is what he had to say:
"What is common to these examples of code is that they cleanly separate concerns in a program, allowing separate developments of parts. That simplifies understanding and eases maintenance. These basic language techniques allow separate "things" to be separately represented in code and combined only when needed."
When he was asked to comment about the desire to "dumb down" programming languages so that more people can develop program, his observation is spot on:
"I think that would be misguided. The idea of programming as a semiskilled task, practiced by people with a few months' training, is dangerous. We wouldn't tolerate plumbers or accountants that poorly educated. We don't have as an aim that architecture (of buildings) and engineering (of bridges and trains) should become more accessible to people with progressively less training. Indeed, one serious problem is that currently, too many software developers are undereducated and undertrained.
Obviously, we don't want our tools--including our programming languages--to be more complex than necessary. But one aim should be to make tools that will serve skilled professionals--not to lower the level of expressiveness to serve people who can hardly understand the problems, let alone express solutions. We can and do build tools that make simple tasks simple for more people, but let's not let most people loose on the infrastructure of our technical civilization or force the professionals to use only tools designed for amateurs."
I know of some manager's view of being a competent programmer is to know the tool's IDE. In the manager's view that's the amount of training they need.
He further remarked that,
"Most applications involve standards, operating systems, libraries, and tools that far exceed modern programming languages in complexity. What is difficult is the appreciation of the underlying techniques and their application to real-world problems.
... We need relatively complex language to deal with absolutely complex problems."
Not only many developers lacks proper training, many lack sound understanding of the underlying techniques or mechanism. This often produces very fragile solution and they lack the skill and knowledge to explain things when they do not work.
The rest of the interview is on his view about .Net and C#.
It's worth a read.