Bill Blogs in C#

Julia Lerman wrote about coping with the widening gap between .NET Newbies and .NET Pros. She mentioned the concept of a pre-meeting presentation that was geared for beginners, and the main presentation engaging those interested in more advanced topics. Well, We (The Great Lakes .NET Area User Group) have been doing just that for some time. It’s worked great for us. Thanks to Alex Lowe for originally suggesting it to us.

• The tutorial session starts at 6:00.
• The obligatory pizza is served at 6:45.
• The main session starts at 7:00 (or so, depending on pizza consumption).

We give the right of first refusal on the tutorial session to our main speaker. Quite a few have taken us up on it. In addition, we always try to make the tutorial an introduction to the main talk. Finally, we publicize the two talks as two different sessions, fully expecting some members to arrive after the tutorial.

Here’s what we’ve found:

• We are getting roughly 20 to 30 people attending the tutorials.
• Almost all of them stay for the main session.
• We’ve seen growth in our regular attendance that mirrors the tutorial attendance.
• Evaluations for the tutorials have all been positive.
• The tutorial as introduction to the main talk really helps newbies get more from the main talk.

I would say it’s a great way to make the user groups more accessible to the .NET newbies, yet still contain rich content for the more experienced .NET developer.

Julia's original post
How to handle the gap in .NET skills in your user group
The MI Gang homepage
Our user group

Happy St. Patrick’s Day. A tradition at one of our local news stations is to play The Bricklayer’s Lament in morning. That got me thinking about extreme programming. If your not familiar with The Bricklayer’s Lament, you can read the lyrics here. Don’t worry, I’ll wait. (I looked for an MP3, but I could not find one. If you know of a location, please let me know.)

I’m glad you’re back. Let me know when you’re done laughing.

Great, now, let’s get back to extreme programming. There are many things I like about agile development. But there is one element of extreme programming that really concerns me. No, it’s not pair programming, although I’m not thrilled about that either. It’s the stringent policy of concentrating on the current story card to the exclusion of all else. Developers should not be looking ahead at all, because that’s how schedules slip (at least according to XP doctrine).

Well, the bricklayer certainly did complete the one task in front of him. And, he did it ahead of schedule. Quite a feat if you are a seasoned software developer. But, clearly he did not succeed. The humor in the story is that the bricklayer made a number of critical mistakes that cost him dearly. All those mistakes could have been prevented with a little forethought. Until I see XP embrace that fact that software developers should at least be familiar with upcoming story cards, even while they are focusing on the current task, I’m very skeptical.

The bottom line for me: If you don’t keep at least one eye on the risks that could cause your project to fail in the future, you will fail. That’s everybody’s responsibility, not just the project manager.

A colleague of mine had some fairly detailed questions about graphics programming in .NET. My favorite refernce is Graphics Programming with GDI+, by Mahesh Chand.

It's well writen, and covers a wealth of GDI+ topics. It assumes some rudimentary knowledge of graphics program techniques, but Mahesh does take you from the basics of lines and similar figures all the way up to complex 2D concepts such as gradients, color blending, alpha blending, transforms and transform composition.

It is much more of a reference book than a tutorial. I did not read this cover to cover, but over time, asI've needed the topics he covers, I've read all the content.

Graphics Programming with GDI+ homepage
More information about the book

The Updater Application block is part of the enterprise library.  This brings click self-updating assemblies to .NET 1.x applications. This is the last version which will target the .NET 1.x framework. From here on out, it's all Whidbey.

Updater Application Block homepage
From this page you can read the synopsis, and download the application block.

So, a few weeks back we heard that Alex Lowe left Microsoft. Now, we know his replacement is the current Ohio Regional Director: Drew Robbins (drewby in the blog world.) Congratulations Drew. I’m sure you are going to be a great asset to the developer communities in the Great Lakes District. And, Ohio isn’t that far from Michigan, stop on by.

If that’s not enough we are losing our favorite academic .NET guy: Eric Maino is going to Microsoft to work on the VC# IDE team. It’s tough to see one of the most intelligent, dedicated tech people in our area move away, but it’s nice to see him succeed.

Oh, and I was interviewed on WJR am today. The topic was blogging, so it will seem like old hat to this audience. But is one fun being on a major radio station.

I received the following question (which does related to Effective C#). I thought the discussion was of general interest, so I posted it here instead of in the blog relating to the book:

I have a question about some recommendations that seem to conflict. Item 7 (Prefer Immutable Atomic Value Type) and Item 38 (Utilize and Suuport Data Binding) seem to contradict each other. It was my understanding that the data binding classes only worked on public properties to synchronize data. If you only provide "get" properties and not "set" properties, how would this work?

It is correct that Data Binding works by reflecting on public properties to synchronize data between controls and data objects.

The first answer is quite simple: If you only provide get accessors, you can transfer the data value from the data object to the control (either a web control or a windows control). You’ll see in Item 38 that I have some examples of this technique. Those are the examples that use a property on a data object to set the foreground or background color of a control. Being read-only properties, there is no way to store the data back into the data object. When that’s what you want, it works just fine.

The second answer is a bit more complicated. You’ll note that I stated in Item 7 that not every type can be an immutable type. Some of your low-level data storage objects should be immutable, and should be value types. But, if everything is immutable, your users cannot change anything in your program. Once again, look at the examples in Item 38. Some support edits: those are not immutable. Some (like the color example) are immutable.

Finally, let’s look at these two recommendations in concert. You could have a mutable type (an employee record for example) contain an immutable type (like an address structure). You could support data binding and transactions using these two types. You would expose the get and set accessors on the employee record. The set methods could create copy of an internal address structure. You can see this idiom in Item 41. (It is in a counter example, but there are times when it is the correct idiom.)