If you've used TortoiseSVN for any length of time, you've no doubt encountered a situation where it tells you to run the Subversion "cleanup" command. This happens when TortoiseSVN needs to clear inconsistencies in your local copy, which means that under-the-covers it needs to re-execute log files within your .svn folders to get things back to a happy state. And usually when this happens, it's easy enough to simply right-click on the offending folder, go to TortoiseSVN, select Cleanup, and you're good to go.

But what if this happens on your build server while running your automated builds? It doesn't make much sense to log on to your build server every time this happens just to manually issue the cleanup command to get the build working again.

To solve this problem, add a <prebuild> element to all of your CC.NET config scripts that issues the cleanup command automatically. The existence of a <prebuild> element in CC.NET means that whatever tasks are inside it are guaranteed to run before anything else in the build script. For example, here's what the <prebuild> element looks like in our Community Server CC.NET build script:

<prebuild>
  <exec>
    <executable>C:\Program Files\CollabNet Subversion\svn.exe</executable>
    <buildArgs>cleanup</buildArgs>
    <baseDirectory>D:\Builds\CommunityServer\Working\Trunk</baseDirectory>
  </exec>
</prebuild>

Having a <prebuild> element in your CC.NET scripts ensures a smooth build each and every time without the need for ad-hoc manual intervention. And the less manual effort, the better.

---

Tagged as tools , subversion , cc-net , tortoisesvn

Similar Posts

1. TortoiseSVN Global Ignore Pattern vs. svn:ignore
2. Compare Assemblies with BitDiffer
3. Decreasing Developer Ramp Up Time

When using a source control system, there are certain files and folders you normally want to exclude from source control. For instance, on projects developed with Visual Studio, you almost never want to check-in your bin and obj folders, nor should you ever check-in any .user or .suo files.

If you use the TortoiseSVN-Subversion combo, you have a couple ways to exclude files and folders from source control:

1. By setting the svn:ignore property on the relevant files and folders, or
2. By using the Global Ignore Pattern setting in TortoiseSVN

Using the svn:ignore Property

Let's look at the svn:ignore property first because I'm willing to bet that many people set this property without actually realizing it. With TortoiseSVN, it's really easy to exclude an item from Subversion source control by right-clicking on it, going to TortoiseSVN, and selecting "Add to ignore list".

That's simple enough, but you have to do this for each and every file/folder you wish to exclude, which can be tedious. But what's really happening is that TortoiseSVN is setting a svn:ignore property on the parent folder of the item being excluded, which will get committed for that folder on the Subversion server side during your next check-in.

For example, in my main Trunk folder I want to exclude a folder named Temp from source control, so I right-click it, go to TortoiseSVN, and select "Add to ignore list". To see the effect, I right-click on Trunk (the parent folder of Temp), go to TortoiseSVN, select Properties, and see this:

Before I added Temp to the ignore list, this box was empty, and now this change will get committed in Subversion and everyone else on my team will pick up the change the next time they get latest, which may or may not be the desired effect.

Using the TortoiseSVN Global Ignore Pattern

That's all well and good, but like I said, it can be tedious to do that for every item you wish to exclude from source control. Another way to accomplish the same thing is to use the Global Ignore Pattern in your TortoiseSVN settings. To do this, right-click on the root folder of your local repository, go to TortoiseSVN, and select Settings (notice I said Settings, not Properties). This is what you'll see:

It's here that you can enter any item you wish to ignore, and TortoiseSVN will save them in your local settings without ever adding svn:ignore properties to anything.

So if you're using TortoiseSVN, I think utilizing its Global Ignore Pattern setting is a better option than adding svn:ignore properties to every item you wish to exclude from source control.

---

Tagged as tools , tortoisesvn , subversion

Similar Posts

1. TFS Offline Pending Changes in Visual Studio
2. How to Move from Subtext to Graffiti
3. Executing VSTS Unit Tests and Code Coverage from the Command Line

Like with any new technology, getting started with PowerShell was not without a few hiccups. One of the first issues I ran into was how to properly pass script locations to PowerShell so that it could actually run them.

It turns out that PowerShell is a bit finicky in how it locates the script to run. You basically have two options for getting PowerShell to find and run your scripts:

1. Explicitly pass the full path of the script to PowerShell, or
2. Add your script location to the PATH environment variable so that you can just pass the script name

