August 2005 - Posts

Sometimes things that everyone just knows aren't always true.

For example, when I look at c# code, I know that local variables are stored on the stack.  Or, I thought I knew that.

However, Ian Griffiths notes that in .NET 2.0, this isn't neccessarily true.  This change was made to support anonymous methods, and mutability of variables in the enclosing scope.

Time for me to 'unlearn' a few things.

 

So, over the last couple of years, I've been what I consider a 'defender' of MSDN documentation.  After all, the docs are miles ahead of what they used to be.

As a user, I've also taken to reporting doc bugs to Microsoft.  My first couple of experiences with this was pretty good.  In one case, the doc team actually rewrote an entire code example based on my feedback.  I was impressed.

Recently, however, my experience has not been as good.  Most of the doc bugs I report now get a generic response from a support specialist that is little more than a glorified secretary.  It's obvious that these support people have no idea what I am talking about.  They merely take the email, and forward it on to the appropriate team.  When they get a response, they cut and paste that response in an email.  It is frustrating, because these support people have no clue.

The other thing that I'm finding is a resistance to change. I've found a few examples where the docs were wrong, and I could prove it through experimentation.  However, the product teams weren't really interested in correcting the issue.  For example, although the documentation on debugging windows installer custom actions can be shown to be wrong, I received a 'brush off' response.

So, I'm making a new promise to myself. 

Every time I find a doc bug in a Microsoft product, I'm going to post about it.  I've tried to correct issues through appropriate channels, and it doesn't seem to work.  Instead, I'll let google juice do the work for me.

 

An interesting meme I've encountered a number of times amongst c#/Java programmers:

   Low Level c/_asm programmers are 'smarter' than the rest of us.  Kernel hackers are psuedo-gods.

Ok, I've worked with a wide variety of programmers.  Embedded programmers, Driver developers, EE/ board designers, Windows Programers, Unix 'hackers', Java devs, .NET developers, etc.
One of the things that I've noticed is that each developer usually considers his technology superior, and others just don't get it.

Actually, I think that they are all correct.  Or all incredibly wrong.  Take your pick.

Embedded Developers:  Can hack 'C' like there's no tomorrow.  Typically push memory around like it's ice cream.  These developers excel at handling low- and out- of memory conditions.  You'll rarely see an Embedded programmer fail to handle a memset failure (or new(), though that command would be rare..!).  My experience is that C++ is a major leap for many embedded developers, and Classes are certainly a difficult construct to grasp.

Driver Developers: (See Embedded Developers)

EE / board designers: It always amuses me when EEs think that they can both design the board, and write software for it.  Truthfully, you can be successful at one or the other, but not both.  In my experience, EEs really don't understand the concept that the hardware actually does fail.  Usual shortcomings amongst these developers include a failure to handle error conditions, and a lack of understanding of higher language constructs such as events, classes, and exceptions.
 
MFC/ATL/Windows developers: These programmers present an intimate knowledge of the arcane structures, return codes, and other esoteric knowledge required to leverage the Win32 API.  Unfortunately, these engineers are too stuck in the middle - too high in the food chain to know everything that's going on underneath them, but too low to be able to excuse that lack of understanding. 

Java Devs:  They really wish that "Write-Once, Run Everwhere" had some actual truth.  Oh, and real runtime supported generics would be nice.  Hacks need not apply.

C# Developers:  Trying to be more respectable than VB.NET, these developers strive to impress everyone else with there knowledge.  Eschewing VB.NET's "My" namespace, most of these developers would rather pretend that they code everything on their own.  However, the .NET GC is there to pick up the errant memory leacks that c# developers enevitably 'cast' aside.

VB.NET developers: I refuse to touch this flamebate language.  I won't even say the obvious.  Draw your own conclusions, please.

Unix 'hackers': Major flaw:  There really is such a think as 'best tool for the job'.  Sometimes that tool is *nix.  Sometimes it really is Windows.  /. Readers need not apply.

Did I miss your pet language?  (LISP, Ruby, Python, PERL, Delphi, VB, PHP,......)
There was a reason for that - no one cares.  Least of all, me.

Have a good language war - see you next Armageddon.

 

My new favorite line of code:

FUC.Queue("AJAX");

From Tobin Titus's new JAXASS.net.

 

The PDC 'scheduler' is out - visit http://commnet.microsoftpdc.com.

 

My tentative schedule of breakout sessions:

Tuesday:
11:45 AM - 12:30 PM - FUNL02 Lap around the WinFX and Win32 SDKs
1:00 PM - 2:15 PM - DAT301 High Performance Computing with the Windows Server Compute Cluster Solution  
2:45 PM - 4:00 PM - DAT303 SQL Server 2005: Building Distributed, Asynchronous Database Applications with the Service Broker
4:15 PM - 5:30 PM -COM304 Networking: Building IPv6, Firewall, and IPsec Aware Applications  


Wednesday:
11:00 AM - 12:15 PM - COM200 Applications and Communications Roadmap: Platform Presents and Futures
12:30 PM - 1:15 PM - TLNL06 Tips & Tricks: Scrubing Source Code for Common Coding Mistakes (FxCop and PreFast)
1:45 PM - 3:00 PM - PRS309 Windows Presentation Foundation ("Avalon"): Overview of Windows Vista Graphics
3:15 PM - 4:30 PM - DAT411 SQL Server 2005: Extending and Embedding Integration Services (ETL)
5:00 PM - 6:15 PM - COM416 Windows Communications Foundation ("Indigo"): Under the Hood of the Windows Communications Foundation Channel Layer


Thursday:
10:00 AM - 11:15 PM - FUN412 Five Things Every Win32 Developer Should Know
11:45 AM - 12:45 PM - PRS320 ASP.NET: Future Directions for Developing Rich Web Applications with Atlas (Part 2)  
1:00 PM - 1:45 PM -  PRSL03 Ten Amazing Ways to Speech-Enable Your Application
2:15 PM - 3:30 PM - DAT219 BizTalk Server Future Directions: 2008 and Beyond  
3:45 PM - 5:00 PM - COM325 Workflow + Messaging + Services: Developing Distributed Applications with Workflows  
5:15 PM - 6:30 PM - FUN034 Windows Vista & "Longhorn" Server: Improving Reliability with the New System.Transactions Classes, File System and Registry Transactions  

 
Friday:
8:30 AM - 9:45 AM - COM430 Windows Communications Foundation ("Indigo"): A Deep Dive into Extensions for Security and Identity  

More Posts