If you've been wondering why I haven't posted lately, it's not because I've been lazy (at least not overly).

I've recently been hired by Microsoft and have been drinking from the infamous "Firehose".

I've also had the opportunity to host my blog on the MSDN site, which is where you'll be able to find the new content for me - http://blogs.msdn.com/agileer.

 

The current application that I'm working on is pretty configuration-heavy.  There's even configuration to drive the configuration.  There's configuration that drives the UI that drives the configuration.

Even so, when the product owner recently said, "I think we need to move some of this out of configuration and just hard-code it."  Well... let's just say that I didn't agree.  I do now.

I recently added a whole lot of flexibility by providing a "plug-in" configuration chooser enabled by... you guessed it - more configuration.  We then deployed the application last week and my app worked nicely.

However, another application that consumes my code did not fair so well.  It failed each time it was called because of the additional configuration.  Yes, it was a "communication" gaff on my part, but it could have been avoided since we didn't really NEED extra configuration to achieve the plug-in capability.  I could have just hard coded something to the affect of - in MODE1 do X, and in MODE2 do Y.  That way we could have executed just fine in production without failure.

Ayende has similar feelings here.

 

xDD (TDD, BDD, DDD, etc.) emphasizes the standard "Red, Green, Refactor" mantra in order to prevent the buildup of technical debt.  However, without the addition of Integration testing, or user-acceptance testing, and then committing the code to source control, you're only partway there.  I'm not saying that cycle should execute all five every time (RGRIC, RGRIC, RGRIC), but it should definitely happen when a feature/story has been completed at the very least (perhaps RGR1, RGR2, ...RGRn, IC).  Don't forget that Integrate & Commit or you will end up with some very heavy technical debt rather quickly.

I'm writing this down in order to remind myself.  I've also placed it in my desktop background via BgInfo.

 

One of the great things about ALT.NET is the variety of choices it affords.  However, this can also become an albatross around your neck when trying to choose a particular unit testing framework, mocking framework, IoC container, etc.  I mean, if you haven't tried most if not all of the choices, then you don't know what you're missing.  Of course you can read about the different options out there, but that's no substitute for trying them out for yourself.  Having said that, there's still a lot of utility in reading about them to exploit them to your advantage.  Thus, I recently moved out of my normal comfort-zone, (NUnit, Rhino.Mocks, Windsor Container) and tried some other technologies. 

What follows is a short description of my impression of a couple of Unit Testing frameworks that I've played with in the past couple of weeks.  Note that this is not intended to be an complete portrayal of each tool, but rather how I felt when attempting to use them.

NUnit

This is the old standby, but there's a 2.5 alpha that I hadn't tried.  I liked a lot of the changes that have gone into it, but found that too many things that I depend on for integrating with NUnit don't work with 2.5 yet.

XUnit

I like XUnit.  It's simple.  ALT.NET takes a bad rap for being hard to adopt, so one thing I try to emphasize is simplicity.  This is XUnit's strength.  If I were starting someone off in Unit Testing, I'd tell them to look at XUnit.  I have to admit that I do like the Constraint model in NUnit, however.  It just reads more naturally.  Also, pretty much everything works with NUnit, but not necessarily with XUnit (like TeamCity, currently).  So eventually, I went back to NUnit 2.4.8.  It worked fine with TestDriven.NET, however.

So the moral of the story is that software (including OSS) has momentum.  Once you get used to a certain way of development, it feels painful to switch, even if the other applications have some nice new features.

Conspicuously missing here is MbUnit, which I've tried in the past but again went back to NUnit eventually.  I'll have to try it out again soon.

 

The type name that you need to use in config files, such as for IoC containers, can be quite complex. For me, it's easier just to spike them than to try to remember the format gobbledy-gook.

public class GenericsTypeSpikes
{
    [Fact]
    public void The_name_of_a_complex_type_can_be_found_in_Type_AssemblyQualifiedName()
    {
        Type t = typeof(IList<ISource>);

        Assert.Equal("System.Collections.Generic.IList`1[[Blah.Core.ISource, Blah.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]], mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089", t.AssemblyQualifiedName);
    }
}

 

