Thanks to all the folks who attended my session at the Victoria Code Camp.  I know it was a little rough and having the VPC not respond to the keyboard was more than a little frustrating.

I have cleaned up the code so that it is now in the state that I intended to reach by the end of my presentation.  You can download it here.

Here are some of the great resources that I have found for introducing you to nHibernate.

• Oren Eini (nHibernate God) -- www.ayende.com
• nHibernateEg project -- http://nhibernate.sourceforge.net/NHibernateEg/
• Billy McCafferty's Best Practices -- http://www.codeproject.com/aspnet/NHibernateBestPr...
• nHibernate documentation -- http://www.hibernate.org/5.html#A17
• nHibernate Tutorial (a little old, but a good read) -- http://www.theserverside.net/tt/articles/showartic...
• Oren Eini on DnrTv (Episode #51) -- http://www.dnrtv.com/

I hadn't wanted to post on this until we got something a little more concrete.  Apparently Roy wanted to build up the tension a little bit.  Since nobody reads Roy's blog and everyone reads mine, I'll put the information into public domain.  We (D'Arcy mostly) are working on getting Roy Osherove to do a user group tour in Canada after he gets done presenting at DevTeach.

This is very tentative, but also very exciting.  Here's hoping that we can make this happen.  It would be a May trip to Edmonton so I'm sure we can convince Roy that the 50% chance of blizzard is worth the risk.

I have a distant admiration of Robert Scoble.  He's doing things in new ways and that's admirable, but sometimes I read his posts and I think "WTF?"  This morning was one of those times.  Wee Bobby posted a bit of a rant about the fact that Engadget didn't pick up his vidcast about Intel's recent breakthrough in chip manufacturing.  I say Wee Bobby, because the post came across like some 8th grade kid complaining because his book report was given an A not an A+.

I understand that Scoble is excited about a great interview on a topic that was headline news in a number of international newspapers.  Actually, I find it admirable that he has such a passion for what he does that he'd get up and publicly show his disappointment.  My problem what the tone that his disappointment took.  Robert, you know, I know, and your readers know that whinging isn't becoming.  Don't be a whinger.

Let's face the facts, Engadget is an independent company and that's what makes them so valuable to you.  If you can get your story picked up by them you and your company will reap the rewards of industry validation of that story.  Part of that independence that you covet is the fact that Engadget reserves the right to choose what they cover.  They run their business by a set of revenue generating and ethical guidelines.  Within those guidelines they reserve the right to choose what they do.  They made the choice not to choose your story.  The content may have been part of that choice or it may not have been.  The simple fact is that they didn't want to run it.  Welcome to the real world.  Just because you're an A-List blogger and you get a great quote in your story, it doesn't guarantee you anything.  Learn to live with the disappointments like the rest of us.

I'm out at Victoria International Airport in the fog.  Thick fog.  So thick that I can't see the light posts 100 ft away.  Flights are being canceled, but it looks like the fog is rolling out.  It's kinda neat to see actually.  I've watched it slowly move down the airfield revealing one building, tree and light post at a time.  I'm pretty sure that the cancellations are over and that the day is going to be fantastically beautiful.  It's a shame that I'm not getting to spend it in this city.  Instead I get to go back to Edmonton where the online weather is showing a forecast for blowing snow.

I was out last night at the Sticky Wicket with JP, JK, NZ, JG and a couple of Victoria locals (if you two read this, ping me with your blog addresses).  At one point the conversation centered around the differences between Victoria and Edmonton/Calgary.  The Alberta cities can't compete with Victoria in the downtown area, the restaurants or the pubs.  Victoria has a large and vibrant downtown core that consists of a great street side shopping selection and an amazing number of eateries.  On top of that Victoria has an architectural appeal that goes on block after block.  Heck we were sitting in a pub and I leaned back and looked up at the 30+ foot high ceilings adorned with turn of the century decor.  In Edmonton if you do that you'll see a suspended panel ceiling that hasn't been painted since it was hung in 1972.

I can almost see the end of the runway now and I have another 30 minutes until they're supposed to start boarding, so it looks like I might not meet my first canceled flight today.

