CodeMash 2.0.1.2


It's like riding a unicorn over a double rainbow. CodeMash. All the way across the sky.
One of many CodeMash slogans on display

I went to CodeMash this year. I was one of the 1200 (or 1300 and something, after speakers and other people were counted). It was my first time attending this community-organised conference and I had a thoroughly enjoyable time. I would show you pictures but I neglected to take any as I was having far too good a time to remember that I'd brought a camera.

My wife and I1 arrived at the venue, the Kalahari Waterpark and Resort on Tuesday, the day before everything started with Wednesday's pre-compiler. Tuesday evening was spent meeting fellow mashers in the two resort bars, but ultimately led to a rocky start to Wednesday (breakfast was scheduled for 7am but I had forgotten to schedule bedtime accordingly).

My improvisation when the coffee cups ran out
My improvisation when the coffee cups ran out

At every meal during CodeMash, I enjoyed great food, nerdy conversation and copious quantities of caffeinated beverages with some fascinating people. Most of the time I dined with people I had never met, being sure to introduce myself and making a concerted effort to remember names (though, alas, I forgot a few). Although the pre-compiler day was overshadowed by a number of beverage-related issues varying from no coffee to no Mountain Dew to lots of coffee but no coffee cups (I improvised2), the remainder of the conference catering seemed to go without a hitch. This was in no doubt thanks to the CodeMash organizers and the amazing Kalahari staff.

Every evening after the sessions ended, a copious number of tempting options were available from the game rooms where D&D, poker and various other pastimes were enjoyed to Open Spaces3, from the bars, restaurants and water park to panel discussions. Attendees and CodeMash organizers alike would advertise a plethora of options to while away the hours until sleep was the only option. I was so exhausted after CodeMash that I slept for nearly a day when I got home.

What about the sessions themselves?

Wednesday

Going Independent

I'm not going independent, at least not anytime soon, but considering I have worked with many who are self-employed and might consider it for myself one day, it seemed prudent to learn more. Michael Eaton (@mjeaton) was the speaker for this session. He drew from personal experience and the experiences of those he knew (some of whom provided their own anecdotes) to outline the common practices and pitfalls that beset anyone trying to go it alone.

Michael's conversational style provided a great start to the conference and the information presented gave me a fresh perspective on the overhead, sales and productivity concerns of a business owner (apparently, if you manage 30 billable hours per week, you're doing well).  Even for someone under full-time employment like me, it provided useful details that will help me to continue supporting those who employ me.

HTML5 is here, and the Web will never be the same

Wednesday afternoon was spent with Brandon Sartrom (@BrandonSatrom) and Clark Sell (@csell5) learning all about markup, behavior and presentation with HTML5, javascript and CSS3. I am not a web developer, my acquaintance with HTML and its supporting technologies would probably make a professional sob, but this lab on the latest and greatest was fantastic. Each area of the HTML5 offering was presented with hands-on labs to sink ones teeth into. There was so much to cover that eventually time fell short, but I still have the labs on my desktop and be assured, I intend to complete them. This was a great stuff and the session so popular that we had to move rooms about an hour in. Apparently, this web stuff is a big deal. Who knew?

Thursday

Unlike the pre-compiler format of half-day and full-day workshops and discussions, the remainder of the conference was split into concurrent hour long presentations, open spaces, gaming and other activities. The sheer number of distractions was sometimes overwhelming, making the act of choosing a distraction in itself to the point where a couple of times, I gave up and just took an hour long break.

On Thursday, we had our first keynote speech, Rethinking Enterprise, while munching away at the remnants of breakfast. The speaker, Ted Neward, had an energy that made sure everyone was awake. Although Ted's presentation style was ultimately controversial, I felt the points he made were valid, well thought out and thoroughly enjoyable to learn.

From the keynote, I swiftly headed to see the popular double-act of Jon Skeet(@jonskeet) and Bill Wagner (@billwagner) presenting C# async inside and out. It was a packed out double session. Some only turned up for the much more complicated second session and I'm sure probably left very confused and scared of both C# and async. However, I loved it. Not only did I witness Jon Skeet's passion for C# first hand, but I also learned a lot (a useful mutable struct?).

