Under ordinary circumstances, all three of my blog readers know that I don't like playing blue. Yet sometimes, it is the only possible response.

This is to the 1998 Honda Civic Headlight Replacement Technical Writer:

You Suck.

I'm no mechanic, but I have replaced my car battery, and I'm generally aware of what goes on under the hood. Plus, I'm a good reader. I can follow directions. In my older cars, the bulb was encased in the complete housing. A few screws and a plug-and-play later was all it took. Not so today. All you get at the store is the actual bulb. Much smaller and easier to ship.

The following images show the 1.5 page description of how to replace a light bulb in a 1998 Honda Civic.

The instructions for headlight replacement begin on the right side of the following page. The author notes some good points to understand before tackling the job.

Then, it gets into the meat of the job with a full page shown in the following image.

As you can plainly see, at no point does the author state the following truth:

If you are reading this manual, then your best course of action is to return it to the glove box and drive to your nearest Oil Can Henry's location. Request a bulb replacement and happily pay the fee knowing that (a) you didn't have to do it (2) you didn't break anything; aka, less swearing and (iii) the delta between the cost of the bulb at the NAPA auto part store and what you paid at the shop are negligible.

And for that malfeasance, this technical writer sucks. It is my opinion that anyone replacing the driver's side headlight in a competent manner would not need to resort to the manual. For if they did, it would be a clear indication of the pain to come.

For starters, a light source for working under the hood is a good idea. I used one of these pod lights. Press the light to turn it on and off. They're small and nimble.

So here's what we're dealing with. The drivers side headlight sits squarely in front of the power steering reservoir. The following image shows my finger on the reservoir. Its connected by one hose on each side and is seated on a small cradle. You can already begin to see the terribly small spaces we're about to engage.

Just from the previous photo alone, you can see how the designers failed with this bulb location on the 1998 Honda Civic. Per the instructions, I am to lift the power steering reservoir out of the cradle and push it aside so I can gain access to the bulb housing. Those two hoses that attach to the reservoir aren't too keen on movement. I finally ended up disconnecting one of the hoses and stuffing it with a rag to stop the flow of power steering fluid to my garage floor. There was quite a bit of cussing to just reach this state.

Now that I had the reservoir propped up and out of the way and the power steering spill slowed to a slow dribble, I could being the real work. The following photo shows an overhead view of the bulb housing and my light source nestled into a good crevice.

Next, I need to pinch the tabs of the bulb housing to release it. This is very important, so you would think that the book would do a good job of describing where they are and what they look like. Not so. The tabs are nearly invisible, even with great lighting. They're about the size of a small pea on each side as indicated in the following photo. Before learning this, I cracked the plastic housing on the bulb housing with the pliers. Go me!

After the bulb housing is removed, the rubber seal and wire latch can be removed to produce the following item of grief - a blown out halogen bulb. I bought a new one at NAPA for $8.00

When you're wrestling with the wire that provides a constant pressure on the bulb housing and keeps it in place, be careful not to snap off the little plastic tab that hooks onto the wire; that's bad. Grrrrrr.....

Finally, I drove (the other car) to the NAPA auto parts store (again) and purchased a small amount of power steering fluid. When I arrived, the very nice man behind the counter saw the section I was looking and advised me on a good brand of leak sealant. I explained that I actually wanted power steering fluid. Sizing me up accurately, the man tilted his head and asked why I wanted power steering fluid. Evidently, I didn't pass muster. I explained that I had spilled some quantity onto my garage floor when I was replacing a headlight. At that point I must have passed some threshold of the "i-know-what-i'm-doing" home mechanic or the "complete-idiot" home mechanic. He was nice enough to stop the inquiry there and saved me a little face. So for $3.75 I left the store with a some power steering fluid and a small funnel to refill the reservoir.

So, in summary, this experience was an absolute unnecessary pain in the ass. I realized the folly of my plan about one-third into the debacle and kept thinking of reasons that I should just fold up now and waltz in to the nearest Oil Can Henry's to stop the suffering. Yet, I persisted and now I have two functional headlights in my car, and one extra piece of wire in my garage.