As simple as those sound, there's still a catch: if the path to your script contains a space, PowerShell won't be able to find it and will throw an error, unless you use some special notation. For example, below I'm trying to run a PowerShell script where the path has a space in it:

Enclosing the path in quotes works with your basic cmd.exe, but not in PowerShell. To get this to work in PowerShell, you need to use notation that follows this format:

"& '[full path to script]'"

I told you the notation was special. So now I have this, which will run the script just fine:

And there you have it. You can bet I've filed this one away permanently.

---

Tagged as tools , powershell

Similar Posts

1. Use a Single Web.Config for IIS6 and IIS7
2. How to Move from Subtext to Graffiti
3. TechEd 2005 Recap

ScottW is issuing a challenge to all bloggers this holiday season:

"Find at least one gadget, gizmo, book, toy, etc that you are no longer using, list it on eBay, and donate a percentage of the proceeds to charity."

It's a great idea and I'm definitely in, but surprisingly I don't really have gadgets laying about the house like you'd think. The wife and I are pretty good about getting rid of stuff on eBay and Craigslist every time I buy a shiny new toy, so here's how I'm going to participate: I'm donating all of my Lounge ad network earnings for November and December to our local food bank [1].

And not only that, but after taking with James, he's decided to sweeten the deal by donating his portion of revenue of any blogger in The Lounge who does the same thing. That's pretty cool.

So if you're a blogger, get in on the action. Donating to worthy causes always makes you feel better :-)

[1] I don't make tons of cash from my blog, on average about $25/month, but every little bit helps.

When I took over our builds, one of the things I wanted to provide was a report after every build that showed the changes in assemblies between the current and previous build. This would include things like new or removed interfaces, classes, methods, and properties, as well as changes to method signatures. Well, it didn't take long to find a tool that performed this type of analysis: BitDiffer.

Similar to FxCop, BitDiffer has a standalone client app as well as a command-line executable, making it easy to integrate in a build process. BitDiffer can analyze versions of single assemblies as well as sets of assemblies across different directories. And not only can you check for changes on public types, but BitDiffer can check for changes in private members/types and even implementation differences.

BitDiffer Client

The user interface for the BitDiffer client is simple yet very polished, and done well. Here's a few screenshots of what the BitDiffer client app looks like:

Creating a new comparison set, in this case comparing all assemblies from two different builds.


Results after analysis. Assemblies in gray don't have changes, assemblies in black have non-breaking changes, and assemblies in red have breaking changes.


A breaking change. One of the constructor declarations of the Wiki class has changed.

BitDiffer Command-Line

The BitDiffer client is great for running comparisons ad-hoc, but it can't be automated; that's where the BitDiffer command-line executable comes in. It's name is BitDiffer.Console.exe and contains a number of options:

 

BitDiffer with MSBuild and CruiseControl.NET

With BitDiffer.Console.exe and its options comes the ability to include it as part of a build process, which in our case is performed with CruiseControl.NET. Each of our builds has a CC.NET config script that invokes a MSBuild script, most of which in turn invoke BitDiffer to compare assemblies from the previous build to the current one. For example, here's what the MSBuild script looks like for Community Server:

And here's a breakdown of that script:

• Line 2: We need the math functions from the MSBuild Community Tasks project, so we include that assembly here.
• Lines 5-7: Our CCNetLabel properties are simple incremental build numbers, so we subtract 1 from that to determine the PreviousCCNetLabel property value.
• Lines 10-11: We set the current and previous drop directory locations by using the CCNetLabel and PreviousCCNetLabel properties, respectively.
• Line 12: We're setting the full path to BitDiffer.Console.exe.
• Line 16: We're telling MSBuild to build the entire Community Server solution.
• Lines 18-22: We're telling MSBuild to copy all the assemblies from the CommunityServer.Web\bin directory to the current drop directory.
• Line 24-27: We invoke BitDiffer to perform the assembly comparisons.
  • The %22 is the code for " (double-quote); MSBuild needs it this way to properly surround the strings.
  • Line 25: We want to perform a directory comparison, but only for public types while ignoring implementation changes.
  • Line 26: We want BitDiffer to create an XML report named bitdiffer-results.xml in the CCNetArtifactDirectory, which is defined in the CC.NET config script.
  • Line 27: We're telling BitDiffer to analyze the assemblies from the previous drop directory to the current drop directory.

