Troubleshooters.Com Presents

Troubleshooting Professional Magazine

Volume 3, Issue 12, December 1999
A Tribute to Programmers
Copyright (C) 1999 by Steve Litt. All rights reserved. Materials from guest authors copyrighted by them and licensed for perpetual use to Troubleshooting Professional Magazine. All rights reserved to the copyright holder, except for items specifically marked otherwise (certain free software source code, GNU/GPL, etc.). All material herein provided "As-Is". User assumes all risk and responsibility for any outcome.

[ Troubleshooters.Com | Back Issues ]


Editors Desk

By Steve Litt

My other writing deadlines are so tight I have only 3 hours to write this Troubleshooting Professional Magazine.  Thats why this issue wasn't published until the eighth of the month. I've always found the fastest thing to write are editorials on a subject you feel strongly about. So how bout this:

Programmers Rock!

We built this world. Every bank transaction, every robotically created car, every special effect in every movie -- we programmers created it. We pound out code all day and all night. If we finish our work we do it for fun. When we've run out of fun ideas we code Open Source projects. We're unstoppable.

This issue of Troubleshooting Professional Magazine is a tribute. So kick back and relax as you read this issue. And remember, if you're a Troubleshooter or programmer, this is your magazine. Enjoy!

Steve Litt can be reached at Steve Litt's email address.

Vote for Your Favorite Troubleshooting Professional

By Steve Litt

Please vote for your favorite Troubleshooting Professional issue (by year and month) and/or article (by year, month and title).
Submit your entry to  Steve Litt's email address. The results will be announced in our third anniversary issue, which comes
out in January.

Steve Litt can be reached at Steve Litt's email address.

We Rock!

By Steve Litt
My first copy of "The C Programming Language" disintegrated in 1995 when the duct tape that held together finally gave up. It had been a constant backpack companion since 1984 when I used it to first learn C. Back in the days when I programmed professionally all day, then went home and banged out Turbo Pascal on my Kaypro 2x just for fun.

Back in those days I used to laugh at the old guys whose every thought involved a goto. Today I'm amazed at the arrogance of my youth.

It didn't cross my mind those guys didn't grow up with the luxury of 64K of memory to save subroutine states and return addresses. They had to make do with 1K or less, and they did it admirably. Older and wiser, today I know I don't have the intelligence to write such code. My generation was the first who could afford to substitute RAM for intelligence. The guys who came before us established programming as an activity and a profession. They did their job superbly.

The structured guys took programming from the research facility to the business, then to the home, and finally to what would someday be called "the enterprise". With their truly prolific functional decomposition design paradigm and their cowboy mentality, they could write programs with double the functionality in half the time. Their language of choice? C! By the time their era ended, their code was everywhere, including the architecture of the Internet.

Somewhere in the early or mid 1990's the structured crew handed the baton to the OOP guys. These guys could assemble a serious app out of a bunch of prefabricated object before functional decomposition got down to the fourth level. When they couldn't find an object, they built their own. They built objects independent of any language, that could be linked in at run time. They were called "developers", "application developers", and "software engineers", but they continued the proud tradition of "programmers". They run the world, and run it well. On the way, the OOP era took a detour. Many OOP development environments were created to fill marketing needs, not to produce robust code. Serious bugs cropped up.

Open Source to the rescue. Using the ancient C language combined with their knowledge of modern OOP concepts, they created small, fast, modular and robust software. Others used new Open Source programming languages such as Python and Perl to achieve remarkable productivity. Programmers have always loved to make money in the day and program at night (some vice versa). They were quick to join Open Source projects. Armed with the surprisingly versatile and long lived C language, and the best of modern OOP concepts (devoid of the cow pies that often accompanied popular OOP), they produced spectacularly clean code.