The first time I heard of NDepend was on Hanselminutes (show here).  It sounded intriguing, but at the same time the show went into a lot of detail and used a lot of terminology that I wasn't familiar with, even with a computer science degree.  So it was with a little trepidation that I downloaded a copy and ran it against an application that I was working on at the time. 

To be honest, a bit of information overload was involved.  I could see that NDepend had gathered a lot of statistics regarding the code base, but I had no idea how to use it.  I didn't look at NDepend again for a few months.

The next time I saw NDepend was when I was looking at CI-Factory last year.  It was included as one of the tools in the continuous integration mix.  Same experience - information overload.

Just last week or so I took one more look at NDepend to see if it could help out with the code base I had inherited at work.  I had many places that needed refactoring, but it was hard to tell where to start.  My initial (3-minutes) reaction was the same - too much information after the analysis was complete.  I didn't know where to start.  But this time I stuck it out for more than 5 minutes - and that was all it took for me to fall in love (this time) with NDepend.  NDepend is largely based on "CQL" (Code Query Language), that sorta-kinda looks like SQL, but goes against code instead of a database (hmm... "LINQ to code" can't be very far off).  NDepend has several canned CQL statements that it runs as part of the analysis to help identify coding faux-pas, and the first query, with the description of "Quick summary of methods to refactor" was a treasure-trove of bad juju.  It identified methods that were too big, too complex, too... just about anything that can be quickly called out, and it picked the worst offenders to show.

NDepend showed me where the worst code was first.  That's what I got for sticking it out this time.  Now there are many, many more features that I have hardly scratched the surface of, and I hope to be able to cover those in later blog posts.  For now, just try out http://www.ndepend.com and check out your own FBI-most-wanted list.

 

Look at the following piece of code:

private void DbMove(CopyInfo info)
{
    string targetDb = GetTargetDB(info);
    if (targetDb.Equals(string.Empty))
        return;

    PrepDbsForCopy(info.SourceDb, targetDb);

    GetAllData(info);
    if (IsNoSourceData())
        return;

    int upperBound = GetUpperBound();
    int rangeCount = GetRange();

    if (CopyNotCurrentlyPossible(_isDisconnected, _isHomogenous))
        return;

    DoAsyncDbCopy(info, upperBound, rangeCount, _isDisconnected, _isHomogenous);
}

Now this is a standard piece of code with several "short-circuit" returns in the code.  Short-circuiting is good, but usually only if it appears as the first instruction in the method, and only once.  Otherwise, refactoring the code (as above) is a bear.  Select a section of text to pull out (extract method), and if it contains a "return" or break, or anything like that, then you'll most likely get a complaint from your refactoring tool.  ReSharper 4 complains "Extracted block has exits to different points Proceed with refactoring?(sic)".  Besides the pain from lack of proper punctuation (just a typo, I'm sure), the pain of not being able to refactor when you want to is even worse.

However, you can refactor if you do some manual refactoring (and this is still easier than manually extracting the method).  Instead of:

    string targetDb = GetTargetDB(info);
    if (targetDb.Equals(string.Empty))
        return;

    ...

 

Try the following:

    string targetDb = GetTargetDB(info);
    if (targetDb.Equals(string.Empty))
        return;
    else
    {
        ...
    }

Then you can start using your refactoring tools like "Invert If"

    string targetDb = GetTargetDB(info);
    if (!targetDb.Equals(string.Empty))
    {
        ...
    }
    else
        return;

And "voila," your else can be tossed as cruft.  Do so with the other "if"s and yes, you have more indented blocks of code, but indented blocks of code can be easily refactored with "Extract Method."
 

Active Directory is funny.

Or should I say "permissions in Active Directory are funny."

I find that whenever I'm "stuck" on a problem for a good chunk of the day (AD or not) , about 80% of the time it's a permissions issue.  A couple of days ago I was stuck on an issue that I knew was a permissions issue, but I couldn't figure out why.  I mean, here I was, supposedly something of an development expert in directory services, but I couldn't get my DirectoryServices code to delete a simple AD object.  I could create objects, but I couldn't delete them.