I'm not going to be posting this until I get back to Edmonton.  I'm too cheap to pay the $9 for a days use of the wireless here at the airport.  I understand that there are infrastructure and maintenance costs associated with providing wireless internet access, but after seeing what was available at the UVic facilites used by the Victoria Code Camp, I don't understand why airports need to charge for access.  I suppose it boils down to the fact that people will try to make a buck wherever they can.

Update: I see that a plane has landed, but it's starting to look like the fog might be rolling back in.

Update: We made it off the ground, but it as we started to rotate (leave the ground) the fog at that end of the runway was getting thicker and thicker.  Sunny and blissful at the other end though.

Nolan Zak and his crew put on a fabulous event here in Victoria.  The UVic facilities were fantastic.  Three rooms, each with a podium where the speaker just had to plug in their laptop to the power and the projector, and each with dual projection screens for the attendees.  The level of technology used in the rooms, as well as the amount that was available to the attendees at their desks, was frightening.  The seating area had power and Cat-5 for everyone.  The facility had wireless web access (intermittently) as well.  I'd love to find this kind of place for the Edmug events.

Nolan did a great job getting a large number of great speakers from his local community, Redmond and Alberta.  With the exception of the presentation by yours truly, I heard nothing but rave reviews from the attendees.  I had a few technical issues I had to overcome during my presentation (my VPC lost it's keyboard capabilities), but I managed to plow through and the attendees seemed to be keen on the topic.  It was great to see the number of people who were interested in nHibernate too.

To those of you who attended and are looking for the materials from my presentation, I will be posting them when I get back to Edmonton.  Now I must begin packing and make my second trip to the Victoria Airport in as many days (long story).

So I just got into Victoria in advance of the Victoria Code Camp.  The cab ride from the airport was a long one, but I did see some interesting things.  First, every Victoria Yellow Cab that I saw (all 4 of them) was a Toyota Prius.  I have never seen this before.  It makes perfect sense to me, but I doubt you'll ever see it in the land of the Cowboy Sheiks.  The other thing that I noticed was that all the public transportation (buses) seemed to be double deckers.  Not the old style British ones that you may think of in Victoria, but instead big new ones.

The one thing that I did expect and was greeted with fully was a nice drizzle.

We all know how annoying it is when you're surfing the web and you're greeted with a cascade of never ending pop up windows.  I saw the same thing happen yesterday at work, but instead of with popups it was with defects.

The goal of the day was to finish the last of the defects, push the fixed assemblies them to the system integration test environment and freeze the code before a release to production.  I wasn't overly involved with the process (I'm already hard (ly) at work on the next major release of the software), but I did see the effects of it on the team.  These guys came in to work that morning with a lot of energy and optimism, but by lunch time they looked like they had been marched to hell and back and they still had a late night in front of them.

