Expandable Descriptions - Client-Side

Earlier this week I bought Dragon NaturallySpeaking version 9.5. It took me close to an hour to get the software install and configured properly on my system, primarily because I am using a 64-bit operating system. Dragon NaturallySpeaking does not support the 64-bit versions of Windows Vista or Windows Server 2008, but there is a workaround that allows you to install on a 64-bit operating system. Another challenge is that Dragon NaturallySpeaking has trouble with certain onboard sound cards.  This blog entry highlights the challenges I faced when installing Dragon NaturallySpeaking provides workarounds.

If you try to install Dragon NaturallySpeaking a 64-bit operating system you will be stopped by the installer. After a bit of searching, I found this helpful post by VelvetPoodle:

The problem is the installer bundled with the software. This has code preventing it from being run on 64 bit vista. This can be edited using the free application orca.exe which is part of the much larger Microsoft core platform SDK. If you only want the application orca.exe do a google search for it. Make sure you get the 64 bit version though… Alternatively get it from here:
http://blogs.msdn.com/astebner/archive/2004/07/12/180792.aspx.

1. Copy the entire contents of the DVD to a folder on your computer
2. Make a backup of the file Dragon Naturally Speaking 9.msi
3. Install Orca and open Dragon Naturally Speaking 9.msi from the installer directory
4. To the left under tables, scroll down and click on the “launch Conditions”. The error conditions will appear to the right.
5. Select the Condition “Not VersionNT64”
6. Right-Click and select “Cut Row(s)”
7. Save the edited "Dragon Naturally Speaking 9.msi"
8. Install as normal

While this method will certainly get Dragon NaturallySpeaking to install and work on 64-bit operating system, one thing to keep in mind is that NaturallySpeaking will not respond or respond very slowly when dictating in 64-bit applications. For example, if I try to dictate in Internet Explorer, Dragon NaturallySpeaking virtually hangs. Supposedly, the next version of Dragon NaturallySpeaking will support 64 bit operating systems.

After successfully installing Dragon NaturallySpeaking on my computer, the application started and I was greeted with a warning: "Audio Setup Wizard cannot find the sound system." This error threw me for a loop because my computer certainly does have a sound system - I can hear music coming from my speakers and am able to record voice from a microphone. Some online sleuthing turned up message board posts from other Dragon NaturallySpeaking users who encountered similar problems with onboard sound card systems not supported by Dragon NaturallySpeaking. My computer has an onboard RealTek sound card; other users with the same configuration had reported similar errors.

In the same post where VelvetPoodle shared how to install Dragon NaturallySpeaking 64-bit operating system, another poster named webbediva shared a workaround for the audio wizard problem that worked for me:

To get past the audio wizard error:
With Naturally Speaking bar running, right-click on the audio.exe file using Windows Explorer in Program Files\Nuance\NaturallySpeaking9\Program. Under "Properties" click "Compatibility" tab and select "XP". Double-click to run.

To summarize,  with Dragon NaturallySpeaking running need to set the compatibility level of the audio wizard program to be compatible with Windows XP and run this program from Windows Explorer.  With this step out of the way, Dragon NaturallySpeaking (finally) worked! It took a bit of research and effort to get Dragon NaturallySpeaking properly installed and configured on my machine, but I haven't had any issues since (except for slow or nonexistent response times for 64 bit applications).

Read the post with the two workarounds: http://forums.cnet.com/5208-6035_102-0.html?forumID=44&threadID=280578&messageID=2744514

Earlier this week I broke my right hand playing basketball.  I currently have a splint on, which renders my right hand useless.  I can wiggle the tips of my fingers but I lack the control to use a mouse or type with this lame hand.  I'm getting proficient typing with my left hand, but it is still significantly slower than typing with both.  For instance, with both hands I can type in the neighborhood of 100-120 words per minute.  With just my left, I type a shade under 40 words per minute, and even slower when keying in typical code syntax with its mix of punctuation and case changes. (Thank God for IntelliSense!)

