Chris Holmes Online

Savij just blogged about a problem he had with tabbing through a CAB application and invoking logic on a control that was not being shown. This is a problem we ran into as well. He posts his solution here.

Our solution is quite different, so I thought I’d post it as well.

What we do is hook into the SmartPartActivated event for our workspaces. Our intention is to turn off the TabStop for all Controls, and then turn it on for the ActiveSmartPart, as well as set the Focus:

 private void EmployeeEditDeckWorkspace_SmartPartActivated(object sender, WorkspaceEventArgs e)
{
   Utility.FocusWorkspaceView(EmployeeEditDeckWorkspace);
}

The utility is a static class with a method that looks like so:

public static void FocusWorkspaceView(IWorkspace workspace)
{
   foreach(Control control in workspace.SmartParts)
      control.TabStop = false;

   Control smartPart = workspace.ActiveSmartPart as Control;
   smartPart.TabStop = true;
   smartPart.Focus();
}

I think static methods of this type are pretty ugly, but this is more of a short-term solution as well as a way to prevent ourselves from having to write repeating code. A more elegant solution, in my opinion, would be to put this code in the Workspaces themselves and recompile CAB for your solution.

At any rate, I thought I’d show there’s another way to solve this problem. After we hooked into the SmartPartActivated event for our workspaces our tabbing woes vanished.

A Word About Spoilers

I had not read a single Potter book until about six weeks ago. I had only known Harry Potter through the magic of the first four films, of which The Prisoner of Azkaban was my favorite. The Goblet of Fire had many holes, it seemed to me, that the film did not adequately explain, not the least of which was Priori Incantatem. I could not understand how Harry’s meager disarming spell could stop Voldemort’s Killing Curse, for which the film established that there was no known counter.

Desiring answers, I took up reading the books. I was unsure how much information might have been left out of the other films, so I started at the beginning with the first book. I had never followed Potter outside of the movies, so I had never been exposed to spoilers. I did not know how The Half Blood Prince ended.

I know other people only follow Harry Potter through the movies, and so you will not find any blatant spoilers here.

The Review

I Open at the Close

That is an inscription written in magic on a Snitch; the very first Snitch Harry ever captured in a game of Quidditch. It is given to him by Professor Dumbledor in a way that I will not reveal here, in case some people have not read The Half Blood Prince.

When first encountered in the book, the inscription’s meaning is unknown. It could just as easily have been intended to describe my tear ducts. They opened at the close. Quite liberally.

I admit to being cautious prior to reading this book; fearful of reading even one single sentence, review, or spoiler. For a long while prior to the publishing of The Deathly Hallows, there had been a rumor, perpetrated in part J.K. Rowling herself, that Harry might possibly die in this book, the seventh and final installment of the Potter series. I felt that if I read anything resembling “It sucks!” that would mean he died, and if I read anything resembling “It’s great!” he would have lived, so I avoided all media until I finished reading it. I did not want anything given away (I would advise anyone who wishes to read the book, who has not finished it yet, to avoid all reviews, even this one, until you are done with the novel).

What I didn’t realize about The Deathly Hallows is that it didn’t matter as much whether Harry lived or died, this was still going to be farewell. This was still going to be sad. This was the final chapter – the last book Rowling would write about Harry – and so in effect he does suffer a kind of death. Whether or not a literal death would be added to the equation was the mystery everyone in Potter fandom was waiting to discover.

I can say only this about the end of The Deathly Hallows: I, like most everyone else, had become so entranced by the seemingly binary possibility of Harry living or dying that I had no even considered any other alternatives. I had not considered that Rowling might do something much more creative with Harry’s final pages. I won’t reveal whether he ultimated lives or dies, but I can say with certainty that I felt the final chapters were some of Rowling’s best storytelling.

I did not think I would be able to say goodbye to Harry Potter and feel good about it. Rowling made that possible with the way she put the final chapters together.

As to the book: When a series gets beyond a 3rd installment and grows into a larger work (i.e. Frank Herbert’s Dune), I usually find it difficult to choose favorites. I loved The Prisoner of Azkaban and The Half Blood Prince. I also especially liked The Order of the Phoenix. I won’t say what I think about The Deathly Hallows for fear of tipping someone off.