So what happened?  Well, apparently bug fixes were ticking right along and then the first of many migrations to system integration testing occurred.  Even with a strong team and a good (not great though, but that's for another post) set of source control tools there were problems with getting the correct set of files into the build and then getting the build deployed correctly.  I don't know the specifics, but it is safe to say that myself and the other team leads have been pointing to this process as a huge gap for a number of months.  It finally bit our collective asses.

A while back I did a post on environment reproducibility where I discussed the need to be able to quickly and effectively create development and testing environments.  Even with solid and reproducible environments you need a solid and reproducible way to get your software into them.  Without an automated migration process you are relying on the installation gods and the last time I checked they didn't respond well to chicken sacrifices.  We have tools to ensure that we can deploy components to the desktop in a consistent manner such as ClickOnce and MS Updater Blocks.  Why don't we have great tools for the movement of the system from development to the locations that are required by these tools?

How can you do this?  I'd love to be able to give you an end to end solution, but I think that too much depends on the environment you work in and the technologies that you're using.  Deploying assemblies, html and other files is as easy as creating a batch file and using xcopy.  What about database DDL upgrades or Stored Procedure changes though?  Some environments preclude you from doing this without providing a script to an administrator.  If that's the case, then you might not be able to perform an end to end migration process.  If you're like us, you probably can't automate the deployment of the JCL or COBOL either.

What I will suggest is that you automate as much as you possibly can.  You'll never know about the troubles that you saved yourself.  On the other hand, you'll know all about the troubles that can be present with the stuff you don't have automated.

This past week we upgraded our CCNet server from v1.0 to v1.1 and encountered a few issues.  The first number of issues that popped up were most definitely caused by the networking departments insistence that they push the new version down to the build box.  They of course got it wrong, we uninstalled their attempt and installed v1.1 ourselves.

After successfully connecting to the server using the CCTray tool, we began to test the ability to click through and see the Dashboard.  This worked fine, but anytime that we attempted to drill down into one of our projects we were greeted with a HTTP 401 error.  After an afternoon of digging and some tweaking, one of my team members figured out the problem.

We're running CCNet on a build "server" that is essentially a desktop (not even glorified) with Windows XP as it's operating system.  Tracing the issue led us through the logs where we found these gems:

17:18:31 192.168.0.1 GET /<Rejected-By-UrlScan> 401

[01-18-2007 - 10:24:28] Client at 192.168.0.1: URL contains '.' in the path. Request will be rejected.  Site Instance='1', Raw URL='/ccnet/server/local/project/My Project/build/log20070118095626.xml/ViewBuildReport.aspx'

My coworker researched some more and found that the url that CCNet was using had the following format.  Note that just before the end there is the name of the log file, complete with the .xml extension.

http://mybuildserver/ccnet/server/local/project/My+Project/build/log20070118125448.xml/ViewBuildReport.aspx

This was what was causing the problems.  The solution to eliminating this was to find the following file:

C:\WINDOWS\system32\inetsrv\urlscan\urlscan.ini

Open that file and edit the shit out of it.  Well, no don't.  Just change the bolded line below from a 0 (zero) to a 1 (one) and all will work for you again.

 

[options]

UseAllowVerbs=1                ; if 1, use [AllowVerbs] section, else use [DenyVerbs] section

UseAllowExtensions=0           ; if 1, use [AllowExtensions] section, else use [DenyExtensions] section

NormalizeUrlBeforeScan=1       ; if 1, canonicalize URL before processing

VerifyNormalization=1          ; if 1, canonicalize URL twice and reject request if a change occurs

AllowHighBitCharacters=0       ; if 1, allow high bit (ie. UTF8 or MBCS) characters in URL

AllowDotInPath=1               ; if 1, allow dots that are not file extensions

RemoveServerHeader=0           ; if 1, remove "Server" header from response

EnableLogging=1                ; if 1, log UrlScan activity

PerProcessLogging=0            ; if 1, the UrlScan.log filename will contain a PID (ie. UrlScan.123.log)

AllowLateScanning=0            ; if 1, then UrlScan will load as a low priority filter.

PerDayLogging=1                ; if 1, UrlScan will produce a new log each day with activity in the form UrlScan.010101.log

RejectResponseUrl=             ; UrlScan will send rejected requests to the URL specified here. Default is /<Rejected-by-UrlScan>

UseFastPathReject=0            ; If 1, then UrlScan will not use the RejectResponseUrl or allow IIS to log the request

Next Saturday (January 27th) I'll be in the beautiful city of Victoria to speak at the Victoria Code Camp.  My topic...Introduction to nHibernate.  So if you're in the vicinity of Victoria, drop by and watch one of the presentations that is in the same time slot as me.  I'm sure it will be worth your time.

The good folks over at O'Reilly are '...unilaterally declaring Friday, January 19th to be "Windows Developer Tools Day."'  They're tying this to the launch of the new book by Jim Holmes and James Avery titled "Windows Developer Power Tools".

In the spirit of this, I'm going to list a few of the tools that I currently can't live without.

• Cruise Control .NET
• ReSharper
• nUnit
• nCover
• nAnt
• MS VPC & MS Virtual Server
• SlickRun
• Notepad++
• SysInternals

There are a number of others that I use regularly, but these are my daily tools right now.

Last night Miguel made the long journey from the Garden State to the City of ex-Champions.  We warmed it up so that the foreigner didn't have to talk about getting frostbite while typing.  The start of meeting was met with a small technical glitch (apparently Miguel's laptop rejected the notion of working in the cold so it switched to tablet mode), but we got that sorted out in relatively short order.

