Saw some excellent sessions at TechEd on Tuesday.  The first was by a blogger I've been reading for a while, Scott Hanselman.  Scott has a lot of interesting and humerous observations on his site, including such gems as "Can we use WS-Powerpoint for this" and various Zen mantras related to .NET coding.  Then quotes in his powerpoint reminded me of something I've been into for a long time, which is writing Haiku about topics such as coding and everyday life. For example

Asynchronous call
Such an efficient method
Of getting work done

I should really poste more .NET related Haiku, as I'm sure its something that would benefit the community immensly.  Back to Scott's talk: the topic was about code generation.  I've been getting more interested in this ever since a local client disallowed me to use a CG tool to generate Types from a datastore.  I'm like a small child that way, making it forbidden makes me want to do it more.  Scott showed a lot of interesting code generation best practices and ideas including:

• Generating Big word docs as part of your build process
• Generating unit tests and CHM files along with your code
• naming conventions to indicate what files are generated
• Using XSD and WSDL for creating your Domain Specific Languages
• How to make your own XSD files available to VS 2003 so you have intellisense support

And a lot more.  The most interesting part is that Scott did all this in VS 2003, no built in DSL support or partial classes.  I became interested enough in this to switch one of my sessions on Wednesday to a talk on the DSL support in VS 2005.

My favorite talk of the day had to be one concerning adding voice support to mobile devices using Speech Server.  This is something casey has been using for a while and had good success with.  It still amazes me sometimes how Microsoft can take some incredibly complex problem spaces and make them accessible to almost anyone.  The speech server model is a web-application model, and adding SALT-like support to your pages is incredibly straight forward.

There is simply too much to learn.

Today was a day of many meetings at the Orange County Convention center.  I met some people from some newsgroups that I have previously known only through posting.  Steve Ballmer is really an excellent speaker, I have not seen him before but was duly impressed.  Before the keynote was over I had ran into Eric Michel, Gerry Heidenreich and Scott Isaacs.

The first session I attended was an architecture talk concerning some best practices for Office system solutions, this turned out to be a yawner.  A later session was an intro to Info Path which was a little more interesting.  The best parts of the day were talking to various people in Microsoft booths.  I'm looking forward to tomorrow's sessions much more.

It smells like Microsoft here.  There's a lot of energy as all the eager geeks pace about the floor with their coffee and donuts, anticipating Balmer's Key Note.  There must be something in the air because I'm feeling more pro-Microsoft at the moment than I ever have before.  If Bill were to walk up to me right now and ask if I'd like to graft a copy of Windows into my DNA I'd probably agree.

Seriously, its very cool being here.  I have to give a shout out to SafeNet for sending me.  I'm going to go see what they are playing on the 30 ft. Xbox screen and get ready for the opening address.  I'll bring the camera tomorrow.

Well we are in Florida in a nice hotel with a not so nice internet connection.  No hard-wire in my room so I'm sitting in the lobby.  Bah. Seriously folks, what year is it?  I have already learned something on this trip: My Laptop + Beta 2 + no plugin on the plane = battery dead in 40 minutes flat.  Nice.  I know that a couple of other Wisconsin people are around so maybe I'll hook up with them this coming week.

As I mentioned in the "Simulation" article I have some fabolous (cough) graphics in a Direct 3D game I'm using as a simulation for various theory testing.  The next step was to implement some kind of AI so that the bad guys shoot back at me.  I'm almost done with the pre-simulation-simulation-tester for my neural net.  Why a neural net?  I should say before optionsScalper slams me for mis-applying the idea, wait for my next post where I justify why this notion is very fitting for mimicing how a human would look at something on a screen and try to guess at a trajectory and how to acheive it.  Stay tuned.

The TechEd plane leaves early Saturday morning.  I truly loathe flying in post 9/11 America but not as much as I loathe long car trips.  The Family is coming with me which will to some degree affect the amount of geekery that I am able to participate in but I am very much looking forward to these sessions.  I'm sort of hoping I can finish one of my side projects in between sessions and leave more time for interesting research when I get home.  I should be able to get to the next stage of my simulation on the plane ride down there.

