CTO clubs, open source, outsourcing, Bluetooth

When work gets intense, blogging seems to suffer, but here are a few nuggets:

Join the CTO Club. My recent column on the thriving CTO clubs around the country brought mountains of feedback and requests from CTOs all over the country (and at least one in Europe) for help in starting a CTO club or finding an existing one to join. I promise that I will answer every one of those e-mails, but I'm still organizing them so I can respond most efficiently to them. If you're in NY, LA, Chicago, Raleigh-Durham, Denver, Boston, DC, Houston, Seattle, Memphis, Austin, Minneapolis, Madison (WI), Barcelona (Spain) or the Bay Area (among others), there is something going on in your area or there are folks interested in starting something. Look for more information in the coming days -- it's very exciting to hear from so many CTOs around the country!

Open source or outsource? In this week's InfoWorld column, I write about how my own IT decision-making process is evolving. While commercial software purchases are still on the horizon, that option seems to be diminishing in favor of outsourcing to service-based offerings with rich web services APIs (think Salesforce.com) or building functionality in-house on an open-source stack. This doesn't mean that no one is buying big commercial software packages, but with web-based interfaces becoming the norm and ubiquitous IP networks, the "where" of an application is mattering less and less, and I'm happier in many cases to not have servers sucking down electricity and spewing hot air into my own server room (I agree with the CIO who Jonathan Schwartz quoted when he announced utility pricing for Sun's N1 Grid: "there are two issues really keeping me up at night. Number one, I'm out of space in my datacenter, computing equipment and storage have filled it to the gills - and real estate's not getting any cheaper; number two, I can no longer supply enough power to, or exhaust heat from the place. I feel like I'm running hot plates, not computers.")

Bluetooth mouse and keyboard. I recently got the Logitech Cordless MX Duo bluetooth mouse and keyboard, and it's great. One of the nice features is the base station that doubles as a charger for the mouse. . but guess what? It seems like I forget to put the mouse in the charger every day before leaving work, so I come to work with a mostly dead mouse. The keyboard also came with a couple of batteries. Somehow, I just know that I'm going to be working on something important one day and have to dig for a couple of AA batteries to keep typing. Anyone who has seen remote control batteries die at an inopportune moment knows how frustrating that can be. So, that's a long way of saying Bluetooth is cool, battery-powered devices are not (but what's the alternative?)

More on my year with the PowerBook

I got some good e-mail feedback about my year with the PowerBook column -- here are some tidbits (two of these were pointed out by many people, hence no specific attribution -- thanks to all who responded):

• Daniel Gratiot recommended VueScan, a piece of shareware scanner software that works with some "unsupported" scanners on OS X. Unfortunately for me, my Visioneer was on the unsupported list. Still, it looks like a potentially nice alternative to the generally inferior scanning software that is bundled with most scanners.
• A number of people pointed me to Omnigraffle, an OS X Visio surrogate. Omnigraffle is such a well-kept secret that it actually came with my PowerBook and I didn't fire it up until now. I don't have time to fully test it, but supposedly you can import/export Visio XML files with it, and it does come with basic network shapes and client shapes for IT uses -- really detailed shapes for Apple products, right down to the iBook. Visio is still the industry standard, though, and I don't see Omnigraffle knocking it from its perch any time soon. Still, it looks like a nice piece of software.
• Others pointed me to a free download from Microsoft to deal with my Virtual PC woes: the Remote Desktop Connection Client. I have actually used this, and it works well. It delivers Windows functionality when using a Mac, but here's the catch: to employ this solution, you actually need to connect to a Windows PC over the network. Not a viable solution for when you're on a plane or when you're mobile in general (and who wants to carry around a PC laptop all the time for occasional use?) If I'm in an office where I can connect to my PC over the network, I'll just use the PC. The RDC solution saves desk space, but not much else.

DNS pain