After the Skeet/Wagner show, I took a break to check on my wife and make sure she was having a good time. I actually had to persuade her to make an appointment in the spa as she was perfectly happy eating homemade gumbo and watching bad daytime TV in the hotel room. Once I'd convinced her to spend some money in the spa (what did I do?!), I headed back down to learn about usability testing with Carol Smith (@carologic), attended a vendor session from Robert Half Technology, and then headed to David Giard (@DavidGiard) and his presentation on data visualization.

I have to say that while I enjoyed all the talks and workshops I attended, David Giard's presentation on data visualization was by far in the top two sessions I attended. Not only did Mr. Giard give a great talk while very much under the weather, but the examples of good and bad data visualizations he presented were useful and clear. I came away with a new found appreciation for graphs and charts, and a new found skepticism of those who create them and their motives.

Thursday was rounded out by dinner, the hilarious Pecha Kucha competition, live music, impromptu free beer in one of the hotel rooms and a late night water park party just for CodeMash attendees. At least, those were the things I attended; as always there was far more going on elsewhere in the resort if one was so inclined to attend.

Friday

Friday started slow. The night had once again taken it's toll but breakfast was thankfully an hour later, which helped. I skipped the first session, opting instead to wander the vendor stands and show my appreciation for their support.

My first session of the day was Dealing with Information Overload delivered by Scott Hanselman. I really wanted to catch one of Scott's two presentations as I had seen him present at the San Francisco StackOverflow DevDays and really enjoyed his presentation style. Just as at DevDays in 2009, Scott gave a very enjoyable presentation packed with useful, necessary tips, tricks and lessons in how to deal with information and stay productive. I have already started to fold some of the techniques into my working day and intend to continue. Along with the Data Visualization presentation from Thursday, Dealing with Information Overload was in my top two talks of the conference.

Lunch followed with our second keynote speech, How We Got Here, And What To Do About It presented by Barry Hawkins. The keynote was excellent and the presenter only went up in my estimation when we spoke and I learned he was both an anglophile and a thoroughly nice chap4.

As lunch digested, I rounded out the conference with some C# Stunt Coding from Bill Wagner (and a little Jon Skeet when he got up to refactor Bill's code; thoroughly entertaining) and some applied F# from the crazy-shirted Gary Short (@garyshort). Both of these talks were wonderful and gave me some inspiration for some crazy and not so crazy things to try in the near future (both code- and fashion-based).

Friday night's raffle was entertaining, but I didn't win so I'm not saying anymore about it. I'm not bitter, but seriously, didn't win. I did, however, win a book from O'Reilly (@oreillymedia) just for singing a couple of lines to a song. O'Reilly had a large collection of books with them on their vendor booth and gave them all away to anyone willing to sing on video. I haven't seen that video surface yet, but I'm sure it will. Still, I now have a spanking new copy of Programming Android and they're not getting it back if they decide they don't like my pipes (but seriously, thanks for the book).

The End

Jafar hamming it up for the camera while the wife and I pose
Jafar hamming it up for the camera while the wife and I pose

And that was that. There was more partying and water park fun but the mashing was over. My wife and I enjoyed the remainder of our stay, including a few photos with Jafar, the Bengal tiger and then travelled home to pass out and catch up on sleep.

Congratulations to all who helped put this together and a hearty thanks to all the folks (speakers, staff, attendees and Jafar) that made my CodeMash experience. It was such a wonderful event to have been a part of and I hope I am fortunate enough to get a ticket next year.


  1. Yes, I took the missus. While I was learning and networking and totally not eating too much bacon or drinking, she was cooing at a Bengal Tiger cub or doing spa type things. 

  2. Okay, so I took at least one photo. 

  3. Open Spaces are free-form discussions on topics suggested by attendees where an open exchange of ideas, experiences, tips and other things can occur. 

  4. My assessment and conclusion of the latter was in no way swayed by learning the former…I swear. 

Ann Arbor Day of .NET

