Are you a concerned citizen with ideas on how technology could solve social problems? A developer with the knowledge, technical skills, vision, and desire to contribute to the future? Have you been waiting for a reason to write a Metro App for Windows 8 or publish to the Azure Marketplace? Your time has arrived.

MOBILE AMERICA is a public app contest for Windows 8, Windows Phone, and Windows Azure. Entries in each category have a chance to win $1500 or $500 and a Windows Phone (full contest rules). Ready to get started, but still waiting for that great idea?? Check out some sources of inspiration like Apps for Democracy (an app contest in Washington DC) and Data.gov repository of public data and applications. As you build these applications, I’d ask that you think about open-sourcing your applications (github, codeplex, whatever) so that people all over can benefit from your innovative creations. Good Luck!!

I was talking with a coworker who focuses on Business Intelligence. He described the job as taking something boring like accounting (sorry accountants) and making it sexy. Like a professional stylist for a career. I thought that was pretty funny, but as I ruminated on that idea, I realized that my customer’s have no idea what I do for a living. How could I create a dashboard that keeps me on the road while I’m hip-deep in a new project, and still provide insight for non-technical customers.

1. User Tasks- Looking for the old TODO in the source code. This lets me know if (I/my team) trusts the code that we are writing. If the codebase is littered with TODOs and HACKs then it’s probably time to do some refactoring to make sure that we are properly addressing all requirements and side cases.

2. Warnings- Of course, every time you build you will be forced to close out any errors, but what about warnings? Your code can run great even with thousands of warnings, so what is the point in closing warnings? I think it comes down to attention to detail. I don’t adhere to every recommended practice every time, but if I’m going to break the rules, I don’t mind adding a justification to explain the exclusion.

3. Resharper/CodeRush notifications- If you aren’t using a refactoring productivity tool in Visual Studio you are wasting your time. Gamers have precision joysticks, devs have VS plug-ins. If you’re already using this tool, you know that refactoring opportunities are highlighted. Are you taking advantage of this low-hanging fruit?

4. Unit Tests- I rely on my unit tests to get me through the day. We all write pseudo-code or prototypes to try out ideas, a lot of this code can be reused. Once your projects have a baseline of unit tests, the code coverage stats in Visual Studio (Tests | Windows | Code Coverage Results) can identify areas of your codebase that could be further exercised with unit tests.

5. Code Metrics- The Code Metrics feature in Visual Studio (Analyze | Calculate Code Metrics for the Solution) provides a Maintainability Index to identify possible problem areas. Additional metrics include Lines of Code, Cyclomatic Complexity, and Class Coupling.

These metrics provide a little more insight for customers, team members, and managers who want to see the data behind a technical risk, or progress report. This dashboard can also help us stay focused on the path ahead as we guide our projects to success.

In developing apps for Windows Phone, I’ve been using the Northern Lights code library which includes Little Watson; a library for packaging exceptions and sending them to a http listener. The demo application uses a php page to send an email. Scott Hanselman’s inaugural WP7 post has him doing the same thing with an EmailComposeTask. Deep down, I’m a numbers nerd though, so culling through email to determine trends and statistics isn’t going to work for me. So I’ve created a ASP.NET webform that writes to a database. Not a huge deal, but when combined with ASP.NET dynamic data, I’ve got a live bug collection system that I can cull and extend as my needs grow more elaborate. I’ve setup three applications using this approach now, and it’s working pretty well for me.

To get this working for you, you’ll need to

1. Create a new Dynamic Data website (or add dynamic data features to an existing website).
2. Create a WatsonException entity that has the properties of the ExceptionContainer. I’m using Message, StackTrace, App Name, App Version, ExceptionRecordedDateTime.
3. Create a webpage that LittleWatson can send an HTTP post to. All of the exception data will be encoded in a variable called Exception. The Application Name is not included in the post, so I am creating a separate listener for each application.
4. In the webpage, save the exception data to the WatsonException context.

For me, this was another situation where a dynamic data website let me quickly deal with the incoming data on my terms, not letting this exception data clog my inbox. This also has the added benefit of requiring no user interaction, which makes it more likely that these reports will be submitted. If you choose to go down this route, there are two other items I would encourage you to remember.

The library uses a network connection to send the error reports (obviously). This means that your app needs to have the ID_CAP_NETWORKING or your error code won’t work. Just add it now, to save yourself the drama.