Miguel's presentation was great.  He covered the Provider, Plug-In and Chain Of Responsibility patterns showing how his one code example evolved with the implementation of these patterns.  For our first INETA speaker I was greatly impress as were the attendees.  The event had great attendance and many were first timers.

Next month (February 22nd) Edmug plays host to JP Boodhoo who's going to talk on Enterprise Patterns.

I know when people read this they think I'm being facetious when I say I live in an igloo and on an ice flow.  Well let me tell you, it's not all fun and games up here.  After a wonderfully brisk walk to work this morning (the ice flow has run aground) I heard through the mukluk telegraph that the walk home might not be have me skipping and whistling.  I went over to the Canuck Bison and Caribou online and looked at the weather report.  Once again, the mukluk telegraph was right.  I love it when you can see the b-word on the forecast.  Not only do we get the b-word, but we also get the complimentary follow up cold snap!  What a deal!  I bet you the Coding Hillbilly is really wanting to trade this for the Bahamas now!

 

In the past the most that I've ever used serialization is the automated kind that you get with web services.  I've recently been looking into some stuff that could use the power of serialization to eliminate thousands of lines of code that is custom serializing.  Today I decided to take the little bit I knew about the technical situation (some dummy left all that stuff at work) and do some exploratory coding.  Here's what I found out.

Output format

The output format that we need to generate is not something that is intuitive to programmers.  Below is a snippet of what we need to see generated and most of the current development team see this and guesses at the meaning of the elements based on the data values that each element holds.

<R2345>
     <F6677>Joe</F6677>
     <F5422>Plumber</F5422>
     <F8757>45</F8757>
</R2345>

For maintainability we need to be able to provide an easy, in code translation of these values to a meaningful business nomenclature. 

Current XML Generation

The above example trivializes both the size and the depth of the XML that is being generated.  That complexity also leads to a great deal of confusion when you're looking at a StringBuilder that concatenates elements and values together for a structure that is 8+ levels deep and over 10,000 characters in length.  As we know more lines of code increases the chances for a developer to make a silly accidental mistake.  Regardless of if you're an ardent TDD practitioner, or if you're performing thorough multi-person code reviews, when you're creating string values problems like these are almost impossible to detect before they become visible in the application.

What I was playing with

Once I saw all the code that was being manually written to generate the XML, I immediately thought of some stuff I had read about serializing business objects.  I was pretty sure that this would help us, but because of the depth of the embedding and the use of custom elements I wanted to create a proof of concept.  I started by creating some classes that would represent multiple layers of depth and having some elements that contained many embedded elements.  To translate the elements back and forth between the meaningful business names and the cryptic XML element values I employed a number of different attributes as follows:

    [Serializable()]
    [XmlRoot("R1234")]
    public class Employee
    {
        private int _employeeNumber;

        [XmlElement("K5501")]
        public int EmployeeNumber
        {
            get { return _employeeNumber; }
            set { _employeeNumber = value; }
        }

        private string _firstName;

        [XmlElement("F5582")]
        public string FirstName
        {
            get { return _firstName; }
            set { _firstName = value; }
        }

        private string _lastName;

        [XmlElement("F5584")]
        public string LastName
        {
            get { return _lastName; }
            set { _lastName = value; }
        }

        private DateTime _hireDate;

        [XmlElement("F5598")]
        public DateTime HireDate
        {
            get { return _hireDate; }
            set { _hireDate = value; }
        }

        private Department _department;

        [XmlElement("F3466")]
        public Department Department
        {
            get { return _department; }
            set { _department = value; }
        }

        private List<WorkingSpace> _office;

        [XmlArray("R2394")]
        [XmlArrayItem("R2323")]
        public List<WorkingSpace> Offices
        {
            get { return _office; }
            set { _office = value; }
        }
    }

