Now is as good a time as any to point this out:

“Fluency Fumble,” the consonant title to this humble blog, never intended the kind of “fumble” that has landed the 2006-07 Steelers far afield of playoff hopes. That kind of fluency slip-up has happened along my path to better understanding IT, surely, but I hardly advertise it.

To the contrary, the kind of “fluency fumble” I imagined that very first week, when logging in for the first time, was a kind of unscripted stumble in a dark basement … arms out, grabbing everywhere, aware that the elusive pull-cord for a bare lightbulb is somewhere nearby.

Occasionally, I find the pull-cord to illuminate the room.
This was one of those weeks.

Our FLAG was charged with teaching the class about Snyder Chapter 15, “Database Queries.” A quick glance through the pages indicated to us that it was intensely technical. We elected to split things up, and I (why, God?) agreed to learn Structured Query Language and present it to the class.

As it so happens, I am an employee of GSPIA professor who chose that week to assign me to a database project employing many of Snyder’s concepts of table design and query. The work went toward the benefit of pittsburghtoday.org, a new collection of regional indicators designed to better inform local citizens about the region’s comparative status in a number of categories.

Here I was, faced with the daunting task of understanding database queries so thoroughly that I would not only be able to present it to the class, but also produce a good amount of analytical work based on database principles … all in the same week.

After a couple of quick meetings with Jeremy (thanks, Jeremy!), I gained enough information to work with the Snyder text and a number of online tutorials to find the competencies I needed. It wasn’t until the FLAG presentation and the completion of my project for the professor that I realized exactly how much I had learned — essentially, my new skill set comprised organizing various tables in an MS Access database, relating them with added master key variables, running queries to sift through large piles of information for very specific entries, combining variables to view data in new ways, and (of course) a good amount of troubleshooting.

SQL really only confused me on one count — why use it? I contacted a friend, Eric P., who works as a bioinformatics developer here in the city and apparently uses SQL every day. He insists that it’s faster, simpler and much more flexible than running queries through the design wizard in MS Access.

Sure, Eric. Probably simpler once you learn the language, eh?
For now, I’m quite satisfied to have made it through the week — and I’m certain that the new database skills will come in handy. Probably too soon.

For your perusal, here are a few of the SQL lessons I found most helpful:
w3schools.com
— includes SQL sandbox
http://www.sql-tutorial.net/
— nice, simple interface
http://www.sqlcourse.com/
— riddled with ads, but includes lots of explanation

I used to be a newspaper editor.  As such, I was Responsible — with a capital R — at the end of production to ensure that the PDF’d file containing the day’s work, tomorrow’s newspaper, made it to the presses error-free.  It was during this time that I witnessed a great phenomenon: infallibly, one hour before deadline, everything goes wrong.  The server crashes, the printer backs up, computers forget how to create PDF files, QuarkXPress switches into Spanish-language mode.  Let me share my usual troubleshooting techniques:

— Resetting computers: the magic cure

— Sighing heavily

— Unplugging the printer, then plugging it back in and hoping for the best

— Drowning my sorrows in a Diet Coke from the vending machine

As the reader might imagine, frustration and giving up often ensued.  Snyder’s section on debugging, Chapter 7, offers the antidote: logic.  The author outlines a series of steps (replicating the error, identifying the specific problem, eliminating “obvious” causes, dividing the process, and reassessment) that seem intuitive — but often aren’t, in the heat of deadline.

I’ve found what usually happens in the face of a technical problem that must be solved quickly is blame … on a user, not a cause.   Snyder points out that this isn’t all wrong: “When a computer is in an error state despite our thinking that everything should have worked out perfectly, two of the three possible problems — wrong data, wrong command or wrong system — involve us.”  We users are usually guilty, especially when under the kind of stress imposed by a pressing deadline, of getting hasty — hitting buttons and clicking rapidly around until a problem solves itself.  It happens all too often that this complicates a problem, opening up unwanted applications and sending conflicting commands to a system already suffering from some kind of error.

However, slamming buttons or blaming a peer are solutions hardly as practical as Snyder’s systematic diagnosis steps.

And for those of us who are too frustrated to even think logically through Snyder’s steps, good news — programmers offer various kinds of automatic or algorithmic debugging.  This site is a collection of links to programs designed to make the troubleshooting process simpler.  It includes, among other things, model checking, a Carnegie Mellon project for “formally verifying finite-state concurrent systems,” real-time software checking information and a variety of digital bibliographies on the subject.

Snyder’s Chapter 5, “Searching for Truth,” involves an explanation of the way information is organized and stored on the ‘net. After last week’s 90-minute in-class group presentation, I would wager there can’t be much of Google.com that we haven’t seen. However, the Internet giant hosts enough apps to keep a procrastinating amateur techblogger occupied for days.