I'm installing DotNetNuke v4.7 and I scroll to the bottom of the standard page that I've seen many times before, when lo and behold, I come across this for all to see!

Everyone who installs a brand new version of DotNetNuke gets to see a tiny photo of me on the cover with Shaun Walker. Sweet!

I had remarked to The Wife that she had spent over N on clothes during the past month. She retorted that it couldn't be correct.

Thanks to http://www.wesabe.com, this was an easy thing to confirm. Wesabe organizes purchases that you upload to your Wesabe account from your bank. It creates some great charts and graphs for managing your money with precious little effort. All free of course.

I returned to The Wife and explained how all of the values are tagged correctly, and the value is actually N+1. There are purchases from Motherhood, Gap, Macy's and Old Navy.

And here's the quote:

"Oh, that's why! Not all of those are clothes. Macy's isn't clothes... it's make-up."

Zing!

In my experiences as a software developer, its fairly normal to hear comments like the following:

• That's too many hours
• They don't have the budget
• I'm not paid enough

I had the good fortune of attending a Portland XP Users Group presentation a few weeks ago by James Shore. He got off on a slight tangent and gave us (well, at least me) a simple equation to chew on:

He explained that at its core, Return On Investment is represented by the previous equation. It can help explain quite a bit about the world. This was in response to someone asking about the high cost of the software development methodology under discussion that night.

If you're presented with a scenario where the value is constant, then the only way to play the game is to minimize costs. Think of a job that never changes. If it always provides the same value to a business, management will seek ways to reduce cost in order to improve the ROI equation.

On the other hand, a scenario where value has the capability for growth is much more interesting. If you wanted to make $500,000 a year then you would be challenged to deliver some multiple of that cost as a value to the business.

Here's my favorite take-away: At some point along the graph, as value increases then cost becomes insignificant. This is the place to be.

The initial cost of software can make some people squeamish. I'm certainly not one to be afraid of zeros; I'm much more interested in the value.

• What is this solution doing for the business?
• Is there a practice in place for tracking ROI over time?
• How soon can it begin providing value?
• Can it provide even more value?
• It is possible to reduce cost and drive the equation even higher?

This is why I love my job at Pop Art. Driving value higher and then swooping back to cut costs with new technology that makes me more productive. Value will often come in several forms including cash value, brand value and community value. In any case, it all starts with that equation.

I was working with a web service client that talked to SharePoint this week. I wrote a quick Silverlight app that extracted a list of tasks out of a SharePoint list. I love how simple this is to tap into:

http://sharepoint.yourcompany.com/_vti_bin/lists.asmx

The previous URL will show the path to one of the web services provided out-of-the-box by SharePoint. This particular web service provides several methods for dealing with SharePoint lists. I just needed to call the GetListItems() method and pass in the list name and view name as parameters in order to get my data.

This worked fine on my local machine, but when I migrated the solution to a staging server, the SharePoint web service refused to send me the data. After a bit of finagling, I realized the web service was happy to talk to my laptop, but it politely declined the remote web server's request as I lacked the proper credentials. I even was running the web solution with impersonation enabled because I wanted to pass along my Windows credentials during the call from the web server to the remote SharePoint server. I forgot that this is just simply not possible.

For security reasons, the web server does not hold on to my credentials "just in case" I might want to use them later. In this scenario, I do need them - but no dice. This particular list in SharePoint is locked down tight.

I didn't have the proper credentials when my web service client fired off a request to SharePoint. When I was running on my local machine, using Casinni, my credentials were readily available. On a remote web server, the credentials vanish. This is called a "Double Hop" problem - the hops are from the browser, to the web server, to another remote web server. The second hop tanked. It was a silly mistake on my part, but hopefully by writing this down now will help me remember sooner next time.

