When I was 8 to 12, I was big into Dungeons & Dragons. My brother was five years older, and sometimes I could sit with his friends and play. We had all the books, much to the chagrin of my parents. When the D&D cartoon came on, all other things ceased to exist for those short 30 minute chunks of time.

Now that I'm older, I watch a new show called Start-Up Junkies, its on the MOJO channel. I first heard about the show at my local .Net User Group meeting. The PADNUG organization gets together about once a month, sponsors buy pizza and someone presents for 60-90 minutes on a .Net related topic; recruiters abound here. Being so close to Redmond, we're a little spoiled with lots of juggernaut speakers around. At the last meeting, Matt Davis gave what was arguably one of the best sessions I've ever seen here. He's a relaxed speaker and clearly an expert in his craft.

Matt works for a company called Earth Class Mail, a start-up with a great idea. They offer a mail processing service. When you sign up, you change your address and send your mail to them. They scan all of your mail and you access it online. They can scan just the outside of the envelope or open and scan all of the contents too. You can shred it or have the physical document sent to you if you want to keep it. The company was growing at a reasonable pace when they signed on the mysterious giant corporate client, code-named "cheetah". If they make this pilot project with cheetah work, they'll be huge. Matt mentioned the TV show in passing during the presentation and I looked it up.

Start-Up Junkies follows the company through the frantic pace of trying to scale up without failing. I saw the .com bubble rise and fall so I really get this show. The cameras wander all over the offices, covering the CEO, marketing, sales, I.T. and operations. Sometimes I'm cheering and other times I'm yelling and the screen and shouting WTF!?!?!

I love my job and now I get to watch a little bit of it portrayed on HDTV. Watching in the one-piece jammies with feet is optional.

One of my teammates recently had a problem with some Flash injection code. She was setting some properties and then calling a function on a JavaScript object that threw an error. We got a message that said "Object doesn't support this property or method".

We isolated it down to a timing issue by dropping an alert() into the code just before we called the method. With the alert() pausing execution for a few seconds, the browser had enough time to fully instantiate our object. Without the alert(), the method was called before it was built. Its a problem that can make your brain hurt.

Here's how you can test for the existence of a JavaScript method before you call it. You might need to do this if you're working with asynchronous calls or dynamic objects that take a while to build.

I created a sample page to demonstrate the issue and how to deal with it. I put three hyperlinks on the page that each call a JavaScript method. Here's the JavaScript code.

At the bottom of the previous code block, you'll see some JavaScript in the mainline section. This code gets executed as soon as the browser sees it. JavaScript is an interpreted language and the browser processes it in a top-down fashion. So, by definition, the browser already knows about my three methods before it runs my code in the mainline.  This is where I define an empty object to test and then create an instance of that object. Just two lines, not much so far.

When I click the link that runs the function named TestForFunction(), I perform some due diligence tests by checking for an undefined object as well as a null object. The last test with the arrow pointing to it is the key part. This will tell me if the method exists without actually running the method. I show one of two messages based on the existence of the method.

The top function named CreateFunction() just spot welds a method onto my object. Even though I've already created an instance of my object, I can still see this method in my instance because I've added the method to the prototype. When this function returns, I've got my new method. When I run TestForFUnction() again, it will see the method.

The bottom method just executes the function I added on the fly. When my DoWork() method fires, it shows a message in the alert() pop-up.

If you find that you need to deal with this type of problem in your code, inspect the object for the method before you call it. If the method doesn't exist, refactor your code to call the window.setTimeout() function for a few milliseconds and check again. Once it exists, your code can continue executing.

I was on a call with a former colleague discussing a specific technology and how it applied to his situation. It was good to catch up again with him and give some useful advice. I fielded several questions about the flexibility, complexity and fitness.

During the call, I had a thought that really stuck with me:

We (read: the world) are currently in the fifth version of the Microsoft .Net Framework, we have more AJAX libraries than you can shake a stick at, SQL Server 2008 is launching soon, and I still haven’t finished pulling tricks out of SQL Server 2005. There’s not much outside of our reach. We can customize nearly anything and change most behaviors to suite your taste. I can override methods, inject JavaScript, and execute complex database activities in just a few LINQ methods.

But… should he do this to the platform? The word “could” and “should” really stood out for me.

The answer to his specific question was a resounding yes. It was absolutely possible to do brand those pages. I was positive that my former colleague’s team could build a custom external application to manipulate the database and perform the same types of functions that come with the default installation of the system; albeit through their own unique user interface.

In this call, I was asked about completely customizing the administrative pages. My first instinct was to identify which way the cost/benefit ratio tipped.

