I've been employed at Healthvision for the last 6.5 years.  I joined the company when it was just 6 months old and I'm now one of only three people left in the development group from the beginning.  I've seen us go through some bad times, some really good times (currently in that now), and made a whole lot of friends.  To be honest, it was very hard to talk with my boss about it since he's my friend more than my boss and he's been a great guy to work for.  The company has been an awesome place to work and they've been great to me and my family.  But sometimes you just feel the Lord leading you somewhere else.

So, effective 4/21 I'll be unemployed...until 4/25 when I start the life of a contractor and my first contract is with Jack Henry & Associates in Lenexa, KS (Kansas City).  Its a contract-to-hire situation, via JMA, so hopefully it will be a good fit and I'll have full-time employment again pretty soon.  At first I'll be traveling back and forth every week but when school/baseball/softball are over in May the whole family will come and stay for a while.  We lived in Kansas City before Dallas so it will be familiar territory for us.

I plan on attending the KC .NET User's group so if by chance anyone reading this attends that meeting let me know and say hi.

To follow up on my most recent post - here are two about Team Smells and how TDD could help from Blake Caraway.  I'm starting to see TDD like TiVo.  When you get it, you get it and to everyone else they think you're just trying to sell them something.  I'm not there yet on TDD but want to talk TiVo...just let me know.  :-)

Team Smells...Refactoring For A Better Tomorrow (Part One)

Team Smells...Refactoring For A Better Tomorrow (Part Two)

Since I got my iPod I've subscribed to the DotNetRocks (DNR) podcast.  The first one I listened to was from 3/21 with Jean-Paul Boodhoo on TDD.  It was enlightening to say the least.  Someone who uses it daily, designs software with it, and can give real life experience on the topic was awesome! 

We don't use TDD where I work but I've used it on a few smaller projects and personal projects so I could see what the fuss was all about.  After listening to Jean-Paul I realized I really wasn't doing TDD all.  I would write some code and then right the unit test for the code.  According the Jean-Paul, TDD is where you write the unit test against your idea of what the code will do and then write the code to make the test pass.  Think about that.  You are writing a test for code that doesn't even exist.  So basically you have an idea of what you want your code to do, what results that should return from it, and that's what you use to write your tests.  That's a mind shift and something to get your head around.  Another thing to get your head around is that TDD is not a testing strategy but a design strategy.  I think I just got this listening to Jean-Paul's interview.  One thing I've felt as an advantage to TDD is the extra thought that has to go into your design and how the pieces will work together.  I don't know about you but more than once I've sat down to write some code and then coded myself into a corner and had to do some heavy refactoring to clean it up.  Maybe, don't know for sure, but maybe if I was doing it TDD style I would've seen something like that coming sooner?  Or maybe it is just me.  :-)

What prompted me to even blog about this was Jeffery Palermo's post last Friday but more importantly the comments.  In the comments are somewhat of a debate on what is good/bad/ugly with TDD.  The comment that stuck out the most was Brian Sherwin's:

 Brian Sherwin said:
 The biggest problem here is that there are really three groups that don't get along real well with each other.
 First, there is the group that says "ALL code has to have a test FIRST" (hardcore TDD).
 The second group says, "We don't have time to write all of these tests before we write code--too much time is built running the tests just to see red when I know it's going to fail.  That's just STUPID." (TDD is for idiots).
 The third group says, "Wow, unit testing gives me confidence to refactor.  I should have unit tests to cover all my code.  I should at least be thinking of how to write the test as I'm doing the development, and ideally, I write that test soon after I wrote the code.  TDD is too much, not TDD is too little."  (Both sides can work.)
 I'll be honest--I don't TDD *ALL* of my code.  I do however TDD any refactorings.  Recently I was rewriting a module of a huge application I am working with, and the approach was--write a test that exercised the method I was replacing/rewrite code/verify new method returns the exact same results.
     Assert.AreEqual(Obj1.TestMethod, Obj2.TestMethod)

I totally agree with him.  I typically fall into group #2 but I'm think I'm slowly moving to group #3.  Group #1 is too absolute for me and to me there is only one thing that is absolute.

Anywho, there are also two DNRTv episodes (#1 & #2) where Jean-Paul develops an app from scratch using TDD.  I've got them downloaded and ready to go.  I'm sure they are great as Jean-Paul is on the teaching side of TDD and not the "if you don't use TDD you stink" side. 

Giddy Up!

Friday I mentioned that Dave, Joel, and Jay got me on the coComment bandwagon.  It's a cool wagon at that!  Now that I can track my comments on other coComment enabled sites I needed the same for my blog.  I got some insight from what Thomas did for CS 2.0 then did the work specific to dotText.

I left off the commentAuthor variable in the coComment script and will always use the commentAuthorFieldName variable instead.  I'm the only one who logs into my blog and my username doesn't correspond to my real name.  This way others will always see "Erik Lane" in the coComment thread.

The code snippet below will go in your skin's PostComment.ascx file just below the control directive.

Giddy Up!

<%@ Import Namespace="Dottext.Framework" %>
<%@ Import Namespace="Dottext.Framework.Components" %>
<%@ Import Namespace="Dottext.Framework.Configuration" %>
<%@ Import Namespace="Dottext.Common.Data" %>
<% Version dotTextVersion = VersionInfo.FrameworkVersion; %>
<% BlogConfig currentBlog = Config.CurrentBlog(Context); %>
<% Entry entry = Cacher.GetEntryFromRequest(Context, CacheTime.Short); %>
<script type="text/javascript">
 var blogTool   = ".Text <%= dotTextVersion %>"
 var blogURL   = "<%= CurrentBlog.FullyQualifiedUrl %>";
 var blogTitle   = "<%= currentBlog.Title %>";
 var postTitle                = "<%= entry.Title %>";
 var postURL   = "<%= entry.Link %>";
 var commentAuthorFieldName = "<%= tbName.UniqueID %>";
 var commentTextFieldName = "<%= tbComment.UniqueID %>";
 var commentButtonID  = "<%= btnSubmit.UniqueID %>";
 var commentFormName  = document.forms[0].name;
 var commentAuthorLoggedIn = "false";
 var cocomment_force  = false;
</script>
<script type="text/javascript" src="http://www.cocomment.com/js/cocomment.js"></script>