DevCon 2005: Denied

I received my Borland DevCon Abstract Review Status email today. All my abstracts were denied. Most of them were being covered by another author. A few "No coverage of this topic is planned for this conference," and "of interest only to a small number of attendees." One was ". . of interest only to a small number of attendees. Too basic."

The fact that most of my abstracts were turned down because they were being covered by another speaker means I had good ideas for my abstracts. That is a plus.

This last one that they said was "Too basic," really makes me think they didn't bother to even read that abstract (and maybe the others) as it was one of the more advanced topics I submitted. The abstract was HTTP Inside and Out, which would cover resumable downloads from the client and server side, downloading the same file from multiple servers, as well as details on all those useful tidbits of information in the header that most people know nothing about. Then time permitting we would look at creating extensions to HTTP. Most people don't realize this, but Gnutella is really an HTTP extension at its most basic level.

It does leave me wondering about the selection process. I am a returning speaker who received a "Very Good" score the previous time with 84% of my 49 attendees saying they would come hear me speak again.. I submitted fourteen abstracts (some are variations on what I listed in my blog post), so they should have plenty to pick from. I am experienced speaking and training, and even recently received a certification as a trainer, and to top it off I am published author.

Maybe the conference is going to be really, really small this year so they don't have room for any speakers that are not on TeamB or Borland employees. . . .

I was looking forward to presenting at DevCon. It is a great opportunity to give back to the Borland community. This year with hardly any benefits for speakers it really is just an opportunity to give, especially since I don't have a training or consulting business to bolster with my speaking credits. In a way I am kind of relieved because they saved me a whole lot of work.

Gutters, numbers and colors

I really love how Borland's Allen Bauer, Danny Thorpe and others elicit feedback on their development efforts through their blogs. It creates good will with their customers so they have a vague idea what is coming, and they get to provide feedback and influence the process.

Allen has a post about he and Steve Trefethen's efforts to improve the gutter in D2005. They even included some screen shots.

My first suggestion was going to be to put the blue dots directly over the line number dots, then I thought, why not just make the line numbers blue instead of putting a blue dot on them? The next logical progression would be to make the line numbers red for a breakpoint. Maybe bold too. The break point is already fairly obvious because the whole line is colored. I would keep the execution point as a green arrow and use the bookmark icons. Maybe alternatively colorize the background instead of colorizing the text. I would like to see some variations on that. By colorizing the white space or the line number itself then there is more information displayed in a smaller space. Also, if you are going to only display line numbers on every 10th line, I would ALWAYS display the line number on a folded line, maybe on the line after it too or instead. That way you would know what line it was even though it was folded. While we are in the gutter, something that would be really nice is the ability to close a folding block from within the block. Either by clicking the line in the gutter just like you would the plus (preferred) or clicking on the end of the block. The right click fold menu is a huge help! I wonder if Visual Studio will finally have that whenever their next version comes out.

Mountain Dew = Coding till 3 AM

So my wife picked up a bottle of Mountain Dew the other day as she was really sleepy, but wanted to stay up late working on our Star Wars costumes. Usually when she gets Mountain Dew she just sips a little bit and leaves it in the fridge for a while. I spotted it in there last night, so I took a drink. It has actually been quite a while since I have had any. I've been avoiding soda for a while now since it is just sugar water.

Not sure if it was the Mountain Dew, or if I was just excited about writing code, but I found myself up until 3 AM, when I finally forced myself to go to sleep. I still laid in bed for at least a half hour before falling asleep. I was then up with my son at 6:30 AM for our morning bike ride. That was actually a lot of fun.

What was a I working on until the wee hours of the morning? Operator overloading to create a safe string and unsafe string type. All in response to the wrong code looking wrong meme.

I will publish it shortly.

Hungarian = Abbreviations but Apps does not!

Nick Hodges and Jim Cooper got into a bit of an argument about Hungarian Notation. This all started with Nick's praise of Joel's article on Apps Hungarian and Making Wrong Code look Wrong.

I think they both agree, but they are caught up in the semantics. They both say it is more important that an identifier indicate its purpose and what it contains, then the type of what it contains. The both also seem to dislike cryptic variable names.

