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 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."
 

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.

 

Unfortunately, as of today (2/28/08), the ReSharper 4.0 EAP still can't handle LINQ (or partial methods, apparently).  However, I just can't give up ReSharper's refactoring capabilities and other goodness, so here's how you can disable the code analysis and IntelliSense in the ReSharper -> Tools menu dialog:

If you don't use LINQ (or partial methods), just ignore this advice - use ReSharper to the hilt!

If you're not yet using ReSharper for VS 2008, I'd still advise that you download the latest nightly build and give it a try.  You'll not want to go back.

 

As I've said before, my organization does an awful lot of SharePoint work.  Since button-pushing really isn't my thing, I've got only a few options when it comes to coding most SharePoint projects:

• Custom Workflow
• Custom Web Parts

I've started to duplicate this blog on our internal MOSS server, and there's something that I've missed about dasBlog that's not available in WSS or MOSS blogs - Tag Clouds.  That sounds like a good place to get my feet wet in Web Part development.  I know that there are already several web parts available that provide tag clouds for MOSS, but of course, they're "not invented here".  No, seriously, this is purely for my own educational purposes, so even if I do provide a solution to the general public, there's certainly no assumption that it would be any better than what's already available.  This project will let me explore several interesting technologies:

• Web Part development (of course)
• Code Access Security (CAS) in SharePoint
• STSDEV
• Microsoft Unity (though I'd rather play with StructureMap <sigh/>.)
• VSTS 2008 TFS Team Build
• any other random bits of new tech that catch my eye!

 

I'm not dissing MS Unity, Microsoft's new IoC Container - I'm really going to give it a chance.  Rather, I'm talking about the reaction to it on the Yahoo! [altdotnet] group.

I have just spent most of the morning following a thread on the [altdotnet] mailing list titled "Unity" Ioc from Microsoft has been released in CTP...  And it has.  But in retrospect, based on the thread, "Unity" was a very ironic name choice for the tool.  This is a very long thread that is involving dozens of folks.  It started off by comparing the functionality in Unity to functionality in other IoC containers, mostly Castle Windsor & StructureMap.  The Spring.NET crowd has been strangely silent.

Later in the thread, however, the "altdotnet"ness of the list has begun to show its colors. Passions have arisen and tempered.  Staunch defenders of each "side" (and there are more than two sides to this polygon) have held their ground while alternately being gracious one minute and on-the-attack the next.  It's the ultimate Reality TV... except that it's not TV, of course.

I've wasted too much time trying to follow this thread and I declare that I am DONE with it.  Not that the task wasn't worth it.  I've learned a lot about IoC that I hadn't know before.  I'm familiar with Windsor, and I've downloaded Unity and played around with it as well.  The really great gem that I have just discovered is StructureMap.  I just love the "fluent interface" it has - much like is available in Rhino.Mocks.  Fun, geeky stuff.

I thought it would be a useful exercise to compare "Hello, World!" scenarios between the big-four (and, yes, I'm including Unity as part of that):

Function	Castle Windsor	StructureMap	Unity	Spring.NET
Putting an interface and concrete type into the IoC container	WindsorContainer. AddComponent()	StructureMapConfiguration. BuildInstancesOf(). TheDefaultIsConcreteType()	UnityContainer. Register()	N/A - Spring doesn't support XMLless config (that I could find).  Those Java guys just have a love affair with XML, I guess
Getting a concrete type for a given interface	Resolve()	ObjectFactory. GetInstance()	UnityContainer. Get()
Default items are	Singleton	separate instance	separate instances

The fluent-interface of StructureMap is so nice.  Yes, it's longer to type, but hey, that's what IntelliSense is fore, and that will make it easier for new developers to discover.

Incidentally, Unity looks an awful lot like Windsor in its syntax, and it was mentioned in the aforementioned thread that the PM on the Unity project is a big Windsor fan.

Apology: I just couldn't resist the lolcats thing, it was just too apropos.  This is my one (1), lifetime, self-imposed limit.

 

Wow, that was a lot of work.  I always hate when a screencast of demo starts with this big huge installation of a bunch of different technologies, but doesn't tell you how to get the same environment, so I started from scratch and show you how to go from a generic W2K3 base image to a fully functional TFS 2008 box and THEN show the Continuous Integration sample.  Due to the fact that we're going soup to nuts it's a pretty big screencast for me 34+ minutes - a new record for me.  I only wish complete installations like this REALLY only took 30-40 minutes.

Screencast: Continuous Integration and TFS 2008

 

A colleague, Daren May, has turned me onto a great Scrum resource, Scrum and XP from the Trenches, which is the best online Scrum resource that I've seen yet.  It's a free PDF book about one ScrumMaster's experience with Scrum.  Most of what I've read about Scrum so far has either been heavy on theory or very "Pie in the Sky"ish. I was so impressed by it that I've emailed everyone I know who's interested in Scrum.

The author, Henrik Kniberg, has a blog that's just dynamite as well.  Lots of good content on agile and Scrum in there.

As I said, I was very impressed, so much so that I decided to pay for a hard-bound copy, which is pretty out of character for me if it's available in a free form.

 

If you've followed my blog for very long, you've seen that it's mostly about agile software development.  I took a short "sabbatical" over the holidays and started playing around with SharePoint (both WSS 3.0 and MOSS), and I posted maybe 5-10 blog entries on these subjects.  Since then, I've seen a dramatic increase in my blog traffic - particularly from search-engine traffic.  It's now 9-1 SharePoint referrals.  It's not like there's not a lot of places out there to get SharePoint info.  I know that I haven't had a hard time finding SharePoint info in the Googlesphere:

but there you have it.  People are so starved for SharePoint info they're coming for my meager offerings (I must be 18,100,001).

It's all about marketshare.  I remember seeing something similar in 1994-95, when I was mostly a Borland C++ guy.  I loved Borland, but Microsoft Visual C++ seemed to reach a tipping point in marketshare around then and I decided to hop into a different boat - turned out to be a really good move.  Whatever happened to Borland anyway?  Funny, I don't even feel the need to look them up now, it seems so irrelevant.  But I did, and it looks like the used-car dealearship of the internet:

But unlike Borland C++ vs Visual C++, I don't feel quite the same tension.  I don't need to abandon "agile" in order to do SharePoint.  At least I hope not.  Agile hasn't made nearly the same in-roads in the MOSS world as it has in other areas of software development, so I kind of consider it a challenge to "agilify" (I just made the word up, I believe) the SharePoint world.  There's only one question left...

Should it be MosScrum or ScruMoss?  For some reason, I'm leaning toward's ScruMoss.

 

I knew that conventional wisdom states that you should only mock your own classes, but I was tempted by all the beautiful interfaces within Microsoft.Office.Interop.Outlook.  I'm starting to pay the piper, however.  Rhino is slowing down a good bit because it has to emit so much "Reflection"ed stuff each time I CreateMock<AppointmentItem>(), etc.

Oh well, live and learn... or re-learn.

 

I'm beginning to feel like Ayende @ Rahien with all my posts today.

I'm slowly coming to the realization that one of my favorite patterns, namely Presenter-First, just won't work well in the new ASP.NET MVC Framework.  Perhaps I should have expected trouble (and maybe I did just a little), since the MVC (Model-View-Controller) pattern is the antecedent of MVP (Model-View-Presenter) pattern.

In fact, Presenter-First may actually work better in the old ASP.NET WebForms than it does in MVC, though in a slightly kludgy way.  This is due to the fact that at least in WebForms events are supported through the "postback" mechanism, whereas the MVC Framework does not support postbacks (nor events from what I can tell).  Presenter-First  relies on events to connect the Presenter to both the View and the Model, and... well... there just is no capability for events from the View to the Presenter/Controller. 

Presenter-First simply acts as glue, abstracting the interface between the Model and the View.  The Model knows nothing of the View, and the View knows nothing of the Model, and neither cares.

Another point at which MVC collides with Presenter First is in the concept of an "MVP Triad" in Presenter-First.  The Triad is a logical connection between a specific Model, View, and Presenter.  The Presenter is more or less associated with a single view from what I've been able to tell, but in the MVC Framework, a controller (presenter) is capable of rendering many views.  Oy vey.  Things just get worse.

I still think I like the idea that the Presenter/Controller is as thin as possible, and that the View is even thinner (if possible).  The Model should handle all the grunt-work, as I advocate a Model which is more of an "application model" rather than a "data model." 

No matter how you go about it, you're going to lose the cool capability to use the same Model between both a web-based client and a smart client like WinForms or WPF.

Another problem that I see with the plain vanilla MVC is that you still have that old code-behind class (the web-pages are still .ASPX files after all, just without view state or postback), and it is ever so easy to stuff functionality in there where it does not belong in the code-behind.  Put your custom code in the application model, not in your view, and to a lesser extent not in your controller.  I do realize, however, that it is possible to forget WebForms altogether in the MVC Framework and to roll-your-own view engine or use one from Monorail.

Now, if I can just figure out how AJAX works with the MVC pattern... hmm.

 

I'm currently "in-between" projects here at the EMC Microsoft Practice, and partially through guilt that I'm not "producing" anything right now, I'm going to use this blog to assuage my guilt, somewhat.  I'll be using it (for the time-being) as what "blogs" were originally meant for, more or less.  That is, a diary of "stuff I do".  I'll try to continue to make it interesting, but it probably won't be as in-depth and as focused as in the past.  No, I'm not going to Twitter, since you don't need to know how many diapers I change a day (plenty today, let me tell you), etc., but I'll talk about each thing I work on for as long as my Attention Deficit Disorder allows.

Today I began by downloading code and watching/listening to some screen casts coming out of Microsoft for ASP.NET, namely the ASP.NET 3.5 "Extensions", which are really more like ASP.NET 3.6.  Pretty much the only thing I was originally interested in was the ASP.NET MVC Framework, which helps make TDD for web-sites easier to do, and that is always cool.  But there are other interesting things in these extensions as well, like "Dynamic Data", which appears to bring the Web to a point where VB6 was years and years ago, Point to some tables and "voila!", you've got a completely workable solution for instant CRUD.

---

I almost forgot, I have to do a phone-screen today.  In the past I've used the FizzBuzz test via Live Meeting, but I should probably come up with something a little more original.  How about:

Write a method for a console application that:

Performs a loop that goes from 3 - 99 by threes, prints the current time when the index is divisible by 4 and prints yesterday's date/time when the index ends in the digit 7.

That's a little harder (but only slightly) than Fizz Buzz, but still lets you gauge a candidate's basic coding ability, which is really all it needs to do.  The point isn't that there's one BEST solution, but rather it's illuminating to watch a simple problem like this be solved on the spot.  What if someone reads my blog and figures it out beforehand?  Well, if you read my blog, then you gotta be pretty good anyway, right?  You're hired!  How did it go?  You guys aren't the HR department, so I'm not gonna tell.

---

I've just spent more time than I'd like to admit finding a decent tool with which to write to my blog.  Back when I was using WSS 3.0 as my "blog engine" I used Word 2007 as my blog entry tool, but I've discovered today that it doesn't work so hot with dasBlog.  With dasBlog, I'd been either using the built-in web-based blogging functionality to dasBlog or BlogJet.  The trial for BlogJet has expired and I just can't bring myself to fork over about $47 US for the thing.  I just didn't get enough bang for that amount of buck.  So I'm back to using another free tool, "Windows Live Writer," which so far seems to work like a breeze, even with dasBlog.

---

Well, that's pretty much been my day today so far (after 5:30 PM here). Not that it's over. I'll probably be sitting here doing more or less the same thing until about bed time - or past.

 

What’s with the Agile Israeli gurus, Roy Osherove & Oren Eini leaving their respective employers and looking to work somewhere else?  One thing is for sure - they’ll be able to pick up a new gig very easily.  I’m not sure about Roy, but according to Oren, his company is going in a direction that he’s not too happy about: SharePoint & CRM.  He’s so upset that he hasn’t made any posts on his blog today – I can’t remember the last time that happened (check his monthly post count on his site – it’s insane).

I can totally see where he’s coming from.  The same thing has been going on for years at my company, even before Internosis was acquired by EMC.  I love being a developer – and I’ve remained one even through the “bad time” earlier this century.  At the time Internosis was primarily an IT consulting company as opposed to a software consultancy.  It was “stressed” to us developers that we consider becoming MCSE/MCSD hybrids.  I like standing up servers as much as the next guy, but I really didn’t want that to be my career.  I apparently coined the term “master configurator” as a euphemism for MCSE in a “reply to all” email and didn’t realize it.  A couple of years later I heard someone say “Master Configurator” and I laughed – I thought it was a good line, said I’d have to remember that one.  Then they told me that I was the one that had come up with it.  I bet that happens a lot to people who are often quoted.  I have a whole book of C. S. Lewis quotes, and I bet if he read it now (if he were alive) he’d say, “Huh.  I don’t remember saying that!”

So we were encouraged to learn more than just coding.  I can handle that.  It’s a good thing.  One thing I ask Microsoft developers during an interview is, “Have you ever installed Active Directory?”  The usual answer is, “No.”  I don’t reject them for it.  At one time I’d never installed AD.  And all the Master Configurators (or a good portion of them) have installed it, so it can’t be too hard to learn (@MCSE’s => j/k).  But it does give me a view into the candidate’s ability to go “find the cheese”.  My harried “reply to all” email previously mentioned prompted an associate to tell me that my cheese had been moved.  I can handle moved cheese.  I just didn’t want mine changed from Jarlsberg to Velveeta.

A couple of years after the MCSE/MCSD “suggestion,” I noticed a sharp drop-off in the number of pure App Dev projects we booked.  In the vacuum, SharePoint gigs were being sold – lots of them were, and still are.  It just looked like a glorified Digital Dashboard to me.  So I dodged the SharePoint bullet for a long time, but in doing so I still became this weird hybrid of MCSD/MCSE that I had been trying to avoid.  You can only dodge so many bullets when your name’s not Neo.  Now it looks like I’m finally going to get hit by the SharePoint bullet, too – the same one that Oren is trying to dodge as well.  Not to mix my movie metaphors but I’ve come to a conclusion, Oren – resistance really is futile.

Also, here’s a shout-out to my daughter, Kaiti, who has been gracious enough to provide the image!

 

 

 

 

 

Testing is about a lot of things.  One of the major things is confidence.  When you have good test coverage you can have the confidence to make changes (assuming that you run your tests after making your changes, which not everyone does).  Making changes to a production system is risky business and the importance of the staging environment is paramount.  This gives you the liberty to try out new technology, new functionality, and things that you would otherwise be afraid to attempt (or should be).  One should not let one's enthusiasm to impress overcome common sense and while performing rigorous testing is not glamorous it not only builds your own confidence, but other's confidence in you as well.  Shortcuts lead to not only grief but sometimes embarrassment as well.  Seeing green is such a good feeling.

 

As a Microsoft developer who's embraced Agile principles & practices, I've had a deep case of "Ruby envy." Yes, I know that I can download the ruby environment and run it any time on my windows machine. I just didn't know how I'd ever use it in real life (i.e. professionally). As a consultant, I'm more or less beholden to whatever my current client is using. And as a Microsoft shop, I really didn't see us advocating our expertise in a non-MS technology like the standard Ruby environment. I've been hearing about dynamic languages for ages now, primarily about Python & Ruby. And yes, Microsoft has a Python environment called IronPython (isn't that a pro-wrestling move?). So I certainly could have adopted IronPython for myself and used it professionally. The problem was that I knew there was something else coming from the Microsoft DLR team, which is IronRuby. I knew I didn't have enough brain-bytes with which to learn two new languages, so I've chosen ruby, and apparently I'm getting in on the ground floor (as far as Microsoft is concerned).

John Lam has been working hard to put this together, but apparently Microsoft needs our help (or at least John does). I've never seen this before, but Microsoft is accepting source code submissions for the ruby standard library. I believe a lot of it is to be written in C#, so that's not too scary. I may even take a stab at it, even though I myself am only a ruby neophyte. They worst thing that could happen is to be rejected, and I figure I'm still learning from my mistakes, so what the hey!

 

I've found in the last few days that a name does mean something.  Not to "dis" Shakespeare, but some judicious renaming of Classes can change code-smell into a sweet smell.  The code does seem to talk, and classes or methods can sometimes say to you, "I'm not a 'foo', I', a 'bar'" - and simply making that change can make the code speak better to you.  Design emerges, and it makes it that much easier to maintain - either by you or others.  ReSharper makes refactoring things like this a joy!

 

CI Factory is another technology that I failed to put on my "to do" list. Nevertheless, I've been playing around with it this past week and from what I've seen so far, I really like it. I'm a little concerned that it could "kitchen sink" you to death, but on the whole, I think this is a great boon to someone trying to quickly bring up a continuous integration server. I still think it's better if you learn the basics of particularly CruiseControl.NET and NAnt yourself before bringing up a CI server. In fact, if you didn't at least have a basic understanding of these you wouldn't be able to troubleshoot any problems encountered along the way of bringing up CI Factory, nor would you be able to customize/extend it in any way. .NET Rocks! or more precisely dnr tv has what I would call the best screen cast so far explaining how to set up CI Factory. In about 1 hour Jay Flowers, Scott Hanselman, and Carl Franklin had the whole SubText open source project downloaded and incorporated into a brand-new CI Server, though I think Carl was kind of bored during the whole thing. Here are some of the "gotchas" (just actually things to be aware of) that I've discovered so far when installing CI Factory:

• Don't try to develop on your buildserver, certain packages in CI factory get confused
• Have Subversion installed (if you're using SVN) before you try to install CI Factory. Make sure you have it installed to C:\program files\subversion and that it's in your path
• Have NCover installed before you try to install CI Factory
• Go with the flow the first few times you attempt to install CI Factory. Don't try to customize it too much. Once you're familiar with how things work, then you can start to experiment.
• I was getting errors trying to commit a large amount of information to Google Code during CI Factory set