Even though my only reason to go to this event was for the off chance I would get a free copy of vista (even though it was just RTM), I still had a great time.

The keynote was targeted at the buisiness crowd it seemed to me. I found that strange as there was a huge IT presence there. Towards the end they actually started showing some of the cool features of Exchange, Office, and Sharepoint which really impressed me (that or my head was starting to clear).  I can not say I did not get some business ideas out of it but I dont know how many people at the event were business people.

The morning developer track seemed to be a lot of powerpoint and buzz words to me but it was short at least.

After lunch John Bristowe turned on the magic and started a presentation about WPF (Windows Presentation Foundation). This was a great showing of the things you can do with things like xaml, microsoft expression. I really liked this presentation and found it was just the right mix of showing the new features without going to deep into something most developers are not going to be using for months at least. After the talk I went upstairs where John was answering questions (so I skpped the office 2007 presentation). Some of the cool things I discovered:

• Users in vista are just regular users by default (not admins).
• You can have your application prompt to elevate its permissisons.
• There is a cool virtualization feature that takes for instance when a program tries to write to protected areas of the disk (i.e. c:\program files) that it actually gets writen to your user profile instead. This helps to protect areas like program files, the windows directory, and the registry for corruption / bloat. You can still actually write to these areas if you elevate your permissions
• Vista now randomizes the location of assemblies in memory on startup. This is great for mitigating buffer overflows that expect a certain application to be in a certain area of memory. John was stating that if there was something trying to do this you would now get a protected memory exception which should be a warning sign that there is some sort of exploit on your system
• I asked if MS Expression (the interface designer tarketed more towards the graphics people that produces xaml) will be available on Mac. John was unsure on this but I really think this is a necessary step for someone to produce a xaml editor for the Mac as this is what a lot of designers use for a computer.

Bristowe was then back presenting on Windows Communication Foundation (WCF) and Windows Workflow Foundation (WF). I really love the distrubuted technologies like com+/enterprise services, remoting, and even sometimes asmx and msmq. The presentation showed how they have unified all these technologies into one. I really hope it is as good as the hype. WCF is a communication layer that supports running over any port, do any type of serialization, authenticate users, easily configurable, and has all the ws-* protocols (reliable messaging, message queing, security, and a whole load more). Basically WCF is all of the distributed protocols combined with none of the weaknesses of any individual one. I really really want this.

The workflow foundation stuff I had pretty much seen before but is another great technology. Basically you can create a graphical flowchart of a workflow in your organization and then associate code to decisions (or any other action). It seems like such a well thought out system there really is no point in creating your own workflow system. My favorite feature was the debugger in which you could actually step through the flowchart (and associated code) to see why decisions were being made. That is something I bet no inhouse shop has ever built for their own workflow engine.

Christian then came up to do a presentation on Office Sharepoint Server 2007. I am not a sharepoint person… and I dont really want to be. But seeing the technology gave me some good ideas and I really saw what you could do with it. The last presentation of the day is always hard and lots of people were leaving to go get swag and beer which makes it really hard to capture intrest in a presentation. There were also some technical problems that cropped up and even a few asp.net exceptions. Christian did not even break a sweat it seemed even when someones cell phone rang with the mission impossible theme. If that does not make you crack nothing will. So great content and I am sure that the bugs in this presentation will be worked out for the next stop of the tour.

So all in all a great launch event. I learned a lot more than I thought I was. I am excited about the technology. I was disapointed in the swag and prize selection but got free knowledge, food, networking, and way more beer tickets than Donald or I could consume.

I am working on a few small consulting projects with some people that are new the consulting thing. It has inspired me to write another post of tips on consulting lessons I have learned.

1. Only have one copy of your project or file. The biggest nightmare is having two (or more copies) of a work on your drive (or shared between the project members). This leads to all sorts of visioning issues, working on the wrong file, uploading the wrong file, etc. Just have one. If there are two of anything…… delete one…. please!

2. Release early, Release often. Now I am not talking to the client in this case. I am talking about the other members in your team (especially when you are working remotely like I am on these projects). I can not count the number of corrections so far due to missing something or not being informed of something.

3. Make sure the web stuff is final when coming from the graphics people. No point in implementing the HTML twice into the UI (or trying to mimic their changed). Inform them that there will be no changed (unless they want to change the aspx pages themselves… read next point)

