I somehow missed this John Robbins blog post from back in May. He calls out an excellent presentation on writing data structure visualizers presented at BoostCon 2010. Here's the title slide:

Oh yes, this is a fun talk. I wish I had a recording, but the slides alone are entertaining and useful. I am already planning to put some of this code into practice, and I must find time to check the other talks, too. The links are in John's blog post.

Kate

As a new school year starts to roll around I naturally pay a little more attention to articles about undergraduate education. I'm once again teaching a one-term course on Object Oriented Design and UML at Trent University in Peterborough. This is of course just one piece of the curriculum. Trent is an interdisciplinary place and its graduates are expected to understand the concepts that underpin what they're learning. In fact this is what I see as the main difference between those with a university education and those without (though there are exceptions on both sides.) It's one thing to learn, perhaps by rote, the steps required to make a certain kind of application, and it's another to understand what you are doing and why. The latter kind of person generally finds it easier and easier to learn new things, connecting them to things already known, while the former finds it harder and harder as a mass of seemingly-unconnected facts moil around in an overly-crammed head that feels ready to explode.

I approve of valuing concepts over specific how-to's. It's hard work keeping up with the very latest technology when all you're doing is using it. It's even harder when you're also working on concepts and trying to teach. I don't expect a university to teach students how to use a specific user interface framework (MFC, Winforms, WPF, whatever) -- I expect it to teach them user interface concepts, illustrated with some framework the prof happens to know that's generally available. The students can then learn a variety of UI frameworks over their careers. But that doesn't mean I approve of all the ways in which programming as part of undergraduate education varies from programming in real life. Two specific variations I have a problem with are team size and problem size.

In real life, it's rare to work all alone, all the more so when you've only just graduated. Most university computer science grads will join a team of 2-10 developers reporting to a lead of some sort, with various people from QA, user reps, the business people and so on having various positions of semi-authority, semi-teammate in relation to them. Yet undergrads are generally expected to work alone on all projects and never discuss them with anyone until handing them in.

In real life, problems are not well specified, certainly not as tightly as undergrad assignments are. Most importantly, in real life user input is bizarrely ill formed. Users type letters where numbers belong, leave mandatory fields blank, even deliberately construct complicated bad input as part of hacking attempts. Yet most undergrad assignments do little or no input validation or error handling unless those are the point of the assignment. And of course, most undergrad assignments can be completed by an inexperienced programmer working alone a few hours a week (10 at most) in a week or two while most real problems take weeks and months of work by one or more dedicated resources to produce even a preliminary solution.

Trent (and I presume most other universities) addresses these issues with a fourth year course in which a team of students works on a real problem for an outside entity - usually a local firm or charity. They must gather requirements, code, test and implement a solution, and present to their peers and professors a summary of the project. Some students benefit immensely from this, though most take on far too big a challenge and struggle to complete it.

My contribution is to point out to my students where things are being simplified for them, where things would be vastly different in real life. Undergraduate courses simply cannot be the same as on the job training, and I don't want them to be. I want my students to be learning concepts and underpinnings as much as language syntax and how to work particular tools. But I want them to understand that when they start to put all this to use, things will feel very different than they did during class time. An assignment from your boss and an assignment from me are very different. (I've blogged before that in real life, you don't get 7/10, you have to keep doing it until it is right.)

I don't have all the answers. Lots of people muse about this stuff. Here's the inventor of C++ on the same issues. Easy to complain, hard to do anything about it, but we can all do our bit.

Kate

I mentioned Hilo when it was first released. This is a cool project doing Windows 7 development in native C++ with no frameworks - not MFC, for example - so you can really see just how it is done. It's not just code, it's also a walkthrough of their design thoughts, and explanation of that code.

The next application, Hilo Annotator, is ready. It features a ribbon, it uses the Windows Imaging Component, Direct2D, and so on. While you probably don't need an image annotator, you may find the code useful in your own applications. And remember, this is all native C++ code.

Your best place to start is the Visual C++ Team Blog entry about it. It's rich in links and has a nice screenshot too.

Kate

Have you ever heard of the All-in-One Framework? Well I hadn't. They've been around for about 18 months. Back in February, on their first anniversary, they described themselves like this:

...this initiative [has been] developed by the CodeFx Project Group to an "all-in-one code framework" that includes more than 300 code samples, covers almost all Microsoft development technologies, ranks 18th among 13000 open source projects on CodePlex, received numerous kudos from customers, proved its values in real support incidents, and created a lot of win-win opportunities within the corporation.

It looks like the participants are all Microsoft employees and they're collecting pieces of code for any language and platform that can be used to solve real world problems. On the CodePlex site, they elaborate:

Microsoft All-In-One Code Framework delineates the framework and skeleton of Microsoft development techniques through typical sample codes in three popular programming languages (Visual C#, VB.NET, Visual C++). Each sample is elaborately selected, composed, and documented to demonstrate one frequently-asked, tested or used coding scenario based on our support experience in MSDN newsgroups and forums. If you are a software developer, you can fill the skeleton with blood, muscle and soul. If you are a software tester or a support engineer like us, you may extend the sample codes a little to fit your specific test scenario or refer your customer to this project if the customer's question coincides with what we collected.

For example, they've written a summary of the ways to call native C++ code from managed code. You can find the pieces elsewhere, but having them all together makes it easier for you to compare and contrast. They often blog additions as they are completed.

Now as you can imagine, a big team creating hundreds of samples needs some sort of vision and structure to keep things consistent. That's where the style guide comes in. And now you can download it from CodePlex. It's an 87 page Word document that covers everything you might wonder about, for both native and managed code, including tabs-vs-spaces (no tabs, please), how much to comment (as I blogged recently and not so recently), Hungarian Notation (use it in native code if you must, but it's a relic; do not use it in managed code), smart pointers (yes, but don't bring in all of ATL for them - I look forward to this section being updated for C++0x), the right way to implement IDisposable, and an especially nice section on Interop at the end.

I don't care what language you work in - this is a document you should at least skim. It could settle some arguments at the office, improve your code, and spare you from some horrible bugs. Download it, won't you?

Kate

Recently, I was shown this quote. The person who showed it (in a general talk, not to me personally and specifically) is a smart person I respect, so I'm going to leave that person un-named. The authors of the quote, Kernighan and Plauger, are legends of the field. In 1979 (the very same year I was first paid to program) they wrote:

1. If a program is incorrect, it matters little what the documentation says.
2. If documentation does not agree with the code, it is not worth much.
3. Consequently, code must largely document itself. If it cannot, rewrite the code rather than increase the supplementary documentation. Good code needs fewer comments than bad code does.
4. Comments should provide additional information that is not readily obtainable from the code itself. They should never parrot the code.
5. Mnemonic variable names and labels, and a layout that emphasizes logical structure, help make a program self-documenting.

In general, I agree with this. Point 5 is really strong. But when I watched that person I respect walk through this quote I suddenly realized, for the first time in all the times I've seen this, that 1 and 2 are wrong. Really. They're wrong.

Imagine you came across this in a code review:

// Process the first 5 elements
for(i = 0; i <= 5; i++)
{
   ProcessElement(i);
}

I hope it's clear that this code actually processes 6 elements. The program is almost certainly incorrect. Perhaps the reason we're reviewing this part of the code is that there is some sort of message in the event log or unprocessed records or incorrect answers that have led us here, suspecting and hoping to find some incorrect code. And look! A comment that disagrees with the code! It's like a giant arrow pointing to the incorrect code. The documentation doesn't agree with the code, and that's great! It makes it really likely that we've found the bug. This sort of thing happens all the time - developers write the correct logic, as agreed in the requirements, into a comment, but sometimes make mechanical errors in representing that logic in code.

If a program is incorrect, comments that represent what the developer hoped or planned or tried to write may be of great value in rendering the program correct (fixing the bug.) If the documentation doesn't agree with the code, with any luck at least one of them is correct.

I still actually agree with the conclusions of the quote, and of those who quote it. Good variable names and function names, well structured code, and written requirements are all more helpful than comments inside the code, as I've written before. A true conclusion can follow from a false premise. Still, I was initially shocked to find myself disagreeing with these premises, and I wanted to share that insight. And don't feel bad if you leave "translating into English" comments around from time to time. They may surprise you some day.

Kate

Telerik is having an Eastern Canada User Group Tour this fall. Evan Hutnick will visit 6 user groups to speak on Silverlight topics. Here are the details for the East of Toronto event:

Monday, September 13, 2010

Silverlight Development Best Practices

Speaker: Evan Hutnick

Location: Whitby Public Library - Room 1B
405 Dundas Street West, Whitby, ON, L1N 6A1

In this session, we will explore best practices of development with Silverlight. This will include a look at the current toolset (VS2010/Blend) as well as the different options for architecture and data access (to MVVM or not to MVVM, WCF RIA Services or not, etc.), as well as how you can structure your application for intelligent reuse of styles and resources, making it easier to design a large-scale application with a unified look and feel.

Agenda

Time	Title
6:30 - 7:00	Socialize and refreshments
7:00 - 9:00	Presentation

See you there!

Kate

This is a story you might find hard to believe. A guy's project is cancelled and he's laid off, but he just shows up to his building (without being paid) and keeps working on it. He gets other people to help him and the product actually ships! One of my favourite quotes:

"The secret to programming is not intelligence, though of course that helps. It is not hard work or experience, though they help, too. The secret to programming is having smart friends."

Could this happen today? Almost certainly not. It probably couldn't even happen in another company. Remember the start of all this wasn't the support from former coworkers - that only happened once the product was almost done and the glamour of working unpaid on a feature caught on. The start of this was that a laid-off guy's badge still worked, and then when it finally stopped working he was able to tailgate through the doors every morning. Which leads to my second favourite quote:

"We wanted to release a Windows version as part of Windows 98, but sadly, Microsoft has effective building security."

A fun read and a reminder of how some people felt (and still feel) about creating software.

Kate

I'm collecting link on Windows Phone 7 topics and now is as good a time as any to blog some of them:

• Joey's roundup from two weeks ago, with pictures and links to dev tools, plus details on the two day cross-Canada Bootcamp DevTeach is running to get you great fast.
• Windows Phone 7 paper prototype - to supplement your emulator experience.
• Charles Petzold has an e-preview of his book available online.
• Colin Melia, who is part of the above-mentioned bootcamp, came to DotNetRocks TV as well.

Plenty of material no matter how you prefer to learn. Why not get started?

Kate