The code below shows how I solve this problem by manufacturing a credential on-the-fly and then fire off a request to SharePoint. There are multiple ways of solving this problem; I just happened to chose this one.

         MySharePoint.Lists list = new ProjectBoard.MySharePoint.Lists();

         list.Credentials = new System.Net.NetworkCredential(

            ConfigurationManager.AppSettings["Credential.Username"],

            ConfigurationManager.AppSettings["Credential.Password"],

            ConfigurationManager.AppSettings["Credential.Domain"]);

         XmlNode listItemsNode = list.GetListItems(

            ConfigurationManager.AppSettings["LoremIpsum.Guid"], 

            ConfigurationManager.AppSettings["LoremIpsum.View.Guid"], 

            null, null, "100", null, null);

         XmlNode dataNode = listItemsNode.ChildNodes[1];

         foreach (XmlNode rowNode in dataNode.ChildNodes)

         {

           // extract values here

         }

Now that I've got this little prototype functional, I can encrypt the credentials in the web.config file by using DPAPI, an encryption tool that makes it easy to protect sensitive information. Since I'm creating new credentials here, I can avoid the Double Hop problem and get on with my prototype.

By some cruel trick of nature, I've been surrounded by web content management systems for the past several years. I've written several (who hasn't?) and stood up instances of DotNetNuke, Windows SharePoint 2007, and now Interwoven TeamSite.

I'm told Interwoven has been around for 14 years and they're currently on version 6.7.1 of their TeamSite product. This offering includes features for enterprise content management (ECM) and the assorted adjacent technologies that simply must accompany ECM in a large scale deployment. Since the beginning, their product has included version control and workflow features. I'll describe a few core parts of Interwoven TeamSite here.

Source Control Repository

First off, developers will get a quick leg up if they simply know that TeamSite includes a source control repository. It works like any other. You can get the latest source, edit something, check it back in, compare versions, label a snapshot of the repository as well as branching. There. You're farther ahead than I was when I got my first explanation, about two years ago.

Standards based developers can relish in the fact that they have carte blanche control over the HTML and CSS sent down the wire to the browser. I'm talking about the production site here, not the administration pages used to interact with TeamSite. Nearly everything you'll do with TeamSite is done through a browser, providing that browser is IE or Firefox. Sorry Safari, this car is just a two seater. Again, browser support for the production site you're building is up to you - just talking about the TeamSite administration pages here. You'll continue editing specific files in your favorite tool, such as Visual Studio, Photoshop or TextMate. So once you get the subtle nuances of this source control system in you're brain, the challenge is to build a compelling web site using the same tools you have now; no silver bullets here.

Its also worth noting that this is only a source control repository; not a web development platform. You'll still need IIS, Apache, or some other web server technology to host your site. Interwoven TeamSite is mature enough that it supports Windows, Unix and Linux environments and several popular databases such as SQL Server and Oracle; just what you'd expect from an enterprise content management system.

FormsPublisher

Interwoven's TeamSite product includes a feature called FormsPublisher. This is useful for scenarios where an information worker needs to contribute to the web site, but lack HTML and CSS skills. This type of user can complete a form, let the system validate it, and then press a button to have the system generate the equivalent HTML page. The form can include validation, business logic, database queries or anything else you can dream up. While an HTML expert would prefer their favorite text editor and complete control to the HTML page. An information worker without HTML skills can now edit an existing page, based on an customized form. Now the challenge shifts to having the information worker select the appropriate form to build the page.

A developer configures a set of files and folders to support this process. At a high level, there are three parts in motion. The Data Capture Template (DCT) is an XML file that describes how TeamSite should present the form to the information worker. A Data Content Record (DCR) is an XML file that contains an instance of a form completed by an information worker. You launch TeamSite, click File, New Form Entry and select the form you want to complete. Next, the given form appears in the browser. The fields of the form are defined by the DCT. After you click the Save button, the field values are serialized into a DCR file. These files are organized in a collection of folders on the TeamSite server; one folder per form. Each folder has a conventional set of child folders to hold the DCR files as well as the presentation template file(s), These are the files with the .tpl file extension.

A presentation template converts a DCR into something else. Most of the time, at least for me, that something else will be an HTML page. Imagine a single DCR file that contains both public and private information for a company; perhaps the DCR contains public information about a single product as well as private information for their tech support staff. The DCR file can be send around via workflow for approval and the finally be ran through both sets of presentation templates which results in two different HTML files - one file is deployed to the public and the other file is kept on the Intranet. Both files are assured of having the appropriate content via the approval process and the presentation templates apply the correct branding and layout. This model supports a good workflow model as well as good separation of design from content. Its just one example of using the FormsPublisher in the enterprise.

Since DCR files are just XML, it's relatively painless to import legacy data into TeamSite. These imported XML files map to a given DCT, then they're translated into HTML pages via a presentation template. For example, if you have the last 15 years of press releases on the legacy system, you can import the existing information with some batch processes and stand up a new TeamSite server pretty quick.

Workflow

A workflow describes an automated business process. It can instruct an author to perform an edit or add a new file to the site and manage the process of approvals, taking a snapshot of the system for archival purposes and finally deployment. When a task such as "Edit Content" or "Review Content" becomes active, an e-mail can notify the appropriate party. When the work is completed, the assigned person just pushes it through the hole. Reviewers can click "Accept" or "Reject" after previewing the changes, they don't need to know the next appropriate step in the process - its automated. The system tracks the state and flow of information of the activities throughout the lifecycle according to the established business rules approved by the given company rather than based on how the given employee feels that particular day.

TeamSite has always included a workflow mechanism, but I can only imagine how difficult it was to develop them in the past. This latest version includes a Windows client application that supports drag-and-drop editing of workflow designs. You can work locally with workflows saved to your desktop in an offline mode, but you will eventually need to save the workflow up to the TeamSite server via commands in the tool. Workflows are serialized into XML files in the background, but its rare to look at the raw information. The workflow designer application helps you do the things you would expect such as setting up a series of tasks linked by arrows; some might be conditional based on human interaction or automated entirely by Perl scripts, Java classes or some other business logic.

Its interesting that Interwoven prides itself on a large number of supported platforms for the server product, but the Workflow designer client requires the Windows operating system. As I understand it, some (or all) of the workflow client application was recently purchased from another company. My hunch is the client application is written in C++ based on the look and feel as well as the OS requirement. Its a little clunky but it gets the job done; I sure wouldn't want to hand code all of the XML it generates.

Conclusion

Overall, I'm happy with my experiences thus far with TeamSite. The documentation is rich, it has a thriving online developer community, and the paradigm isn't too hard to grasp. At one point, I started getting bogged down with the massive about of XML configuration files and customization points. After sleeping on it (and a stiff cup-o-coffee) I realized that any other enterprise level application has a similar amount of customization. Since TeamSite embraces a litany of platforms, it makes sense that they don't (or haven't) invested a lot in slick little Windows GUI programs for configuration needs. Why build a server GUI tools when Windows is only one of your supported OS platforms? On the other hand, they could build a few more web based administration forms to get around some of these XML file updates. Once I started tallying up how many configuration pages I go through for Windows SharePoint, I stopped feeling like I was building my own box and installing Linux and started thinking about the broader ideas and why I was configuring the system instead of how - perhaps it just semantics, but I felt better.

