Shame on Telstra Text Buddy for failing LUA Test

You think the largest telecommunication company in Australia will develop and release software that works in LUA. Sadly not.

Telstra has a bonus credit feature that allows their mobile pre-paid broadband user credit that they can use to send SMS messages. One of the two ways you can send SMS from the comfort of your computer is to use a Telstra developed program called Text Buddy (version 1.0), which looks like this:

Despite the fact that this program is only compatible with Windows XP, it demands administrator privilege to run. Bad!!!

I bet you any dollar that their developers do not use LUA development and they developed this program in Administrator account.

Would I recommend NOOK for reading non-fiction materials?

I am grateful for receiving a color NOOK for Christmas and to avoid writing a review of a device with superficial experience, like many reviewers, I have decided to hold off writing a review of this device until I have adequate usage of it. Now more than 6 months of usage reading many technical eBooks I believe I have enough experience to write a review.

This review is from the usage and perspective of a reader of technical materials. Reading technical materials is very different from reading a novel and hence it is important if you are thinking of getting one of these devices, either NOOK or other similar device, make sure you have a good idea of what kind of materials you will be reading. Try it out with a DRM-free technical book.

If you are planning to use it to read technical materials, I will definitely not recommend you to buy a NOOK (color or not) for the reasons I list below. As a previous owner and long time user of a Fujitsu Tablet, I am no strange to this kind of keyboard-less device.

With no apology to Barnes & Nobles, I have not bought one single B&N DRM controlled eBooks for obvious reasons and probably never will. I bought all my DRM-free watermarked eBooks from InformIT, which is a great site for technical eBooks because you can get both ePub and PDF format for the one price; I can put the ePub version in my NOOK and the PDF version in my notebook. That's the wonderful benefit of using DRM-free books. This allows me to test the NOOK and to find which format is the best.

Here are the reasons why I believe a NOOK is a unsuitable reader to handle technical materials:
1) The extremely primitive and incapable user-interface is one of the root cause of problems elaborated below. It makes a mockery of having large storage capability allowing one to carry many books with you when the interface is so primitive that you cannot open several books at the same time, like you would with a physical books on your desk, and returning to the page you left off. This is a severe and fundamental oversight in the design.

In reading a novel, you will not never be reading several at the same time darting from one to another. Hence the ultra primitive user-interface is adequate for that purpose but is totally inadequate for anything else. It is a joy to use my PDF XChange-Viewer to read the PDF format of those eBook on my notebook.  

2) Even overlooking the problem mentioned in 1) above and reading just one book (ePub format) is also very frustrating. There is few technical book not containing notes (endnotes, footnotes, or bibliography) and all have provided hyperlinks to them. While it is so convenient to press the hyperlink to jump to the destination, you only have a few seconds of window of opportunity to jump back to where you came from. This is because the back button on the top middle of the screen disappears after several seconds. The time it is allowed to stay around is not even configurable but there is a setting to enable animate page turning.

Surely the developer of this device is not serious and placing animation ahead of functionality. Once that back button disappears, you have no way of bring it back. Returning to where you came from is a major hurdle. I often keeps a piece of scrap paper with my NOOK for jolting the page number.

3) Following on from 2), one wonders why someone would prefer to provide a slider bar to go to the required page when an edit box will be more functional particularly these touch device is so imprecise to allow one to move one page either way. Unless you remember the page number when you press that hyperlink, you will have a hard time finding your way back. As a result, it is a very frustrating device to use. I do not have such issue when reading the PDF on my PC as I can jump to a particular page by entering it into the text box.

It is definitely a sad case of cuteness trumping over functionality.

4) Its ePub reader cannot magnify diagrams at will and this is not only annoying but downright dysfunctional when reading technical materials full of diagrams and charts. Its PDF viewer can magnify but its ePub reader cannot.

5) Because it cannot retain your place in several books, it is very frustrating when using the NOOK as a device to replace physical books. You can do this comfortably on a notebook but not on NOOK.

I definitely will not recommend anyone to buy a NOOK to read technical materials.

Good way to study the effect of sgen.exe for XmlSerialization

SGen,exe is a tool from Microsoft to pre-generate a .Net assembly that writes the object to be serialized. There is no shortage of blog posts telling you how to use this, like this one and hence not repeated here.

