Barry Lapthorn’s WPF/MVVM Quick Start Tutorial

WPF/MVVM Quick Start Tutorial over at CodeProject:

So to address this, I’ve written this based on what I would have liked to have found as the #1 hit on Google after typing ‘WPF Tutorial’. This article may not be 100% correct, or even do things ‘the one true way’, but it will illustrate the main points that I wish I had found in one place 6 months ago.

Fairly good walkthrough of MVVM and why you would use it.  (I had to ramp up yesterday, and spent probably too long trying to sort out the “why”.)

My thoughts:

  • I very much appreciated that the business objects were chosen so that “Name” would not be one of the business properties.  MVVM adds enough new classes, where there are enough opportunities to misunderstand and poorly name things, that having these things completely separate is helpful.
  • The code is very elided.  I missed the bold warning to download the code, and things were much smoother once I did.  (Generally, web articles shouldn’t require that you download code samples, though.)
  • I like the idea of “write something quickly, in a naive way, then patch it up with best practices.”  More articles should be written from this perspective.
  • However, it could be clearer when we’re doing something “quick and dirty” with the intention to clean it up later.
  • I wasn’t famliar with the “xmlns:local” namespace concept, so I spent a half-hour trying to figure that out.
  • I really liked the progression from not working, to working, to using a little more of the .NET framework, to growing our own framework.  It made a lot of sense.
  • I still have a sense that MVVM frameworks replace a lot of brittle syntax (which, to me, is unfamiliar and disorienting) with a more stable, extensible platform (which, being new to me, is also unfamiliar and disorienting).

I think good next steps from this article are to find a framework that I can try out a little more deeply.  Or, I may revisit knockout.js: with a better understanding of the problems it’s trying to solve, I may have better luck with it.

Ardalis – When to Comment Your Code

When To Comment Your Code:

Good comments tell only what the code cannot express itself, such as why a particular technique was favored or the dangers of optimizing a block of code.  Most other kinds of comments are simply noise, and their presence clutters of code, making it more difficult to understand and creating errors when, inevitably, the comments get out of sync with the code they reference.

Since comments are “good” and not writing comments is “bad”, more means better, right? This is a good look at why we write comments, and why writing more comments than we need will actually make things harder to understand down the line.

Google Reader Replacement

One of the things I used to write about at the last place was RSS.  I think it’s an amazing technology.  Applied correctly, it can connect you to the things that are important to you in your life, with much less effort than you’re used to spending.

I’ll make this perfectly clear: if you follow more than three websites, like can’t-miss-it must-read websites, you’re wasting an enormous amount of time by not using an RSS reader.

I was an early adopter of a lot of that technology.  I’m not sure exactly when I was a Bloglines user, but I became a Google Reader fan pretty immediately after that opened up.  (I got so excited about podcasting, one of the most inspiring applications for RSS, that I started a podcast in 2005.)  I’ve had my ups and downs with RSS and feeds generally, but I’ve been a pretty steadfast user of Reeder over the past three-or-so years.

Soon, they’ll be shuttering Google Reader.  I’m not exactly sure about the reasons, but I imagine the platform doesn’t perform well across paid-search metrics, so it’ll stop working.  Any app (like Reeder) that has been tightly coupled to the platform will need to be refactored to deal with different providers.

For my part, now that I’m self-publishing again, I’m trying to embrace the “stream of news” and seeing what comes out of it.  For that, I’m really enjoying Feedly.  It’s available as a mobile app and, while there isn’t a web interface, per se, it works as a browser extension.  I’m using it with Safari and Chrome, and I’m really impressed.

Neither HTTP nor HTTPS

I don’t know if you caught this in the jQuery CDN post of earlier this week, but the link to jQuery didn’t use “” or “”, but “//”.  Why is that?

I’m not sure when it became kosher by the browsers, but it’s called a protocol-relative URL.  If you make sites that serve pages up over http and https, then you’ve seen the need for this: to avoid a nasty (IE-only) security warning, you have to serve up assets that match the page.

Leaving the scheme off puts the browser in charge of asking for the assets the way that matches.  Problem solved.

Mostly.  Apparently, this had weird side effects in IE7 and IE8.

Hanselman on CDN Fallbacks

CDNs fail, but your scripts don’t have to – fallback from CDN to local jQuery:

Even better, RequireJS has a really cool shorthand for fallback URLs which makes me smile:

    enforceDefine: true,
    paths: {
        jquery: [
            //If the CDN location fails, load from this location
require(['jquery'], function ($) {

With RequireJS you can then setup dependencies between modules as well and it will take care of the details.

Good insight on potential CDN problems, and great mitigation plan.

Toast Your Enemies

One thing I don’t want to do here is pollute the Internet with war stories, but I have to tell one to get to the point of this post.

I was on a contract, and the client decided that it wasn’t working out.  It’s tough to describe it in any other way: I was fired.  I learned, in front of everyone else, that I was leaving, effective immediately.  It was six months of communication problems, crammed into a fifteen-second shouting match.

That day, and the days after, were a low for me.  I’d been wildly successful on a number of engagements, and highly sought-after.  (In fact, this was a second stint with this particular client, who loved me the first time.)  I couldn’t make sense of it.  I was miserable.  I had stress and anxiety for days, made worse by the fact that I didn’t start another gig for a week.  I cheered myself up with comedy and music.  I did everything I could to stay positive.

And my next gig was another return engagement with a different client.  I had the most fun I’d ever had working at the next place.  I met the best manager I’ve ever had, I worked with the coolest team, and I spent four years there.

It wouldn’t have been possible if I hadn’t been fired.  Once I became a manager, I got some new perspective on contractors, communication, and attitudes.  While I had empathy for the people in that unfortunate environment, I tried to learn lessons from that day, considering deeply how the people in my new environments perceived the people around them.

You’re going to lose something.  Where you work right now, it won’t always be that way.  It’s going to hurt, and you’re going to hate it.  And it might not immediately bring another amazing thing.  But if you don’t see the joy in the challenge, if you cling to things that are changing (and insist that they aren’t), and if you stay with that past, you put real limits on the growth that can come out of the experience.

On the anniversary of that day, I say a quiet thanks to the people who pushed me out of my comfort zone.  Gosh, I think of it as “toasting your enemy”, but I don’t have an enemy there (I don’t think).  It’s just a reminder to me that, even when it feels like the end, it’s almost always the beginning of something else.