On Thursday I bought Dragon NaturallySpeaking from my local Fry's. NaturallySpeaking a popular voice recognition software package.  I opted for the Standard Edition, which set me back $100.  Not having had experience with voice recognition software in the past, I was a bit skeptical at how accurate such software could be.  I knew it would not suffice for coding, but my hope was that it would make a good substitute for writing e-mails and authoring articles.  So far, I have been pleasantly surprised with the accuracy and ease of use.  The marketing literature claims over 99% accuracy. I have no clue how accurate it truly is, but keep in mind that even with 99% accuracy that still means that there will be one error every 100 words you utter. And if you are as verbose as I am, 100 words comes very quickly.  Every couple of sentences there are one or two corrections I have to go back and make with my keyboard or voice commands.

Speaking of using voice recognition software for coding, I did try writing a little bit of code with my voice. My only foray into this was with a simple "Hello, world" example. What I intended to write was:

Response.Write("Hello, world!");

I said: "response", "period", "write", "open parenthesis", "open quote", "cap hello", "comma", "world", "exclamation point", "close parenthesis", "semi-colon". What I got was:

Response.  Right ("Hello, world!");

Close, but no cigar.  One of the main problems is that the software injects spaces where it thinks they are needed when speaking English, not when being parsed by a programming language. Moreover, it has trouble with homonyms at times.  Note how it chose to use "Right" instead of "write".

In addition to writing text with your voice you can also use Dragon naturally speaking to issue a computer command such as copy, paste, formatting, and other common commands. The copy and paste features are quite useful, but what can be frustrating is when you say a word to type that to also maps to a command, such as "print" or "close".

All in all, I'd recommend using Dragon NaturallySpeaking or some other voice recognition software for people with some sort of typing impairment who spend much of their day sitting in front of a computer responding to e-mails or writing articles or other documents. It takes some getting used to, and there certainly are errors that you have to put up with, but it is a lot more efficient than typing with one hand and allows you to keep that one good hand on the mouse most of the time.

One warning regarding Dragon NaturallySpeaking: the software does not natively support 64-bit operating systems (although there is a workaround), and certain onboard sound cards are not recognized by the software without a bit of a workaround.  I'll discuss some of the challenges I had installing Dragon NaturallySpeaking, and the steps I took to surmount those challenges in: Installing Dragon Naturally Speaking (DNS) on Vista / Windows Server 2008 64-Bit.

i broke my right hand playing basketball tonight. splint on, prognosis is 4-6 weeks in a cast that will likely be high enough on  my hand to greatly reduce finger mobility. as it stands now, i can only type w/my left hand and have moved the mouse to my left and switched the right and left buttons, but typing w/ one hand is excruciatingly slow and error-prone. i'm sure practice makes perfect but right now it is frustratingly slooooooooooow.

maybe best to ditch natural keyboard for a 'normal' one as the keys on the natural are so farther apart.

i wonder if there's a key mapping that's ideal for left handed only typing. like dvorak for lefties

any tips on how to get by on a computer with a busted hand?

thanks in advance

Tutorials #6, #7, and #8 in my Master Pages Tutorial series on www.asp.net have been published. These tutorials examine the interaction between the master page and its content pages:

