On August 10th, Udi Dahan came from Haifa, Israel, to Whitby, Ontario, to speak at the East of Toronto .NET Users Group meeting. (Well, OK, he was in Toronto to teach a course.) He was talking about high availability and some architectures that let you keep a system up, for example, even while you're upgrading it. I took a few pictures:

Udi did a great job demonstrating that design up front and thinking about architecture doesn't mean you're not agile. Taking the time to architect something so that it's highly available gives you the freedom to be agile.

Watch for the fall schedule of the East of Toronto group in the next few weeks. And if you're visiting the area and would like to speak, let me know!

Kate

Visual Studio 2010 has pretty cool Windows 7 integration. It gets jumplists right, for example:

But it could do more, and this little add-in adds some fun extras.

Here's a taskbar progress bar overlay during a build:

(If your build results in errors or warnings, you'll also get a taskbar icon overlay when it's done letting  you know about them.)

And here we have handy thumbnail buttons - for build, debug, and start without debugging:

Give it a whirl! You can download it from the gallery, or use Tools, Extension Manager, Online Gallery right in Visual Studio and search for Taskbar.

Kate

I got a call this week from a recruiter who is trying to find senior C++ developers for a firm with a growing need. He has placed people with them in the past and it's worked out well and they want more. They write performance-sensitive applications for the financial industry and need someone who's comfortable with templates, and has experience with applications that process high volumes of data. If you're interested, drop me an email and I'll forward it to him for you. Good luck!

Kate

I'm speaking at TechDays 2010 in Toronto. So are some other very good speakers. (Feel free to click the links on that page to other cities to see the equally good crop across the country.) Would you care to join us?

Seriously, Microsoft has an entire track in each city, ten hour-long talks and two half-hour ones, for Local Flavour. The most important criteria is that you want to talk on something you're passionate about. Seriously, this isn't "Introduction to Visual Studio 2010" or "What's New in C#" - instead it's something that is far more specific and personal. A technology or methodology that you use and care about. A story that will help other developers, or IT pros, or DBAs. Something important that won't be covered in the entire two-day conference unless you step forward now and offer to talk about it.

As John Bristowe puts it:

You need to get cracking on this to meet the submission deadlines. Download the application form from the Canadian Developer's Blog, and submit as many ideas as you have.  You don't have to have prior speaking experience, but if you do, be sure to mention it!

See you in the speaker room,

Kate

Recently I had a nice chat with David Starr on the Pluralcast about Visual Studio Extensions. This topic is just so much fun. Visual Studio is where most of us live all day, and making it work perfectly for us is incredibly appealing. The introduction of the VSIX format with Visual Studio 2010 takes so much of the deployment pain away and is really changing the landscape of who is willing to write and share handy little things that make Visual Studio a tiny bit different - in a good way.

If you want to find some great extensions, do check out the Visual Studio Gallery or click Tools, Extension Manager and then click Online Gallery. There you can search for Triple Click, Ctrl-Click Go To Definition and many more. You can also look around to see if anyone's implemented your fun idea.

If you'd like to learn how to get in on the fun, please do check my course - I am having such fun writing it and as always learning a few things I never knew as I go. Also check the links David has on the Pluralcast page - they will get you started.

Kate

I've done a lot of training in my day. I really enjoy it - you get immediate satisfaction, as a trainer, from seeing people leave changed by having spent a week with you. It's one of the easiest ways to have a major impact on someone's career and even their life. These days, there's a lot less of it going on. Partly it's because technology has enabled other ways of learning. Partly it's because we're a lot more "fast-paced" - someone who realizes they are missing knowledge will search for it online, ask on StackOverflow, watch a recorded talk or screencast and then carry on, rather than waiting several weeks to be able to go on course. There is still a lot to be said, however, for spending a day or three days or a week with a really smart person who has committed to making you better at something you don't know enough about.

So why would someone who was lucky enough to be "sent on course" by their employer, or who has invested their own time and money on taking a course, waste that opportunity with self defeating behaviours? I don't know, but I know for a fact that it happens. I've had people in my courses who didn't care, who didn't want to learn, who were hostile to the language or tools or methodology I was there to tell them about. Sadder still were the people who did care, wanted to learn, wanted to learn this topic, but still chose to act in a way that prevented it. Back in the day when you couldn't check your email in class (no wireless, and email on phones was rare) it was the folks who burst out into the hall at every coffee break and every lab period to go check their email and voicemail. Often they would say "I read the exercise and I only need 10 minutes for that, so I'll check my messages then come back and do it." My reply was always "if you really only need 10 minutes, do the exercise and then go check your messages." But this group of people can't make the training their top priority even for this one day, this one week. And often, they don't learn much as a result. In person training is probably a bad fit for them, and they might even give it a bad name. Then there's the showoff, the arguer, the "sorry I was zoned out can you say that all over again", and so on.

Paul Randal and Kimberly Tripp are still teaching more than I ever did. And now Paul's written up a lovely list of ten things NOT to do when you're on a course. None of it is SQL-specific and it's all good advice. Enjoy.

Kate

Oleksandr Krakovetskiy, a Regional Director in Ukraine, has written a cool Bing Maps application that shows you where Regional Directors are located and provides a bit of their bio. It's an interesting supplement to our blog aggregation and event calendar at The Region.

Hover over a star to see someone's name (as in the screenshot) - click it to read their bio and get links to their Twitter, blog, etc. You can zoom out to the whole planet or in to a region that interests you. Nice work, Oleksandr!

Kate

Here are some interesting lists. Each of them is fleshed out in a blog post you really should read. I'll give you the lists so you know you want to read them.

First, Ted Neward on 10 Things To Improve Your Development Career:

10: Build a PC.
9: Pick a destination
8: Be a bell curve
7: Learn one new thing every year
6: Practice, practice, practice
5: Turn off the TV
4: Have a life
3: Practice on a cadaver
2: Administer the system
1: Cultivate a peer group

Some of those are metaphors: I'll let Ted explain them.

Then, we have Jim Carroll and How to Get Faster When the World is Faster:

• build up experiential capital
  
• master collaboration and share
  
• focus on tactical to strategic transitions
  
• fuse generational insight
  
• take on anticipatory projects
• be a farmer
• displace indecision
• implement quicker
• think bold

The advice is aimed at entire companies, but I think it can resonate well with an individual. Again well worth the read.

And then there's John MacIntyre and 11 Personal Programming Assumptions That Were Incorrect.

1. The customer and user are the same person.
2. You isolate and kill all bugs without exception.
3. Writing beautiful software as an act of craftsmanship.
4. Working 24/7 would be rewarded.
5. Vendors can be believed.
6. You are not actually working from the monitor.
7. That I wasn’t a very good programmer.
8. You need to / should grok a language or tool before you even start.
9. You don’t say you know something unless you’ve grok’d it.
10. Other programmers saw beauty in their work.
11. The best programmer is recognized.

There's some cynicism in there, but others might call it realism. I suspect most of this you have to learn from experience, but perhaps you recognize a few?

Kate