In the end I have only one or two small concerns (I wish I hadn't forgotten those format documents!), otherwise I think that this will be a great way to eliminate a whole bunch of brittle code and bring some meaning to the data access layer of the system.  Download the sample code that I created here.

Anyone who has seen me harp during a code review knows that I promote and practice defensive programming.  I don't like to leave anything to chance when I write a public facing piece of code.  It's my code...I'm advertising how it works (XML comments please and thank-you)...ergo, I'm responsible for how it reacts to various possible inputs.

How did this train of thought start?  Well, at work I've been in a series of seemingly endless meetings to discuss the documentation requirements for coded service interfaces provided by one technical team to another.  There are a number of reasons that the meetings seem endless, but one of the biggest is that they always seem to degrade into a discussion about who should be responsible for validating the data being sent to the service interfaces. 

One of the arguments being made in the meetings I've been attending is that the consumer of the service interface should be aware of the values that the service considers to be valid.  In my mind this is wrong.  The power and benefit of creating service interfaces is that consumers of these functionalities don't have to know or care what goes on behind the interface.  To them it is a very, very black box.  To me that's the argument for programming your service interface as defensively as possible.  Instead the retort that I get is that the service owner doesn't want to have to manage "...all that validation code when we don't use it..."  To them I say, provide services at your own risk.

Like a number of other people, I find chain letters, endlessly forwarded jokes and these blog chains quite challenging.  Don't you think that there's enough mindless drivel on the web with me adding to it.  On top of that I already have posted the 5 things that will most likely make people walk by me and not say "Hi".  I will not post another 5 just because D'Arcy and James have asked me to.  Instead I'm doing this to see if I can evolve this blight on the internet.  My inspiration is James saying that he broke a toe once and Bil saying that he's never broke anything.

With that, here are the 5 worst accidents (no particular order) I've been in.

1. Fractured Skull #1 --  I grew up in near a very small town in BC.  To have any fun we had to go to a not-quite-so-small-town.  When my high school graduation rolled around the organizing committee decided to send us out of town to a sports and fitness type place for a dry grad party.  One of the events was a tournament of wally-ball (volleyball in a racquetball court).  Being competitive, and the captain of the varsity volleyball team, I played all out.  At one point I dove for a ball no realizing how close to the wall I was.  Apparently I hit the cement wall about three feet off the ground, head first.  It knocked me out, ripped my forehead open (still have that rather large scar today) and I left a large blood stain in their precious wood floor.  About five months later, when I was off at my first year of university, I started to randomly black out.  It was kinda scary.  One minute I'd be getting out of bed and heading to have a shower, the next thing I know I'd be face down in the hallway.  I decide at this point that I should see the campus doctor, who immediately sent me to a neurosurgeon for a CAT scan.  According to that guy I had still had one of the worst skull fractures he'd ever seen.  He recommended that I stay in hospital for evaluation and monitoring, but I decided not to.  I had a girl coming into town that night to visit dammit!
2. Fractured Skull #2 -- About four years after my first fractured skull I decided that I should try to duplicate the effort.  Apparently I didn't feel that the cement wall was a worthy adversary so I went with something a little more animate.  As you know from the previous list of 5 boring things in my life, I used to ride bulls.  At a rodeo during my second stint at a school of higher (?) education, I had a wee accident involving me, my head, and the business end of a bull's hoof.  The bull that I drew up on didn't want to load in the truck to come to the rodeo so the stock contractor loaded a replacement bull.  This replacement bull was of a much higher bucking caliber and had actually been used at pro rodeos (I was only riding in a college/amateur rodeo).  To top it all off once I called for the gate and made it through the first 2-3 seconds of the ride, the bull turned back (started to spin) and dumped me off his back to the outside of the spin.  When I came off, my hand got hung up in the bull rope and the fun began.  The bull was bucking hard enough and fast enough that I couldn't get back onto my feet to work my hand free.  Instead I kept getting sucked farther and farther under him.  Finally I was far enough underneath that one of his back feet came down on the side of my head, grazing me from the back of it, through my ear and past my cheek.  Grazing is an accurate, but disturbingly understated word because this little tap completely knocked me out.  Luckily it also was enough to rip my hand out of the rope.  The bull, doing only what it knew, just kept bucking around above me while I was unconscious on the ground.  After one or two more bucks he connected again, this time squarely in between the base of my skull and the top of my shoulders.  This was enough to make me conscious again and my first, and correct, instinct was to find a fence and get over it.  I thought I saw a perty looking red fence ahead so I started running towards it.  All of a sudden I felt a huge impact in my back.  Apparently there was no red fence, and in my dazed state I was running aimlessly through the arena.  One of my good friends came over the fence and into the fray and caught me from behind (the impact I felt), wrapped his arms around my chest, picked me up and put me through the nearest gate and into a safe area.  Admittedly, things after that are a little foggy.  The next thing I remember is lying on my back watching the paramedics scramble to work on me and having a very peaceful and relaxed feeling about it all.  Then my loud mouthed sister (who was quite drunk) started yelling at the EMTs telling them that I'd be okay and to leave me alone.  I told her the beer gardens were still open and she shut up and left us alone.  After a few hours strapped to a backboard in the hospital (I can't remember how many x-rays I had that night), and having STARS air-ambulance on standby, I was finally diagnosed with skull fracture #2.  Like the diagnosis of skull fracture #1, it came at a very inopportune time so I left the hospital that night for the rodeo dance and women with Wrangler butts.  The next day, headache in tow, I borrowed a hockey helmet and rode (well, bucked off if you must know) my second bull of the weekend.
3. The Stump -- When I was in high school I became an avid skier.  A few years back I was living at the base of the Canadian Rocky Mountains and it only took an hour between locking my apartment door and standing in the lift line for the first ride of the day.  That season I had golden horse shoe luck and it seemed like every time we went skiing there was six inches or more of fresh, fluffy powder.  I was out one trip with a couple of friends and we were blasting down through this small saddle to get up a small hill to the top of a great gladed area.  The sun was quite flat and I didn't see the snow covered stump sticking up about a foot high.  I was moving at a very, very high rate of speed and I hit it with one ski.  The impact shot my knee up into my chest and sent my careening through the air.  Unfortunately I don't remember the flight, but I have a feeling it was spectacular.  I vaguely remember hitting the ground which, amazingly was ski first.  Unfortunately, the landing was completely out of control and my head continued it's downward motion and my mouth made contact with the top of my pole which I'd conveniently planted during the landing.  The next thing I remember is coming too on a large pile of blood soaked snow with one of my skiing partners standing over me asking me if I was alright and telling some guy that I didn't need the ski patrol.  The aftermath of this was the largest fat lip that I've ever had along with the worst concussion imaginable.  It took about four to five months for the effects of that wreck to wear off to the point where I could even be productive at work again.
4. The Ankle -- This is another story from my bull riding days.  I was out at this little rodeo in northern Alberta on Canada Day and it had been raining like it was monsoon season in Manila.  There was so much water on the ground that the organizers had a vacuum truck sucking it out of the arena so that we could start the rodeo.  I drew up on a great bull that spun to the right immediately after it left the chute, and I was very excited about the possibilities of winning that rodeo.  I started to climb down on the bull in the chute as I prepared for my ride.  To set the scene in a chute for you, you have to understand that the chute itself is made from steel piping and is only slightly wider than an average bull and a rider's legs.  This bull was a little bigger than average so it was a tight squeeze, and then, to top it all off, he was a leaner.  Once I got my legs down between him and the steel piping of the chute, he leaned over to the left with all his weight (about 1800 lbs for this guy).  As luck would have it, my left leg was in such a position that my ankle was against a pipe, but my foot wasn't.  The pressure of the bull against my leg sent a searing pain up it.  I looked down the outside of the chute (nothing to see but leg and bull on the inside right?) and was greeted with a full, unobstructed view of the bottom of my boot.  Being the quick learn that I am, I figured out that this most likely meant the ankle was dislocated.  My first course of action was to extract my leg from the chute and do some more analysis of the situation.  Once I got it up into the daylight again, I realized that I was going off to the hospital to have that fixed.  If I left for emergency right then, I'd have to turn out that great bull though, and I didn't want to do that.  Instead I got my leg into such a position that I could apply pressure down through my ankle and onto the back of the bull.  By doing that (not recommend by most trained medical professionals I've been told since) I managed to pop my ankle back together.  The chute boss (buddy who make the rodeo flow) was kind enough to give me a few minutes to get composed and he bucked out another bull and rider before coming back to me.  I made it out on this bull, rode him for 7 of the 8 required seconds and was unceremoniously dumped into to the foot deep mud.  I had no ability to walk, let alone run, and my biggest fear at that point was getting gored by the bull and possibly drowning in the mud. Neither happened, I made it to the hospital and successfully pissed of the on-call doctor in that small town by making him leave his Canada Day picnic.
5. The Toe -- Just so I have some way to tie this to my technical blog I'm going to tell you about how I broke a toe programming.  Some could say that I took extreme programming just a little to far.  I say, I'm just stupid and clumsy.  At one of my previous programming gigs I had a piece of 2x4 wood that was about a meter long.  It was my thinking stick.  Any time that I needed to step away from my computer and contemplate the direction I was going with my code I would get the thinking stick and wander the halls of the office.  From time to time I would toss the stick in the air and catch it as a way to alleviate the boredom of just packing it around.  One day I was thinking a little to hard and, at the same time, performing the stick toss.  The stick went up, and the stick came down.  It came down right through my hands which I neglected to close around it to prevent gravity from continuing it's course.  The next non-movable object that the thinking stick (now a thinking projectile) found was my foot.  Contact was made, gravity's effects were halted and I was now in pain.  I only broke one of the toes (or at least I think it was only one....who goes to a doctor for such a trivial injury?), but the whole top of my foot turned black.  It was like I had advanced gangrene.  My advice to all of you?  Extreme programming can be dangerous.  Only perform it on a closed circuit and under the supervision of experts.

That's that.  Who do I tag?  Last time, in an attempt to kill this thing, it was no one.  This time.......Jason Hunt, Steve Pietrek, Jason Haley, Derek Hatchard, and Dmitry R.  Tell me what you got boys.

 

We are having another great presentation at Edmug in January.  This time, with the help of INETA, we've been lucky enough to get Miguel Castro out of New Jersey.

**Please note that this event is on Monday, January 15th.  The location and the times are the same as usual.

I wanted to write some things down so I can clear my mind and, hopefully, approach 2007 with a different perspective.  These aren't New Years resolutions.  These are career oriented and hopefully this career will go beyond the end of 2007.  Also, this is a living document.

I will set aside time to review code that I wrote in past years

I'm hoping that this will help me in a number of areas.  The first would be to allow me to grow technically and critically reviewing code is a great way of doing this.  Reviewing my own code doesn't allow for the easy out of "...it's bad code by bad programmers..."  If I feel like saying this, I know who to go and bitch at for writing the crap code to begin with.

The second thing that I really want to get out of these reviews is a sense of humility.  Hopefully I have grown as a programmer since writing the code I'm reviewing.  Hopefully that growth is obvious to me.  Hopefully I realize that I was not, still am not, and most likely never will be the superior coder.  Hopefully this gives me more patience with the devs that I'm working with.  Hopefully it pushes me to continue to grow as a developer.

I will work to provide a positive career experience for myself

Like everyone I want to enjoy my career and my work.  I'm lucky to enjoy my career already, but I need to put effort into ensuring that I enjoy the work I'm doing in my career.  I don't want to be a bitter, sour or caustic person at my job.  I've been there enough and I don't need to be there again.  As a contractor in our current market, I have the ability to put myself into situations where this isn't the modus operandi.

I will make sure that I take the time to enjoy life

People often say they don't live to work, the work to live.  I'm not a big fan of either of those two options.  I work.  I live.  I must make sure that there is a clear designation between the two, and that one does not interfere with the other.  I can't be going out to the pub and hindering my work performance the following day.  I can't be going out to the pub and letting the conversation solely revolve around work.

My life away from work needs to have time dedicated to it.  I must curtail some of my technical and professional pursuits in order to grow my life away from work.  I have to plan pleasure time in advance.  I can't just be taking time at the last minute because "it fits now".  I can't let work schedules or a feeling of indispensability stop me from taking time for pleasurable pursuits.  Too often I have pushed off time away from work because of an incorrect feeling that the work world would be severely hampered if I wasn't there.  I can't let this happen any more.

I will work on a comprehensive training plan

As a contractor it is up to me to ensure that my skillset does not become stagnant and/or out of date.  I must set aside time and money to prevent this from happening.  I also need to make sure that my employers understand that this is non-negotiable.  It's my responsibility to stop my current work demands from preventing me from having marketable skills when I've completed my current work.

 

It's not a big list, nor is it a comprehensive list.  Regardless, it's a good start to a philosophy for my contracting/consulting career.