One of the major reasons to go to Tech Ed is to meet other people in the industry. Everyone says you get the best jobs, the best advice, the best learning opportunities if you happen to know a lot of people, and the way to know a lot of people is to meet people and talk to them. But haven't we all had trouble finding someone to speak to at conferences? I always seem to end up at a table of sysadmins who know more about PowerShell than would seem humanly possible, or some hardcore DBA types who spend the lunch swapping tales of index problems from hell. If they're having a really technical conversation that's over my head, that's a meeting opportunity come and gone.

Over the years Tech Ed has tried lots of ways to help people find like minded people to talk to. Once you're on site, there are Cabanas or Track Lounges or whatever they call the informal place from year to year. These are great. But what about in the months leading up to Tech Ed? This year, there's something called Tech Ed Connect. You enter some details about yourself and are shown a map where people with similar interests appear closer to you. Mouse over someone and you see their user name (looks like many people are using their name, or initials) possibly a picture, and some details.

(I had to put IE8 in compatibility mode to see the map, by the way.)

You also get a "quick connect" card that can help people find you using this site. Here's mine:

Give it a whirl!

Kate

Some time ago, I told you about an issue with the Tech Ed DVDs and Silverlight versions. I also gave you a workaround for how to play the sessions after looking up the session numbers in a PDF document that functioned as an index. Now Laurent Duveau, a Canadian MVP, has gone one better ... he's written a utility that will fix up the index on the DVDs so you can have an all-electronic experience. Nice work!

Kate

Another Dan Griffin sample you might want to look at is the EC2 Console. I think his description from the first post in that category sums up his approach very nicely:

The purpose of the EC2 Console, like the other ones, is to demonstrate an attractive (WPF-based), novel, and useful application on Windows. In this case, we chose as our vehicle a helpful control panel for Windows developers who are new to cloud computing and would like to experiment with Windows Server, ASP.NET, and MS SQL on Amazon’s EC2 platform.

As it happens, Amazon already has an EC2 console (currently in Beta). But we’re going to differentiate ourselves from that in two ways. First, our EC2 Console will be specific to developers targetting Windows, and we can automate many administration tasks given that assumption. Second, our console (again, a WPF client app) will exhibit the kind of superior usability that is very difficult to achieve via the browser.

Client applications have many more advantages than just offline availability. Here's an application that's only useful when you're online, but is going to be a client application anyway. Follow along and see why.

Kate

Dan Griffin is working on some samples for client development and blogging his progress as he writes them. His SPOS sample combines workflow with access to local hardware (in this case, a fingerprint reader) to create an application where you could approve, say, purchase orders with a fingerprint swipe. It's a good example of the kind of application that is better as a local client application than something web-based and browser hosted.

He's created a Codeplex site where interim releases are appearing, and a blog category where you can follow his progress, read his musings on what fingerprint reader to buy, and so on. This is a sample designed for you to use in your own work, so follow along and see if it can help you.

Kate

I have a favourite piece of advice, and I give it even though it frustrates many recipients. If you want to write, write! If you want to get into public speaking, speak in public! If you want to start a user group, start a user group! If you want to be an MVP, do what MVPs do (advise others and solve problems and volunteer for stuff) and you'll start to get the benefit even before you get the award. I'm not quite saying Just Do It but the fact is the barriers to entry are very very small these days and possibly non existent. Technical writing especially - start a blog or get active on newsgroups and presto, you're writing! Listen to feedback (people telling you you're wrong is bad, people thanking you for your answer or quoting you elsewhere is good) and you will get better. Public speaking isn't much harder to crack because the world is full of user group leaders and similar folks who need someone to speak to them month after month. It's also full of Code Camps and other places to get started (they tend to come with coaching and encouragement too.)

Still some people don't like this advice. They feel held back from what they want to do, and they don't like to be told "nothing is holding you back, you can start whenever you want." Alternatively, they don't want to speak or write or lead for free, they want to be paid for it, and they don't like the idea of starting for free and working hard for years to get that overnight success. So here's a rephrasing that maybe you'll prefer: "80% of success is just showing up." It's attributed to Woody Allen, not a guy I would normally take advice from, but it sure is accurate. Go to the meeting, open the document you're supposed to be writing, be there when someone asks for volunteers, go to the whiteboard and draw as much as you know, put your shoes on and go outside, ... not all at once of course, but these are the "just showing up" tasks that get you on the road to success. Try it.

Kate

Paul and Kimberly are so romantic! Paul started it with a Valentines Day post about how to be a better speaker, giving lots of credit to his lovely wife. So naturally she followed up with a post of her own. If you've never seen Kimberly speak, you really should, even if you don't know anything about her topics. We're often speaking at the same time but the few times I've managed to get free time and sneak into the back of her room, I've been tremendously entertained and learned more about SQL Server as well. I know, too, how much time sweating demos, rewriting things, practicing, and just plain working hard goes into being so entertaining and accurate. You start to get a sense of that by reading these posts - from the tiniest detail of what to wear to the vital "practise your demos" and "show up for your tech check" you can understand that what matters most is caring. If you want to give a great talk you will do all that it takes to give that great talk.

None of their tips are SQL-specific. Read them and you're on the way to getting better. Get out there and do some talks with this in mind, and you're really starting to get it.

Kate

Well perhaps not all the way to Considered Harmful but Allen Holub is willing to call them Evil. I came across this article because I'm teaching OO Analysis and Design again this year and my students have generally already heard that the way you do encapsulation is you make all your attributes private and then add a public get and set method for every attribute. What's more, they generally feel if you change the type of the attribute then you need to change the return type of the get and the parameter type of the set. This of course gets you pretty much nowhere, and this is what Allen is railing against.

Now I am OK with Get methods as long as you swear you will never change the return type. The example I give the students is a bank account class with a balance. In the original design you keep the balance as a floating point number, 12.34000000 for 12 dollars and 34 cents. You add a GetBalance() method that returns a float, and Deposit() and Withdraw() methods that take (among other things) floats to represent the amount being deposited or withdrawn. Now when implementation time rolls along you discover that floating point arithmetic is expensive computationally, and needs lots of rounding to stay accurate: add 1.00 to 1.00, then add another 1.00 and the time may come when your number ends .01 or .99 ... neither of which banks care for tremendously. So you decide to store the balance as an integer number of pennies. Everything is OK in my book as long as you DO NOT CHANGE the signature of GetBalance(), nor of Deposit and Withdraw. These methods don't need to know what you just did. When Deposit tells you the amount is 50.00 dollars, your code can multiply by 100 to get 5,000 pennies, and add that to the balance. GetBalance() can divide by 100 (and round) to change pennies to dollars. That's a good use of a Getter method.

I am less OK with Set methods. I sure don't want a SetBalance() method. Deposit(), Withdraw(), and their cousins will change the balance. But there's no business rule in which it becomes necessary to announce that account 123456 now has $183.27 in it, and set the balance to that number. Having the method just encourages some code outside the class to do things that belong in the class - calculating service charges, or giving interest perhaps. Locking up access to the value means that if your business rules change, you don't need to look outside the bank account class for code that implements those business rules.

So do I think Get and Set methods are Evil? No, but I do think they should not be your first reflex, one of each per attribute. Make them earn their place.

Kate

Here's another Channel 9 Video you need to watch: Rico Mariani: Visual Studio Today, Tomorrow and Beyond - Your Questions Answered. I love that in addition to planning for version 10 of Visual Studio, he's planning for 11, 12, and to a certain extent 13. To have the courage to start on a feature that won't really be done for ten years is very impressive. I'm looking forward to "Dev10" for a lot of reasons ... even more after watching this video.

Kate