A quick mini rant as I work on some code tonight.  Disclaimer: I am far from perfect but I strive to improve at all times.

If you are developing a class library that you make freely available on the internet, you should realize that someone might actually download and use it.  In light of this, error handling is important.  I am using an FTP library for the compact framework that I downloaded from a reputable site..  My clients were having FTP issues this past week though, and I had to duplicate a situation that did not come up in my testing.  For reasons I won't get into, their servers have issues sometimes, so I had to implement a Re-try mechanism for the FTP items in question.  I tracked the issue down to this code:

FileStream fs = new FileStream(localFileName,FileMode.Open);
SendStream(fs, remoteFileName, type);
fs.Close();

See any issues here?  Maybe if I compare it to what I changed it to?

            FileStream fs = null;
            try
            {
                fs = new FileStream(localFileName,FileMode.Open);
                SendStream(fs, remoteFileName, type);
            }
            finally
            {
                if (null != fs)
                {
                    fs.Close();
                }
            }

Sometimes things will blow up.  In this example, if the FTP send fails, which is entirely likely due to network connectivity issues then the file stream will not be closed and cannot be closed because I've lost my reference to it.  The Re-try was then pointless since the file is locked by an object off in la-la land that has not been garbage collected yet.  While I'm at it, I don't know how many obscure bugs I have traced back to a resource such as a SqlConnection or DataReader not being taken care of in a Finally or Using block.

There, I feel better.  The author has still saved me a ton of time with a very easy to use library.  The next step is for me to be a good citizen and politely inform them of the issue.  Better code for all.  I would certainly want someone to inform me if I had released a library with bugs.  Happy coding.

Update: The Agile Developer pointed out that refactoring support and some other features are in fact supported for VB in VS 2005.  This is not meant to be controversial, as I despise the practice of being offensive just to try to create traffic.  This article is a combination of my own biases and a possible explanation for "Why do people bash VB?" Don't kill the messenger.

The google searches are a little slow today and The Agile Developer made a post and used VB.NET in his example so now's as good a time as any to resurrect my extreme dislike of VB.NET.  VB.NET is not "equal" to C#, regardless of what marketing material you may have read that tells you it is. I could drone on all day about how much worse my carpal tunnel would be if I had to keep typing

public overridable shadows Sub ThisIsMyMethodName() as MyReturnType

or about how much I dislike setting

option Strict on;
option Explicit on;

in order to enforce strong typing in an already strongly typed language.  Without these options there would be nothing wrong casting an instance of System.Web.Form to say, an instance of System.Integer.  Nor will I drone on all afternoon about how annoying these options make any form of OO programming, since turning them on means if I have a type Child that extends type Parent and a method that accepts an argument of type Parent I have to cast descending classes down to the base type (I guess strict means "So strict we don't trust you with Object Oriented programming") before the compiler will accept it.  If I enjoyed using obscure pre-compiler directives to make things work right I'd go back to creating C++ apps that run on multiple unix flavors: no shortage of #pragma directives there to keep me happy.

  Also missing from my lecture this afternoon will be how crippling not being able to override operators is, since many framework class methods such as ArrayList.Contains make use of "==" and not "MyClass.Equals" for its testing.  If anyone can remind me how to initialize an Array with a given size in VB I would congratulate you for keeping the roughly 39 uses of the paren "()" straight.  Finally, if I think it is ludicrious to have to specify which one of my methods implements an Interface method (public sub MyFunction() as string implements ICrap.MyFunction) then that's just one man's opinion, of course.  Since the man in question is obviously an elitist anyway we should not concern outselves.  If you want to program in an IDE that enforces Word-like AutoCorrect syntax fixers on your code, that's your problem.  Many times on user groups I have seen a question posted regarding some data binding or Reflection issue related to case sensitivity, ie MyMethod is not the same as mymethod to the CLR.  "How can this matter in a language that's not case sensitive?"  If the previous statement does indeed seem like a very good question to you, please stop reading now.