Once the build is finished, CC.NET adds the contents of the bitdiffer-results.xml file to the build log, at which point an email is sent with the overall results.

BitDiffer XML Report and XSL Stylesheet

Depending on the number of types in your assemblies, the size of the BitDiffer XML report will vary. For instance, for all the assemblies and types in Community Server, our BitDiffer XML report is over 5MB (you can download one of them here; don't worry, zipped it's only 320KB). That's a lot of data to churn through, but lucky for you I spent a lot of time putting together an XSL stylesheet to parse it all (download here). I'm by no means an XSL expert, but I kept the XSL pretty clean and straightforward, so feel free to adjust as necessary.

To use the XSL stylesheet in CC.NET, you need to add it to the appropriate xsl directories and edit dashboard.config (to see it on the web dashboard) and/or ccservice.exe.config (to see it in emails); consult the CC.NET web site for more details.

Here's a screenshot that gives a glimpse of what the report looks like. Note that the "Options" label at the top of the report is hardcoded to say "Public only, no implementation". BitDiffer doesn't put the command-line options used in the XML report, so that was the best I could do. Adjust that for your needs accordingly.

What's the catch?

I love free tools as much as anyone, but BitDiffer is not free. It does provide a 7-day trial, but after that it costs $60 per user or a mere $480 for a full site license. Take that for what you will, but I believe it's a small cost to keep track of changes between different versions of assemblies.

Disclaimer: BitWidgets, maker of BitDiffer, is an advertiser in The Lounge network, for which I am a part of. However, I was not asked to write this post, nor was I given a free license. I just think the tool rocks and thought people should know about it. I also think it's important to note that I got good support from Greg Ennis, the guy who wrote BitDiffer, on a number of questions I had when initially setting up BitDiffer. I told Greg months ago I was going to write this post and finally got around to it.

---

Tagged as tools

Similar Posts

1. NHibernateRepository
2. TechEd 2005 Recap
3. How to Move from Subtext to Graffiti

As part of my current automation work, I've been messing around with PowerShell quite a bit. Before now I've only had cursory exposure to PowerShell, but now that I've actually used it, it's pretty sweet and has really grown on me.

One of the things I'm automating is the building and packaging of the Community Server SDK. Up until now, putting the SDK together has been a mix of scripting and manual copying/pasting, with the last step being a manual effort to zip up the package for download. But I didn't want us to continue doing that, as my goal is to automatically build and package the SDK on our build server every night (and of course off-schedule as needed).

I got the PowerShell script doing all the necessary things, but the last remaining item was the zipping up of the package. After some digging I found that PowerShell can invoke code from .NET libraries. Obviously, this opens a huge door to leverage existing functionality from whatever .NET libraries you need.

In my case, I needed functionality from SharpZipLib, the free .NET library that programmatically builds zip files. After a little more reading and experimentation, I came up with this for the part of the PowerShell script that invokes the SharpZipLib library:

$zipTarget = "D:\Builds\CommunityServerSDK\Drops\" + $sdkFolder + ".zip"
$zipSource = "D:\Builds\CommunityServerSDK\Drops\" + $sdkFolder
$zipLibraryPath = "D:\Downloads\SharpLibZip\net-20\ICSharpCode.SharpZipLib.dll"
[System.Reflection.Assembly]::LoadFrom($zipLibraryPath)
$zip = new-object ICSharpCode.SharpZipLib.Zip.FastZip
$zip.CreateZip($zipTarget, $zipSource, "true", [string]::Empty)

A little explanation:

• The $sdkFolder variable is the name of the SDK folder defined higher up in the script.
• The [System.Reflection.Assembly] line uses the LoadFrom method to load the SharpZipLib assembly into the PowerShell process.
• The new-object command creates a new FastZip class from the SharpZipLib assembly.
• The last line invokes the CreateZip method from the FastZip class, passing in string.Empty as the last parameter.

And there you have it. Nothing complex or earth-shattering, but extremely useful, and now for us, completely automated :-)

Last month I spent a week in Dallas for our in.Telligent conference, which was held at the Westin Galleria hotel. The hotel was pretty nice and was adjoined to the Galleria mall, but for all the shopping that was on-site, what I was most interested in was the big AT&T store across the street. You see, my cell phone contract had expired while I was there and I had my sights set on a shiny new 3G iPhone.

