Look, I get Microsoft Office Sharepoint Services as a platform.  I get what it is, what it does, and why it's so cool.  Hell, Sleepless in NY was all about MOSS, and it was fun.  But I do need to rant about something.

At Sleepless in NY, Kurt Guenther, in his introductory Sharepoint presentation, characterized MOSS as "Microsoft's Web Platform."  Full stop.  Almost implying that that ASP.NET developers that didn't build on MOSS were an endangered species, that all .NET web development would eventually be done on MOSS.  I don't know if that's what he meant to imply, but that's what I heard.  And I don't buy that.  At least, not when MOSS has such a painful development story right now.

When I'm developing ASP.NET, I make my changes, I do a build, and I debug.  Wash, rinse, repeat.  Once I'm in that rhythm, things progress very quickly.  There's some JIT overhead here and there, but besides that, it's a very smooth process.

When I'm developing on MOSS, however, it's a lot harder.  I make my changes, deploy to my bin folder (or the GAC), sometimes IISReset, wait forever for the whole damn thing to JIT.  And then, when I debug, if I set a breakpoint and leave the code running at a break too long, the entire Sharepoint object model times out or something and turns null, locking up Sharepoint in the process and requiring another IISReset to correct.  What a huge pain in the ass.  And all that's assuming that I'm not dealing with code that requires feature activation or a new site collection to test.  And don't get me started on the cryptic exceptions.  GAH!

So yes, MOSS brings a lot to the table.  Collaboration, search, business intelligence, business forms, workflow, content management, and more.  It's an awesome product.  There's a reason why every headhunter and his brother is looking high and low for MOSS developers right now - they're in high demand.  But until the development story improves, I think I'd prefer to wait before calling myself a MOSS developer.

I've been invited to Infusion's Sleepless in NY training weekend. 

This sounds like a fun little trip, getting to hang out with some geeks, including one of my personal heroes, Carl Franklin.  SharePoint is a good technology, and while I'm not personally overly excited about it compared to other technologies (like Silverlight), this is free training, and it's a great opportunity to network and get my name out there a little. 

And who knows?  Maybe I'll bring home the grand prize, "Insomniac, the developer's machine that never sleeps..."

This is my first post since starting my new job.  I've been a smidge busy, as they threw me in immediately on a high-profile project utilizing Microsoft Office SharePoint Services, and, well, my working knowledge of MOSS was somewhere between zip and zilch.  That's changed significantly over the past few weeks, and while I've been hesitant to call myself a MOSS developer, I'm certainly getting my bearings and starting to kick much ass.

One problem our team has run into several times is source code control.  Pretty much everybody on the team was a SourceSafe user and didn't have any experience with SVN.  I initially balked at this, because, well, SourceSafe sucks.  I advocated SVN every chance I got, particularly when SourceSafe would eat somebody's changes or we fought over file contention. 

As luck would have it, the company is in the process of standardizing on SVN, and, when our VSS repository became obviously too corrupt to be much use, the technical architect on this project caved to my requests and we switched to SVN.

The problem with this is, SVN's Copy-Modify-Merge paradigm can be confusing for developers who are used to Lock-Modify-Unlock.  We've had several occurrences of changes mysteriously disappearing, and, since I'm the de facto SVN expert on the team, it was left to me to reconstruct exactly what happened.  To avoid naming names and pointing fingers, I’ll illustrate with Alice and Bob…

Let’s start with a file.  We’ll call it Text.txt.  Text.txt looks like this:

Alice and Bob both did an update and now have Revision 1 as their working copy.

Alice makes some changes and commits them.  She removes the line “Baz” and adds “42” and “Don’t Panic”.  She commits her changes as Revision 2.

Bob, meanwhile, makes some changes of his own.  Working with Revision 1 as his base, he adds “Quux”

Before committing, Bob does an update and realizes he has conflicts.

Now, what I think happened, is Bob made a mistake while merging, and chose to accept his entire conflict block as the merge output…

Bob then marked his conflicts as resolved and committed this as Revision 3.