On Saturday (29th Oct), I attended the Ann Arbor Day of .NET. I thought it would be nice to summarise what I heard. I doubt these notes on their own will be greatly useful, but I hope they act as a launch pad into deeper dives on the topics covered as well as a review of what topics were covered. There were five different tracks for the day: Cloud, Framewords & Platforms, Soft Skills, Tools and Mobile. I chose talks from the first four of these based on the talk itself, rather than the track to which it belonged (I ruled out presentations that I had seen a variation of before such as David Giard's (@DavidGiard) Introduction to Microsoft Windows Workflow and Jay R. Wren's (@jayrwren) Let's Go to C# On The iPhone, though they were excellent when I saw them).

Be A Better Developer

I started out the with Mike Wood (@mikewo) and his session, Being A Better Developer. This was a soft skills talk, meaning it was not there to show off some cool .NET feature or technology, or teach me all about C#. Instead, the focus was on what makes a great developer and what we can do to attain that status.

Mike explored the various roles that developers have to take on, the hats we have to wear. From the student learning new things everyday, to teacher imparting knowledge to those around them. From janitor‚ÄĒmaintaining what already exists, to researcher‚ÄĒinvestigating and choosing frameworks, languages, platforms, etc. Using these roles as a foundation, we then moved on to some tips such as setting up time blocks in which to work. If the time limit is reached and the problem isn't solved, turn to someone else for help (or somewhere else, like the Internet1) to avoid thrashing and time wasting. This seems somewhat obvious and yet I'm betting that many of us don't do it as often as we should. The other tips were equally useful, obvious and often compromised in our daily development lives:

  • organize
  • prioritize
  • know your tools
  • set SMART2 goals
  • be a catalyst for change
  • be lazy…

Right, that last one is maybe a little less obvious, but the point wasn't: don't do more than you have to.

One of the best pieces of advice from this talk was to choose a good mentor. I was very fortunate when I started out my career to have several excellent mentors and I miss working with them almost every day. Even now, I imagine what they might have said in order to guide my efforts3. For an hour, Mike filled that role.

There was much more to this talk than what I've written here. This session was an excellent way to spend an hour. While much of what Mike presented could be considered commonsense, it was reassuring and also provided some new tricks for my arsenal to be deployed in any situation, not just day-to-day software development.

Things to check out after this talk


How I Learned To Love Dependency Injection

Next, on to James Bender (@jamesbender) and his presentation on how he much loves dependency injection4. This talk started out looking at the way things were and the ideas behind a loosely-coupled system; a system where each component knows as little as possible about the other components in its parent system, whether it uses the services those components provide or not. Tightly-coupled systems don't promote reuse, create brittle systems and are inherently difficult to test.

James told a compelling story, starting out with familiar concepts‚ÄĒa constructor that takes various interfaces through which the created object can obtain various services, the factory pattern, etc., but soon we were looking at an overview of dependency injection frameworks, what they do and how they do it.

And then, code. Code about cooking bagels. The only bad part about this was the lack of bagels to eat5. The talk moved quickly on to the various features of Ninject, an open source dependency injection framework. I would've preferred it if there was more emphasis on dependency injection, using Ninject to provide examples, rather than the "how to use Ninject" approach that was given. However, this was still very informative and laid a path towards the next part of the talk which showed how dependency injection and TDD6 go hand in hand. This in turn led to an introduction of mocking (the mock framework of choice in these examples was Rhino Mocks, but James recommended Moq for new work).

Things to check out after this talk


A Field Guide for Moving to the Cloud

We're back with Mike Wood (@mikewo) for this one. I've never done any Cloud development but I'm really interested in it and what it may do for me and the work I do, so I'm hanging a lot on this introduction (no pressure, Mike).

Mike started off with a Batman reference, tying the reason why I'm so tired (Batman: Arkham City) with the reason why I'm here. He then fired off some acronyms: IaaS, SaaS, PaaS. This is a great starting point for me as terminology is often the last refuge of miscommunication and I hate not understanding what all those acronyms and terms mean. One participant immediately asked, "What's the difference between IaaS and PaaS?" and most of us nodded, realising we didn't know either. To paraphrase, IaaS gives the most control as you're responsible for patching your OS, upgrading the frameworks, etc. PaaS manages all that for you. Mike did a great job explaining this (unlike my paraphrasing‚ÄĒMike used a whiteboard and everything) and we moved on, that bit more informed and ready to learn more.

At this point, Mike gave us a run through of the Windows Azure platform, again making sure we're all talking the same language as the presentation progresses. Mike's presentation style is nice and fluid, taking questions and interruptions in his stride, and he clearly knows his topic well (Mike is an Azure MVP, after all). He walked us through the various parts of Windows Azure, Microsoft SQL Azure and Windows Azure AppFabric before we moved on to planning for our move to the Cloud.

Mike discussed identifying suitable applications for moving to the Cloud, scale of the application and the independence of scale, the services used and tight integration with loose coupling (not the first time we've heard this today but I would hope, not the first time in our careers either, otherwise, you're doing it wrong), usage patterns, latency, security and many other facets to be considered when moving to the Cloud.

The final point related to whether the move would save money or not and the importance of answering that question before making the move. This kind of information was great to see and may prove very useful when talking with project managers or business development types. Mike also pointed out using techniques like multipurpose worker roles and disposable compute instances to save as much as 50% in costs.

And then it was lunch.

Things to check out after this talk


Develop IT: Intro to PowerShell

I admit it, I have only ever used PowerShell for things that I could've done from a regular command prompt, so this talk was one I didn't want to miss. I want to know more so I can do more. I feel like PowerShell is an exclusive club for productive individuals and I'd at least like to take a look inside, so this was my opportunity. Sarah Dutkiewicz (@sadukie) was the presenter for this session, a C# MVP and co-author of Automating Microsoft Windows Server 2008 R2 with Windows PowerShell 2.0. This talk was entirely presented using PowerShell, which certainly made it stand apart from other presentations given so far today.

The initial examples given by Sarah quickly demonstrated how PowerShell provides similar behaviour to the traditional command prompt but also how it is different, providing .NET objects ( dir w* | Get-Member¬†demonstrated how dir¬†provides an object‚ÄĒvery cool). We then learned all about the standard PowerShell syntax that provides an easily dicoverable set of commands (known as Cmdlets in the PowerShell world) and some useful Cmdlets like Get-Help¬†and Out-GridView¬†(which outputs things to its own filterable grid in a window).

Sarah continued introducing us to a variety of PowerShell concepts and features including but not limited to:

  • functions
  • modules
  • manifests
  • PowerShell ISE7
  • providers
  • aliases
  • registry interaction

My biggest takeaway is how easy it can be to work with the registry from within PowerShell (just open PowerShell and enter cd hkcu: then dir to see what I mean). Overall, a great introduction that has given me a starting point for exploring PowerShell and becoming more efficient.

Things to check out after this talk


Stone Soup or Creating a Culture of Change

For the final session of the day, I rejoined James Bender (@jamesbender). I was really looking forward to this having faced many challenges in changing culture as part of my efforts for meeting the requirements of CMMI8. This was expected by event organisers to be a popular talk and I still feel that it should have been; however, the turnout was disappointingly low. This made for a more intimate session and certainly did not detract from the informative content. James expressed that this was probably the last time he would present this talk, which is a shame as I found the anecdotes and the lessons that were drawn from them to be very insightful.

The things I've learned will definitely help me in my work and elsewhere. Things like:

  • Go for low hanging fruit
  • Don't change too much at once
  • Support the change and let it simmer
  • Don't judge
  • Know your tools
  • Only introduce changes you believe in
  • Understand the business
  • Know when to say when
  • Evangelize
  • Build a network of like-minded people
  • Be a politician
  • Be a therapist
  • Realise that it might be difficult to reach everyone
  • When all else fails, buy doughnuts
  • Be patient

There's not much more I could say about this talk that would do it justice (not that my notes have really given justice to the earlier talks), but suffice to say this presentation was very relevant to me and I am very grateful to have been able to see it.

Things to check out after this talk


To conclude, I had a great day. The organisers, sponsors and speakers deserve a huge "thank you" for setting up and supporting this event. Wandering the hallways of Washtenaw Community College, attending talks in rooms and lecture halls reminded me a little of being back at university, but the speed at which the day flew by certainly did not. It was a very informative and enjoyable way to spend the day and among the best $10 I've spent this year.


  1. Use Internet search before you ask someone. 

  2. Specific, Measurable, Achievable, Realistic/Relevant, Trackable 

  3. Besides, "Shut up, Jeff!" 

  4. An appropriate amount as allowed by law. 

  5. Mmm, bagels. 

  6. Test Driven Development 

  7. Integrated Scripting Environment 

  8. Capability-Maturity Model Integration 

Crash handling in Silverlight (Part Two)

This post is the second part of a two part series.

Adding a little polish

In part one of this series we learned about the basic out-of-the-box crash handling that a new Silverlight project provides for both in- and out-of-browser applications, we learned how we can catch unhandled exceptions inside our application or let them escape into the browser to be handled by JavaScript (or a bit of both) and we learned that we are at the mercy of the HTML bridge.

What we had was far from fancy; the user would end up with a potentially broken Silverlight application or a blank screen and only some cryptic text in the JavaScript console to explain. This is not how we make friends, but now that we have a foundation, we can look at how to enhance the experience for our quality departments, ourselves and the poor souls that must suffer for our mistakes, our users. However, some simple modifications to our error handler can move the cryptic text out of the console into the page. We can even add some pizzazz and remove most of the cryptic text too. So let's take what we were left with at the end of part one and add a little polish.

In the following example, I've constructed a simple page that gives the user some information and provides a mailto link for sending the details to our QA department. When a crash occurs, the Silverlight application is hidden and the error page is displayed, customized to the specific error code1 and information.

Now, I understand, this is not the most elegant JavaScript in the world, but it works. Here is what your user sees…

Example of what a user will see when the application crashes
Example of what a user will see when the application crashes

…and if the user clicks our mailto link, they'll get something like this…

Example of the auto-generated e-mail incident report
Example of the auto-generated e-mail incident report

The example could be expanded to add additional information such as the URL of the application, the version of Silverlight and the user agent string by just modifying the JavaScript to include that information2. You could even show the same information on the HTML page that you include in the e-mail (in fact, you can go even further than that, just use your imagination…or read on for some suggestions). And yes, a little CSS would help, but I never promised it would be pretty‚ÄĒpretty can come later; I'm aiming for functional and as functional goes for showing that something is non-functional, this is good enough.

A bridge too far

Of course, as we have access to all the wonders of HTML and JavaScript, we could do so much more. For example, we could play a video to entertain the user while we call a web service that sends our error report automatically to our servers and tweets an apology (it's the personal touches that count). However, it doesn't matter how fancy and special we make the crash experience, it is all for nought once the user installs and uses our application out-of-browser or the HTML bridge is disabled. So, what do we do?

Out of the browser and into the app

The simplest way I have found to handle crash reporting in an out-of-browser application (or an application that lacks the HTML bridge) is to throw up a ChildWindow containing the details of the crash and provide no discernible means to dismiss it, thus disabling your application from further use without closing the application. This relies on the Silverlight runtime remaining intact even though your application suffered a problem; however, from my experience, crashes that take out the runtime are rare, especially in applications that have been tested and have well-formed, correct XAML.

Of course, if the runtime is still working, why stop at a ChildWindow? If you have access to the Silverlight runtime, you could do more like call a web service call or use some trusted API3 or COM4 interface. Whatever you try, exercise caution as you don't want your crash handling to crash as well. Keep it simple and it will serve you well.

Conclusions

Whichever route you choose, you should work hard to cater for all the scenarios that might be encountered, that way you will provide the support your user deserves. When deciding on your crash reporting strategy, always consider:

  • What level of network connectivity might be available?
  • Will the application be in- or out-of-browser? Do you support both?
  • Will the application be trusted and therefore have access to COM or Windows APIs?5
  • What Silverlight runtime(s) will you want to support?

  1. If you were paying attention there, you may have noticed that I mentioned the error code. There are many error codes that can be reported by Silverlight. You can use the error code to tailor your report or even consider not reporting a crash at all, but that depends on just how badly your application will react to the error. 

  2. Getting the User Agent string or the site URL are relatively simple, especially when compared with retrieving the Silverlight runtime version from within JavaScript. Thankfully, this was solved already, just visit this blog for details. 

  3. Silveright 5 

  4. Silverlight 4 and up 

  5. Starting in Silverlight 5, both in- and out-of-browser trusted applications are supported. Earlier versions only support trusted applications when out-of-browser. 

Crash handling in Silverlight (Part One)

This post is the first part of a two part series.

I love working with Silverlight but once in a while I get it wrong and I, or worse, a user experiences a crash incident. I believe it is important for developers to acknowledge that incidents will occur and to include incident handling and reporting as first class citizens in the software we write. It benefits both us and our users by providing both a graceful degradation of our application and a source of feedback regarding application stability and bugs.

In this and subsequent posts, I want to take a look at the functionality a new Silverlight project includes for handling and reporting incidents, and then build upon it to give us some top notch error handling in our Silverlight applications.

So, let's start with the basics1

Create a new Silverlight application (including a companion ASP.NET web application or website) and you'll get two flavours of error handling: the first reports errors when you're not debugging your application and the second reports errors when you are2. When there is no debugger attached, errors are reported to the DOM via the HTML bridge. This all happens in App.xaml.cs via an event handler for the Application.UnhandledException event, which is subscribed in the class constructor. The event handler checks whether the debugger is attached and if it is not, it sends the error to the DOM via the cunningly-named ReportErrorToDOM method. The comments in Application_UnhandledException explain what is happening. Also, note that the event is being marked as handled, meaning our application won't stop running just because of this pesky exception.

And a quick look at ReportErrorToDOM shows us the HTML bridge is being used to evaluate some JavaScript that will throw an exception inside the hosting browser.

If you try this and you're using a recent browser, it's very likely that you won't even notice anything happened. I put a button on my vanilla application and tied that to a click-event handler that throws an InvalidOperationException exception. Clicking it in IE9 gave me nothing until I pressed F12, viewed the Console in the developer tools and tried again. In some older browsers, a dialog box may appear indicating a scripting error.

Console in IE9 after a crash using basic Silverlight exception handling
Console in IE9 after a crash using basic Silverlight exception handling

I'll leave it as an exercise for you to go and see exactly what this looks like in your browser of choice, but I think we can all agree that with error handling like this our users must surely feel a warm fuzzy glow (especially with our hidden, cryptic error message and an application that continues running, unfettered by the potentially fatal bug lurking within). In fact, if the HTML bridge is disabled3, there isn't even a cryptic error message!

However, you'll be pleased to read that things are almost ever so very slightly better different when we have the debugger attached.

Attaching the debugger

The exception handler we just looked at only reports the error to the DOM when the debugger is not attached (and the HTML bridge is enabled). When the debugger is attached, the handler does nothing at all and the exception goes unhandled by our application. So what happens next?

Well, when an unhandled exception leaves our application, the Silverlight host looks for a JavaScript method assigned to the onError parameter. If there is such a method, it calls that and stops the application. The default handler is defined for us in the auto-generated HTML and ASPX. You can see its assignment in the default HTML and ASPX pages generated for us when we created our Silverlight application.

The default JavaScript handler generates an error similar to the one we get without the debugger, but with a few extra details4. Unfortunately, just like when the debugger isn't attached, disabling the HTML bridge (or running out-of-browser) also disables the error being reported.

Console in IE9 after a crash using basic Silverlight exception handling with debugger attached
Console in IE9 after a crash using basic Silverlight exception handling with debugger attached

The story so far…

In this introduction to Silverlight incident handling we have seen that, out of the box, we get some basic reporting that in a release scenario, will allow the application to continue running and will output a stack trace in the console5 but, when debugging, will stop the application and output a stack trace plus the added bonus of some extra details6.

I think you will agree, this is not a first class system for handling errors. Of course, all is not lost and in the next post we will look at how we can expand this error handling to be more helpful to both us and our users, perhaps even coping without the HTML bridge. That said, if this is all you use, I recommend deleting the code from App.xaml.cs so that the "debugger attached" style handling is used for all scenarios7. At least that way, when your application crashes, the user won't be able to continue using the application in blissful ignorance of whatever dangers lurk beneath.


  1. More detailed information on error handling in Silverlight, can be found here

  2. I am using Visual Studio 2010 Professional SP1 with the Silverlight 4 SDK. All line numbers refer to a vanilla Silverlight project created using New Project in the File menu. 

  3. You can disable the HTML bridge by adding <param name="enableHtmlAccess" value="false" /> to your Silverlight object declaration or by running your application out-of-browser. 

  4. The Category value is only available if the development runtime is installed, but the Code value is provided with all runtimes. It indicates the type of error, which can be looked up here

  5. If we're running in a browser with the HTML bridge enabled. 

  6. If we're running in a browser with the HTML bridge enabled. 

  7. Please don't actually use this as your error handling. Although it is in the most part, better for the user, your application will appear to crash a little more often as the onError handler gets called for more than just unhandled exceptions.