• Interacting with the Master Page from the Content Page [VB | C#] - there may be times when the content page needs to programmatically interact with its master page. This tutorial looks at common scenarios where this type of interaction is needed and shows various techniques for accomplishing this type of interaction.
• Interacting with the Content Page from the Master Page [VB | C#] - the most typical type of master page and content page interaction originates from the content page. However, there may be times when the master page needs to signal the content page to take some action. This tutorial looks at such scenarios and shows a technique for this style of interaction.
• Master Pages and ASP.NET AJAX [VB | C#] - web pages that use Microsoft's ASP.NET AJAX framework must include the ScriptManager control on the page. This control can be placed in the master page. This tutorial looks at the effects of adding the ScriptManager to the master page. It also walks through a complete AJAX example and shows how to use the ScriptManagerProxy control to add custom script references in a content page.

Like my past tutorials, these tutorials are all available in C# and VB versions, include a complete working source code download, and are available to download as PDF, as well.

There are two remaining tutorials in this series that should be published by the end of this month. The two remaining tutorials look at specifying a content page's master page at runtime and using nested master pages.

Enjoy! - http://asp.net/learn/master-pages/

In my ten year software developer career I've only worked for two companies, and both job experienced pre-dated the 21st century and my graduation from college. At both jobs, I only had one monitor, albeit a rather large one for the time (21” at both companies, if I remember correctly). After graduating, I decided to strike out on my own as a freelance writer, consultant, and trainer, and haven't looked back since. Not knowing any better, I used a solitary monitor until April 2006, when I finally updated to a dual monitor setup. I bought a second video card, picked up the same brand/model of monitor, and graduated into the 21st century. (What prompted me to upgrade to two monitors was, primarily, stories of enhanced productivity from my wife, who was, at the time, working for a company that supplied dual monitors to all its devs. Bill Gates is also a big fan of multiple monitors.)

Two monitors are superior to one for many development- and writing-related tasks. Having Visual Studio in one window and the browser in another and being able to see both simultaneously nets huge performance gains. Likewise, when writing, having Microsoft Word up on one screen and code or a browser is a great time-saver. Today I have a hard time functioning when at a client's site and am reduced to using a single monitor setup. But just how much better are two monitors than one?

Anyone who tells you that they are twice as productive with two monitors than with one is probably over exaggerating. For development- and writing-related activities I find that two monitors allows me to accomplish somewhere on the order of 25%-50% more work in a given unit time. That's a wet finger in the air estimate, but there have been more formal studies. Microsoft Research reports that multiple monitors “can increase your productivity by 9 to 50 percent.” A small study performed by Darrell Norton shows productivity as lines of code per day increased by 10% and defect levels decreased by 26% (hat tip Jeff Atwood). What doesn't get measured in these studies is the increased quality of worklife. Even if the actual productivity gain is nominal, having a second monitor feels better. It lets you see more screen real estate at a given point in time. It lets you compare two documents side by side rather than incessantly Alt-Tabbing.

A couple of months ago I upgraded to a new computer. The only components I salvaged from my old computer was a 350 GB S/ATA hard drive and my two monitors; everything else was bought new. While investigating parts and formulating my shopping list I debated whether to upgrade to three monitors. Jeff Atwood is a big fan of three monitors:

As good as two monitors is, three monitors is even better. With three monitors, there's a "center" to focus on. And 50% more display area. While there's certainly a point of diminishing returns for additional monitors, I think three is the sweet spot. Even Edward Tufte, in the class I recently attended, explicitly mentioned multiple monitors. I don't care how large a single display can be; you can never have enough desktop space.

I didn't think a third monitor would make me any less efficient, but I questioned as to whether the improvements in efficiency (or quality of worklife) were as grandiose as Jeff made them out to be. In the end I decided to give it a whirl. I bought two GeForce 8600 GT video cards for the new system. These have dual DVI outputs meaning that I could upgrade to a fourth monitor if I were so inclined. I kept the two monitors from my previous setup - 17 inch monitors from Sharp - and bought a new Samsung SyncMaster 2053 BW monitor, which is a wide screen that has about the same visible height at the Sharps, but is about 33% wider. The two Sharps run at 1280x1024, the Samsung at 1680x1050.

I've been using the three monitor setup for a couple of months now and regret to say that I have not seen the same productivity benefits or improvement of worklife that Jeff espouses or that I enjoyed when going from one monitor to two. For certain tasks I am more productive with three monitors than two, a prime example being if I need to review a client's email while bug bashing. I can have the email open that explains the error in one window, Visual Studio in another, and the web application running in the third. However, for most other activities the third monitor does not add too much value. Consequently, it's not uncommon for one of the three to sit unused for long stretches of time.

Three monitors also have some detriments that weren't present with two. Because of the width of the three monitors, I frequenty tilt my neck to see the side monitors; with two monitors I could see both with when looking straight ahead by just turning my eyes, but not with three. The net result is that if I spend an inordinate amount of time focusing on one of the side monitors my neck becomes a bit stiff. To combat this I try to make myself swivel my chair when I start looking at a side monitor, but it's second nature for me to turn my head and I don't realize that I'm not swiveling until my neck starts to bother me.

In the end, three monitors are better than two, just like I imagine four would be better than three, but the returns on multiple monitors quickly diminish as the number of monitors grow (at least for my line of work and from my personal work habits). Knowing what I know now, if I had to choose between a third monitor and some other upgrade (perhaps a super high-end hard drive or a high-end office chair), I'd stick with two monitors and take my luck with what's behind Door Number 1.

I have long used FireFox as my default browser for surfing the web, but I typically test my ASP.NET pages on Internet Explorer for a couple of reasons:

• Some of the larger software projects I work on are developing intranet applications, where all users' browsers are fixed (IE 6 for one client, IE 7 for another).
• For book and article and tutorial screen shots I typically use IE as my browser of choice because IE is still, after all, the most used browser.
• Until Visual Studio 2008, Visual Studio used IE as the browser when debugging an ASP.NET application (even if FF was setup as the default). Because all of my clients are still on ASP.NET 1.x or 2.0, I don't use VS 2008 too often.

However, I have recently been working on some AJAX material and have been using VS 2008 more frequently. Visual Studio 2008 kindly launches my default browser (Firefox) when I debug my web application. The problem was I noticed that Firefox was loading pages very slowly. I'd visit a site through localhost (via the ASP.NET Development Web Server) and pages would take several seconds to load.

To help analyze the problem I used the excellent Firefox extension Firebug (which I reviewed in the March 2008 issue of my Toolbox column). Firebug will show you the total number of network resources downloaded when visiting a page, along with the time it took to download each.

Each resource - from the 4KB HTML fiel to the 7KB JPG file, was taking close to a FULL second to retrieve! When requesting this same page from a remote, production web server, download times were 5 to 10 times faster per resource. What was going on here?

I next opened Internet Explorer - the same pages loaded instantaneously. I fired up Fiddler, an excellent HTTP Debugger for IE, and noted that the resources were being downloaded in 0.02 seconds, nearly 500 times faster than from Firefox. By now I was seriously stumped. I then did what I should have done from the getgo - I searched the web. Duh!

Turns out that there is a known issue with Firefox's IPv6 support and the ASP.NET Web Development Server that introduces these lengthy delays. To quote from the Mozilla Wiki:

IPv6 was designed in part to solve the problem IPv4 will soon be facing: the exhaustion of all possible IP addresses. Mozilla implemented IPv6 support in early 2000, but that support did not receive widespread testing until recently as IPv6-capable OSs and network software/equipment became more common. One particular bug that has appeared exists not in Mozilla, but in IPv6-capable DNS servers: an IPv4 address may be returned when an IPv6 address is requested. It is possible for Mozilla to recover from this misinformation, but a significant delay is introduced.

...

Two approaches were taken to work around these bugs: first, a preference to globally disable IPv6-based DNS lookups browser-wide (this preference [network.dns.disableIPv6]), and a blacklist of domains which should never have IPv6-based DNS lookups performed (network.dns.ipv4OnlyDomains).

Consequently, to fix this problem of slow response times when visiting localhost using Firefox, either set the network.dns.diableIPv6 configuration property to true or set the network.dns.ipv4OnlyDomains configuration property to “localhost”. My search led me to many pages around the Web suggested that you set the nework.dns.disableIPv6 property to true, but this would disable IPv6 support for all sites visited by the browser (at least according to the Wiki documentation). Therefore I set the network.dns.ipv4OnlyDomains property to “localhost”.

To set these properties, fire up Firefox and type about:config in the address bar. Next, locate the appropriate setting and change its value to the desired one. With that small change the debug-time experience in Firefox is greatly enhanced. And make no mistake, Firefox's rich library of extensions make it a great browser for web development. (I'll share some of my favorite Firefox web development extensions in a future blog post.)

Lesson for the day: If you bump up to a problem, search for a solution online first. If your search is fruitless then take the time to investigate it further, otherwise you may spend 15 minutes troubleshooting a problem that is already well-known and has a simple solution.

My Toolbox column in the July 2008 issue of MSDN Magazine is avaiable online. The July issue examines:

• ScrewTurn Wiki - a wiki is a web application whose content is maintained by its users. Adding a wiki to your site is remarkably easy with ScrewTurn Wiki, a free, open-source ASP.NET wiki application (written in C#). By default, ScrewTurn uses the file system to store its content, which makes adding it to a site as easy as copying a few files up to the web server.
• Blogs of Note - Scott Hanselman - Scott is one of my favorite technical bloggers. His The Weekly Source Code entries and annually-updated Ultimate Developer and Power Users Tool List are something every .NET developer should check out.
• SnagIt - SnagIt is one of the best screen capture utilities available. With a simple keyboard shortcut or the click of a mouse it can capture a particular window, a specific region of the screen, or the entire contents of a scrollable window. What's more, you can very easily touch up the image, adding text, highlighting, callouts, and so on, and then save it as an image, Flash file, or PDF, or send it via email, IM, over FTP, or to a Microsoft Office document.

For The Bookshelf section I reviewed LINQ in Action, by Fabrice Marguerie, Steve Eichert, and Jim Wooley. An excerpt from the review follows:

LINQ is made possible thanks to a number of new language enhancements and several new namespaces and classes in the .NET Framework. Because of the breadth and depth of the topic, to really learn LINQ you'll need more than a few online articles. One LINQ book, which explains the various facets through rich examples that build on previous chapters, is LINQ in Action. ... What I liked best about LINQ in Action is how the authors start each new section with straightforward, easy-to-follow examples that highlight the most important features. Next, they pull back the curtains and show how the LINQ queries and features are actually implemented.

Enjoy! - http://msdn.microsoft.com/en-us/magazine/cc700339.aspx

As always, if you have any suggestions for products or books to review for the Toolbox column, please send them to toolsmm@microsoft.com.

A few days back I was browsing some of Jeff Atwood's older blog entries and stumbled across one titled, The Danger of Naivete. In it, Jeff discusses an algorithm for randomizing an array that, while simple and seemingly intuitive, is subtlely incorrect in that it over-weights certain permutations and under-weights others. The naive algorithm enumerates each element in the array and swaps it with a randomly selected position in the array. Here's the naive algorithm implemented in C# code.

Random rnd = new Random();

for (int i = 0; i < deck.Length; i++)
{
   // Set swapWithPos a random position such that 0 <= swapWithPos < deck.Length
   int swapWithPos = rnd.Next(deck.Length);

   // Swap the value at the "current" position (i) with value at swapWithPos
   int tmp = deck[i];
   deck[i] = deck[swapWithPos];
   deck[swapWithPos] = tmp;
}

While reading Jeff's blog entry, my stomach sank because I knew that I had authored an article on randomly ordering an array on 4Guys back in the day (circa 2000). I was certain that I had implemented the naive and incorrect algorithm. Upon digging up the old article - Randomly Reordering an Array - I realized that I had used the naive algorithm. Urp. At least in describing my implementation I labeled the algorithm a “quick and dirty way to [randomly reorder an array].”

Of course there are algorithms that randomly reorder an array with an even distribution of permutations. What's interesting is that the simplest such correct algorithm - the Knuth-Fisher-Yates shuffle - is very similar to the naive algorithm. Depending on your programming language of choice, you can likely morph the incorrect naive algorithm into the Knuth-Fisher-Yates algorithm by changing less than 10 characters in the code file.

Rather than blindly change the old article, I wanted to better understand why the naive algorithm doesn't work. Despite Jeff's explanation of why the naive algorithm over-weights certain permutations and why this doesn't happen with the Knuth-Fisher-Yates shuffle, I still had a mental roadblock. It wasn't until I did what Jeff suggested - sit down and draw out the various possible permutations from the naive algorithm vs. the Knuth-Fisher-Yates shuffle - that things came into focus. I also find that having to explain some technology or algorithm or concept helps bolster my understanding of it, in part because any parts that I have trouble explaining force me to do further research. Therefore, this week's 4Guys article - Techniques for Randomly Reordering an Array - looks at ways for shuffling an array and highlights what's wrong with the naive approach and how other solutions account for this. Because Jeff's blog entry was the impetus for Techniques for Randomly Reordering an Array, the two are very common. However, in my article I show the probability breakdown of the naive algorithm (and analyze another approach mentioned by Jeff in his blog entry Shuffling).

In a nutshell, the naive algorithm computes n^n possible outcomes, yet there are only n! permutations available. In the case of a three element array, there are 3^3 = 3 * 3 * 3 = 27 possible outcomes from the naive algorithm yet only 3! = 3 * 2 * 1 = 6 permutations. Because 6 does not divide 27 there must be some potential outcomes that are over-weighted by the naive algorithm and others that are under-weighted. To make this point more clear, check out the following diagram. It shows the possible outcomes when shuffling a three element array whose elements initially have the values [0, 1, 2]. As you can see, the end result is that the permutations [0, 2, 1], [1, 0, 2], and [1, 2, 0] appear five times while the permutations [0, 1, 2], [2, 0, 1], and [2, 1, 0] each appear only four times.

When facing a particularly tough probabilty problem sometimes it helps to sit down and draw out the possible outcomes for the given scenarios. In doing so, things that may otherwise seem very complex boil down to a very apparent solution or explanation.

A great example of simplicity through diagraming is the Monty Hall problem, which goes like this: You are a contestant on the TV game show, Let's Make a Deal and are presented with three doors. Behind one door there is a luxury car. Behind the other two doors there is a poster of a car. The game show host asks you to pick a door. After choosing one, the game show host reveals one of the other doors that has a poster behind it and then asks you if you want to change your door choice to the other unopened door. What is the best strategy?”

The answer is that you should change the door you had selected, because there's a 2/3 probability that the door you did not select houses the luxury car. In other words, there is a 2/3 probability that the door you picked has the remaining poster. The solution seems backwards. It seems paradoxical that the door the host reveals to have a poster of a car could have any influence on your initial selection. But if you sit down and draw out the various probabilities you can see that there's there are more good outcomes if you make the switch than if you hold fast to your initial choice. The following diagram was created by Rick Block; here, instead of a poster of a car you get a goat. Same difference.

While penciling out the various outcomes of a probability problem doesn't feel very sophisticated, it can often be a quick and surefire way to better understand a problem.

When writing my Security Tutorials for www.asp.net, I often wrote sentences like the following: “To log in to the site, ...” Although sometimes I'd write it, “To log into the site, ...” and other times I'd use, “To login to the site...”

I can't say with certainty whether any one of these three are grammatically correct or if any are grammatically incorrect. My guess is that in the sentence above, “To login to the site...” is incorrect because, according to Dictionary.com, log in is a verb, while login is a noun. In other words, you would only use the word login in a sentence like, “Your login is comprised of a username, password, and PIN.“ That leads me to believe that the correct form is, “To log in to the site,“ but I'm sure someone out there can make a case for “To log into...“

In any case, I should have picked a particular approach and used it throughout, rather than varying the styles throughout the tutorial series. If it's any consolation, I assure you that the variance was done on a purely subconscious level.

All that being said, what do you prefer?

• To log in to the site...
• To log into the site...
• To login to the site...

The more I read it and think about it, I believe the latter one to be grammatically incorrect.

Another thing I noticed is that when I read them there is a very subtle pronounciation difference among the three sentences, although I don't know how clearly that difference translates into the spoken word. When pronouncing login I run the “g” and “in” together, like I'm speaking 1.5 syllables instead of two. Log in to are pronounced as three distinct words with a briefest of pauses between each, whereas log into is pronounced as two distinct words: “log” and “into,” with no pause between “in” and “to” (again, almost as if blurring the two words together into 1.5 syllables).

The economics behind the college text book must be interesting. I've not written any textbooks, so my comments here are based more on assumption than knowledge, but what I but what always intrigued me - whilst a college student, at least - was how authors would release different versions of books and how teachers would require students to buy the most recent version (or whatever version the class was using). I can understand updated versions for cutting edge fields, like biosciences and computer-related topics, but has the knowledge or instruction of introductory level Calculus changed any since Newton and Leibniz's time? And if not, then why does a book like Calculus and Analytic Geometry - a highschool level Calculus book - have nine editions? What has changed so significantly since the eighth edition to warrant a ninth?

As a student, I was always envious of those authors who wrote a new edition. I figured it must be easy money.

1. Correct a few typos from the previous edition,
2. Replace some of the sample problems,
3. Have professors (or school board administrators) require that all students use the most recent version, and
4. PROFIT!

Sure, writing the first version might take an inordinate amount of time and energy and effort, thereby rendering the profit per unit time to be less than ideal, but once you got past writing the initial version, each subsequent version had an incredible ROI. Not only that, but with textbooks selling in the $50-$150 range (compared to the $9.95 you pay for the mass market Stephen King novel), those professors must be raking in the dough.

(As an aside, I'd be interested in any insight from authors or publishers or agents who have experience in this niche market. What are the royalties like for professors? Are they in the 10-15% range, like for computer trade authors, or are they higher (or lower)? How many copies does a successful textbook sell? I imagine that writing textbooks is like any other profession - you have a very small handful of extremely successful people - e.g., the authors whose book becomes the de facto standard for teaching a common subject across many universities or high schools and who can profit handsomely from future editions - but the vast majority of textbook authors could have earned more had they worked at a restaurant for those hours they spent their time writing, editing, and reviewing their book. In other words, I assume it's very similar to the field for writing computer trade books, except in computer trade book land, an 'extremely successful' author likely could make more money working a regular 9-5 job in industry than she could writing books full time.)

Despite having authored seven books on ASP and ASP.NET, I haven't really had much opportunity to work on 'second editions.' The challenge with computer technologies is that they change so radically so quickly that the 'second edition' is really about a brand new technology with many new and exciting features that require virtually rewriting the previous edition in its entirety. For example, my first two books were on ASP, my third on ASP.NET. ASP and ASP.NET are two very different technologies, and are different in very fundamental and important ways. I don't think I've seen a single book with a consistent title gracefully move from ASP to ASP.NET.

But what about ASP.NET? We've had five versions of the .NET Framework - 1.0, 1.1, 2.0, 3.0, and 3.5 - but only three of them had enough difference between them and previous versions to warrant a new edition (namely, version 1.0/1.1 to 2.0 and 2.0 to 3.5). And the changes from 1.x to 2.0 were profound enough that new editions between these versions required many new chapters. Granted, the move from 2.0 to 3.5 was less radical and offered an excellent opportunity for established ASP.NET authors to release a new edition with much less energy and effort than is needed to start a book anew or was required when transitioning from 1.x to 2.0. (I'll have more thoughts on this in a future blog post, when I write about my latest book, Teach Yourself ASP.NET 3.5 in 24 Hours.)

The point of it all is that, at least in the ASP.NET world, writing subsequent editions is not something that is as easy to do as you might imagine. Yes, it's easier than writing a book from scratch, as you already have an outline down and can reuse certain content, but it's not as easy as (I imagine) authors in other fields have it when producing a new edition. This is something to keep in mind if you're deciding whether to start writing computer trade books. If your plan is to write an initial book at an economic loss, but to make up that loss with future editions, chances are you'll need to reevaluate your plan. As I said in my first blog entry on the economics of writing computer trade books, “If your dream is to become a rich man, don't write computer trade books.” :-)

Scott Hanselman, one of my favorite bloggers, has expressed his deep disdain for Northwind.

I'm just sick of Northwind. Sick to death of the Northwind Database. You know, this is the Products, Categories, Suppliers, yada yada yada sample databas