Learning The Basics

First, my respect to those who write for a living, particularly against a schedule.

Now, on to today's topic.

I had an interesting discussion at a July 4th party, in which I echoed a discussion I'd had with my mother several decades ago.  My mother, a third grade school teacher at the time, was telling me about the new plan at her school district to focus on job skills rather than basic math.  This meant that they'd teach the kids all about calculators, cash registers, and the like.  Stunned, I looked at my mother and asked "What are they going to do when the power fails?"  She didn't have a ready answer.

Jump forward to this past July.  I was having a discussion with someone I'd just met, who teaches a technology course at the high school level.  He asked me what I thought about teaching the basics.  So, I told him about the conversation with my mother.  I went on to say that you don't have to know how an engine works to drive a car, but a basic understanding of how the major parts of a car work together will help (maybe) when the car fails to work the way you expect.  For those of us who tinker, a basic understanding of a system gives you a starting point for troubleshooting.

In the case of computers, understanding the basics means a lot more than knowing a programming language and how to compile and run a program.  I can't think of any useful programs that don't interact with other parts of the computer, such as the keyboard, display, and files on a hard disk, floppy, or thumb drive.  Really useful programs often interact with other systems by communicating across the Internet, which then involves network interface cards, routers, modems, and Internet service providers.  When things don't work as expected and all you know is programming, you run out of troubleshooting tools pretty quickly.

So, what do you need to know to cover the basics of computers.  My stock answer is "It depends."  What you need to know depends on how you intend to use computers.  Clearly, if you want to program them, you need to know a programming language or two (or fifteen).  But you'll also need to understand how computers are organized, since your programs will be exercising the various parts of the computer and you need to understand how doing something to widget A affects widget B.  If your programming will be to control external devices, you may also need some basic electronics to understand how changing the voltage on a digital output affects the transistor, relay, or other components connected to it.  You don't need to know enough to design the electronics, any more than you need to know how to rebuild a carburetor to be able to drive a car.  But, the more basics you know, the better prepared you'll be to figure out what's wrong when things inevitably fail.

If your computer needs are such that the computer is just another tool, for Email, bookkeeping, web browsing, and such, there are continuing education programs at high schools and colleges specifically for teaching computer novices the basics.  My wife and I attended one many years ago so she could get more comfortable working with Windows.  I was the smart ass who could answer every question the teacher asked, but I could see the value of the class for people who need or want to learn about computers, but have no idea of where to start.

The flip side of the question about learning computer basics is how much do you need to know about computers if you're going into some non-computer profession?  Well, it turns out that there aren't a lot of professions where you don't use computers any more.  Sure, ditch digging.  But the engineer who planned the ditch probably used a Computer Aided Design (CAD) program to plan the route, determine the materials and manpower required, and whatever else goes into a well-engineered ditch.  Time sheet information is entered into a computer and eventually the computer spits out pay checks.  My grandson uses a laptop to do some class work at his elementary school.  Computers are pervasive enough that everyone should be comfortable enough to use them as the tools they are meant to be.

So I'm back to the beginning of this discussion.  Learn the basics.  You may never need that knowledge (like the calculus I've used twice in the past 40 years), but you never know.

Error Handling (or Lack Thereof ...)

We've all been told at some point how important it is to check for errors.  We all nod our understanding and proceed to do things the way we've always done them.  We've all done this (and we nod again).

I'm probably more adamant than most about building good error checking into a program at the very beginning.  With 40 years of programming (and debugging) experience, I've been burned plenty by poor (or no) error checking.  But I still need to get burned occasionally to remind me.

I write a lot of scripts on my Linux server to automate things.  I'm a big proponent of Cron jobs, At jobs, and Procmail for handling the thousands of little activities that need to be performed on a daily basis.  I try to make it a point in my script writing to check for errors and include at least a stub to let me know I've run into a ditch or hit a speed bump.  But, sometimes I'm in a hurry or it's very late (after 3 AM) and I think: "I'll worry about this later."  Hah!  Right!

While using my Nexus 7 last week I saw the beginning of a YouTube video that I thought I'd like to watch on my server's 22" display, so I shared the video to my server Email address.  I have a rule on Procmail that recognizes YouTube share notices and automatically captures the referenced video and queues it up for viewing.  I saw my script's notice that a video had been captured, but the video was nowhere to be seen.  Oh, must be a bug.

So, I manually issued the command the script issued, which was to run a third-party Python program.  Aha!  A string of traceback messages indicating a problem with capturing the video.  But why didn't the script do something with those messages?  Well, it did, but ...

The normal output to stdout from the Python program is a single line giving the video's title.  My script took stdout and wrote it to a file of captured videos.  So, when I really dug into the problem, I found the error messages, but not where they would have been helpful.

So, the solution here was to capture the output from stdout and count the number of lines.  If just one line, it's a good capture and the line is the video's title.  If more than one line, assume it's a traceback of some sort and report an error via Email, including the traceback text, so I get notified there was a problem and have the first level error information in front of me.

While the problem description and solution appears pretty simple, as is the nature of after-action reports, taking the time to investigate, debug, and improve the script took several hours over the period of a few days.  This was an isolated event related to a specific video, so I wasn't shut down or otherwise impeded from normal usage of my system.

So, what's my point here?

Whether it's a simple-minded script of a few dozen lines or a complex program of hundreds or thousands of lines, you need to think about error handling beyond just simply checking return codes, which you should ALWAYS do.  If you always expect one line of text, check the line count and report zero or multiple lines returned.  If you expect a certain string to be part of the line of text, check for its presence and report if not found.  When testing, try to simulate errors wherever possible so you know what gets returned and are prepared to handle it.  Oh, and even when you're checking those well documented return codes, do something about the undocumented ones, also.

Okay, I see lots of nodding heads.  Just one more piece of advice:  buy some burn ointment.  We'll all need it sometime.  I just prefer to buy mine one small tube at a time.

Hello!

The term software guy seems an apt description here in upstate New York.  Our plow guy takes care of pushing snow around.  Our stone guy provides the gravel that keeps our car from sinking into the mud.  So I’m a software guy.  And that feels right.

I’ve been programming computers since September 1968.  It started as a hobby, something to do with my best friend.  I was hooked almost immediately.  Even when I didn’t have access to a computer, I was writing code, initially in BASIC, then progressing through machine language, assembler, and Fortran before I was out of high school.  And yes, I had glasses and a pocket protector.

College was another quantum leap.  I was introduced to the IBM 360/65, then the Data General Nova series of minicomputers, then Intel’s newly introduced 4004 and 8008.  And I added a slide rule holster to my wardrobe.

College graduation was a long time ago.  At times I feel a bit like Forrest Gump, being in the right place at the right time to watch the computer business change.  Computers have gone from being the domain of the techno-wizards to being on every office desk to being in nearly everyone’s pockets.  Programming is still a bit of a wizard’s job, but even that is changing with new tools being introduced every day to make control of our ubiquitous computers easier.

So why am I writing this blog?  Good question.  I’m hoping that the process of writing will help me answer that question for myself.  In the mean time, I’ll write about what I’ve done for more than 40 years and feel I know best — software.  My current favorite software topics are Linux, C/C++, and embedded systems, so I’ll write about those.  My biggest hot button is error handling (or lack thereof), so I’ll write about that, too.

Welcome to my confessions.