For the past two years I've used the Samsung Blackjack I smartphone, which was a great phone and did what I needed. But over the last couple months the phone seemed to weaken quite a bit and many times struggled to hold calls. I began to research new phones, and the more I read, the more I kept coming back to the iPhone. My decision also became easier because between my brother-in-law and my co-workers, I've seen a lot of the iPhone. So after verifying the AT&T store across the street had plenty of new 3G iPhones in stock, I took a break from the conference and went over to grab one. I chose white (16GB):

Now that I've given myself plenty of time to use it, I can honestly say the iPhone is how phones are supposed to be. There's really not much to complain about, and it's easily the best phone I've ever had. By a landslide. Some other thoughts:

• Love the interface. Simple taps and finger slides is all you need. Brilliant.
• Very sturdy and solid. Size seems just right.
• The App Store is a great idea executed well.
• The electric plug adapter for the USB cable is simple yet genius.
• The on-screen keyboard takes some getting used to.
• Exchange support is smooth, but why allow only 1 ActiveSync account?
• The built-in camera is average. And why no zoom in/out?
• The awareness of apps to automatically change orientation (portrait/landscape) is pretty cool.
• The built-in GPS with Google Maps is sweet and will come in very handy for directions.
• Showing people how to zoom in/out of Google Maps will never get old.
• The Airplane Mode setting is, again, simple yet genius.
• The jury is still out if the iPhone will replace my Zune for all my travel media needs.

After now having the iPhone, it's easy to see why there are so many Apple zealots out there. Apple's approach to design is far ahead of everyone else, yet it makes me wonder why? It's not like Samsung, Motorola, or Sony don't have great designers.

In any case, I'm a happy camper. I don't necessarily regret waiting so long to get an iPhone, but now that I own one, I can't see myself using anything else.

One of the great little utilities I use is RunFast, a free, simple tool that allows you to launch applications using customizable shortcut commands, known as aliases. It's a perfect example of a simple tool that does it's job and does it well.

Once installed, RunFast stays in your system tray, so you can simply hit Ctrl+R and it shows a tiny little window with a single textbox to enter your alias, such as when I want to launch the awesome Paint.NET:

RunFast is completely customizable, as shown here in its Settings window (notice that you can change the RunFast hotkey from Ctrl+R to whatever you like):

Creating and editing aliases is pretty straightforward, with you giving the alias a name and mapping it to the application it should launch:

Like I said, RunFast is a great tool, but I'm sad to say its maker, Idiogen Software, has closed shop, literally. Their web site redirects to a furniture store and they are nowhere to be found. I really don't want to see RunFast just die like that, so I'm making it available for download from here:

Download RunFast

Enjoy.

---

Tagged as tools

Similar Posts

1. How to Move from Subtext to Graffiti
2. NHibernateRepository
3. Taskbar Shuffle

It's only Tuesday but this weekend is fast approaching. Of course, weekends are always a good thing, but even moreso this weekend because of the Raleigh Code Camp.

I fly down Friday evening and will be giving my "Turning the Ship" talk sometime on Saturday (not sure of the exact time as I haven't seen an official schedule, and the times aren't listed on the site). It's been awhile since I've attended a code camp, so I'm looking forward to hanging out with everyone and seeing what kinds of conversations and mayhem I can get myself into.

And speaking of conversations, James is organizing a small open spaces event Sunday morning. The topic is "Managing Complexity in Software" and is limited to 30 people, so get on that list early.

See you then.

---

Tagged as speaking

Similar Posts

1. TechEd 2005 Recap
2. Clarity
3. Every Beginning Has An End (And Tattoos)

It's finally here: Gears of War 2. I picked up my copy at midnight and quickly spent some time playing with Jayme and AngryGamer. My first impressions of multiplayer are:

• The graphics are stunning. The graphics in Gears 1 were awesome as well, but Gears 2 takes it to the next level.
• The party system is vastly improved, and the bump from 8 players to 10 is nice.
• The 3 or 4 maps we played were well done.
• The gold Hammerburst I got for the midnight pickup is a neat touch.
• The Scorcher (flamethrower) will be a much sought-after weapon. Seeing someone's skin melt induces immediate giddiness.
• The targeting for the Hammer of Dawn has been improved.
• The game comes with a code to download 5 maps from Gears 1.
• The Hail map was interesting: it rains razor blades.
• We couldn't hear each other talk a couple of times. Hopefully that was just a hiccup.