I'm working on a solution that requires a special type of chart to visualize results from some elaborate number crunching algorithms. Dundas Chart for .Net has an implementation of the standard polar chart.

That's the closest "buy" option I could find and it might very well do the job. I'm a big fan of using existing software when it can solve a significant portion of the problem domain. When you find a good off-the-shelf option, they're often inexpensive and supported (by someone other than me), two big wins right off the bat. The ultimate solution has a few features that are difficult or impossible in the "buy" option, however they might be deemed insignificant. So the "buy" option might very well win out during the upcoming evaluation of my solution, but as part of my due diligence I had to see what the "build" option could offer me.

When I first envisioned the solution, I had ideas of 3D modeling like the work described by Tim Huckaby at InterKnowlogy for the Scripps Research Institute. They built a cancer research application called the Collective Molecular Environment.

Researchers from around the world can review the same model, zoom in, rotate models and insert annotations of their observations. The screenshot to the left shows one of the sample molecule views that comes with the demo. Spinning the molecule around with your mouse is pretty cool.

It's written in C# using Windows Presentation Foundation. SharePoint tracks the collaboration on the back end, but its invisible to the user. Researchers just launch the application and start clicking on cells in 3D.

Download a demo of the WPF application and twirl cells around on your own computer. The thing that floors me is that the proof of concept took only six weeks to build. WPF and SharePoint were really put to good use here.