The folks at Flickr are having (or hopefully had by now) some DNS problems. I admire Stewart and team for being straightforward about the cause of the problem -- consider it a heads up to the rest of us running Internet-based services (and who isn't?)

I actually wrote about the importance of DNS recently, so the advice is worth repeating: watch your DNS, folks -- it could happen to you.

What are the worst IT mistakes? Send 'em in!

I'm working on a feature story about the top 20 (or so) IT mistakes and wanted to solicit some ideas from the blogosphere. The mistakes can be specific ("building apps that depend on Internet Explorer") or more general ("outsourcing problems because you don't understand them"). A couple of others I have been thinking about (and for some reason, the ones I've been thinking about seem to be naturally contradictory):

• Not considering open source solutions
• Only considering open source solutions (I've seen this cause problems)
• Off-shoring
• Not off-shoring
• Focusing heavily on perimeter security but passing key traffic "in the clear" on your internal LAN (which, with Wi-Fi, might not be as "internal" as you think)
• Keeping one's head in the sand when it comes to emerging technologies instead of figuring out a way to work with users (think handhelds, IM, weblogs, etc.).

My favorite mistake so far (and this is partly in jest, but not really): thinking you are completely in control of your IT environment. (nervous laugh)

If you have some mistakes you would like to share, drop me an e-mail (chad_dickerson -at- infoworld.com) and we can talk (on the record, or off). Even better, post to your own weblog and link back to this post and I'll find your thoughts. Maybe we can get a conversation going.

While I welcome feedback from vendors who have seen their clients make the same big mistakes over and over again, I would really like to get some feedback from working IT folks. My ultimate goal is to produce a piece that will help new IT folks and old pros avoid common mistakes.

My year with the PowerBook

In this week's InfoWorld column, I look back on my first year of using a PowerBook as my primary work machine:

About a year ago, I enthusiastically switched to OS X running on a PowerBook laptop. Since then I’ve experienced the ups and downs of managing enterprise IT from a PowerBook. As a personal device, my PowerBook has become the center of my digital life in a way that my Windows laptop never did, mainly because I love the look and feel. Yet running OS X in a typical enterprise is not problem-free. A positive experience, yes, but not perfect.[read the rest here]

A couple of bonus links (because I have been neglectful of posting links to my past couple of InfoWorld columns):

• The Whining Class: Is it time to crack down on willfully clueless users who soak up support bandwidth?
• Real-world laptop recovery lessons: A story in which yours truly laments a forgotten boot disk deep in Mexico -- but not deep enough to be without Costco.

Know of CTO Clubs in Seattle, Dallas, Houston, Phoenix, Philadelphia, Chicago?

In my role as CTO of InfoWorld, I try to keep up with the regional CTO clubs scattered around the country. I'm in regular contact with the folks in NY, LA, and here in the Bay Area, but I would like to hook up with folks in other cities (not just the ones I listed above) who might be running their own CTO Clubs. If you are already running one, I would like to help you publicize it, and if you want to start one, I would be glad to offer advice and help. E-mail me at chad_dickerson -at- infoworld.com if you're interested (or know someone who is) and we can set up a phone call to talk in more detail.

If you're wondering what a CTO Club does, a ComputerWorld article from a couple of years ago explains the concept:

Outside of a few MBA programs, there are no schools that formally teach IT professionals how to become chief technology officers. But aspiring technology managers and CTOs who want to learn from their peers can receive an informal education through a number of regional CTO clubs. While there are only a handful of these groups, they appear to be broad enough in scope to help both junior IT managers and seasoned CTOs. More recently, members say, they've been especially helpful to managers by providing guidance on how to steer budgets, projects and staffs through tough economic times. [link to full article]

Dan Woods, a fellow CTO and member of our CTO Advisory Council, also wrote a column for InfoWorld a few years back describing the concept (registration required).

The essential difficulty of canonical URLs

Earlier this week, Jon Udell posted "Canonical URLs and network effects." Jon referred to a discussion we had when he brought up a URL bifurcation in some InfoWorld content:

The InfoWorld review orginally published at this URL now also appears in the new product guide at this URL. When I mentioned this to Chad Dickerson, he pointed out that even if InfoWorld.com were to enforce a canonical-URL policy internally, our stuff is syndicated out to places we don't control. So for example, the InfoWorld column at this URL also shows up as the Computerworld story at this URL.

And:

When a piece of content is syndicated into a new context, there's no reason why that new context shouldn't have its own canonical URL -- particularly if it adds value in the form of direct or indirect commentary.

As I thought about this issue over the past few days, I realized that a key point was being left out of the equation and it's this: not all original content sources are URL-addressable! In fact, I would go so far as to say there is A LOT of content that falls into this category: think content originating from AP, Reuters, and their ilk. It doesn't take long to find examples. This story on CNN.com is in fact an AP story, but you can find it on Yahoo! Asia as well (just find any CNN.com story with ".ap." in the URL, and search for a key phrase from that story at Yahoo! News, and you'll find endless examples). If you're a blogger and want to point to either of these stories, which one is canonical? Who is "closest to the source"? The answer is "neither."

CNN and Yahoo! presumably have licensing deals with the AP to reproduce these stories in whatever form they come over the wire. This is a very deliberate way of doing business for the AP (which is actually a not-for-profit cooperative). In fact, if you go to the AP home page and click on any story under the "AP News on Media Sites Worldwide" heading, the site will randomly redirect you to a page with member newspapers' branding to get your story (in three tries, I got the Tullahoma News, the San Angelo Standard Times, and fredericksburg.com). The AP presumably doesn't want to serve as the canonical home of the content it produces, because that's not how the AP works as a co-op, and despite the occasional breathlessness of folks like myself claiming that the Internet changes everything, it seems unlikely that the AP will ever become the canonical web site for the news it produces.

Before I go further, I should provide a little background on my experience with news wire content. When I first started working at a big news site several years ago, one of the first development tasks I tackled was writing mountains of Perl code to parse incoming news wire feeds. I eventually wrote most of the feed parsing code for the big sports site that I moved onto. The feeds were literally coming in over a specialized 9600 baud modem hooked into the serial port of a Sun workstation (they probably still are) via a leased line from New Jersey to Atlanta. My job was to convert this content into some reasonable URL-addressable HTML-ized content for the site. This still being the early days of the web, naming conventions were wide open, so my development tasks included coming up with a reasonable URL structure that would match how the feeds came in. For example, if an update to an existing wire story comes in, do I overwrite the existing story at the same URL, or is it a separate story? The environment I was working in was moving quickly enough at the time that I had to make editorial judgments at times with my code. My spec for parsing these news feeds was the ANPA (American Newspaper Publishers Association) Wire Service Transmission Guidelines, which was last updated in 1989. I was working with stuff like this:

Please note that the Associated Press text delimits paragraphs with CR (Carriage Return), LF (Line Feed), HT (Horizontal Tab), followed by 3 SPs (space codes). UPI uses QL (Quad Left), CR, LF, HT, followed by 3 SPs.

Drawing from the wire-parsing experience, I'll illustrate examples of non-URL-addressable content by pointing to the content produced by Sportsticker. If you're a sports fan, you have probably consumed way more Sportsticker content than you realize. Back when I was working in that world, Sportsticker data fed every scoreboard you could imagine: the "crawler" at the bottom of the screen when you watch ESPN, the scoreboards in baseball parks, the scores on CNN Headline News, the scores you hear from radio announcers, and the scores on most web sites. The reach of Sportsticker became clear to me one day when there was a temporary problem with our feed and I noticed that every sports information outlet I checked manifested the problem I was seeing (and yes, the thought that there was essentially a single point of failure for something as critical as sports scores was indeed chilling! Since then, STATS Inc. has grown more popular it seems, but I know of no other sports data services than those two.)

OK, finally to my point about non-URL-addressable content. The Sportsticker service (like all the wire services I dealt with) relied on what is known as a "slug." The Sportsticker spec defines it as such:

The SLUG provides for a maximum of 35 upper and lower case characters to identify the contents of a message. There are three different types of SLUG coding corresponding to text messages, non-text messages, and system messages. Text SLUG’s are in uppercase, while non-text and system SLUG’s are in lower case. The "bc-" in the first three positions (1-3) identify the publishing cycle as both AM and PM. The remaining positions describe the contents or the message, and differ for text and non-text messages.

The slug (combined with the date of transmission if I remember correctly) is the unique identifier for a particular story coming over the wire. In that sense, it functions as a URL of sorts, but in an entirely different namespace -- the namespace of the stream of data coming over that 9600 baud modem. Rather than point to the spec, it's easier to explain what the slug format looks like using an example from the NFL. Note that we would receive "advisories" for sports like the NFL with lists of slugs for particular sports just before the season started.

BC-FBP-STAT-AFCINTS-R
(FBP means "pro football/NFL",STAT means "statistics" -- which mean tabular data to be wrapper in <PRE> tags at the time, and AFCINTS meant "current AFC interception leaders," something that was communicated to us in the NFL advisory)

BC-FBP-LGNS-PHILADELPHROS-R
(similar to above, but LGNS meant "league news," and "PHILADELPHROS" meant "Philadelphia Eagles roster")

When I was immersed in wire parsing, we made the editorial decision to produce URLs that were easy for our users to comprehend, so in the Philadelphia Eagles roster example above, we would produce a URL that looked something like this: /football/nfl/teams/rosters/philadelphia.html. That way, a user who was on this particular page could easily change "philadelphia.html" to "chicago.html" if that user was interested in the Bears. This created a certain amount of overhead in writing our code. Some of our competitors didn't have time for such URL pleasantries, so they pumped out the same content with URLs that were closer to this: /football/nfl/bc-fbp-lgns-philadelphros.html. Not as pretty, but it was the minimal required to prevent namespace collisions when converting the wire slugs to URL-addressable content, and it worked.

So, given the reality of how the wire services work with their customers, what can we do about the problem of canonical URLs that Jon Udell discussed in his blog post? With intentionally non-URL-addressable content still bubbling up to the Internet over "old school" wire services with their own protocols and conventions and with hundreds and thousands of news organizations making separate decisions on how to present that content on their sites, I'm not sure it's an easy task.

When the going gets tough. . .

. . . the tough post quick links to their linkblog (RSS) instead of writing longer posts.

Linkblogs are great for busy folks like me who experience blog guilt occasionally.