We played for about an hour and a half, but tonight it's on like Donkey Kong. Not only will our usual crew be on tonight, but so will lots of Telligenti, and I expect we'll be playing most every night for the next couple of months at least (just like we did for Gears 1). If you want in on some mass pwnage, feel free to add me. Gamertag = Arcware.

One of the big things I've learned with building software is that spikes must be accounted for. The word "spike" is an agile term, but it's certainly not specific to agile-only projects; in non-agile projects, a spike is commonly referred to as a proof-of-concept. Basically, a spike is an investigation into something that cannot be properly estimated. In other words, a spike gives you the ability to say "We don't know how to do that, but we need to figure it out".

Spikes are extremely important in software development but one thing I've noticed is that people/companies tend to "forget" that a spike took place. It's not intentional, but because a spike doesn't immediately contribute to a delivered feature, they are often overlooked. This is usually because they don't account for it in the plan nor give the spike itself an estimate.

For example, let's say you need to get data from some external system. You've heard that there are a couple ways to get data from this external system, but you don't really know how it's going to work within your application. At this point you have one of your developers spend a couple days trying to figure it out so that he can come back with a proper recommendation for how it needs to be done.

The time spent on that problem is a spike, but it was never added to the plan nor given a proper estimate (in this case 2-3 days). This causes your velocity and/or burndown charts to be inaccurate, because it will appear the overall team velocity decreased when in fact it most likely remained the same. Believe me, I've had more than one conversation trying to explain to management why our velocity decreased with the same number of developers working the same number of days/hours per week, all because we forgot to account for a spike.

The point is that you need to account for *every piece of work* in a project, including spikes. This goes a long way towards reflecting accurate metrics with regards to your project plan.

---

Similar Posts

1. Decreasing Developer Ramp Up Time
2. TechEd 2005 Recap
3. Clarity

For awhile now there has been a quiet "movement" among developers with regards to the color scheme they use in their Visual Studio text editor. Specifically, many developers are going away from the out-of-the-box white background to black or some-form-of-dark backgrounds.

For me, I haven't used a white background in a long time; it's too bright for my eyes. The background color I've been using is sort of a soft beige, just enough to take the edge off. I haven't used a dark color scheme yet, mainly because I haven't found one I like and because when I read web sites with dark backgrounds it kills my eyes and I see spots or lines for several minutes afterwards.

But that has now changed. Somehow last night I came across Brad Wilson's dark color scheme and gave it a try. After spending a few minutes with it I realized my eyes had adjusted quite well and I had come to really like it. As I spent more time with it I made quite a few tweaks, such as lightening up the background, using a different color for strings, and changing/softening up some other colors. Using Jeff Atwood's comparative code sample, here's a screenshot of what my color scheme looks like:

The mono-spaced font I've used for years is Lucida Sans Typewriter (size 10), but I've switched to Consolas for the time being (shown above in size 10, but I actually use size 11). You can download these settings by grabbing the .vssettings file and importing them into VS 2008. Don't worry, the .vssettings file only contains fonts and colors, so it won't munge any other custom settings you might have.

If you're interested in seeing other color schemes, check out this post by Scott Hanselman and the IsYourIDEHotOrNot site. Enjoy.

---

Tagged as tools , visual-studio

Similar Posts

1. TechEd 2005 Recap
2. Every Beginning Has An End (And Tattoos)
3. Going Independent

This post is way, way overdue, but it's been sitting in my queue ever since Jim Holmes tagged me *four months ago*, so I figured better late than never :-)

How old were you when you started programming?

I didn't really get into computers and programming until I went to college, so I'm a late bloomer compared to a lot of people.

How did you get started in programming?

"CIS 111: Programming in Pascal". That's how I got started. When I went to Ohio State, my major was Actuarial Science because I was good at math and you could make a lot more money as an actuary than you could as a math teacher. One of the prerequisites for the major was the Pascal course, and the rest is history. It didn't take long for me to realize the logic involved in programming was how my brain worked, and not long after that I switched majors to CIS.

What was your first language?

Like I said, Pascal was the first real language I'd been exposed to, but HTML was my first language outside of school.

What was the first real program you wrote?

Honestly, I don't remember.

What languages have you used since you started programming?