We developer is often a doubting lot and wanting to know what magical power this sgen.exe has that claims to make some difference in performance or does it? Apart from pre-generating, much like NGen, an serialization assembly to avoid generating it on the fly, one wants to know what is in it and how it works.

The best way answer these questions and to study the output of SGen to convince yourself what it does and that it is indeed loaded is to include the following switches when generating:

• /debug  - this produces the PDB file
• /keep    - this keeps all the temporary files that were used in the process of producing the DLL. It is extremely useful because they (the .cs file) allows you to put break points in the generated code. It is also extremely educational to study them.
• /force   - to force the generation. But would be better if you include /o to generate the files to a different directory and then you can delete all files in that directory before running sgen. In this way you are not accumulating the temporary files creating a very confusing situation.

Don't forget to put the *.XmlSerializers.dll and *.XmlSerializers.pdb into the run directory, otherwise it will not be found.

SGen basically generates derived classes of XmlSerializationWriter and XmlSerializationReader containing code to write your class members out to or read from the xml data stream. It uses an XmlWriter to write to and XmlReader to read from a XML document. If you study these classes, they share some similar methods.

Generating an Xml Document from class or regenerating it from document can be done in many ways. In fact, if study the generated files you will discover that there is really no magic when calling XmlSerializer.Serialize() and XmlSerializer.Deserialize(). Whether you called XmlWriter or XmlReader to handle your class's member yourself or by some generated code, the process is the same.

If these overheads of dynamic code generation and building or using SGen.exe too troublesome or does not meet your needs, you can cook your own with using various techniques and classes available in .Net

Driven to Linux by Microsoft

I could rephrase this to "Driven away from Windows by Microsoft". No matter which way one words that, Microsoft has driven me away to Linux. As a staunch and long term Microsoft developer since DOS1, a few years back I would not have believed that today I am writing code in Ubuntu using MonoDevelop/Mono.

What causes me to wander away from Microsoft? Several.

1) The advent of machine with Hardware Virtualization Support and Microsoft's draconian unfriendly licensing requirements, including the consumer unfriendly activation scheme is largely the impetus for me to desert Windows. Virtualization (I use VMPlayer but I could easily use VirtualBox) allows developers and ordinary users to have a number of 'dedicated' machines or 'machines' that one can restore very quickly. But if the VM uses Windows, it becomes very expensive. You literally requiring one license per VM. Not only Windows but Office etc.

With more and more multi-core 64-bit machines being released, they are ripe for running VM but Microsoft's not making that easier and economically. Don't try to defend this with XP Mode as it requires XP Professional while other virtual machine software runs happily in lower edition of Windows and offering wider guest OS support.

In fact, Microsoft went out of their way to frighten their customers.

2) Running up a Windows VM and UBuntu VM is like watching a race between a Tortoise and a Hare. Even the size of the VM is a stark contrast. MonoDevelop is also lightningly fast compared VS2010. This shows how inefficient Windows has grown to.

3) It is also my "Pay Microsoft minimum amount" policy. UBuntu has MonoDevelop and OpenOffice and are all free. Who needs to buy Office? I could continue to use my Office 2000 in say XP VM or Win2K VM (no activation).

4) UBuntu brings back the feeling of the carefree days of early Windows experience - no activation to worry and no worry of installing another copy. So carefree and joy to use. Not anymore with Windows. The unknown of UBuntu/Linux is like unchartered water to this newbie with new things awaiting me to discover. Just like the days with Windows in the '80.

5) Mono, not a product from Microsoft, offers me cross-platform cross-language development without using Java that Microsoft has steadfastly refused to embrace. Sorry, you have lost my vote. There are so many good and solid tools that are running fine in both Windows and Linux.

So it takes a lot for this staunch Windows supporter to look for greener pasture but the step is well worth it. I urge all Windows users to give this a try. It is free and nothing to lose! Send a message to Microsoft. It is a joy to live in the Ubuntu VM!

Beware of 8.3 names

I wrote a piece of code that used System.IO.Directory.GetFiles(string, string) and executed the code in Windows XP. I was totally dump founded when I discovered  this function returning more than what was expecting. The same things happened in Vista & Windows 7.