The problem with this is that it negates Alice’s changes – She removed “Baz”, and she added “42” and “Don’t Panic”.  The next time Alice did an update, she updated to Revision 3 and the changes she previously made in Revision 2 were missing.  SVN gets blamed, making Cam look bad for being such a vocal SVN supporter, when it was really Bob’s fault.  (The “making Cam look bad” part was a joke.  Smile.)

What Bob should have done was take a good look at the differences between Revision 2 and his working copy…

…and asked himself, “what exactly did I change in my working copy?”  In this case, Bob did one thing and one thing only: He added “Quux”.  So Bob has to assume that any other changes to the file were done for a reason.  Somebody wanted “Baz” removed, and “42” and “Don’t Panic” added.  It’s then incumbent upon Bob to ensure that only his valid changes are included in the merge.  The resulting file could have looked like this:

The moral of the story:

Copy-Modify-Merge (like SVN) is more powerful than Lock-Modify-Unlock (like SourceSafe), but, as Uncle Ben Parker told Peter Parker, “With great power comes great responsibility.”  When you merge and commit, you have some responsibilities to live up to:

Update frequently.

When you merge, be sure you are not removing someone else’s important changes, and that you are only merging in the changes that you made that are relevant. 

When you commit, always read the file list to ensure you are not inadvertently committing changes to a file you did not mean to modify.  Also, it helps to do a diff of each file in the file list to be sure you are only committing code changes you mean to commit.

Good luck!

There's been a lot of chatter lately about the so-called Alpha Geek, and his perceived exodus away from .NET.  This strikes home for me, because I'm an Alpha Geek who is madly in love with .NET as a platform.  I see and understand some of the new "in" languages and platforms for Alpha Geeks (particularly Ruby and Ruby on Rails), but really, I'm just not all that interested right at the moment.  Scott Hanselman talks about the beauty of Ruby, but I see just as much poetic beauty in well-written C#.  And when you consider the great things coming out of Microsoft lately, like WPF, WF, WCF, etc., and the great things coming soon (Orcas, Silverlight, Acropolis, LINQ), .NET is such a compelling platform.

But this whole TestDriven.NET thing has got me concerned.  For the unfamiliar, a major contributor in the open source community is getting leaned on hard by Microsoft for a perceived violation of the Visual C# Express EULA.  Basically, he made an add-in that supports all versions of Visual Studio, including the Express SKUs.  And Microsoft's lawyers claim that distributing add-ins for the Express SKUs is a no-no. 

This is already creating a significant chilling effect throughout the community, and is undoubtedly going to push a lot of people away from .NET too.  It's a shame, too, because the development tools teams in Microsoft clearly get who their strongest supporters are.  Look at all the great ways Microsoft has engaged the developer community:  Codeplex, Channel 9, shared source projects like the ASP.NET Ajax Control Toolkit, supporting Silverlight on multiple platforms, and more to come.  They know that when the Alpha Geek feels engaged and empowered, he will evangelize the platform for them.  But the lawyers don't get that;  And to be completely fair, Microsoft's legal department can't be selective about EULA enforcement, or they lose much of their power in cases of genuine EULA violations. 

It sucks for everyone.  It sucks for the people in Microsoft who are watching their good will in the developer community get pissed away by the soulless lawyers, it sucks for open source developers like Rob Conery and Jamie Cansdale, but most of all, it sucks for the Alpha Geek who can do nothing but stand by and watch the train wreck unfold. 

I stole this from Alan Stevens, but it's fun and surprisingly true.  Here are the results of my Programmer Personality Test...

DHSB

You're a Doer.
You are very quick at getting tasks done. You believe the outcome is the most important part of a task and the faster you can reach that outcome the better. After all, time is money.

You like coding at a High level.
The world is made up of objects and components, you should create your programs in the same way.

You work best in a Solo situation.
The best way to program is by yourself. There's no communication problems, you know every part of the code allowing you to write the best programs possible.

You are a liBeral programmer.
Programming is a complex task and you should use white space and comments as freely as possible to help simplify the task. We're not writing on paper anymore so we can take up as much room as we need.

