Come learn about SketchFlow!

On Saturday, November 7, I'll be presenting an introduction to SketchFlow at the Central Maryland Association of .NET Professionals (CMAP) Code Camp in Columbia, Maryland.

A bit more info on my talk:
Microsoft's Expression Blend 3 has a baked-in tool called SketchFlow, targeted directly at prototyping your WPF and Silverlight applications. In this talk, I'll walk through building a prototype and exercising several SketchFlow features available out-of-the-box. I'll also show how easy it is to distribute a prototype and get back annotated feedback from your reviewers.

A bit more info about the code camp (from cmapcodecamp.org): The Code Camp will run from 8:30am - 5:30pm with 20-25 awesome sessions covering a wide range of database, software and portal development topics. It's totally free. No gimmicks. No sales pitches. Enjoy breakfast and lunch at no charge while you mingle with your peers. To register for this event, visit here.



For even more info, visit http://www.cmapcodecamp.org/.

Starting To Use The Windows 7 Touch API in .NET

I don’t know about you, but I’ve been really looking forward to the touch features built into Windows 7 (also known as Windows Touch). Now that we’ve hit general availability for Windows 7, I took a look at how I might be able to start using the Windows Touch in my .NET applications.

After a little review, it turns out that it is not as simple as you’d think. Windows Touch is not a .NET native, and a platform invoke (p-invoke) is needed to really reap the full benefits. I say full benefits, because Windows Touch sends some events to applications, without doing anything at all. It’s pretty much what you’d expect: a single touch sends a Click event to the form/control in question, holding a touch to the screen will send a RightClick to the form. But in order to do the really neat stuff, you need to use p-invoke.

A basic example of how to perform a platform invoke is creating a simple form which determines the touch capabilities of the client running your application. While this doesn’t use the touch API, it does provide a basic example of how access the user32.dll.

Start off by creating a form in .NET. Be sure to include an imports / using statement which accesses System.RunTime.InteropServices. Next, in the form you’ve created, be sure to add a DLL Import of user32.dll for the GetSystemMetrics() function. This is what we’ll use to determine what touch features are available. It will look something like this:

Next, we’ll need to create some constants to handle the value returned from the GetSystemMetrics function.

These constants are AND-wise compared with returned value to see all of the capabilities available. This is needed, because a computer might well have an integrated pen and an external pen. The AND-wise compare looks like this.

In case you are wondering, the 94 submitted to the GetSystemMetrics() function is a ‘magic number’ that tells the function to bring back just the Windows Touch-related capabilities. You can reference the Windows API and see other kinds of metrics (How many buttons are on the mouse, whether or not the call is being performed in a Terminal Services environment, whether you’re running a “Starter” edition, etc..)

In conclusion, this is a good start for getting your feet wet in using platform invoke and to determine how to what touch capabilities your computer is capable of. In another post, I’ll describe how to register a touch window in .NET with p-invoke and how to get information from the Windows Touch API.

Our Code Stinks

When I say “our” I am of course referring to the editorial we. I did not mean to imply that your code stinks. How could I know that? I haven’t even seen it. If it does stink, it’s not for the reasons you think. The ultimate audience for your code is not another developer. It’s someone much more unpredictable: a user. The sooner you face up to the fact that your code stinks the easier the road ahead will be.

When a user declares that some piece of software stinks, the complaints normally fall into one of three categories:

1. It is difficult to use
2. It crashes
3. Performance is poor

Notice what this list does not contain: lack of comments, bad framework choices, incorrect design patterns, lack of OO purity, poor variable naming conventions. You get the idea. All these things are important (and the subject of many good books) but users don’t care. Users want software that is easy to use, resilient, and impossibly fast (even when they try crazy stuff). There are people with fashion sense and trendy footwear who handle the interface design, so clearly if the software is difficult to use, it is through no fault of the developer. Since we’re all professionals, I am going to assume #2 is covered (mostly). That leaves us with #3: performance.  Oh, how i hate that word. Buy faster hardware and leave me be!

Performance, it turns out, is not so difficult (well maybe it still is but you can at least make your life easier). It starts with your test data. Your goal as the developer should be to find a data sample that is so mind bogglingly huge that no user could ever even conceive of it. Finding that data is no easy task. You have to consider what a “big” sample looks like right now, what it will look like in a year, and what it will look like in five years. Oh sure, you’ll be long gone in five years but trust me, these things, much like a bad penny, have a way of finding you. Test with that five year data and you won’t be sorry. If someone tells you they have no idea what the data will look like in five years or even what a “big” sample looks like, then stop. Stop developing and don’t start again until you figure that out. Do yourself a favor and find the biggest insurance policy, table, spreadsheet, XML file or image you can, then use it, daily.

The second item you’ll need is a baseline. How fast does your application perform with that crazy test data? Write that number down and keep it in a safe place. After you make a change, re-test and compare the results to your baseline. Did the code get slower? You know immediately what you did and stand a better chance of fixing it. If you can, get multiple baselines with the same data and average them just as a sanity check.

The third key to ensuring proper performance is profiling. You have to understand what your application is doing at run-time. How many times will that method be called? How often are files being read? How long does it take to find an item in that collection? These are all good questions and a good profiler can answer all of them. It’s nearly impossible to guess these answers, so don’t even try. The profiler will tell you exactly where to look and what to fix. Every time I’ve ever tried to guess the source of a performance bottleneck, I wasted time optimizing code that wasn't really the problem. A profiler will quickly help you isolate the bottleneck. There’s even one built into Visual Studio. Multi-tier applications can be complex to profile but you can always divide and conquer by profiling each tier separately.

Once you have isolated you’re bottleneck, optimize it. Optimizing code is an art unto itself. All I’ll say about this topic is that unknown loops are the enemy. Always know what’s going on inside of a loop and how many times you’ll be doing it.

To sum it all up:

Big Data –> Baseline –> Profile –> Isolate –> Optimize –> Repeat

Follow these simple steps and you may hear “this code stinks!” from a user again. No guarantees about the coder in the next cubicle.