Category: C#

Live From Antarctica – the final 7th Summit.

Our team just finished a massive 5 weeks push to building an app for the Romero family, and in particular Jordan, to follow him on his climb of the final summit on the continent at the bottom of the world. You can find the app on his home page today https://jordanromero.com, or access it directly here https://edn1.esri.com/antarctica.

It was actually Jordan’s dream to climb the highest summits on the major continents. And, he is now on his way to accomplish all that…and before his 16th birthday during what is considered summer in Antarctica. I’m amazed at what he has done. I can’t help but think about what he might be able to accomplish in the future now that he has accomplished a feat that very few ever do.

The app is capturing live GPS coordinates (altitude, heading, speed, lat/lon), live weather and it also includes a Challenge component that anyone can take to conquer their own 7 summits on their own time by walking, swimming, running or biking.

I encourage you to check out the app and even take the Challenge!

For the techno-geeks reading this, here is some background info on the technology. GPS processing and ArcGIS mapping backend services were built in C#.NET by AL Laframboise. The Challenge service and REST endpoints were built in C#.NET by Nick Furness. I built the the Adobe Flex/ActionScript client application using Adobe FlashBuilder 4.5, and the ArcGIS API for Flex provided the client-side mapping. The look and feel were accomplished by the excellent help of UX engineer Frank Garofalo in Esri Professional Services. The client app uses a custom dependency injection model at the core, and the skins were built using Adobe Catalyst.

New Developers – don’t use shorthand code!

Our team is increasingly working with folks who don’t have a developer background. So, I’ve been spending time providing tips-and-tricks on some of the basics they’ll need to help them over their first few speeds bumps.

The first thing I always stress is learning how to debug. It’s imperative to know how to do it well, and if you don’t know how to do it then you’ll hate programming forever. It’s just like swimming. If your first experience is bad you may never jump back in the water again. But if you learn to do it right the first time, you are more likely to try it again and again. And, you may even find yourself having fun with it.

One of the fundamentals of debugging is writing verbose code. Those of us who have been doing it a while tend to cut corners sometimes, and we write things in shorthand like this:        

 if(something == 0) return false;

The problem with this line of code is very hard to debug. The recommended best practice is to write the code as such:        

if(something == 0)
{
     return false;
}

This enables three things to happen. First, you can set the debugger on the “return” line. This means you can check to see if the “if” condition actually occurred or not. Second, if there is ever an error you’ll know exactly which line it occurred on without having to decipher which part of your shorthand code caused the problem. This will save you time and headaches. And lastly, it’s much easier to read, especially when your programs start to get large.

So, my recommendation is to “spell it out”!

A better way to measure CPU % using Windows, PerformanceCounter and C#

I’ve seen dozens of reproductions of the same code on the internet showing how to measure CPU utilization on a Windows machine using the PerformanceCounter.nextValue() method. The vast majority of these implementations consistently alternated values of either “0” or “100” on some machines and worked just fine on others, which is essentially worthless. And, since my apps tend to be deployed on many different types of machines, I needed something that worked all the time. 

So, for a recent project I decided I was going to dig deep into Microsoft’s online documentation and solve this riddle once and for all. Sure enough I found what I was looking for in an article that mentioned using the System.Diagnostics. CounterSample Structure as a way to compare two PerformanceCounter values. That seemed like a perfect way to gaurantee better measurements.

So, here’s how I implemented it:

           
     PerformanceCounter cpuCounter = new PerformanceCounter("Processor", "% Processor Time", "_Total");
     CounterSample cs1 = cpuCounter.NextSample();
     System.Threading.Thread.Sleep(100);
     CounterSample cs2 = cpuCounter.NextSample();
     float finalCpuCounter = CounterSample.Calculate(cs1, cs2);

So why and how does this work? System.Diagnostics.CounterSample lets you compare two PerformanceCounter samples to come up with a float value. Rather than taking a snapshot value, which is what the nextValue() method does, you can compare values over a period of time.  Here’s the official description from MSDN of the Calculate() method: “Calculates the performance data of the counter, using two sample points. This method is generally used for calculated performance counter types, such as averages.” 

Feel free to experiment with adjusting the Thread.Sleep timeframe. It may need to be set slightly more or slightly less depending on the speed of the machine in which it runs, and the CPU activity on the machine. For example, if your machine activity is very sporadic and frantic, then you might want a shorter interval. Or, if you have long running processes that eat a fairly consistent amount of CPU you could probably lengthen the sleep time. I tested this pattern on a total of three different machines including two Windows 7 boxes and an 8-core, Windows Server 2008 box, and it worked very well. 

Now, for those of you purists who hate seeing Thread.Sleep in any code there’s no need to yell at me. This is a sample for you to use as you see fit. 

References: 

PerformanceCounter Class (MSDN online doc)

Performance Counter Value Retrieval (article)

CounterSample Structure (MSDN online doc)