That said, I think Rowling has put so much thought, work and plotting into these books that you can’t really judge them fairly as individual novels. They are portions of a larger story that is one of the most enchanting and entertaining of our time.

Rowling will never win an award for great literary accomplishment (Stephen King has joked that Rowling “never met an adverb she didn’t like”), but she has won something much more valuable I think: The hearts and minds of millions of fans. Harry Potter has entrenched itself in our popular culture. He’s an icon now, standing right along side the likes of Luke Skywalker and Frodo Baggins. And that is an achievement I envy. I think most creative people would wish to invent a world and characters as lasting as those that Rowling has created.

To say goodbye to such an extraordinary character in such an extraordinary place is a sad thing. But Rowling has showed, with The Deathly Hallows, that she knows how to bid farewell with style, in a way that her fans can appreciate and enjoy.

If you have not read the books for whatever reason, I recommend doing so. There’s a wonderful world awaiting. You may be tempted to just wait until all the movies have been released; I would encourage you to do otherwise. Rowling has created such a rich, deep and interesting world that there simply isn’t enough room to get it all down on film.

Harry’s story, quite simply, shouldn’t be missed.

Are comments on blogs worthwhile? That’s the question some folks are asking (and answering), namely Adi, Joel and Dave Winer.

Dave puts it like this:

Do comments make it a blog? Do the lack of comments make it not a blog?

Here’s my answer: Comments don’t really have anything to do with the core concept of a blog (self expression). They’re an optional feature. Whether they can add value to a blog depends entirely on (a) the quality of the comments coming in and (b) how the author handles them.

Dave and Joel don’t apparently think they add much value, regardless. Joel writes:

Look at this innocent post on a real estate blog. By comment #6 you’re already seeing complete noise. By #13 you have someone cursing and saying “go kill yourself.” On a real estate blog.

Dave and Joel seem to think that if you’ve got something to say then you should just start your own blog. That idea doesn’t strike me as particularly practical.

I don’t know about anyone else, but I don’t see blogging as a medium fit for everyone (that one-size-fits-all problem again). I think you have to have a little bit of extrovert in you in order to write a blog. Plus you have to, you know, actually like to write. Then on top of that you have to buy web space (preferably with your own domain name), install blogging software, and then blog. Regularly. And not suck at it.

That seems to me like a lot of work for someone who might just want to respond to something you wrote one time, and maybe they’ve got something worth saying.

Isn’t it worthwhile to hear what they have to say?

Adi seems to think so:

…I don’t see anonymous comments as the evil Joel compares them to. I have read many blogs from Jeff Atwood, Scott Hanselman, Phil Haack containing meaningful and entertaining comments, some of them anonymous. Someone may have great ideas and the desire to express them, but no desire to open a blog, and you can force that person to start blogging.

I’m with Adi here. I think there’s a lot of value in other people’s opinions. It’s how I learn. It’s how my own ideas get challenged. For me, a blog post is a starting point. It’s a placeholder for a potential conversation. Without comments, that’s a pretty one-sided conversation.

As for the really idiotic comments, well, that’s where moderation comes in. Now, I admit my site isn’t a juggernaut like Scott Hanselman’s, so maybe there will come a day when moderating comments gets to be too much work. But I think for the vast majority of blogs, moderating comments is well worth the effort. It lets you keep the crap out, while giving people who actually have something interesting to say a place to say it.

Plus, I think there’s another benefit here: It makes people who visit your blog feel welcome. It encourages them to contribute to the conversation; to read; to have their own ideas challenged; to learn.

I feel like my blog is an extension of me – of my house, if you will – and when you’re reading my blog you’re visiting my house. Now, I could go all Soup Nazi on my visitors and tell them to take off their shoes, not walk on the carpet and keep their mouths shut while they’re in my house. But I prefer to make them feel at home; welcome; like they are an invited guest.

Of course that’s just me. Your mileage may vary

Scott Bellware, stud that he is, has put together the ALT.NET Open Space Conference. It is scheduled for October 5th through the 7th in Austin, TX. The list of names participating in the organizing committee is impressive.

There’s just one snag: Scott says the limit for attendees will be 100 participants, and from the sounds of it, it will be first come first serve. I sense an RSS stakeout coming on…