Jim is referring to where in Joel's article he says

"every variable was prefixed with a lower case tag"

And then Joel goes on to use abbreviations in all his examples. Thus tag must mean abbreviation.

If you read Charles Simonyi's original article you will see a few examples where he uses whole words (like rowFirst and rowLast) but the specific tables he provides at the bottom use cryptic one, two or at most three letter abbreviations.

Also if you look at WHY it is called Hungarian Notation. It was given this name because the inclusion of these cryptic letters at the beginning of the words made them no longer look like English, but instead like Hungarian.

So what Nick is advocating is to use the principles of the Apps portion of Apps Hungarian, but not the Hungarian portion. The Hungarian portion is to use cryptic 1 to 3 letter prefixes on your identifiers. The Apps portion is to describe your identifiers based on the kind of data they hold (row, unsafe, counter, etc.) Which is different from the Systems portion of Systems Hungarian which is to describe your identifiers with the type of data they hold.

To summarize the differences:

• Apps means to indicate kind or purpose
• Systems means to indicate the type

• Hungarian means to indicate the above with an abbreviated tag which results in the variable looking more like it was written in Hungarian then in English.

Jim just hates the cryptic 1 to 3 letter prefixes, and I don't think anyone blames him. I agree with all his points, and it isn't just because he has such a cool name.

Almost Famous

For those that have not heard, my wife and I are renewing our wedding vows at Star Wars: Revenge of the Sith today. Got our picture in the paper too.

Hungarian Notation != Evil?

I always hated Hungarian notation. I never understood why you needed to indicate the type of the variable in the prefix when the compiler and the IDE would provide that information easily. After reading this article about the origin and original design of Hungarian Notation I am rethinking my opinion. If you have not read Joel on Software before, he usually writes very thought provoking and well reasoned essays. This is no exception:

Making Wrong Code Look Wrong

The premise is that Hungarian was originally to show what kind of value a variable contains, not the type of the variable. This way you can see if you are mixing your apples and oranges, even though they are both of the type fruit. Not sure if I agree with his assessment of exceptions. He raises valid points, but doesn't provide an adequate alternative. Maybe a design practice of not allowing a method to raise an exception, but then your return types become overly complex. I remember calling GetLastError to see if my API call succeeded or failed. Later that method was improved to always checking HResult. Neither hardly seem like a better method then using exceptions.

I will point out that Delphi Win32 still has the best exception handling of any other language I have used. .Net (especially C# in Visual Studio) in comparison. It was Delphi that introduced useful exception handling to the Windows platform, and they still have it right.

Maybe if Joel and Raymond Chen used Delphi they might change their tune about exceptions. Until then I am open to suggestions.

Chris has twice commented on Hungarian Notation too. Be sure you read the article!

Crazy Standards

What are some of the craziest design standards you have seen? How about these:

• All property names must be palindroms.
• Every block of code must in Haiku.
• Use L33T identifiers for local variables.
• Document with ASCII Art to illustrate program flow.

Not that anyone actually follows these (at least I hope not), but after reviewing this list you won't find your standards (Hungarian notation comes to mind) as crazy.

Book Review: .NET Compact Framework by Wei-Meng Lee

Review by Randy Buchner

.NET Compact Framework Pocket Guide, Wei-Meng Lee

Pros:

• Easy to read
• Short
• Lots of screen shots
• Three example apps

Cons:

• If you can program .NET already, you aren’t going to learn much new stuff here

Things I did learn from reading:

• I learned about the softkey
• Tips about using ActiveSync
• I learned about SQL Server CE, which I didn’t know existed
• .NET CE doesn’t have a Blue Tooth library, so the book has a nice example on how to do it using the com ports and COM InterOp services
• Drawback: this sample uses advanced methods the author doesn’t explain, namely, threading and delegates. Seems odd for a beginner book.
• Building CAB files for smart devices – I probably wouldn’t have discovered this very quickly on my own
• Deployment is different for smart devices, compared to regular apps. The book briefly explains some of this, such as different processors.

[Book Reviews]