We rocked in the 50's, when you could list the worlds programmers in an address book. We rocked in the 60's, when geniuses plied their gotos in assembler, Cobol and Fortran. We rocked in the 70's, when we codified design concepts in preparation for large projects yet to come. We rocked in the structured 80's with our conquest of every business with more than 10 employees. And we rock in the 90's with our OOP, web, and Open Source programming. We eat too much pizza and drink too much coffee. We fly airplanes and ride skateboards.  We have long gray beards and faces devoid of peach fuzz.  We live in every nation on this earth, and we work together on a daily basis. And most of all, we pound out great code. From the first guy to boot a computer with patch cords, to the guy starting a Free Software project in his basement, we take pride in this world we've built.

Steve Litt can be reached at Steve Litt's email address.

Linux Log: The Open Source Opportunity

Linux Log is now a regular column in Troubleshooting Professional Magazine, authored by Steve Litt. Each month we'll explore a facet of Linux as it relates to that month's theme.
I've spent the last month familiarizing myself with Samba's code. No, not all of it -- that takes more than a month. But enough to know several large areas. I found root causes for SWAT 2.0.6 not showing the global, share and printer buttons to those with read permission to smb.conf, and Samba 2.0.6 roaming profiles ignoring logon path= parameter. It was tons of fun.

The Samba code base is truly beautiful. It's unbelievable what great programmers can do with non-oop C. Encapsulation? Yes, plenty. Reusability? Absolutely. Readability? You better believe it -- everything I described in the August 1999 issue of Troubleshooting Professional Magazine and more.

I was a professional C programmer from 1984 thru 1995. I thought I was pretty slick. I now know I just scratched the surface. The Samba source showed me numerous techniques I could have used -- should have used. Encapsulation via static vars. OOP like separation of program functionalities, modeling the problem domain.

Open Source projects like the Samba project give programmers the unique ability to learn from the masters. To learn the right techniques. To learn from a code base that's proved its success in maintainablity by an Open Source team, and proved its success in day to day performance. No longer are we at the mercy of the quirks of the lead programmers who mentored us, or the idealism of our school teachers, or the academicism of books and website authors. Now we can take a known good codebase and disect it. Now we truly can stand on the shoulders of those who came before us.

Steve Litt is the originator of the UMENU Software Project. He can be reached at Steve Litt's email address.

Letters to the Editor

All letters become the property of the publisher (Steve Litt), and may be edited for clarity or brevity. We especially welcome additions, clarifications, corrections or flames from vendors whose products have been reviewed in this magazine. We reserve the right to not publish letters we deem in bad taste (bad language, obscenity, hate, lewd, violence, etc.).
Submit letters to the editor to Steve Litt's email address, and be sure the subject reads "Letter to the Editor". We regret that we cannot return your letter, so please make a copy of it for future reference.

How to Submit an Article

We anticipate two to five articles per issue, with issues coming out monthly. We look for articles that pertain to the Troubleshooting Process. This can be done as an essay, with humor, with a case study, or some other literary device. A Troubleshooting poem would be nice. Submissions may mention a specific product, but must be useful without the purchase of that product. Content must greatly overpower advertising. Submissions should be between 250 and 2000 words long.

All submissions become the property of the publisher (Steve Litt), unless other arrangements are previously made in writing. We do not currently pay for articles. Troubleshooters.Com reserves the right to edit any submission for clarity or brevity. Any published article will include a two sentence description of the author, a hypertext link to his or her email, and a phone number if desired. Upon request, we will include a hypertext link, at the end of the magazine issue, to the author's website, providing that website meets the Troubleshooters.Com criteria for links and that the author's website first links to Troubleshooters.Com.

Submissions should be emailed to Steve Litt's email address, with subject line Article Submission. The first paragraph of your message should read as follows (unless other arrangements are previously made in writing):

I (your name), am submitting this article for possible publication in Troubleshooters.Com. I understand that this submission becomes the property of the publisher, Steve Litt, whether or not it is published, and that Steve Litt reserves the right to edit my submission for clarity or brevity. I certify that I wrote this submission and no part of it is owned by, written by or copyrighted by others.
After that paragraph, write the title, text of the article, and a two sentence description of the author.

URLs Mentioned in this Issue