Tech Days 2009: A Speaking Debut

 

Tech Days Toronto has come and gone, opening what I hope to be one of many speaking engagements to come.  It was an honor to be able to Headline the conference with a presentation on “What’s new in Silverlight 3”.

After taking the time to rest over the weekend, I thought I would take the opportunity to write about it at Guelph Coffee and Code while I wait for some more attendees to show up. For more information on Coffee and Code in general check out the official website

Being my first technical conference, and more importantly the first time speaking in front of a large crowd (approx. 400 people were in attendance for my session), I was extremely nervous. To start my presentation and to try to get comfortable with the audience, I started up getting the entire room to chant “Silver” - “Light”, dividing the room in half.

Feeling energized by the ability to stir the crowd, I began my presentation at a blazing speed. I started into demoing my first topic, “Perspective 3D”. I walked through the 2 forms explaining the idea behind each of the forms, how you have the ability to flip elements on the X, Y, and Z Planes.  After showing these 2 demos, I remembered at tweet of advice from Barry Gervin of Object Sharp, the general idea “Speaker quieter, and slower than you think you have to”.  After the words slower passed my mind, I flinched, I haven’t shown any code yet. In a bit of a panic I explain myself and decide to jump into the code of my first two demos.

After reviewing the code from the first two demos, things went as you would expect a live demo to go. One of my demos didn’t cooperate but I was able to recover and show an example of Data Validation in a subsequent demo. 

Overall, I had a great time being able to present at Tech Days and hope to be able to speak at future Microsoft Events.  I’ll be sure to keep my head in Silverlight code, and make tours at local .Net User Groups (like CTTDNUG & FCDNUG)

Preprocessor Directives - Design Practice

What is a Preprocessor Directive?

A preprocessor directive is a piece of code that is meant explicitly for the compiler.  This offers a programmer to focus compilation for a specific environment at compile time instead of runtime.

How do i identify a Preprocessor Directive?

C#

In C# preprocessor directives can be identified by a hash (#) infront of a word or statement. C# Preprocessor Directives [only bolded directives are covered in this wiki]:

• #if
• #else
• #elif
• #endif
• #define
• #undef
• #warning
• #error
• #line
• #region
• #endregion
• #pragma
• #pragma warning
• #pragma checksum

VB.NET

In VB preprocessor directives can be identified by a hash (#) in front of a word or statement. VB.NET Preprocessor Directives [only bolded directives are covered in this wiki]:

• #Const
• #ExternalSource
• #If...Then
• #ElseIf
• #EndIf
• #Region
• #EndRegion

What's the advantage of using Preprocessor Directives?

Depending on the Preprocessor Directive there are many advantages to using directives over in code conditional statements.

C# - Conditional Directives 

Pairing the #define, #if, #else, and #endif Conditional statements allows you to set variables to target your Testing vs. Production environments.

 

VB.NET - Conditional Directives

Pairing the #Const, #If...Then. #else, and #End If Conditional statements allow you to set variables to target your Testing vs. Production environments.

1.a

This is how you declare a preprocessor directive. I've defined a TEST variable to be able to switch between my Test environment and Production environment.

1.b

Using the conditional directive, I check to see if TEST is defined, seeing how it is currently defined the constant _toEmail gets set to 'test@company.com'. However if i was to comment out the #define TEST, the _toEmail constant would be set to 'user@ClientCompany.com'.

1.c

You can also use the not (!) comparison operator to declare that code is only run if TEST is undefined.  As you'll see here i have wrapped my preprocessor directive around my try catch block this way i will be able to get an understanding of what types of errors will be thrown without the try catch there.  This will allow me to catch the appropriate Exceptions, as seen in 1.e

1.d

This scenerio is just to show that member variables can also be changed by a preprocessor condition.  This can come in handy if you pair the condition to change the subject to match a rule you have set up in outlook for test email filtering.

1.e

Now that i've run through some testing and have seen the Exceptions that my program is throwing i can now catch the appropriate Exceptions and handle them.  Once you have a good idea of what exceptions you need to handle you can remove the preprocessor condition and the try catch block can be tested to show the appropriate user friendly messages.

Summary

Hopefully now that you have seen an example you can understand some of the advantages of using preprocessor directives. If you would have made an in code switch in 1.b, you would have had to declare an extra boolean, and the conditional statement would be taking up valuable runtime processing time, memory for the (unnecessary) variable.  When using the preprocessing directives in Visual Studio, you will notice that there is a visual queue as to what variable is currently active. This makes your application more readable, for you and future developers working on your code, as well as saving your countless read throughs of your code to understand what version of your code is running.

C# - Organizational Directives

Using the #region and #endregion directives you can outline sections of your code and logically organize them within a descriptive code region.

VB.NET - Organizational Directives

Using #Region and #End Region  directives you can outline sections of your code and logically organize them within a descriptive code region.

Summary

Hopefully you can see the usefulness of #regions (#Regions in VB.NET).  Not only can you label sections of code, but in the Visual Studio IDE these tags allow you to collapse the code contained in the directive to make your code smaller and easier to read, maintain and manage.

Summary

Hopefully over the course of this article you have seen some of the benefits of using Preprocessor Directives.  Remember: Preprocessor Directives are evaluated at Compile time eleminating bottle necks of conditional statements in your code to switch between Testing and Production code are eliminated freeing up resources for your actual application.