1. Could the customer use the money elsewhere and yield more benefit?
2. Does this preclude the platform from future upgrades because of egregious customizations?
3. How many people would be subjected to these administrative pages?
4. How often are they used?
5. Does he want to support this code? One reason to buy a platform leverages on-going support and bug fixes; this path has the potential to give away that important strategic advantage.

Once a technology is chosen (no small endeavor), the best approach is to deeply understand what a platform does well and make damn sure you’re embracing it. Don’t spend valuable time fighting technology in lieu of focusing on your business. If you’re not leveraging what the platform does best, you’ve got a good sign that you’re off course or you’ve chosen the wrong platform. Go figure out which one it is and fix it – fast!

I think I visit this guy's page at least once a week to copy-and-paste a little PowerShell snippet that generates a GUID.

Write-Host ([System.Guid]::NewGuid())

You'd think that after the first ten times, I would start to memorize it. I guess when I need a GUID, I'm very far away (mentally) from thinking about the PowerShell syntax.

Harumph.

...or two.

I've had two projects this week where their/my bacon was saved by the branching strategy used for the source code repository. In my line of work, I touch a wide variety of projects. Some are still shiny new and others were written years ago; they're all in a source control repository.

Modern source control repositories (and by modern, I mean things that are not your file server or P:\ drive) let you create a branch. Branching might appear complex at first, but it's really pretty simple - at least conceptually. Here's a little story to illustrate the point of branches.

When I create a branch, I have a snapshot of the code at a particular point in time. So, imagine that on Monday, I have a single branch called the "trunk". It contains all of the code for my web site. On Tuesday, I created a branch based on the code in the trunk. I named my branch "BR-1". When I created BR-1, it was a mirror image of the trunk. I edited the code in BR-1 for a couple of days and nearly got it how I wanted it. My edits were isolated to BR-1 and they did not exist in the trunk.

I got a call early on Friday morning about an important change that needed to go out right away. I couldn't implement the urgent change to BR-1 because it contained my partially completed work. It was a pretty small change; a few hours of brilliant coding and I would be ready for a peer review of my changes. So, I checked out the trunk and made the edit right there and checked it back in. I published the urgent change I made on the trunk out to the live web site in the early afternoon and went back to working on BR-1.

By mid-day on the following Monday, I had finished all of my changes to the BR-1 branch. I had merged the BR-1 code into the trunk too. Now my trunk code contained the changes from BR-1 as well as that urgent change that came through on Friday morning. Complete control with the flick of a switch.

In the previous story, I was able to handle the urgent request efficiently because I used branching to manage my code changes. If I didn't have branching available as a software development tool, I would have some bad choices to make. Either I merge the urgent fix with my own enhancements and risk problems by rushing it, or force the urgent change to wait until my own changes were done; neither are necessary.

Branching is great way to ensure that I can always put my work on the shelf in lieu of more pressing matters. Understanding the concepts of branching is essential to being a valuable member of the team. The keys you actually press to make a branch or merge two branches can be left up to the nerdy folk. For more info, check out Pragmatic Version Control Using Subversion.

Yep, that's my head as of last weekend. I had my two remaining wisdom teeth extracted by Dr. Bell at the Head & Neck Surgical Associates in NW Portland, Oregon. Le Wife says it got a little larger than this at the peak on Sunday morning.

I had the other two extracted in my twenties back in Chicago; a truly horrible experience. I was naive for picking a dentist arbitrarily from a listing and this particular dentist was an idiot for trying to do it. He said he could take all four out without much of a problem. I hadn't gone to a dentist in years and it seemed like a reasonable thing to do; I was in my twenties, so it was time to get the wisdom teeth removed. After multiple hours of pain and agony, he removed 1.5 teeth out of four total. He packed me full of gauze and handed me the address of a surgeon. I drove my corvette to the other office and the surgeon finished taking out the second tooth in about five minutes.

So, I waited about ten years or so on removing the other two. When the Wife and I moved to Portland, we found our dentist, Dr. Halvorsen, right away via referral from a friend and we've been keeping up reasonably well with six month cleanings.

At my last cleaning, I decided to have the final two teeth removed. I knew it would take some time to recoup and the baby is coming in late April, so I made plans to have the procedure in early January and be done with it. They recommended Dr. Bell's office for some super impacted wisdom teeth.

Dr. Bell and his staff did and outstanding job. I had a consultation and scheduled the procedure for about two weeks later. They were friendly and efficient. I arrived at the office, got into the chair, chatted with the nurses, got prepped with an IV, received some drugs, and was sitting back in my car in about 60 minutes total. I nearly didn't believe him when Dr. Bell said the entire procedure would last between 60 and 90 minutes during an earlier consultation.

I *felt* like I could drive home, and the Wife just laughed. I knew I couldn't but the drugs didn't make me feel wobbly or anything, they just targeted the pain.