Pascal, Modula-2, C, C++, C#, HTML, Java, JavaScript, ASP, ASP.NET, VB6, VB.NET, SQL.

What was your first professional programming gig?

At Ohio State I had a part-time job in the Math Department for a little organization called The Ohio EMPT Program (wow, that site is still the same as I left it). While there I worked with some smart people who exposed me to many different technologies, the big one being this thing called the World Wide Web. I was instantly fascinated with it and vividly remember using the NCSA Mosaic web browser to read as much info as I could find. That lead me to build the first version of the EMPT site (this is the oldest version on archive), which became my personal playground for trying out new things.

If you knew then what you know now, would you have started programming?

Absolutely.

If there is one thing you learned along the way that you would tell new developers, what would it be?

Constantly learn. Things change so fast in this profession that it's way too easy to get left behind. It's critical to keep your skills as up-to-date as possible.

What's the most fun you've ever had programming?

For the most part, I tend to have fun whenever and wherever I'm programming, but I have to say the most fun I've ever had was about three years ago when I worked on a project with James Avery and Jayme Davis. It was a large consulting gig, with myself and James being the first two people on the project, and even though there was a lot of pressure, we had fun right from the beginning. As we built the team we were fortunate enough to hire people who added to the dynamic, and then Jayme came onboard and kicked it up a notch. We did some good stuff on that project and worked our asses off, but had a lot of fun doing it. Early in the project we moved the team into a large conference room and looking back, that was the smartest thing we did because otherwise we would have been off that project in no time ;-)

---

Similar Posts

1. TechEd 2005 Recap
2. Every Beginning Has An End (And Tattoos)
3. 5 Things

A big topic for us right now as a product team is technical debt, and it's something that has taken on greater importance as we continue to grow. It's natural for software projects and products to incur technical debt, and depending on the situation, it might have even been the right decision at the time. However, if not taken care of, technical debt can get out of control very quickly.

For example, let's say that because of an important deadline, you cut a couple corners to implement an important feature. You didn't really feel good about cutting those corners, but after talking it over with the team, you realized you'd miss the deadline if you tried to implement the feature in the "ideal" way. So even though you weren't overly happy about it, it was the right thing to do, and you have happy customers (and revenue) to prove it.

And like any normal developer you tell yourself, "As soon as this version ships I'll go back and do it right". But that doesn't happen because the next product cycle starts and more features need to be implemented. The market you're in is highly competitive and you've got to keep delivering to minimize the risk of losing valuable business to your competition. So you don't make it back to fix your cut corners, and then a funny thing happens: someone else implements a different feature, sees the way you implemented the previous one where you cut corners, and then they copy that pattern, thus proliferating the technical debt. You can imagine how quickly this adds up over the course of several release cycles.

The challenge in an environment like this is figuring out how to balance the need to address the technical debt while at the same time continuing to deliver new features. It doesn't make good business sense for you to stop all feature work to perform a big refactor job. Afterall, those features *do* work, they work well, customers are happy, and you continue to bring in revenue.

So what is the right balance and how do you manage it? Admittedly, it's a hard problem to solve, especially with regards to anything of significant size and/or complexity. My experience has been to identify one or two people who's responsibilities include keeping a *constant* eye on alleviating technical debt while allowing feature work to continue moving forward. From a hands-on perspective, it's basically on-going refactoring for the life of the product. It's a unique ability to be able to do this, but one that's critical to the overall health of the system.

Balancing technical debt with feature work is extremely important and cannot be overlooked. On one hand you can't simply stop new development and on the other you can't just keep letting the technical debt pile up. Balance is the key and needs to be tailored to the specific situation (product, people, deadline, etc), knowing that each situation will be different. Just make sure that you first acknowledge your technical debt and then you can make a plan to begin addressing it.

---

Similar Posts

1. Decreasing Developer Ramp Up Time
2. TechEd 2005 Recap
3. Going Independent: Insurances

Several of us Telligenti will be in Dallas next week for our in.Telligent conference, and ScottW thought it would be a good idea to organize a geeks-and-beers get together while we're in town. If you're going to in.Telligent or are in the area and want to just hang out, talk tech, and drink some brews, stop on by. Scott's post has all the details.

---

Similar Posts

1. TechEd 2005 Recap
2. MVP Summit Shenanigans
3. Why Don't You Work for Telligent?