Independently, Ben Waldron reminded me of MusicPlasma.com. You enter a band name and it shows related music artists in a 2D model using Flash. The mash-up pulls information from Amazon.com. When you click on another artist, the map adjusts and they become the new "center of the universe". Its a cool way of visualizing relational data.

Then I thought about the specific challenges I would have to solve in order to build the solution myself. I knew my data would have a central point and other points around it at various distances. Related points would have a line connecting them — not all points are related to each other. Each point would also display a short keyword or phrase.

So, to put it in mathematical terms, I had a center point at (0,0) that was surrounded by multiple invisible circles. The solution had to plot an unknown number of points on the appropriate circle. The size of each point could vary between 40 pixels and 4 pixels in size. The unique phrase beside each point could remain the same size. Finally, related points need a line connecting them.

I selected Silverlight for my proof-of-concept vehicle. Its a technology that can extend a web page and draw shapes or play video, like Adobe Flash. I first heard of this technology a while back at the MIX06 conference in Vegas. Silverlight runs on Windows and Mac OS X today and they've announced plans to support Linux so there's no worries about the supported platforms.

I use XAML or Extensible Application Markup Language to express how the Silverlight component appears on the page. The XAML used in Silverlight is a subset of the XAML used in WPF applications since Silverlight is browser based while WPF apps can take advantage of the full Windows platform. Just like a new version of the Adobe Flash player, you have to download and install the Silverlight component the first time. Then any page on the Internet that uses Silverlight can take advantage of the plugin. It takes less than 60 seconds on standard machine to download the 1MB file and install it. Here's the button created with 100% XAML just by launching Visual Studio and clicking File, New Project, Silverlight Project. With just pure XML, Silverlight can draw a fancy glossy button. Pretty cool.

Now my problem was the math. How could I calculate the points on a circle? So I headed straight to The Wife; a number crunching machine with more degrees than that Nick Lachey's boy band.

The Wife taught reminded me about some fundamental principles of algebra and geometry. As she tells it, this is sophomore/junior level high school stuff. First, I needed to calculate the central angle between two consecutive points. We'll call that theta. As it turns out, it doesn't matter where the points are, providing they lie on the same circle. For starters, I just wanted an even distribution, so if "n" equals the number of points on the circle then (2pi)/n gives me theta.

Next, I need to start calculating the exact (x,y) coordinates of the points on the circle. The first point is easy, its just (r,0) where "r" is the radius of the circle.

The second point is a little tougher as it gets into sine and cosine. These are just names for ratios in a triangle. The mnemonic SOHCAHTOA helps you remember this on quiz day. Let's look at a following right triangle.

• Sine is calculated as "opposite over hypotenuse", or the "SOH" part of the mnemonic
• Cosine is calculated as "adjacent over hypotenuse", or the "CAH" part of the mnemonic
• Just for good measure, the tangent is "opposite over adjacent", the "TOA" part

Now that I have all the ingredients, I can bake my pi. Ha! Ok, onto the task of plotting the points. The second and subsequent (x,y) values of my points are calculated by the following formulas.