At some point during the last five years, Google emerged from a pack of search engines that were once regarded as equal competitors. Dogpile, AskJeeves, Yahoo and most of the others still exist, but their daily hit counts are meager compared to Google’s share (last I checked, second only to myspace.com as the most popular site on the Web). Snyder’s chapter goes to show why: Excluding Google’s business prowess and unparalleled creativity in service provision, it has been quite the pioneer of Internet search as we know it, introducing PageRank and keyword-anchor reference to produce more accurate search results.

Perhaps the most useful Google app by far, for the kind of prying, stalkerish visual mind that enjoys this kind of thing, is Google Earth: “a 3D interface to the planet.” Where else can I zoom in to view a neighbor’s yard, check out the foliage along southern Germany’s Rhine river or see what Iraq looked like three years ago? Sure, most of Google Earth’s images are nondescript photos of pixelated deserts and blocky-looking fields. However, the occasional remarkable find justifies hours of scrolling through blurry images of other people’s neighborhoods.

Here’s my all-time favorite, Flying Car:

It’s in Perth, Australia. Flying Car has its naysayers, who maintain that the obvious shadow of Flying Car is actually a black car parked parallel to the car in question. Commenters on the Google Earth blog speculate that it is perhaps a car-shaped balloon, or maybe a car-shaped shed. They are obviously grasping at straws to disparage the irrefutable photographic evidence of Flying Car that Google Earth has unwittingly provided in this snapshot.

Obviously.

Other valuable GE finds include a capsized cruise ship, a bomber in mid-air, crop circles and African animals in high-res. These were collected by some blogger and can be viewed through links on his site.

Think of it this way — 10 years ago, what are the chances that I could have located a photo of a parking lot in Perth?

Google’s Google Earth app, along with the tens of other apps brought up during the presentation, is a relatively recent addition to the blinding array of information options available to anyone with Internet access. Google’s most popular new features seem to be the applications that truly innovate the way information is published, organized and reviewed — therefore, the Internet giant stands out from its competitors as not only a market-share lion, but often also as the inventor that constantly shapes and frames the way we collect and understand data.

It is probably safe to assume that the average middle-class white kid of my generation, raised during the rise of AOL and home computing, is at least somewhat familiar with Microsoft Excel. Such was the challenge for Chapter 13’s FLAG: Show us something we don’t know.

The group performed admirably.

I always assumed myself fluent in Excel. Throwing values into cells, arranging and ordering data, even a bit of calculating with formulas, I felt comfortable listing it on my resume as an application where I had achieved “proficiency.” Reviewing Snyder’s presentation on conditional formatting/calculation and truncating values convinces me that I should rethink it — I have much left to learn. The sheer number of Excel functions available is daunting, and many of them are statistical and mathematical formulas I will likely never grasp.

This makes me wonder: What else don’t I know?

More than likely, I could stand a brush-up in each of the programs I’ve listed on my resume. While it’s probably nigh impossible to “master” a program without having been involved with its programming, fluency is a spectrum, and it’s difficult to know where you stand without knowing what there is to learn.

A quick search turns up some Excel capabilities that would certainly make work easier:
Lookup table: Allows you to define fields in another spreadsheet from which you’d like to gather information. It can be used conditionally (lookup “tax capacity” where county = “Allegheny,” for example) or simply to view data in new combinations.
User-defined function : For those interested in complex mathematics or text manipulation: Create and apply your own formulas. How ambitious.
Autonumber : I had previously heard that this was impossible in Excel, so I am quite glad to learn that it does work.

I suppose this week’s lesson was one on the nature of fluency as well as practical Excel skills: There’s no upper bound to fluency.

ta-daaa

Now I’m dangerous.

My experience with HTML has heretofore been restricted to bolding and italicizing words in the middle of sentences, which has proven marginally useful on Internet message boards and completely useless in trying to impress anyone with my fluency. Luckily, Snyder’s HTML primer provides not only the code basics (good to remember), but a bit of theory on tables and borders that helps explain how HTML organization translates to page design.

I read an HTML primer …

introducing … “33ccff”

Snyder’s explanation of color is perhaps the thing I’ll remember most from the chapter. The base-16 (hexadeximal) numbering system indicates custom color combinations that are much more sensibly coded than I’d previously thought they were.

I offer a solid salute to those who attempt Web design without the help of Dreamweaver, Flash or other plug-and-go site construction software. I cannot imagine being in such complete command of the language that I could write a page by scratch. However, having even a passing acquaintence with HTML methods allows any amateur to access and manipulate already-written site code.

Every now and then, I’ll scroll up to “view source” on my browser to reveal the framework of particularly well-designed sites. Usually it’s something daunting like this:

… that’s another day.

Until then, here are a couple tutorial links to help any comrades I may have in aspiring HTML abuse:
htmlcodetutorial.com:
A really nicely organized resource, easy to find specific commands
htmlgoodies.com:
Javascript, CSS, ASP and other lessons for budding developers