That night I was back on the computer working on some code. I was prescribed some oxycodone and ibuprofen for the pain and swelling and thankfully, it didn't interrupt my coding much; albeit I might have been a little slower and more *creative*.

The pills worked good as long as I kept my belly full of food. I found out that I got nauseous if I didn't eat enough food with the pills and/or I would get an stomach ulcer feeling. After I figured that out, it was much better. I probably can't go to the gym for another two or three weeks, so this isn't going to help my gut much.

Yet, I'm glad I timed the procedure with the MLK holiday because this past week stinks with pain management and thinking really hard about code. I think I only snapped with cranky responses a few times during the four day work week. :) Its much better to work alone when you're in pain. I figure another couple of weeks I'll be good as new, er... good as a thirty-four year old new guy.

Le Wife and I have tickets to some Portland Trail Blazer games this year. Last night was the first one we attended this season. It just so happened to be an opportunity to keep the streak going and make it ten wins in a row.

As a gesture of respect, I dropped Le Wife (who is now 21 months weeks pregnant) off right in front of the stadium and I parked the car. That was harder than I anticipated. I guess thousands of people congregating on a single place do tend to make traffic and parking more difficult.

Word to the wise — parking in the under the Oregon Convention Center for $6 and walking 200 yards north is very handy. Its deceptively close; walking under I–5 makes it seem farther than it really is. Plus, this lot wasn't crowded 20 minutes before tip off. I might think twice about parking there in a pouring rain, but it was a pleasant walk for me; a nice brisk evening.

The game went right down to the wire with neither team making it farther than 8 points ahead (if they did, it wasn't for very long). In the end, our guys managed to hold off Allen Iverson and Carmelo Anthony to make it ten wins in a row. The packed stadium was booming, I'm looking forward to the next game!

At one point the crowd started cheering really loud — just before the end of half time. Up on the big screen above center court was a live shot of Greg Oden sitting behind the Blazers' bench in a sport jacket and white button up shirt. He didn't see the camera and looked around quickly to see the cause of the cheers. Then he looked up at the screen above center court and realized what was going on. He grinned wide and looked down at the ground in the biggest "aw-shucks" moment I've seen in quite a while. Portland is going to love seeing this guy on the court next year!

And perhaps the biggest boon of the game — bobble-head night! I am now the proud owner of a Sergio Rodriguez bobble-head doll. There's a bright warning on the side of the packaging:

WARNING: Contents in box may make a no-look, behind-the-back pass without warning.

LINQ is an acronym for Language-Integrated Query and a new feature in v3.5 of the .Net Framework from Microsoft. This new version of Microsoft .Net reached RTM status a couple of weeks ago — this framework is chock full of brilliant things I can use to improve my efficiency and effectiveness on daily tasks here at Pop Art.

As one of my favorite features, LINQ helps me write data-driven application even faster than what .Net 2.0 brought to the table. A common example starts with launching Visual Studio 2008. After dragging a collection of tables from a SQL Server database onto a surface in my solution, I can see a visualization of the columns in the tables as well as the relationships between them. Click the following thumbnail to see a larger image.

Next, I start writing data access code directly in my C# program as opposed to switching languages and writing in the T-SQL language. Visual Studio gives me Intellisense here too; as I type the name of a table and click the period key, all of the columns in the table appear where the cursor is located. Big time saver. Huge! I'm certain that I didn't misspell a column name and that my code will compile.

The syntax for LINQ in a C# program is very similar to the T-SQL language, which is a "set based" language. LINQ statements are compiled, just like the rest of my C# code. The first thing someone well versed in T-SQL will notice is that the columns normally specified in a SELECT query are at the end of the LINQ statement instead of the start as in T-SQL. The idea is that you're articulating your constraints at the start of the LINQ statement and then pulling out the fields you need at the very end.

Behind the scenes, LINQ is using the relationships expressed in the database to generate T-SQL scripts on the fly. This is a clear line of demarcation for LINQ. If you're using stored procedures exclusively for database access, then LINQ isn't going to buy you much. You'll still get Intellisense inside Visual Studio and you can specify an existing stored procedure instead of using the auto-generated SQL, but you're giving up a lot of acceleration tools. Perhaps more than you're getting in return.

LINQ really shines in multiple table joins and aggregation. The following two blocks of code show a query is performed in LINQ and its equivalent T-SQL script. The query retrieves product information from three tables where the list price is below a given amount and a sub-category name exists. If you go the T-SQL route, you will still need to write some C# code to call your database query.

Which of the following versions would you rather author and support?

LINQ Version

T-SQL Version

MSDN is a great online resource for developers and they really hit a home-run here. They have a page with 101 LINQ samples. This is my preferred way to learn when I already know the surrounding technologies and I want to fill in a specific gap. The page categorizes several ways of retrieving and iterating over information.