For various logical reasons, a lot of people do not like VB.Net.  Some of these are stylistic choices and some are just plain pains in the ass where certain programming tasks are concerned.  Before I go on, let me make a couple of disclaimers:

• I know some kick-ass VB developers.
• I am proficient in VB.NET
• You can indeed create very serious, robust, scalable, well-designed Enterprise applications in VB.NET

The VB community has gotten a bad reputation over time.  There, I said it.  For many years there were C/C++, Java, Smalltalk developers who just plain did not consider VB a "real" programming language.  In the heyday of pre-.NET VB people developed the notion that "serious" programming was done in a different language, and VB was for creating poorly-designed front ends to a database.  The fact that many VB developers did not have a traditional software engineering background and no Computer Science degree tells us a couple of things:

1. VB was very good at its job of making simple programming more accessable to more people.
2. Everyone from managers to programmers can develop bias towards a technology platform.

Let me propose this: When choosing a technology platform, you are also choosing the community of people who subscribe to that platform. This is not an original idea.  C++ people tend to be different than Java people, who are slightly different than C# people, who are slightly different than VB.NET people. I claim the source of this often goes back to education : If you got a CS degree you probably took classes in C++, Assembler, had some Calculus, etc.  If you got an "MIS" degree (or in some cases taught yourself) you probably had classes in SQL, COBOL, Accounting, and Visual Basic.  In a world of elitist programmers, the former background is considered better than the latter.  Don't shoot the messenger, I'm merely saying what everyone is thinking.  If you want another warm body to write stored procedures, post an ad looking for someone with VB.NET; if you want someone with excellent software engineering skills, post a C++ ad.

Nowhere is this difference acknowledged better than at Microsoft itself.  The Visual Studio team takes its direction to a great degree from ehancement requests by the user communities.  While there are some differences in the way VS 2003 behaves based on programming language, the disparity gets wider in VS 2005.  Take note of some popular new C# features

• Anonymous delegates
• Edit & Continue
• Rich Refactoring support

Versus VB

• The "My" namespace to make already simple tasks simpler
• Crippled refactoring support
• Still no "post build" commands

I'm vastly summarizing and obviously I am biased.  My point is that things like this perpetuate the idea that VB.NET is inferior because a different type of person chooses VB vs. C# for their .Net development.  We've all heard the rumour that the average C# guy makes a lot more than the average VB guy.  Companies perpetuate this idea with hiring practices such as "We need 10 VB guys and 1 C# Architect on this project"; one large local company I know of goes so far as to have a Frameworks/Architect team that develops tools in C#, which are then consumed by the project teams consisting of all VB.NET developers.

That is why I use C#: because I recognize the world-wide bias against the Visual Basic community.

I am proficient in VB.NET because I recognize that when it comes down to the code, there is very little real difference, with the only major item being stylistic preference.  Comments and flames welcome as always.

I've been talking about DirectX and games lately, and I've come up with a simulation for me to experiment with some things I've been wanting to learn or see in action.  Essentially, my brain has been going in several directions at once and this will be a first effort at exploring some ideas I have.  These areas of interest are:

• Physics: Realistically modeling shockwaves from explosions.  Coming up with a mathematical model for uniform and non-uniform force vectors and fluid dynamics such that a virutal world can react realistically with no "arbitrary" parameters defined, ergo "How come this can blows up but not this wall?"
• Destoryable terrain technology.  Using the above to be able to model bezier surfaces that represent a surface after an explosion.  
• AI: I'm very interested in AI, mostly just for academic nerd reasons ,but I may come up with business or gaming related applications

So, I've decided my simulation for all this will be a DirectX remake of the classic game scorched earth.  It will start out as a 2D version and move to a 3D version as soon as I find a good (free) 3D modeling tool.  I already have the game and graphics part of it pretty much done.  Next step: program some AI that shoots back at you.

If you read the site because of the .NET Compact Framework or other "useful" content this may seem ridiculous to you.  Never you mind, games are some of the most complex systems you can write today, presenting very complex design challenges.  Consider it a mental workout.

Of course, if I have fun with this I will try to make a product out of it...