I was trying to get a list of files '*.tab' from a nominated directory but the result contained files meeting '*.tab*'. I was shocked. So I went to my favourite tool, the command prompt, and did a dir *.tab in the same directory and got the same result. Powershell does not produce this unexpected result.

Knowing System.IO.Directory.GetFiles() most likely P/Invoke down to Win32 API, I search through and confirmed the FindFirstFile() is responsible for this unexpected behaviour.

The explanation of this 'oddity' is given by Raymond Chen and you can blame the 8.3 file names for this problem.

So if you use System.IO.Directory.GetFiles(string, string), make sure you filter your results properly to avoid any unexpected results.

There is no way in CMD to list out a list of files with that kind of requirements.

There is no dangerous language only dangerous programmers

It seems the data and comments presented in "Software Failures, follies and fallacies" by Les Hatton provide support for the above mentioned comment.

We all extol the benefits of our favourite programming language whilst denigrating other languages less attractive to us.  In truth, published data from around the world of which Table 2 is a subset shows  that there is no clear relationship between programming language and the defect density of systems implemented in  that  language.    Ada,  for  example,  supposedly  far  more  secure  than  other  languages  produces systems of comparable defect density.  In contrast,  C is reviled by many  safety-related  developers and yet it is responsible for some of the most reliable systems ever written.   We  can  conclude  that programming language choice is at best weakly related to reliability.

However, I doubt his conclusion from

a  recent  study  comparing  two  similar  systems  of  similar  size,  (around 50,000  lines each), one  in  C  and  one  in  object-designed  C++,  the  resulting  defect  densities  were shown  to  be  around  the  same  at  2.4  and  2.9  per  1000  lines  respectively,

that

that language has little effect on reliability, object-oriented or not  and  that  the  massive  drive  to  object-orientation  is  another  giant  leap  sideways  in  which  the software industry appears to specialise.

It is unfair to conclude a programming paradigm is defective or fail to live up to its touted benefit from observation on a programming language. This is particularly true for C++ which actually is hybrid in nature - a better-C and Object-Oriented programming language.

From my personal development experience and reviewing code, a person using an object-oriented language, be it C++, C# or Java, does not necessary mean that the developer is apply sound OO principles to their creation. It is the use of these principles that give rise to the touted benefit. 

If they are not applied, C++ and other object-oriented language can result in system with far worse defects and undesirable features than say a procedural language like C. Lakos echos similar sentiment:

It is completely wrong, however, to think that just using C++ will ensure success in a large project.


C++ is not just an extension of C: it supports an entirely new paradigm. The object-oriented paradigm is notorious for demanding more design effort and savy than its procedural counterpart. C++ is more difficult to master than C, and there are innumerable ways to shoot yourself in the foot. Often you won't realize a serious error until it is too late to fix it and still meet your schedule, such as indiscriminate use of virtual functions or passing of user-defined types by value, can result in perfectly C++ programs that run ten times slower than they would have had you written them in C.
[...]
Unfortunately, the undisciplined techniques used to create small programs in C++ are totally inadequate for tackling larger projects. That's to say, a naive application of C++ technology does not scale well to larger projects. The consequences for the uninitiated are many.

---

"Large-Scale C++ Software Design" by John Lakos, page 2, Anddison Wesley Longman Inc. 1996

What a piece of gem

I am so glad that I have rediscovered this piece of gem titled "Good practice in software" by Les Hatton. It should be read by any aspiring or experienced developer. It is full of timeless advices and facts, like this:

Perhaps the biggest surprise in an industry awash with technology is that it doesn’t seem to make much difference. By far the biggest factor which emerges in most studies is the individual quality of the engineers who build a system and a few common-sense principles.  We have known this since the admirable book by Fred Brooks, [6] which every aspiring software producer should read. Rather than absorbing this powerful lesson, the computing industry became obsessed with the notion that the process or bureaucracy of building software was the most important part.  The evidence is to the contrary.  No matter how well- defined a process, the quality of the product still depends mostly on the quality of the engineers who build it. To this, a good process can bring consistency and accountability.

So true! People are forever darting from one language to another or from one technology to another in an escapist attitude to avoid the hard slog of learning the trade!