Now, at this particular client they've tightened down the screws in their environment substantially, so simply increasing my permissions willy-nilly was out of the question.  No domain admin privileges here.  I'm not even sure any of the developers on this project even use Active Directory Users & Computers, they seem to only use home-grown LDAP tools for examining AD.  They are able to delete items with one particular home-grown tool, but it was written in VB - in all it's COM, late-binding, who-knows-what's-really-lurking-under-this-IUnknown-interface glory.

Has anyone ever tried to peer into the ObjectSecurity class?  It's not for the faint of heart.  And it wasn't something that I was going to be able to decipher in an afternoon.  So I downloaded the old Windows 2003 admin pack, installed it on my XP development box, and went into all the gory details that are AD ACLs.

The question was, why could the old VB code delete the object when my DirectoryServices code not do it?  According to AD Users & Computers, the credentials I was using did not have "delete" permission on the object.  I knew that.  That's what "access denied" usually means.  How could I explain this to the fellow who was successfully deleting with the VB code and expected me to do the same?  DirectoryEntry.DeleteTree() simply would not work. 

However, upon further examination, I could see that the OU that I was dealing with did allow my credentials to create and delete child objects.  Hmm...  One more quick test confirmed it.  Although DirectoryEntry.DeleteTree() failed, with the OU I could do DirectoryEntry.Children.Remove(objectInQuestion).  That's just crazy.  Boggles the mind.  But it works.

