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.
Thursday, August 25, 2011
Wednesday, August 24, 2011
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:
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
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.
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
Tuesday, August 9, 2011
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!
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.
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.
Subscribe to:
Posts (Atom)