As anybody who works with me will tell you, I'm a big fan of Corillian.  Our online banking system at Commerce is built on their platform, and much of my life revolves around that platform and its accompanying development tools.  I'm especially a fan of Corillian's Chief Software Architect, Scott Hanselman, but at a recent conference I got to chat with another highly-respected architect at Corillian, Patrick Cauldwell.

Patrick has been working on a project using a security architecture called AzMan.  When he recently had difficulty navigating a technical hurdle, I made a suggestion that Patrick ultimately used as a basis for resolving the issue.

I couldn't be happier that, in some small way, I got to influence the design of a product that I will likely be using every day.  How often does one get to say that?

Thank you for giving me that opportunity, Patrick!

Hey, Jeff Atwood latched onto the same metaphor I did - Cockburn's "rock climbing" metaphor.

I really love this metaphor for all the same reasons as Jeff.  What I'm trying to figure out is if "programming as a game" - e.g., Cockburn's "Crystal" approach, can fit within a pre-existing methodolgy.

Here at Commerce, the overall online banking team, that is, QA, development, and project management, already use a methodology based very loosely on Scrum.  I can't expect QA and project management to embrace anything new, especially since so much work has gone into acceptance of the current methodology.  But can the developers adopt this new methodology and integrate it into the existing one?

I've sometimes marveled at how different the code I write today looks when compared to the code I wrote just a few years ago.  Apparently I'm not alone - Scott Hanselman just posted about rescuing his C#-based TinyOS from the doom of GotDotNet, commenting that he was "shocked and offended" with himself after review the code a few years later.  Man, I know that feeling.  Here's the comment I posted to Scott:

Hey Scott, nice new theme! I apparently missed the rollout of it since I usually read everything via my feed reader.

I have to take the bait on your comment about telling you how our five year old code looks. Five years ago, I would have been at Commerce Bank for a little over a year, and hoo-boy, did I write some embarrassingly bad classic ASP and VB in that era. Those first couple years at Commerce were a crash course for me in a lot of things - web technology, pseudo-OOP (realizing that we're talking about VB 6), COM, enterprise development, etc. Five years later, I can say with confidence that this code is amazingly bad; Especially anything where I tried to use XML for no reason other than because it's what the cool kids were doing at the time. Any of the code I wrote in that timeframe should be treated as hazardous material and properly disposed of. Thankfully, the programmers who maintain that application today have long since replaced most of my offending code - except the nifty little VB app I wrote to bridge our contact center softphones to our ASP-based web app via DDE.

Prior to coming to Commerce, my start was as a subcontractor for an independent consultant who had a thing for XBase languages. When I started as his apprentice at the age of 12, it was Clipper. Then FoxPro 2.6 for Windows. Then Visual FoxPro 3.0, 5.0, and, by the time I graduated from college and went to work for him full time, Visual FoxPro 6.0. If I were to look around my home office today, I could probably find some code left over from that bygone era, but that begs the question: Why on Earth would I want to? :)