Of course, if the AD admins want to save another developer further grief (and there's no reason to believe they would - I know some sadistic infrastructure folks), then they'll just add the delete permission and avoid further confusion.

 

I heard recently on Hanselminutes (115, I think) something to the effect of "Alt.NET has a lot to contribute, but the barrier to entry is pretty high." I know that didn't necessarily mean "agile" in particular, but perhaps that was actually the intent.

Is it hard to "do agile"? I'm sure there would be plenty of voices on both sides, but I think there could be more effort put into making it easier or at least better explained. Sure all the "sexy" agile info is out there on the cutting edge, but there are plenty of folks who still need the basics. 

My own knowledge of agile principles & practices came over a long period of time. I didn't have the advantage of having a coach. In fact, I remember reading something on MSDN around the 2000-2002 timeframe in which Anders Hejlsberg was writing about good coding practices, and in particular he mentioned how he used NUnit for his unit tests.

Unit tests? I thought that was like, run the application.  If it doesn't blow up it was a successful unit-test; one scant step beyond compiling. So I didn't learn agile overnight.  Even now I continually tweak my practices in an effort to learn the best way to develop the agile way.  I'll probably continue to do that as long as I write code.

After thinking about my own experience, I believe that testing is probably the best way to introduce folks to agile concepts. I mean, if it worked for me without a coach (and for the longest time without blogs or many other agile resources), then perhaps testing is a great wedge for breaking folks thought processes into the agile arena.

So start testing.

 

It's incredible how fast things can change if you turn off your developer technology radar for a few months.  I was pretty comfortable with my knowledge of what was out there around fall of '07.  I'd explored pretty much all the different tools and technologies that had tickled my fancy and even though I wasn't an expert in all of them, I knew that I could pick any one of them up pretty quickly if need be.  So down went my radar for awhile.

Holy cow.

Apparently not everyone has been as idle as I have been.  Here is a list that I compiled in a single afternoon of some things (I'm sure there are plenty more) that I'd like to try out in the not-too-distant-future to see if they can assist me in my daily chores.  What follows is not anything near a full review (basically I've pretty much only heard of them at this point), so my descriptions of what they are may be WAY off:

Gallio	Unit testing framework agnostic unit test runner
Git	Successor to Subversion???
Team City	Continuous Integration competitor to CruiseControl.Net from the makers of ReSharper.  And, yes, it's free.
XUnit	The "opinionated" unit testing framework
Pex	Continuous testing
Spec#	C# with built-in specifications - gives the user of a framework a better idea about how a class/method will behave.
ASP.NET 3.5 Dynamic Data	Automatic CRUD that may actually work beyond simple scenarios

How about you?  What kind of technologies have you excited right now?

 

Let's face it, not everyone has automated unit tests for their code.  You may, however, have inherited some code and are responsible for making changes to that code or for creating additional functionality.  How do you handle such a situation?

The best way is to find places in the code into which you can place a pry-bar (not a technical term) and wedge a couple of components apart.  This is the best way, but it's also messy. 

Pry-Bar Method

I believe this comes from Working Effectively with Legacy Code (Robert C. Martin Series), by Michael Feathers, though I haven't read the book personally (I need to get myself a copy).  But I do understand the concept.

Let's say that you have a class Engine, which contains a class Carburetor.  Let's also say that you have to modify some functionality of Engine.  What you need to do is isolate Engine so that it can be tested all by itself.  We don't care about the Carburetor class at this time - it's to be tested elsewhere (eventually).  Here are the appropriate steps to "pry away" Engine's dependency on the Carburetor class:

1. If it doesn't already exist, create an interface for Carburetor's functionality, ICarburetor, such that ICarburetor contains at least all the methods/properties that are called by the Engine class.  Refactoring tools like JetBrains ReSharper make this very easy.
2. Modify Engine's constructor so that it accepts an ICarburetor parameter and set a private reference to an ICarburetor object(there are variations on this theme, but this is my favorite).
3. In your test, create a mock object of the ICarburetor type, either "manually" or by using a mock framework like Rhino Mocks.
4. Set up any expectations of the mock object if required (that's a future post, or just Google Rhino Mocks).
5. Pass your ICarburetor mock object into your Engine constructor.
6. Do your test on Engine.
7. Confirm your expected state (and/or interactions with the mock object)

I hear what you're saying, "That's an awful lot of work for testing some code that's not been tested before!"  Yep.  However, if you ever intend to get the whole system under proper testing, then you've got to do it that way.  What makes it more painful is when you don't have only one "dependency" (ICarburetor) but perhaps dozens (Carburetor, shocks, exhaust, fuel tank, oil, transmission, etc.).  Whew!!!

Sometimes you may only be responsible for making a change to code ASAP and then go away.  In this case, you're not likely to lose sleep over the fact that someone has written some untested code (gasp!).  All you're responsible for is a small tweak.  What do you do in this situation?

Lazy Method (perhaps too lazy)

For some reason, I find myself in this situation more often than not, perhaps since as consultants we're not often called in after the fact for long-term code maintenance.  You certainly could use the Pry-Bar method above, but it may involve creating a lot of "interface noise" (at least the client sees it that way) when all the client wanted was the web-page widget to appear blue instead of red (ok, that's a little extreme, but you get my point).  So what do we do?  In this case, I'll sometimes resort to the "lazy" method.  In this case, I really do mean lazy.  In agile terminology, being lazy is not always a bad thing.  However, in this case "lazy" may not be such a good thing, but hey - you do what you can to make people happy.

So here you simply create a class (these classes tend to "want to be" singletons, but don't have to be) that take data from the "untested" code and return data to the untested code (or don't in the case of "void").  You can test the "lazy class" all you want this way.  Again, not the best way, but perhaps the quickest for short-fuse work.

Whichever option you choose, it's better than not testing your code at all, which is probably why they called you in for help in the first place.

 

It's amazing.  The battle for agility is far from won.  Folks are still not writing unit tests.  Some folks don't even know what unit tests are, or have a badly mangled definition of them.  I'm not only finding this as a consultant at client sites, but among some of my own colleagues as well.  A developer asked me last week, "What is this agile thing?"  I seriously thought that by now people would have at least a basic understanding of what it is.  But alas, it not currently so.  This isn't to castigate anyone.  I'm more than happy to help folks out with "this agile thing".

So what is Agile?  I point you towards the Agile Software Development Manifesto, and some further explanation, and the "original wiki" houses a great deal of info on agile.  There is much info from people more eloquent than I.  Those who don't know what "agile" is usually know what "Google" is.  Use your search engine of choice and explore.  But back to testing...

Test your doggone code, people!

Why? Because I like to sleep at night.  That means that not only do I have to test my own code, but if I depend on your code, you better be testing yours.  What?  I don't take your word that you've done an excellent job as a developer?  Frankly, no.  I don't trust me, and IMHO I consider myself somewhat more than competent as a developer.  Therefore, if I don't trust myself, why in the world should I trust you?  I read somewhere (I think it was in Ron Jeffries' book, Extreme Programming Adventures in C#) that without testing, the average developer could only write about five lines of code before introducing a bug.  My own folly has born this out in the past.

So if you don't test your code and I'm left to work with it, then I have to find the seams within your code and crack it open to wedge in support for testing, as found in Working Effectively with Legacy Code, by Michael Feathers.

It's all about confidence

Before I embraced the agile lifestyle, I never really knew if my code was doing what I thought it was supposed to do.  I hoped and prayed that it would.  And really, at that point, prayer was my only option, because I didn't know whether the testers (when we had them) were doing an adequate job.  What did we do when we didn't have testers? Well, testing turned out to be the weeks and months after going live on a production environment - not the best time to do your initial testing.  Demos and integration testing were high stress times for me.  I didn't even want to be around when they happened.  I don't enjoy getting yelled at (or looked down upon as incompetent) any more than the next person.

So I took the time to learn about unit testing.  NUnit was the only thing available to me as a .NET developer at the time and it seemed to work well.  Over the years I started with writing unit test - bad unit tests to be sure, but tests nonetheless.  I recently had someone tell me that the code that they had written was too difficult to test and thus it was better to not have any tests at all.  I fail to see the logic in that (besides the fact that there are really very few situations that cannot be adequately unit tested if designed correctly in the first place).  Bad unit tests are SOOOOO.... much better than no unit tests.  Even if your unit tests are brittle and return false-positive results, at the very least you are thinking further about how your code will be utilized.  It could be argued that you can have a false sense of security with badly written tests, and while that my be true, what, if not a false sense of security, is someone operating under when they have NO tests?

Now, with proper testing in place, I have no problem ripping out huge sections of code and replacing them when requirements change.  Why?  With the press of a key I can run all my tests and confirm that yes, all is well.  That for which I am responsible... just works.

In my organization we're going to start trying to bring all the developers up a notch or two.  If you write tests then that's the beginning - the very beginning.  There is so much more to understand about improving the quality of code.  But testing is the very first thing.  If you're not testing your own code - just stop.  Turn around, and take some responsibility for quality without cowering behind some large object when your code goes live to the public.

 

I remember a cartoon I saw in the early 90's regarding the way that software projects were sometimes run.  The punch line was, "You guys start coding, I'll go find out what they want." 

The industry's answer to that was the onset of "Big Requirements Up Front" - (BRUF).  Waterfall.  RUP.  UML full-trip code generation/regeneration - and like most things, it was something of a pendulum swing - reacting to the cowboy coders with a methodology that prevented writing any code that was not useful.  Get all those requirements up front - they'll never change.  Implied in the "They'll never change" was that any analyst worth their salt would make sure that you're asking the right questions, then requirements never change.  Requirements only change when you've gotten the wrong requirements.

But requirements do change, even if you've done a good job up front.  No one has all the info.  Decision makers don't always have the right info.  Things change.  And in RUP - if you were doing it "right" you had oodles of documents to modify if requirements ever "changed."  Not to mention the fact that you're most likely going to hit your client up for more money - they always love to hear that.  Change requests anyone?

In reaction to that, agile & XP arose.  Power to the Programmers!  But there are those who have taken that pendulum swing back too far as well.  We don't need no stinking Architects!  The problem with this approach is that you ignore resources that are already available here, sometimes called the "Not Invented Here" syndrome.  I confess that I've been guilty of this.  I love to code.  I'd rather be coding than analyzing any day.  It's not fair to the customer, however, to ignore the groundwork that other's have done in order to get my coding fix.  A few months ago a client had a project where they wanted to provision all accounts from a single request "front end."  I automatically thought "new web site," and for a long time ignored the fact that they already had a MOSS site available internally.  These account requests fit fine within the paradigm of a SharePoint list.  I almost went with a custom web site in spite of that, but in the end, I could not justify the fact that I'd spend a lot more on this custom web site than I would with MOSS.  In the end, I did get to do a good bit of coding, since we had to implement a custom MIIS extensible management agent to get into and out of MOSS.  I did end up getting my coding fix.

So the moral of the story is - don't assume that you're going to do it better than anyone else who's already done the same.  If you have the opportunity to exploit the collateral of others, do so where it makes sense.

 

Note: There is tech content in here, I promise!

I really suck at math.  Some may think that's odd for a "computer guy," but it's true.  But perhaps it's because of this suckiness that keeps me coming back to it - the challenge of it.  In college, I didn't have a problem with computer science classes (well, except for numerical analysis - math) since I tend to have a pretty linear/logical thought process (or so I wish to believe, perhaps).  I knew in 6th grade (around 1977) what I wanted to do - computer programming.  The fact that I've stuck with it for so long is unusual, given the number of friends that changed their majors, multiple times, during just the four years of college.  Probably only 25% of those people are doing anything even remotely close to what their degree was in.  Again, I'm the unusual one. So I've been the "logical" one, the steady one, for quite awhile. 

Surprise, surprise - I was in the middle school and high-school chess clubs (in addition to football, basketball, track & field, so don't start stereotyping me, thank you very much).  My dad, a West Virginia coal miner at the time, taught me how to play chess when I was in elementary school.  He says he doesn't remember, but it's true.  My best friend in middle school & high-school, and he was my best man as well, was also on those chess teams - another "logical guy," whom we thought of as our own Bobby Fischer.  I went to a several tournaments, but in high-school I caved under pressure, and quit competing in tournaments.  I don't remember my USCF rating, that was almost 30 years ago.  I won some and I lost some.  I've continued to play throughout the years, and have taught my kids how to play (no Bobby Fischers here, so far).  Bottom line - chess is fun and challenging. So chess is about the only traditional board game I ever "got into." 

I have another confession: I like to watch anime with my kids (heck, I like to watch it alone, too.  There, I said it).  I tend towards the Shonen variety, even though I have mostly daughters - Sailor Moon gives me the heebee-geebees.  So about a month ago I started watching one called "Hikaru No Go" (Hikaru's Go - see Wikipedia).  The plot was pretty clear after a couple of episodes.  The story centers around a kid (Hikaru) and his entrance into the world of "GO", an ancient Asian board game. 

Now, I may have heard of Go before, but if so, I don't remember.  I get the same reaction from all my American family & friends - "What's Go?"  In China, Korea & Japan Go is "the bomb."  They follow it the way Russians follow the chess world, which is WAY more than Americans do (see Searching for Bobby Fischer: The Father of a Prodigy Observes the World of Chess).

I was unprepared for how interesting Hikaru No Go would be.  Perhaps it was my ties to traditional board games, but I was really sucked into the story line.  It was also refreshing that it's neither dark nor was their a true "bad guy" in the traditional sense.  It still has the same basic motivation that many Shonen storylines have, which is "try your best and get better and better at what you do."

About halfway through the series, I actually started to get interested in the game itself.  I thought, "Hey, if it's that popular in east Asia, maybe there's something to it.  I saw a few decent introductions online, but I really wanted a book.  I found the ONLY book on Go available in the town of Winchester, VA - Teach Yourself Go.  Now that I've bought that copy, there are no more books on Go available in Winchester - I've looked.  The book is very dense.  You CAN learn Go from it, but it's like learning math from the textbook alone - heaven help you if you miss a concept.

One thing that this book attempts to explain is why there aren't very many computerized Go "engines," and why the existing ones aren't very strong.  The author believes that it's much more difficult to build a Go engine than, say, a chess engine, which now can pretty much beat any world champion.  There aren't any Go programs that can even beat strong club-level players, much less pro Go players (and yes, there are professional Go players). 

Seriously?  No one can write a strong Go engine?  I thought that was hard to believe - until I started to play go.  I'm the one reading the book.  I've taught my children just the rules - and they beat the living daylights out of me.  Not just once in awhile, but about 80% of the time!  There is no randomness involved, no dice or anything.  I thought that I just didn't know enough (and I don't) and that a little more studying would help.  So I went to this section that tries to explain how to capture stones.  Again, this book is a dense, textbook style rather than conversational (which I prefer any day of the week), and I played through the examples, and see this concept of a "net" on the edge of the board.  I see it WORKING, but I can't say WHY it works.  It's almost anti-logical!  I was up at midnight last night raving like a lunatic about how I couldn't see WHY this "net" thing would work (my wife and oldest daughter can confirm that I was on the edge of lunacy).

So I'm only about 1/8 of the way through Teach Yourself Go and already I see a concept that I have NO IDEA how you would code, since why it works is beyond me.  My wife and oldest daughter tell me that I don't need to know why it works, only that it does.  That is NOT good enough for me.  It seems like there should be an easy explanation, but I don't see it.  Not that it couldn't be done EVER, but I have a feeling that you'd have to be a 9-dan Go pro AND a sharp software developer in order to write a strong Go engine.  I have a feeling that I know how many of those are around - none.

That doesn't mean that I'm not going to try, of course.  It looks like the perfect opportunity to get into Silverlight or WPF.

It's this question of "Why does this work!?!?!?" that is both driving me crazy and fueled my desire to learn this game, as well as some of the "science" involved here.  I'm looking forward to an off-site long-term project with a Chinese colleague who has promised (whether he knows it or not) to become my own personal Go tutor. 

Come to think of it, the other colleague of this three man team is Russian.  Hmm... maybe I'll bring my chess set, along with the Go stones.

 

Yes, I know.  I have a weird definition of "tomorrow."  Here are my notes from last Thursday's HHH event in Harrisburg, PA:

Session 2: Office Development

Zhiming Xue http://blogs.msdn.com/zxue

Talked a bit bout how VSTO isn't an extra in VS 2008, but that it's built in. 

One thing I noticed about each of the presenters - they need to discover the Consolas font!  Scott Guthrie uses it, should be good enough for these guys.

He had an interesting use of template expansion.  Before the demo he created some snippets and bound them to keywords inVS (like you do with "ctor" to expand a constructor).  So he'd type something like snip1, then "tab" and get his snippet inserted.  I don't think I've seen that one before, but maybe I'm behind on the power curve.

I noticed that he spent a good while demoing the "auto include imports/using" feature, which has been in VS for three years now.

Showed using WPF inside an office Panel in word, which was cool.  It took me awhile to realize that it WAS WPF - just goes to show what we "expect" from software nowadays.

Session 3: WPF & C++ (huh?)

This session surprised me.  I really liked the first half-hour.  Not the most authoritative speaker, I could almost feel the BS oozing.  Yes, WPF can do some 3D things (on Vista), but that's not its strength.  WPF isn't challenging any 3D game engines out there, yet.  But the demo was really nice.  I almost had an epiphany... almost.  But I'm still not sure where I'd use WPF in a LoB app.  I had a similar experience but GOT the epiphany back at Tech Ed 97, where I finally understood how the Web could be used as an application platform (there really weren't too many of them around back in early 97).

The last half-hour was a total waste.  Completely unconnected to WPF, the speaker began on new features of C++ in VS 2008.  At least I think they were new features.  I haven't used C++ in about 10 years or so I can't really say.  Another famous quote from 97 Tech Ed (from Don Box), "I used to code in C++, but then I had a family and had to go home at night."

 

So that's about it.  There were supposed to be four sessions but one was either combined with the others or just left out (a little confusing).  It was supposed to be about SOwhAt (my term for SOA), but I guess it just didn't happen.  I don't have anything against web services, but I just don't see the big advantage of WCF and w-death-*.