4. Graphics people will usually screw up an aspx page. I know I am stereotyping but stereotyping saves time. Whenever I have told them they can change it “just like an html page” they seem to muck up a grid template, or move things outside of containers, or something. I tell them to make a backup of the file before they start and ensure it works

5. Realize the client will not like what you produce to some degree. Budget for this and expect to make changes.

6. Don’t comment out blocks of code. They end up sitting in there until a year later you say “hrrmrm…. its commented…. must be important… I should not delete it”. This is what source control is for. If something was really important you can look at the previous version of the file and extract it.

7. When coding there is no guarantee that you are going to be the one to make changes on it in the future, even then it might be 2 years down the road. Code everything with the mindset that an idiot is going to be the one making changes to it and has to understand it (and that way no one will be calling you for support 2 years later as well)

8. Establish ownership. Who owns the source code? Do you release it to the client? Unless stated in a contract clients own the source code as they have contracted you to write it (the law is vague on this but that’s what I have read out of it so far). Be clear about this fact right up front. I have offered different pricing if they want the source code in the past but now I just usually give it to them. They always come back to me for changes so why hold them over a barrel right?

9. Establish warranties. Let them know that you will fix any bugs (and let them know what a bug is) within a period that you set. After that there will be charges. This motivates users to test the crap out of an application and really sets you free of an app. I have had people call me up years later about a problem which I had to fix on my own dollar (plus relearn the app).

10. Keep communication between all parties open. If you are having a problem, falling behind, or just don?t think you will make the timeline; the earlier everyone knows the happier they will be….. trust me on this one. I have learned this lesson the hardway.

I was just talking to Tim Goodwin who was a co-worker of mine, and the best programmer on the planet (he made me say that). Seriously though he is a great programmer and seems to be 5-10 steps ahead of where I am. He suggested an alternative to using a strategy pattern for the enum refactoring. This method has a smaller code footprint which is nice and much faster to implement / refactor to.

public enum lineEnum
      Payment=1
      Refund=2
      Void=3
end enum

becomes

public class lineEnum
     public shared readonly Payment as lineEnum =  new lineEnum(1)
     public shared readonly Refund as lineEnum = new lineEnum(2)
     public shared readonly Void as lineEnum = new lineEnum(3)

     private value as integer
     public sub new(int value)
          me.value = value
     end sub

end class

So if I want I can still add a property to expose the integer representation if need be.

UPDATE: To avoid litigation. Tim never forced me to say he was the “Best programmer on earth”. My legal department has advised me to issue a formal apology to Tim in the form of alcoholic beverages.

I have to admit that I have been an enum junkie. I know some people are cringing right now and others are saying “so what?”. So let me explain

An enum is a string representation that gets converted to an integer. The only reason for an enum is so that as coders we dont have to remember that a flag of 1=payment, 2=refund, and 3=void. So it allows us to use magic numbers… without using magic numbers.

There are a lot of drawbacks to this method though. For instance, how do you show a string representation of the enum (yes you can use lineEnum.Payment.ToString() but what if you want it to display in multiple different ways?). Also someone can pass in any integer into a method like so:

public enum lineEnum
       Payment=1
       Refund=2
       Void=3
end enum

public sub CreateLine(linetpye as lineEnum)
        ……
end sub

public sub DoStuff()
      CreateLine(32084926439783968396839683)
end sub

now I dont think that is a valid choice but because its an enum (and hence just an integer) no error will be thrown.

My big issue with an application I am working on right now are enum mismatches. This happens when we change the numbering. For example we decide to start at 0 instead of 1 for our enums.

public enum lineEnum
       Payment=0
       Refund=1
       Void=2
end enum

Now any code with a reference to the old assembly containing the enum when they call CreateLine and pass the enum we will have interesting results. Consumers that create a payment will actually create a refund (as payment has been moved to have a value of 0). My recomendation is to not renumber your enum and it very rarely happens (my real recomendation comes later).

Along the same lines as this is that you dont have to use the right enum to do an assigment. The best case of this is in the data namespace. If I set IDbDataParameter.DbType = DbType.Int everything is good but nothing stops me from doing this IDbDataParameter.DbType = SqlDbType.Int.

So enums are not explandable (you can not add any functionality to them), usually lead to nasty switch/select stements, can easily be mismatched, they can take invalid values, and there is no way to only take a certain enum type.

The solution I have been using quite effectively has been to use a strategy pattern to replace my enums. I am not going to write how to do it as Jonas (another edmonton blogger) has this great article on this topic that I recommend you read.