Somehow, I've failed to add Jeff Atwood to my blogroll before today.  That seems odd to me, since I'm a huge Scott Hanselman fan, and Scott gives mad props to Jeff all the time, jokingly referring to him as his Nemesis.  (Side note:  I don't know that Nemesis is the mythological character I would choose, Scott.  I think him being Pollux to your Castor is more appropriate, but I digress...)

So I added Jeff to my blogroll today, and the very first post to come across my reader is a discussion on Alistair Cockburn's "Software Development as a Cooperative Game" presentation.  This is not light reading, but it is fascinating.

The basic premise is that software development can be viewed as an ongoing, cooperative game, not unlike rock climbing.  Other than the obvious implications of making your work more meaningful than "I do this to get paid," I think this model provides a lot of value, not just in making your own career more rewarding, but also in building a team that can trust each other and build on each others' strengths and weaknesses.

As we've worked to build our online banking development team at Commerce, we've struggled a bit with team dynamics.  Basically, what it comes down to is, as I assert my role as a technical lead, I sometimes have a tendency to be an impatient condescending jerk.  Having identified that as my weakness, and applying the "rock climbing" metaphor, it should be easier for me to understand and curb that behavior.  We can't all climb rock walls at the same speed, or using the same tools, or over the same paths.  Condescending to someone isn't going to help them traverse the wall any quicker;  It's just going to make them want to throw me off the cliff.

I just read on DotNetKicks that apparently Visual Studio 2003 is not going to be officially supported in Vista.  Allow me to say: Double-ewe.  Tee.  Eff.

I'm floored by this.  Supposedly, though, it will only break debugging in VS2K3, since the security model has been reworked significantly.  Note to self:  Install VS2K3 on my Vista box and try to break it.

If this is true, I suppose one could develop in VS2K5 and compile the MSIL in .NET 1.1 with MSBee.

While importing a Virtual PC image into our enterprise VMWare server, the process kept bombing out with sysimage.fault.ReconfigFault.  I Googled high and low, and didn't get any hits on sysimage.fault.ReconfigFault (or anything that appeared to be related).  I decided to try to convert the VPC to a VMWare Workstation image so I could try playing it in VMWare Player, and I got the same results.  I was resigned to giving up.

Then I noticed that VMWare Player included Microsoft VPC in its list of compatible images.  On a lark, I loaded my VPC image in VMWare Player, and it started a short conversion process.   Sure enough, it bombed out with "A required archive (driver.cab) could not be found in the source OS."  Hmmm.  Something else to Google.  Thankfully, this new Google search was a bit more fruitful in its results.  This guy's solution fixed the problem in VMWare Importer as well as VMWare Player.

I'm totally surprised nobody else has run into this.

Update 3/18/2007:

So it looks like this is the #1 hit on Google for resolving this issue.  That's pretty cool.  So I decided that, just in case the above link breaks, I'd grab the pertinent part out of the above link (in case that site ever disappears).

1. Find another computer running the same operating system and service packs.
2. Copy the "%windir%\Driver Cache" directory into the same location on the VPC image.
3. Shut down the VPC.

That's it!

Hey, if this helps anyone, please take a second to drop me an email or leave a comment here.  I'd love to hear from you.

After 9 hours of arguing with Visual Studio 2003, I'm tired, frustrated, but triumphant.

I have no freakin clue what went wrong, but the end result was every time I tried to build my Web Deployment project, it bombed out with "Unable to build folder CBI".  Turns out that there are multiple folders spread out throughout the project tree named "CBI".  And VS2K3 doesn't like that when it's building an MSI.  If I went through the web project and renamed all those CBI folders, it worked fine.

The really weird part was that the project built fine on my workstation, but not on my build server.

Long story short, I uninstalled and reinstalled all my project dependencies on the build server, did a rain dance, and built the code on the c: drive instead of the d: drive (since that's where the original developer built his project).  Voila...  it works.

9 freakin hours.

It's not unusual for my coworkers to come to me seeking my help with .NET, HTML, JavaScript, or just about any other geek topic.  What isn't so obvious to them is that more than half of the time, I don't know the answer to their questions.  My black belt in Google-Fu is what enables me to quickly help them.   Case in point:  Easily 2/3 of all my Google searches start with "site:msdn.microsoft.com." 

I cannot over-emphasize this point:  If you want to be an effective developer, learn Google.  To get you started on learning the advanced features, check out Google Guide.  When you're ready to put your skills to the test, try Gwigle.

I got a chance to sit down and chat with Scott Hanselman for 20 minutes or so while I was in Portland.  Scott was a totally gracious host, and took an opportunity to introduce me to another tool that he raves about (and I never tried), PowerShell.  For the uninitiated, PowerShell is a command line and scripting environment.  Think cmd.exe, but with first-class support for the .NET framework class library, XML, WMI, and much, much more.  After Scott demoed it for me, I went back to my hotel and played with the shell for a few hours.  Although my need for it has been limited, I'm madly in love with PowerShell.  This is powerful stuff.

I can't say anything about PowerShell that hasn't been said already, so do yourself a favor and check it out.  While you're at it, check out some of the info on Scott's blog, his podcast on the subject, and his recent post about the PowerShell IDE.

We have an internal web application at Commerce that makes extensive use of ActiveX controls.  The application is used primarily by our financial service reps and contact center operators.  Thanks to the Eolas judgment, the application in question was still mostly functional, but required users to manually click on the ActiveX controls before they could interact with them.  Not only were the programmers who maintain the application concerned that their non-technical users would be confused by the "Click here to activate this control" message, but this behavior actually broke a control we use to push client-side updates.  Our programmers took Microsoft's recommeded steps to correct the issue.

The problem is, Microsoft's solution didn't work on about half the machines we tried it on. After a while, we determined that the problem machines were all laptops, so we immediately suspected a difference in the images our desktop team uses on our workstation PCs versus our laptops.  After running through all the usual suspects, like OS patches, our laptop security software, IE build number, etc., we were at a loss and opened a ticket with MSDN developer support.

After a week's worth of research on the Microsoft side, the support analyst suggested I compare version numbers on jscript.dll.  Sure enough, the version on the laptops is outdated.  We downloaded the installer for the most recent version, and all is good again.

Holy cow, it's been a month since my last post.  Funny how time flies when you're boning up for MCP exams, huh?  On that note, I've completed two MCPs, I'm almost ready for a third (making me an MCAD) and then I'll be two tests from MCSD.  I'm hoping to have my MCSD by the end of April, at which time I'll start working on my upgrade exams to become an MCPD in Enterprise Applications.  Good times!

So Scott Hanselman posted again on something near and dear to my heart, Outlook Inbox organization.  He's apparently a big advocate of the Getting Things Done method, making use of a concept called Zero Email Bounce.  I freely admit, I don't know much about Getting Things Done, never having read it, but it sounds too focused to be something I'd make work.  I revel in a certain degree of chaos.  As I commented on Scott's blog, I actually drew some inspriration from Gmail in my Outlook Inbox handling routine.

As each message comes in, I make a decision: Action item or not an action item. If it's an action item, it (and its ensuing conversation thread, since I sort my Inbox by conversation rather than date) stays in the Inbox until complete.

If it is not an action item, then I have another decision to make: Is the message signal or noise? If it's noise, and of no possible future value, it gets deleted. If it's signal, then it gets moved into an "Archive" folder in my Exchange message store. I wrote an Outlook macro and assigned it to a toolbar button so I can archive the message with one click (again, ala Gmail). As action items are completed, they are assumed to be non-action signal items, and are archived.

Our organization has a ridiculously tight 85 MB mailbox limit, so I've got my auto-archive settings for the "Archive" folder set at a relatively short two weeks. If there is a "signal" item that I need to stay in my Exchange message store (so it's easily available on both my laptop in offline mode as well as my desktop), I drag it to a "Do Not Archive" folder until it can be moved to "Archive." An example of this is travel itineraries.

To keep my auto-archive file from consuming too much space on my tiny 40 GB workstation hard drive, I have it set to auto-delete after a year. I figure that's enough time for most items to lose relevance, and a year's worth of messages only consumes about 1.5 GB.

To find items, I use Windows Desktop Search (MSN Toolbar and Desktop Search without the toolbar). I really prefer Google Desktop, but it had trouble with my short auto-archive window, often expecting an item to be in my inbox when it was, in fact, in the auto-archive PST. Windows Desktop seems to handle that better.

Say I've got a base class Foo.

public class Foo
{
    public Foo()
    {
       Console.WriteLine("Foo Constructor");
    }
}

Now say I've got a derived class Bar.

public class Bar : Foo
{
    public Bar()
    {
       Console.WriteLine("Bar Constructor");
    }
}

When you instantiate Bar, you'll get the following in your console output:

Foo Constructor
Bar Constructor

That's fine.  That's the expected behavior.  But what if I want to completely override or ignore the constructor for Foo?  The compiler doesn't like it when you declare a constructor virtual, and even if I could, I don't think there's a syntax for overriding it.  It seems that I have to take the base class constructor method whether I want it or not.

Am I missing something here?