Steve Eichert takes issue with Jon Lam’s “dogmatic” label for TDD this morning; something he heard in the latest .NET Rocks episode. Specifically, he writes:

While I agree that the key is unit tests, I don’t agree that a test driven approach is extreme or dogmatic. In my opinion its the most pragmatic approach to writing code that is well designed and well tested. The fact is, writing unit tests after the fact sucks! Especially if “after the fact” is days or weeks after the real code is written.

I couldn’t agree more. For the past year or so our shop has been doing TDD, but it’s been hit or miss. Some developers do a better job of writing tests first and letting the process guide their design, while others tend to write code first and retrofit tests later. The latter method doesn’t produce nearly as good of results, nor does it make the developers feel like they are getting much out of unit testing.

It’s a difficult to get everyone on the same page with a technique that is so new to all of us. This week I’ve been pairing with one of my coworkers and we’ve been working diligently to write test first, refactor often, and let the tests guide our design. And like always, when we stick to the technique diligently we see better results; our design evolves to fit the needs of the feature or use case we’re implementing, we see better code, fewer bugs and we’re able to feel much better about the overall quality of the code we’ve written, knowing that it not only works, but will be easy to maintain in the future. We get a lot of confidence out of this.

That said, I think there’s a very important lesson in here for all of us TDD practitioners and “believers” to realize, and that is this: There’s a reason TDD gets slapped with the “dogmatic” label, and we need to be mindful about that reason when “spreading the word”.

TDD is like many other religious ideology. When people discover it and use it and find it incredibly valuable to them, they tend to preach it like gospel. If you read the blogosphere with any breadth at all you’re certain to run across the word “zealot” a lot in conjunction with TDD. You’re also likely to run across people who have tried TDD and failed. And there are a lot of legitimate reasons for this. There’s a lot of ways to not get the best out of TDD: trying to retrofit tests on legacy systems, trying to test too-complex relationships/not starting out simple first, not refactoring existing designs to better designs that are easier to test and change, trying to test systems that make the tests slow, writing tests after code, etc. I mean, you could write a pretty decent book on the number of ways to fail at TDD.

Because people do fail at TDD, they tend to do what all people do when they fail: they blame the concept and the people who advocate it. Hey, we’re all smart people, right? If we can’t make “it” work then “it” must be wrong. (And I’m not excluding myself from this behavior – guilty like everyone else).

The TDD community doesn’t always help in this regard. Our response (and I put myself in this camp, because I consider myself an advocate of TDD) is to blame the user; they didn’t do TDD right. If only they had done it correctly they would have succeeded, right?

This blame-game has the same effect as in any other area of life: it causes animosity. It causes people to label (advocates for TDD quickly become “zealots”), to fight and bicker, and to dismiss each other outright. It doesn’t help the TDD advocate trying to get the message across, and it doesn’t help the poor sod who decided to go out on a limb and give TDD a try.

I’ve explained TDD to a few people and I can say this: it doesn’t help nearly as much as showing them.

When we hired the people I currently work with, they did not know TDD. We explained it to them, and the result was predictably mixed: they said the right things (because the theory of TDD sounds good), but inside you could tell they had some trepidation. Telling people about TDD and actually doing it with them (following all the guidelines that the experts have cultivated, thus allowing us to achieve some degree of success) were two completely different experiences. It wasn’t until they actually saw the process in action, until they saw the quality of the code, and the ease of refactoring, especially larger refactorings to the system successfully, with little or no bugs, that they were sold on the technique.

But you can’t sit down and pair with everyone who wants to try TDD. You can’t show the world. And even if you could, you’d still find people for whom TDD is not ideally suited. Let’s face it: there’s no one-size-fits-all religion in the world, or we wouldn’t be killing each other all the time. And there’s no one-size-fits-all development methodology. I personally think TDD is the best thing available for producing quality code, but I am in no way naive enough to think that everyone could be made to believe that. We’re human beings; getting us to universally believe anything is genetically impossible.

I think what we, as TDD advocates, must do is always be mindful that we can very quickly sound like Born Again Christians. We can sound preachy; we can sound like zealots. And when that happens, it doesn’t matter how good the message is because we tune out. We don’t like being preached to.

The “dogmatic” label may not seem true to Steve or myself, but it’s easy to see how someone could arrive at that conclusion.