• P₀ = (r,0)
• P₁ = (r(cos(θ), r(sin(θ))
• P₂ = (r(cos(2θ), r(sin(2θ))
• P₃ = (r(cos(3θ), r(sin(3θ))

For the "x" coordinate, I multiply the radius by the cosine of theta. The cosine of theta is "b" divided by "c". For the "y" coordinate, I multiply the radius by the sine of theta. The sine of theta is "a" divided by "c". In case its not obvious,  the P₂ and subsequent points need multiples of theta, so the formula has that minor adjustment.

To apply this information, I created a simple XML file with some elements that define the number of points to draw and some supporting information. I'll just focus on a single circle or level for now. If I can make one, I can make more really fast.

Next, I created a simple ASP.Net page that reads the XML file and outputs the necessary XAML that will allow Silverlight to draw the chart. My C# code iterates over the list of elements in the XML file can calculates the (X,Y) coordinates using the previous formulas. Just to keep things simple, I linked all the points to the center for now. Later on, it'll be easy enough to link other points together with lines as I have already calculated all of the necessary (X,Y) values. You can download my solution through the link at the bottom of the post.

This XAML block produces the following output in Silverlight shown below. As you can see, XAML is just a special XML syntax that is pretty easy to pick up.

To draw an ellipse shape, you add the <ellipse /> element. To draw a line on the canvas, you add an <line /> element. Of course there is tooling available to abstract these details away, but its important to have a fundamental understanding of the work going on under the covers.

Silverlight translates the XAML markup into pretty images as shown below.

If this "build" solution turns out to be a winner, we'll be able to apply nice gradients to the images, add click() events to the bubbles so more information is available through a pop-up and maybe even add the "wet floor" look the feels so cliche these days. These are easy enough in Silverlight, so I didn't spend anytime on the glossy extras just yet.

So, my entire exploration of the "build" option in Silverlight took about two hours, including the time spent with The Wife — time well spent, indeed. It'll be interesting to see how the evaluation of my solution options pan out. Can you tell I love my job?

Download the solution described in this blog post.

So, I wrote a book. I feel really fortunate to have had the experience and I am humbled by the idea that its on Amazon and store shelves across the country. The photo to the right is my brother-in-law and his charming wife with copy-in-hand, somewhere in NYC.

Late in 2006, Scott Vandehey and Kelly White were approached about writing this book. We (Pop Art) were putting the wraps on a successful 15+ month DotNetNuke project for a client and both of them had blogged a little about it. We had put together several DotNetNuke sites with an definite eye for design. After Scott Hanselman helped us dispel the notion that this book offer from Jim Minatel might be a hoax, ScottV and Kelly invited me to join the author team.

We, the three amigos, locked ourselves in a room (figuratively) and wrote down a draft set of chapters using index cards spread out over the table, and then handed out assignments. We went home and worked on a sample chapter to (1) prove to Jim that we could express ourselves sufficiently on paper and (b) to dip our toes into the waters of authorship.

When we reconvened a few days later, the mood and sobered up a little. Kelly was already full with a rich family life and a fledgling local developer community in the works. Scott had a brand new baby on the way too. The long-and-short of it is they were both honest and smart enough to know that the time commitment was too much. I have a lot of respect for them knowing it just wouldn't work rather than bailing out somewhere down the road. They showed a lot of class and professionalism.

I knew full well what I was getting into. Fortunately, so did my wife. She supported me so well during those non-stop evenings and weekends. It was a lot to bite off and she helped me so much just from the occasional drive-by-hug, or the smack-on-the-ass as I walked past her to refill my coffee cup.

I started my career with an internship at Andersen Consulting, then onto Peoples Energy, next was The Information Management Group, and now Pop Art. I've been developing software and consulting my entire career. Over time, I've learned a few important things like "Don't miss deadlines, period". So, it seemed reasonable to approach this endeavor in a similar manner. I worked out a schedule with Jim, my Senior Editor. I didn't really have anything to compare it to and Jim seemed OK with the plan so I just rolled with it. I entered into a contract with Wrox having every intention of living up to the letter and spirit of the agreement; just like any other client.

Every couple of weeks, I'd submit the next chapter to my editor, Christopher Rivera. He would manage the workflow on that side including comments from my awesome technical editor, Robert Bogue. I would occasionally have check-in phone calls with Christopher too. He did a fantastic job of helping me through this maze; a super nice guy.

Along about chapter 10 or so, Christopher chimed in on a conference call and said, "Wow, you're still on schedule. That's pretty rare." Now, I don't know about you, but that's about the worst thing he could have said for my motivation. I let out a big laugh and breathed a huge sigh of relief. I was well aware of interviews with rock star developers like MLB and others who would sign a book deal, get past the due date for the final draft, and only then sit down and start writing it.

Come hell or high water, I was sticking with the impression that rock stars can do that but not little-ol-me. This self-imposed rule of hitting my final due date with solid material worked well for releasing relevant content and minimizing the impact of my home life. Kari was spectacular for eight long months, fifteen chapters, and over 400 pages - I sure do love her.

Towards the end, Jim moved to a new position and Chris Webb became my Senior Editor. I wrapped up the book in late August. It went to production and made it out in time for the awesome OpenForce '07 conference in Vegas next week. I would have loved to attend this conference but alas, I'm in San Jose all week on business and my six year wedding anniversary is next weekend too. Ah, the trump card.

So, I'm incredibly anxious to see what readers make of it. The book describes how to design sites with DotNetNuke using modern web techniques. I steered clear of any hardcore programming or database work, the core of this book is about the front end and how to make it do-what-it-do. Inside, you'll see how to maneuver around skins, containers, modules and apply modern HTML, CSS and JavaScript techniques to the various parts of DotNetNuke. Just to add some panache, I included a few scenarios with sIFR, Silverlight and the ASP.Net AJAX Control Toolkit.

I learned a lot while I researched the nooks and crannies of this framework and I developed a sincere appreciation for the core team and all of their work to advance the platform. I haven't read tech books the same way since and the cliche dedications of "my spouse is so awesome" don't seem so cliche anymore. Its a humbling experience to have such a cool opportunity to impact a thriving community. The Wrox tag line is "Programmer to Programmer" and that's certainly the case here. I'm just a guy trying to help. I hope it helps you.

Holy shit! I'm sitting in my room, typing on my laptop and minding my own business. The entire room starts to shake and the floor feels like its balancing precariously on half a dozen tennis balls. I seriously begin to consider the possibility of the ceiling crashing down and crushing me. I step into strategic locations where I feel like there's less of an opportunity for being instantly annihilated by a slab of concrete (or is it cement?). The entire event lasts for approximately 30 seconds. Have you ever counted to 30? Its a long fricken time!

I think this is my first real earthquake. I was sitting in my living room back home and heard a "bang!" noise from my basement once; I later found out was an earthquake in southeast Portland, Oregon. This is the first honest-to-goodness pants-filling thrill ride for me.

Then, finding sites like this with up to the second reporting on recent quakes don't fill me with much ease, although it is really cool technology: http://quake.wr.usgs.gov/recenteqs/Quakes/nc40204628.html

if I understand that report correctly, I just experienced a 5.6 earthquake. Damn!

I'm sure my buddy Bruce would brush this off as a non-event as he grew up in L.A., but for a good 'ol mid-westerner like myself, these things fricken suck! Especially while I'm in the forth floor of an eight story building. Ok, I'm going to go clean myself off now.

I'm staying in a nice hotel in California this week on business. The restaurant is satisfactory, albeit a little pricey for what they deliver. The gym is OK and the room is good enough. Last week I was in Albuquerque, NM and stayed at the Embassy Suites. I didn't know I had it so good. From now on, I'll take the Embassy Suites any day of the week - there's good and then there's better.

In the evenings, after dinner and a little time on the laptop, I pop down to the bar in the lounge for a nightcap. Last night an Asian man was accompanied by his New York translator. The New Yorker's switch between a thick east coast accent and his sharp Japanese dialect was striking - a lucky people watching opportunity indeed. Its fun to watch someone speak a language that you would NEVER guess they know.

A few steps from the bar is a small doorway that leads to a large room. In the evening, the door is usually open. The room includes several lazyboy recliners, a six foot television with non-stop sports, a pool table and a desk. Seated at the desk is a small black man that looks like he can handle himself. He's probably in his mid 40's, well groomed and confident.

This room is a collection site for the U.S. Army. Each night, a handful of new young men assemble, speak briefly with the man seated at the desk and then mill about uncomfortably in the room. Some will play pool or watch the game on TV. Each man has a duffle bag that probably contains everything they'll be taking to their next stop - the base. Nearly every one of them look like they could step into the octagon in a UFC fight. They have short hair, obviously work out and don't really look at ease as they chat with other recruits or walk over to the restaurant for a free meal by way of the small ticket in their hand. I bet they all watch UFC. Well, I think I'd win most of my bets. I kind of wish I could walk over and chat about recent bouts with them.

The entire spectacle is a thought provoking experience. These are the people joining the military. This is their last night before waking up in a base or elsewhere for the next couple of years. It has a way of putting a somber mood on the room.