Summer Cleanup

This article appears in slightly different form in the July/August 2000 issue of IEEE Micro © 2000 IEEE.

I try to write columns around coherent themes. After a while, the number of interesting items that just didn't fit into recent columns grows to the point where I need to try to make a theme out of no theme.

This month I talk about a cautionary article, algorithms, Windows, Linux, programming utilities, and an authoring tool.

Bill Joy's Warning

In the April 2000 issue of Wired Magazine, Bill Joy, inventor of the vi editor and a whole lot more since then, calls on his fellow technologists to consider the ethical implications and possible dangers of their work.

New technology has often had bad side effects. The early nineteenth century Luddites fought the Industrial Revolution, because it did so much immediate harm. The Luddites lost, but the side effects of the Industrial Revolution were fortunately not fatal to the society at large. In time, society sorted out the problems, and the benefits soon outweighed them.

Humanity, so far, has muddled through the problems of technological change. But technology is becoming more powerful, more potentially destructive, and more widely accessible. The chance that humanity will survive its side effects, accidental consequences, or malicious misuse, drops from the near certainty of the past to a lower, more frightening, level.

Joy begins by quoting at length a plausible but exaggerated and slightly hysterical passage from the Unabomber Manifesto of technologist-turned-murderer, Ted Kaczinski. Kaczinski makes good points, but I can easily see the flaws. I don't worry that we will all become slaves of robots.

Joy's approach, by contrast, is quiet, understated, well reasoned. He looks at three technologies in which our progress is quickly outpacing our ability to control them: genetics, nanotechnology, and robotics. He calls attention to some of the possible consequences of these technologies -- plague, intelligent germ warfare, out-of-control self-replicating robots, and many others. Some of the consequences seem highly unlikely, others very likely. Many are potentially catastrophic, perhaps fatal to humanity. 

Then Joy says, "OK, what do you think about it?" That's his whole point: think about it.

Most people react to an article like this by worrying about it for a little while, then putting it out of their minds. We all have more immediate problems. We want somebody else to figure it out. We've always muddled through.

 

Joy is right. There are real dangers and not enough public concern. He has taken these matters to scientific and other associations, but without much success. I agree with him that we need to consider the ethical implications of what we do. But even more than that, whether we're personally involved in these technologies or not, we must all learn more and think more about how to preserve, protect, and defend ourselves, our fellow creatures, and our planet.

I have heard Joy say in interviews that he will soon establish a means for people concerned about these issues to communicate and to become involved. Watch for it.

Algorithms

The Advent of the Algorithm--The Idea That Rules the World by David Berlinski (Harcourt, NY, 2000, 366pp, ISBN 0-15-100338-6, $28.00)

Math historians see David Berlinski's work the way political historians see Edmund Morris's memoir of Ronald Reagan, Dutch (Random House, 1999). They respect it as a work of art, but as history they see it as a lost opportunity.

Berlinski moves easily between fact and fiction, between scientific exposition and impressionistic evocations of the time, place, and human context of that science. He sketches a set of mathematical and philosophical trends and builds them into a coherent theme. The theme may be oversimplified, but much of it rings true.

An algorithm, according to Berlinski is

a finite procedure,

written in a fixed symbolic vocabulary,

governed by precise instructions,

moving in discrete steps, 1, 2, 3, . . .,

whose execution requires no insight, cleverness, intuition, intelligence, or perspicacity,

and that sooner or later comes to an end.

We all know this, but Berlinski contrasts it with the calculus (the subject of a companion book). Calculus is the basis of mathematical physics. Its continuous variables correspond directly to the real world. Its laws need no further interpretation. Physics, according to Berlinski, seeks to trace everything to final laws, which physicists discover but do not create, and historical accidents. Algorithms, on the other hand, embody intention. They manipulate symbols, which someone must then interpret, in a sequence of steps that represent a design and a purpose.

If this is so, then where does the interpretation of the genetic code fit in? Where is the design and purpose? These are the kinds of questions Berlinski attacks after he finishes his basic narrative.

In Berlinski's view, the basic history of the algorithm (like a two-minute summary of Hamlet) is as follows. 

Leibnitz devised the idea of reducing thinking to manipulating symbols for a finite library of discrete concepts. Later, Peano established axioms for arithmetic, Frege incorporated them into the predicate calculus, and Gödel, in proving his incompleteness theorem, defined the class of primitive recursive functions. Shortly afterward, Church invented lambda-calculus, Turing invented his machine, and all three formulations, as well as a similar one from Post, turned out to be equivalent.

Berlinski goes into somewhat greater detail than this, and if you read the book, you can get a good sense of the essence of all of this work. Unfortunately, the book suffers from careless editing and proofreading, which can make it harder to understand such terse formulations as Church's lambda calculus.

Berlinski intersperses little stories within the narrative. They are imaginary dialogs, sometimes involving him, or brief stories that resonate in some way with the text. At one point Berlinski talks about complexity by comparing Jackson Pollock and Andy Warhol. A Pollock painting is complex because the only way to describe it is to point to it. 

In some ways this book is simple, but in other ways it's complex. You just have to look at it for yourself. If you're interested in computers and modern thought, I think you'll find the book worth reading.

The Firewall

Earlier this year (Micro Review, March/April 2000) I wrote about Windows 2000 Server and my attempts to use a personal firewall from Zonelabs.com of San Francisco. I don't know where the fault lies, because I often install software that's not quite ready for prime time, but after a while my Windows 2000 system became completely unstable, so I reinstalled from the CD that Microsoft had sent me. In the interests of stability, I did not reinstall the personal firewall, because it was not certified to run on Windows 2000 Server.

My new configuration is stable, but it needs some sort of security, so I decided to set up a Linux firewall on a separate machine. Another benefit of the Linux machine, I reasoned, is that it can allow me to route Internet traffic for all of the machines on my network, even when one of them is connected to a corporate intranet via virtual private networking (VPN). I had this capability on the Windows system before I reinstalled Windows 2000 Server, but I have not been able to make it work since the reinstallation. Despite the fact that my old and new configurations both identify themselves as Build 2195, the reinstalled version seems to handle VPN and routing completely differently from the way the original version did.

In recent years I have worked almost exclusively with Windows systems, so I decided to ask a friend for help setting up Linux. It went smoothly enough, but it was like a blast from the past. My conscious mind cannot tell you how to operate the vi editor, but my fingers, perversely, deftly execute the arcane commands for inserting text, replacing characters, and so forth.

Quickly, the great benefits and the evident drawbacks of Linux sprang into view. I found a surplus machine (Pentium, 166MHz) that is more than adequate for Linux. To use it as a firewall, I installed a second Ethernet card (an old 10MBit one) to connect to the digital subscriber line (DSL) modem. Figuring out how to set the jumpers for IRQ and memory mapped I/O went smoothly enough. A Linux command produced a list of devices and the resources they use. IRQ 10 and memory address range 300-31F (hex) showed up as unused, so we assigned them to the Ethernet card.

This all went smoothly, but then Linux began to crash horribly. After a while we determined that the crash occurred every time we touched the mouse. Carefully avoiding the mouse, we prowled around the Linux sources and discovered that the mouse driver uses the same I/O addresses we assigned to the Ethernet card. The mouse driver, probably because it predates the facility, fails to register its IRQ and I/O addresses with the Linux command that produces the list of devices and resources. We moved the Ethernet card's I/O address block to 320 (hex), and now everything works.

Because we could look at the sources, we were able to correct the problem. Because nobody is responsible, there is no easy way to prevent other people from having the same problem. The fundamental benefits and drawbacks of Linux, side by side.

With the second Ethernet card working properly, it was easy to set up IP masquerading, the facility by which the firewall machine routes Internet traffic for the local network. The next steps, still to come, are 

Configuring the firewall for the right balance between security and convenience.

Enabling the firewall to route VPN traffic.

In future columns I'll report on those projects. [Postscript (November 2008): I never got these features to work, but I finally managed to get the Windows networking to work.]

In the course of working on the Linux and Windows systems described above, I was extremely pleased at the ease and reliability with which I was able to manipulate disk partitions using PartitionMagic from PowerQuest (www.powerquest.com). I'm not elaborating on the details, because I know they have released another version since they sent me my copy, but if you need to add, remove, resize, or perform a variety of other operations on disk partitions, you should take a look at PartitionMagic.

Programming Utilities

I have reported on the Visual SlickEdit editor and the MKS Toolkit in past columns. Both of these programming tools are highly regarded throughout the industry. Visual SlickEdit is a cross-platform programmer's editor. MKS Toolkit makes Unix commands and tools available in the Windows environment. Both are recently out in new versions.

Visual SlickEdit, version 5, MicroEdge, Apex, NC, www.slickedit.com, $275.00.

Visual SlickEdit for Linux is the first program I installed on my Linux system. It wasn't difficult, but it was a lot trickier than a Windows installation. It was wonderful to see its familiar screen in that programmer-friendly but user-hostile environment.

I've praised Visual SlickEdit highly in the past, but the new version is even more impressive. I don't do enough programming to use all of its features, but I recently used some of its new features when I had to publish printed versions of a set of Java classes. Java sources in electronic form tend to use vertical space lavishly, which can spread them out over several pages, making them hard to read. Reformatting them by hand can lead to errors, so I used the Visual SlickEdit code beautifier to do most of the job for me. The beautifier gives you a choice of styles, and, as with everything else in Visual SlickEdit, if you don't like the available choices, you can write your own in MicroEdge's macro language, Slick C.

While testing my new versions of the code, I realized that I must not have started from the latest version of the sources. I had to compare the old and new versions to see what I would have to change. Visual SlickEdit provides an amazing tool for doing this. It's called DIFFzilla, and while it's a little hard to figure out what the controls do, the side-by-side views it presents are awe-inspiring in their clarity and accuracy.

I didn't need to merge changes, but Visual SlickEdit does that even more smoothly now than it did in earlier versions. It also handles braces (curly brackets) more intelligently than it used to.

Previous versions of Visual SlickEdit had context tagging, a feature that allows the editor to give you language-specific help while you're entering a program. The current version improves on this with support for HTML, Cobol, Ada, and Delphi. It also provides support for displaying and editing Javadocs, the Java facility for embedding documentation into source programs.

If you're a current Visual SlickEdit user, the new features are well worth the upgrade price. If you don't have a powerful programmer's editor, rush out and get Visual SlickEdit. It will do wonders for your productivity.

MKS Toolkit, Mortice-Kern Systems, Waterloo, Ontario, www.mks.com, $400 - $2500.

Since I first reviewed this product (in 1992), it has matured and grown, and its marketing has become much more sophisticated. Its basic focus, however, remains the same: give programmers working in a Microsoft environment the same powerful programming tools that Unix programmers take for granted.

The product now comes in a variety of versions -- from the simplest package for a single developer to complete support for cross-platform, web-enabled enterprise development. The high end products are pricey, so be sure you know what you're buying, and why, if you take that route. I don't have enough experience with the high-end products to make a recommendation.

The basic developer tools, however, are essential productivity enhancers for any Windows programmer. If you're a current user, take a look at the new versions to see if they offer anything important that you're not getting now. If you're not a current user, you need to get MKS Toolkit and learn how to use it. It will pay off for you in the long run.

FrameMaker 6

FrameMaker is the leading tool, at least in and around the Silicon Valley, for producing printed hardware and software manuals. FrameMaker was not originally an Adobe product. They acquired it a few years ago, and for the last year or so FrameMaker users have worried that Adobe was letting it die. The recent appearance of FrameMaker 6, and its cousin FrameMaker Plus SGML 6, has quelled those worries for now.

FrameMaker 6 and FrameMaker Plus SGML 6, Adobe, San Jose, CA, www.adobe.com, $849 and $1449.

These new versions are not vastly different from the 5.5 versions. The biggest story is that they came out at all, given the doubts in the FrameMaker community about Adobe's commitment to the product.

While there are no big differences, there are a number of important improvements. The first is a greatly improved book mechanism. In the new version, the book file controls the structure more cleanly and closely, and there are many book-wide features -- like search and replace -- that you had to do one file at a time in the old version. The new version now supports the notion of a collection of books, and you can set volume, chapter, and page numbering in the book file. You can now specify a chapter's number as "continue from previous," so that you need not specify chapter numbers explicitly. This makes it easier to rearrange the chapters of a book or to share a chapter between two books.

FrameMaker 6 simplifies the process of including chapter numbers in table, figure, and page numbers. The chapnum variable replaces a complex scheme based on paragraph numbering.

Another problem with the old version was the inadequate mechanism for generating HTML from FrameMaker files. Rather than trying to improve this mechanism, Adobe has dropped it entirely and now bundles a version of Quadralay's WebWorks Publisher with FrameMaker. WebWorks Publisher handles this task extremely well.

The FrameMaker Plus SGML product is just like FrameMaker in most respects, but it facilitates generating SGML (or XML) documents. Rather than tagging with paragraph and character formats (you still can, if you like), you apply tags that show the element's place in the document structure.

If you are upgrading from FrameMaker 5.5 and you have any interest in generating XML documents, consider upgrading to FrameMaker Plus SGML 6. Adobe charges the same amount for an upgrade to FrameMaker Plus SGML 6, whether you are upgrading from FrameMaker 5.5 or FrameMaker Plus SGML 5.5.

FrameMaker is still the standard for large printed manuals, and with version 6, it looks like it will continue to be the standard for some time to come.

The Humane Interface, The Deadline

This article appears in slightly different form in the May/June 2000 issue of IEEE Micro © 2000 IEEE.

Doing It Right

This time I look at two books that aim at making life easier for humans. The first tells how to make computer interfaces that humans can use. The second uses fiction to explore the ways humans can work together to produce good software.

The Humane Interface -- New Directions for Designing Interactive Systems by Jef Raskin (Addison-Wesley, Reading MA, 2000, 254pp, www.aw.com, ISBN 0-201-37937-6, $24.95)

[NOTE: Jef Raskin died shortly after this review appeared.] Jef Raskin's best known work is the Macintosh. That product brought about a revolution in computer interface design, but yesterday's revolutionary idea has become today's entrenched paradigm. Raskin has moved on. In this book he shows the flaws of the desktop-and-application approach and explains how it can evolve into something much easier for humans to use.

Raskin centers his ideal system on your content -- not named files in a hierarchy of directories, but just content. You can have files and directories, but only if you decide to mark their boundaries in an otherwise undifferentiated sea of content.

Rather than applications to process your content, Raskin gives you individual commands. Thus, rather than buying Photoshop and Word, you buy individual (or perhaps groups of) image processing commands from Adobe and text manipulation commands from Microsoft. You can use the text commands to add text to images, and you can use the image processing commands to manipulate the images in your printed documents.

This sounds like component software or Unix filters. It's not a radically new idea, but Raskin arrives at it from a different direction. He begins by asking how he can make interfaces that humans can learn easily and use efficiently. To answer that question, he looks at the equipment on both sides of that interface: the computer and the human.

Many people have studied human cognition, but few have applied what we know about the capabilities and limitations of humans to the problems of interface design. To do this, Raskin applies techniques and observations that the cognitive psychologist Bernard J. Baars discusses in his book A Cognitive Theory of Consciousness (Cambridge, 1988).

Raskin takes a fundamental principle from Baars' work: humans can accomplish many tasks in parallel, but can only pay attention to one at a time. We all know this, but many people design interfaces as if it weren't true. Raskin gives examples of this error -- taken from widely used software products.

The fact that we have at most one locus of attention, while most tasks we perform with computers require us to accomplish a variety of subtasks in parallel, leads to the principle of automaticity: the more we can do without thinking, the more efficient we are. Anything that makes us think about what we already know how to do slows us down. This principle leads to the following conclusions:

• Interfaces should be modeless - the way to accomplish a task should be the same under all circumstances.
  
• Interfaces that change in an attempt to adapt to your actions can actually slow you down.

Raskin elaborates on these points with many examples. Some of the examples are surprising. They show the inefficiency of widely practiced interface design techniques.

Raskin turns a lot of attention to the problems of navigation. He likens current navigation methods in applications, operating systems, and the web to trying to find your way around a maze with only the ground-level view of where you are and where you've been. He proposes a two-prong approach to improving this situation: a zooming video camera metaphor for finding your way around a pictorial representation of your content, and a text-search facility that differs sharply from the most commonly used search facilities.

Raskin also applies quantitative methods to interface design. He uses the goals, objects, methods, and selection rules (GOMS) technique developed by Stuart Card, Thomas Moran, and Allen Newell to measure the relative efficiencies of alternative interfaces.

I haven't come near to covering all of the topics Raskin addresses in this marvelous book -- icons, programming environments, documentation, the number of buttons on a mouse, and even cables and connectors.

If you have anything to do with designing any aspect of computer systems for use by humans, you should read this book. People will be talking about it for a long time.

The Deadline -- A Novel about Project Management by Tom DeMarco (Dorset 

House, New York NY, 1997, 320pp, www.dorsethouse.com, ISBN 0-932633-39-0, 

$24.95) 

In 1964 I knew assembly language for the IBM 650, and I had recently learned Fortran II.  I sat down with the IBM Cobol manuals to see what that language was all about.  It took me very little time to decide that it was not a language I wanted to program in.  I don't regret this 

decision, but it shut me out of the world in which Tom DeMarco was later to flourish.  

Fifteen years and many languages later, I wound up (briefly) advising a large California bank, and the book that bridged the gap between my way of thinking and theirs was Tom DeMarco's Structured Analysis and System Specification (Prentice Hall, 1979).  I still remember how exciting it was to use DeMarco's methods to produce diagrams that represented the elements of the bank's proposed application.  The bank, however, was less concerned with the quality of the information than with the fact that my "work product" was drawn in pencil on D-size graph paper.  We parted company.  They later went out of business.  

In 1979, DeMarco was insightful.  Today he is wise.  Then he was concerned with how software modules work together.  Today he focuses on how people work together.  His book is fiction, but it teaches many real lessons about project management and team building.  

Here is the essence of the plot.  Mr.  Tompkins, a middle-aged middle manager, is laid off from a thinly disguised AT&T, kidnapped by a beautiful and resourceful industrial spy, and spirited away to Moravia, a post-Communist third world country somewhere on the Adriatic coast.  A thinly disguised Bill Gates has acquired this country secretly in a stock swap and has decided to help it dominate the shrink-wrap software business by producing knockoffs of Quicken, PhotoShop, Quark XPress, PageMill, Painter, and Lotus Notes, and giving them away.  

Tompkins takes the job of managing this development.  Because Moravia has far more programmers than required to develop these six products, Tompkins sets up three parallel projects for each product, turning the whole operation into a project management laboratory.  He gets carte blanche from Bill, and everything seems to be going smoothly.  

Just as Thompkins is beginning to feel complacent, Bill returns to the States to work on his house, leaving the sinister bean counter Allair Belok in charge.  Belok embodies every stupid, unscrupulous, bullying executive you've ever worked for.  Sadly, his tactics seem true to life. They certainly rang a few bells for me.  Thompkins must face arbitrarily shortened schedules, merging of his parallel projects, and forced overtime.  On top of this, he must contend with the well meaning purveyors of process improvement, whom Belok sics on him with even more unreasonable goals.  

Thompkins is not alone in his struggles, however.  Belinda Binda, the world's greatest project manager, burnt out and now a bag lady, agrees to help Thompkins staff his projects.  So does Ex-general Markov, former head of software development for the Moravian army.  Lahksa, the beautiful resourceful spy, runs around the world sending Thompkins consultants for 

brief visits.  The reclusive Aristotle Keneros, Moravia's first programmer, helps to divert the process improvement folks, and teaches Thompkins the importance of debugging the decomposition and interfaces during the design phase.  

That's it for the plot.  DeMarco patterned Mr. Thompkins after George Gamow's character of the same name.  Gamow had a wonderful ability to explain physics and mathematics with stories.  In One Two Three .  .  .  Infinity, one of my favorite books when I was in high school, he explains complex numbers with a story about buried treasure.  Mr. Thompkins is a 

bank clerk who goes to lectures on science, falls asleep, and has wonderful dreams that make the concepts clear.  

DeMarco has followed that tradition admirably.  His chapters are little vignettes of project management.  A problem arises, a consultant shows up to help solve the problem, and Thompkins adds a few aphorisms to his journal.  According to DeMarco, most of these aphorisms come from his own journal and represent lessons he learned the hard way.  

Here are a few of the aphorisms that I especially like: 

• Four Essentials of Good Management: Get the right people, match them to the right jobs, keep them motivated, and help their teams to jell and stay jelled. (All the rest is administrivia.)
  
• There are infinitely many ways to lose a day  . . . but not even one way to get one back.
  
• People under pressure don't think any faster.
  
• It's not what you don't know that kills you  . . . it's what you know that isn't so.

The last one is an old proverb, but DeMarco applies it to one of the sacred cows of software development, code inspection.  

I've discussed the more general aspects of DeMarco's book here, but parts of it get pretty technical -- though rarely enough to bog down the story.  DeMarco believes in metrics and modeling as project management tools, and several of his vignettes show surprising ways to use those tools.  

At the end of the book, Thompkins gives away his journal, saying "I can never imagine opening it again.  I don't need to.  I carry those hundred and one principles everywhere I go. They're carved into my hide." The book is a crash course in project management and team building.  If you do any sort of technical development, you should read it and absorb it.  

Windows 2000

This article appears in slightly different form in the March/April 2000 issue of IEEE Micro © 2000 IEEE.

On February 17, 2000, I attended Bill Gates' kickoff of Windows 2000. I've been using beta versions for a year, but now it's official, so I can talk about it.

The kickoff was an extravagant production. Television actors provided glamour as they struggled through ghastly scripts. The captain of the starship Enterprise, for example, came on stage to complain when Gates used the word enterprise to describe his new product's target applications. The great rock guitarist Carlos Santana and his band closed the proceedings, while an army of reporters and publicists fiddled with their laptops and cell phones and pretended to enjoy the music.

Unlike Santana, the kickoff show may never win a Grammy, but the demonstrations of features and performance inspired awe among the attendees. Gates trotted out benchmarks that put Windows 2000 price/performance ahead of all of Microsoft's competitors -- and well beyond that of prior Microsoft systems. Even more impressive were the demonstrations of dynamic reconfiguration and load balancing in multiprocessor clusters. An operator at a console put machines into and out of service by dragging and dropping icons, and processor usage gauges immediately reflected the automatic rebalancing. Other demos showed how easily a user with a laptop can synchronize with a server and how effectively an administrator can control and allocate resources with Active Directory (see below).

The most impressive measurements that Gates announced were of how infrequently the systems crash. Windows 2000 seems, at least in these tests, to be much more reliable and fault tolerant than its predecessors. My own experience (see below) hasn't been nearly as good as the studies Gates reported, but I test lots of software, and I reconfigure often -- all without the benefit of a trained system administrator.

The Operating System

Windows 2000 is a family of operating systems, all targeted at business users. It does not, as you might have thought from the name, replace Windows 98. It is instead an evolution of Windows NT 4. In fact, the earliest beta versions I received were called Windows NT 5.

The bottom of the line is Windows 2000 Professional, which is aimed at business desktops and laptops and at high-end workstations. There is nothing to prevent you from using this product at home, of course, but in seeking to improve security, Microsoft has removed hooks into the hardware that many video games depend on. Drivers for many older devices have also had difficulty migrating to Windows 2000, which is another obstacle to its home use.

The next member of the family is Windows 2000 Server. It's not very different from Professional, and many users will prefer it. Microsoft intends it for use as a file, printer, communications, or web server.

For high-end server applications, Microsoft provides Windows 2000 Advanced Server. This version supports huge memories and symmetric multiprocessor (SMP) configurations. It supports clustering and rolling upgrades. You might use a cluster of Advanced Server machines to support a high-traffic website.

The fourth member of the family is Windows 2000 Datacenter Server. When Microsoft releases it later this year, it will do what the other family members do, but it will support larger memories and more multiprocessors.

I quickly decided that I needed Windows 2000 Server for the tasks I want to run, so that's the only version I have direct experience with. I'm happy with it, because its user interface is much more that of like Windows 98 than Windows NT 4, and it's easier to configure unusual network configurations. I connect my Windows 2000 Server machine to the Internet via a digital subscriber line (DSL). I have a local Ethernet, and I use the Windows 2000 Server as a gateway to give the other machines Internet access. At the same time I connect the Windows 2000 Server as a client to an enterprise intranet via virtual private networking (VPN). This configuration may have been possible with Windows NT 4, but try as I might, I could never make it work.

I won't run through all of the features of Windows 2000. You can find a summary on the Microsoft website. If you use Windows NT 4, or even Windows 98 with standard business software and devices, you'll find Windows 2000 a significantly more capable, usable and reliable product.

Books

Windows 2000 will spawn a huge supply of third party books, and many have appeared already. I look at four good ones.

Active Directory for Dummies by Marcia Loughry (IDG, www.idgbooks.com, 2000, 402pp plus CD, ISBN 0-7645-0659-5, $24.99)

Windows 2000 Registry for Dummies by Glenn Weadock (IDG, www.idgbooks.com, 2000, 378pp plus CD, ISBN 0-7645-0489-4, $24.99)

It may seem incongruous to talk about anything as complex as Windows 2000 as being for dummies, but these two books, and the one that I discuss under security (below), adhere to the same formula that has made the dummies series such a runaway success. The authors know their audiences, and they talk to them as intelligent people who are just beginning to learn the subjects. While they must assume a certain degree of sophistication and general background, the authors explain everything about the topics of the books.

In addition to targeting their audiences accurately and not taking anything for granted, the dummies books enhance communication in other widely known but less widely used ways. Their page layouts, font selection, and clear illustrations draw readers in. The icons for warnings, tips, technical details, and other aspects of the text are consistent from book to book, so the more dummies books you read, the easier it is to find the information you're looking for. The informal and slightly humorous tone of the books helps establish a rapport between author and reader, despite the highly formulaic structure.

Another great strength of the dummies books is that they are task oriented. They identify the tasks you're likely to wish to perform, and they show you how to perform them. Yet the authors don't restrict themselves to a cookbook approach. With each task they give you the background to understand what you're doing and why you're doing it. This technique is sometimes called just in time learning, and studies show that it is an effective way to learn.

Blatantly stealing Apple's famous catch phrase, the dummies books proclaim themselves a reference for the rest of us. And in fact, in addition to their tutorial elements, they contain many aspects of good reference works -- starting in every case with an excellent index. The Active Directory book also has several helpful appendixes.

The registry book contains information every Windows 2000 user should know about. The registry is an evolution of the registries of Windows NT 4 and Windows 98. If those were always a mystery to you, read this book now.

The Active Directory book may be more interesting to administrators than to average users. Active Directory centralizes resource allocation and control. It is a database of configuration information, some of which would have been stored in the registry under Windows NT 4. The book leads you through the daunting task of setting up directory services for an enterprise. 

Given the important role Windows 2000 will play over the next few years, I recommend that you spend a few hours reading these books and getting the ideas straight now. That knowledge is bound to pay off as time goes by. 

Inside Windows 2000 Server by William Boswell (New Riders, www.newriders.com, 2000, 1496pp, ISBN 1-56205-929-7, $49.99)

Boswell's book is very different from the dummies books. It contains a great deal more detail, but you may have to dig harder to get it out. It is definitely more of a reference work than a tutorial. Although it contains many how-to procedures, it is not fundamentally task oriented.

The book has an attractive and readable layout, and its binding allows it to lie flat when open to almost any of its 1500 pages. It is comprehensive and clearly written. While I can't attest to the accuracy of everything in it, it does list three technical reviewers.

If you're a system administrator, you need this kind of reference book. This one seems like a good investment.

 

Security

I became a regular Internet user in the early 1980s, but I never worried much about security until recently. This was not because the threats weren't real. I remember reading a congressional report on databases and invasion of privacy more than 30 years ago, and the threats were scary then. And if you want to see how that aspect of the problem has developed, read Simson Garfinkel's new book Database Nation (O'Reily, www.oreilly.com, 2000, ISBN 1-56592-653-6, $24.95).

While I think the kinds of threats that Garfinkel describes are more ominous, I'm concerned here with the kinds of threats you can reasonably do something about on your own Windows 2000 Server machine, namely, the threats of unauthorized access to your machine and to other machines on the networks your machine connects to.

Windows 2000 Server Security for Dummies by Paul Sanna (IDG, www.idgbooks.com, 2000, 378pp plus CD, ISBN 0-7645-0470-3, $24.99)

If you're a system administrator, this book will lead you through the basic steps you can take to protect your system without totally disconnecting it from the world. Like the dummies books I describe above, this book leads you through the tasks you need to accomplish, supplying you at each stage with the information you need to understand the procedure you're following.

If you're responsible for the security of a Windows 2000 Server system, reading this book is a really good idea.

I found another excellent resource for securing Windows-based systems (not necessarily Windows 2000). This is the website of Gibson Research of Laguna Hills, California (http://grc.com). When you go to this site and the first thing you see is your name on the screen, you know you have work to do. Steve Gibson leads you through some simple steps that will greatly reduce your vulnerability.

One of Gibson's recommendations is to use the Zone Alarm 2.0 personal firewall, which you can obtain free from Zonelabs.com of San Francisco, California. I downloaded this product and have been using it more or less successfully. Zonelabs does not certify the product for the configuration I'm running, and so I don't blame them completely for the occasional blue screens of death that occur when the program fails to handle kernel mode exceptions properly.

Using Zone Alarm has been very revealing. It quite regularly reports probes from unauthorized IP addresses. I'm still tweaking the settings and learning to use it effectively, but I'm happy to have it running, despite the occasional crashes. It's certainly a product worth investigating, and you can't beat the price.

Happy New Year 2000

This article appears in slightly different form in the January/February 2000 issue of IEEE Micro © 2000 IEEE.

A Look Back

I looked back at my first columns of previous years to see if I could spot trends. It's an interesting progression. I'll let you decide about the trends.

In 1988 I complained about the way Word 3.01 implemented styles. I also reviewed books about Word Perfect and microcomputer busses.

In 1990 I reviewed a book about the problems of Japanese language computing. Most of those problems have evaporated in the intervening 10 years.

In 1992 I wrote about upgrading my Macintosh SE/30 to 8 megabytes of main memory and installing the System 7 operating system.

In 1993 I compared Word 5.1 for the Macintosh with Word for Windows 2.0, and reviewed MKS Toolkit 4.1 for DOS and books about debugging, Windows NT, friendly software design, and a realtime kernel.

In 1994 I reviewed some Macintosh utilities and a book about the Intel Pentium architecture.

In 1995 I reviewed four books about the Internet and the TCP/IP protocol.

In 1996 I reviewed Bill Gates' The Road Ahead, a book about the coming information highway. He suggests that you view mergers of ISPs and content providers skeptically. I wonder what he thinks of AOL's acquisition of Time Warner.

In 1997 I wrote about object-relational databases and reviewed a book about how Microsoft conducts its business.

In 1998 I wrote about how Apple was beginning to make a comeback, and I reviewed three interesting books about how technology will affect the society of the future.

In 1999 I wrote about Apple's G3 and iMac computers, reviewed a four-volume handbook of programming languages, and talked about my difficulties getting the Windows NT5 beta software to run on my PC.

This year I'm still struggling with Windows NT5 (now they call it Windows 2000 Server) beta software, but it's a lot better. At the moment I'm running Build 2195, and I'm quite happy with it. I'll say more when I see the released product.

Practical Programming Advice

I've read many books about programming in the last 35 years, and from time to time I review especially good ones. In the past the good ones have been few and far between, but that seems to be changing. In my Nov/Dec 1999 column, I reviewed Extreme Programming Explained by Kent Beck. This time I was delighted to discover another excellent programming book from the same publisher. 

The Pragmatic Programmer -- From Journeyman to Master by Andrew Hunt and David Thomas (Addison-Wesley, Reading MA, 1999, 321pp, ISBN 0-201-61622-X, $34.95)

Andrew Hunt and David Thomas are software consultants doing business as The Pragmatic Programmers (www.pragmaticprogrammer.com). They have produced an outstanding book about programming, and many of the insights they offer apply to other engineering disciplines as well.

In August 1993 I reviewed Steve McConnell's Code Complete (Microsoft, 1993), which assembles in one thick book everything that a journeyman programmer should know. Hunt and Thomas, in a thin book, give you a glimpse of the kind of thinking that leads to the next step -- mastery of the craft of programming. More broadly, if you participate in technological innovation and have access to computer-based tools, you can probably apply many pragmatic programming principles to your own work.

In his foreword to the book, Ward Cunningham says:

Imagine that you are sitting in a meeting . . . thinking that you would rather be programming. Dave and Andy would be thinking about why they were having the meeting, wondering if they could do something to take the place of the meeting, and deciding if that something could be automated so that the work of the meeting just happens in the future. Then they would do it.

To follow an approach like this, you must always be thinking about what you are doing, and you must be so comfortable with your tools that you can take the step from thought to reality.

Hunt and Thomas talk about tools and how to be comfortable with them. They focus strongly on basics like using plain text, command shells, scripting languages, and a good text editor. The main thrust of their book, however, is about attitude -- an approach to life. This could have led them to a programming version of the Tao Te Ching, but instead they have stayed true to their title. They find practical examples to illustrate everything they say.

Much of what Hunt and Thomas say in this book is simple folk wisdom -- care about your work, take responsibility, know when to stop, and so forth. Yet when I look at the whole package, with each homily applied to specific technical contexts, I find the book inspiring. I enjoy the affirmation of many things I've believed for years, and it moves me to return to paths I've strayed from.

The late Rudolph Langer, a great programmer and for many years the editor-in-chief of Sybex, used to collect books of aphorisms. He would have loved the way the authors boiled down much of their advice into 70 catch phrases. For example, DRY - don't repeat yourself, summarizes a deep and important discussion of how to eliminate duplication and increase orthogonality. Configure, don't integrate summarizes an important insight into how to use metadata to increase the reliability and flexibility of your systems.

When I programmed the PDP-8, I treasured a three-fold instruction card that fit in my shirt pocket. It was the only reference I ever needed. Hunt and Thomas have not matched that size target, but their book comes with a quick reference card. It contains their 70 aphorisms (they call them tips) and 11 checklists. For example, the Law of Demeter for Functions checklist says

An object's methods should call only methods belonging to:

• Itself
  
• Any parameters passed in
  
• Objects it creates
  
• Component objects

The authors' discussion of this law occurs in a chapter on flexibility. It's a good example of how they move easily between generalities and specifics.

I could go on and on about this book -- the discussions of projects, the exercises and answers, the references, the bibliography and resource lists. It hangs together and communicates its message extremely well. And not surprisingly, the authors applied many of the methods and philosophy they describe to producing it.

If you're a programmer, or even if you're in a seemingly unrelated engineering discipline, Hunt and Thomas have a lot to say to you. Buy their book. Read it. Become a pragmatic programmer.

Extreme Programming, Cathedral and the Bazaar

This article appears in slightly different form in the November/December 1999 issue of IEEE Micro © 1999 IEEE.

Changes

In my final column of the 1900s I look at two books that challenge twentieth century ideas about developing software and making money from it.

Extreme Programming Explained by Kent Beck (Addison-Wesley, 2000, 212pp, ISBN 0-201-61641-6, www.awl.com, $29.95)

Kent Beck knows how to design and implement software. He advocated using design patterns years before most people had heard of them, and he pioneered CRC (classes, responsibility, collaboration) cards, a low-overhead design methodology.

Programming lies between art and engineering. Too much influence from either can make it an economically unprofitable activity. Isolated artists, working from an inner vision, can produce brilliant work, often quickly. But it's a rare artist whose inner vision coincides with what users want.

Engineering, on the other hand, is thorough and methodical. Engineers insist on complete functional specifications. They devise comprehensive testing regimens, prepare and verify detailed design plans, then build the product. They constantly review each other's work and monitor their adherence to the plan.

This style of engineering requires long product cycles, especially when measured by Internet time. Even a thorough analysis phase usually fails to produce a functional specification that perfectly foresees and communicates what end users need and how they will use the product. This leads to changes, which often produce delays and weaken the overall design.

Extreme programming (EP) adopts the proven techniques that make engineering robust but replaces the long product cycles. An EP project compresses the cycle of specification, design, implementation, and testing into a time period of a week or so. Within that period it uses smaller cycles -- some as short as a few minutes. In this way it replaces the ballistic approach (that is, plan the whole trajectory, then blast off) with frequent course corrections based on feedback.

Beck calls his style of programming extreme because he pushes accepted techniques and principles as far as he can. For example, he requires two programmers to participate in any programming session, leading to non-stop code reviews. Programmers write tests before they write code, and they perform unit testing every time they change anything.

Beck integrates and tests the entire system many times per day. Customers (he requires one to be part of the team) continually test the system's functionality.

Beck clearly separates the roles of customers, management, and developers in defining the functionality and dates of releases. He requires releases to be as small as possible, consisting of just the most important new features. Customers receive new capabilities every few weeks. As they use them, they discover important possibilities or gaps, and these help define the content of subsequent releases.

Because the project meanders in this way, EP requires each piece of software to be the simplest that supports the current requirement. It avoids designing on speculation. As a result EP calls for frequent redesign or refactoring. In other design methodologies, redesigning something that already works is anathema. EP's frequent testing makes this a low-risk activity. EP programmers who see ways to simplify the design or eliminate duplication are obliged to do so. Anyone can modify any code at any time -- no matter who wrote it.

Because communication is such an important part of an EP project, Beck requires the project to have a single overarching metaphor. He bases all project jargon on the metaphor, and he uses it for everything from talking with customers to deciding how the code should work.

Beck's book is easy to read. He explains the principles well, and he doesn't bring in a lot of unnecessary detail. You can read it in a few hours. Then you'll know what EP is and how it works, but you won't really know how to do it. For that, Beck advises, "you will have to go online, talk to some of the coaches mentioned here, wait for the how-to books to follow, or just make up your own version."

If your programming projects aren't proceeding as effectively as you'd like, read this book. You'll probably find something you can use.

The Cathedral and the Bazaar by Eric S. Raymond (O'Reilly, Sebastopol CA, 1999, 280pp, ISBN 1-56592-724-9, www.oreilly.com, $19.95)

In the summer of 1968 the company I worked for hired two high school students to modify Digital's PDP-8 assembler. They moved the symbol table from core memory to disk, maintained it in alphabetical order, and replaced the linear search with a binary search. In the early 1970s I modified programs from DEC, Hewlett-Packard, Data General, and Varian. All of those companies provided source code. Nowadays, few companies do so.

Eric Raymond has been producing open source code for about fifteen years. Much of it is still popular today. Nonetheless, Linus Torvald's Linux project went against much of what Raymond thought he knew. His efforts to understand the Linux model and his experiences leading the Fetchmail project led to the essays in this book. They contain interesting technical and sociological observations of the open source process, and they contain aphorisms embodying the lessons Raymond learned from the Fetchmail project. My favorites are:

• Release early. Release often. And listen to your users.
  
• Smart data structures and dumb code works a lot better than the other way around.

The first of these leads to a style similar to Beck's extreme programming. It responds to the impatience and the parallelism of the Internet culture.

I've heard the second in many forms over the years. Raymond cites Brooks's Mythical Man Month (1969) for one version. I remember the stress Butler Lampson placed on this point in his 1968 lectures on operating systems at UC Berkeley. It's so important, and so often ignored.

If Raymond had stopped at the observations and the aphorisms, this would have been an excellent book. He goes on, however, to frame broader general principles. They seem plausible, but he presents many of them as facts and mixes them with the other material. I think this detracts from the clarity and value of the book.

Despite the quibble, you should read this book. It provides useful insights into the open source movement and its place in the future of software development.

Pot Pourri

This article appears in slightly different form in the September/October 1999 issue of IEEE Micro © 1999 IEEE.

This time I look at a loosely related collection of interesting ideas. Jini is a new technology from Sun. It aims at enabling you to network anything, anytime, anywhere. Java is a programming language and a platform. It has matured considerably since I first wrote about it (Micro Review, June, 1996). WinWriters is a support organization for online help developers. They recently put on a conference about JavaHelp. Adobe Acrobat is the principal tool for working with Adobe's portable document format (PDF).

Jini

Many people have recognized the potential of large numbers of mildly intelligent communicating  devices. Devices as disparate as switches, lights, cameras, sensors, printers, vending machines, and large relational databases might all benefit from exchanging information. In the 1980s, Micro's editor-in-chief, Ken Sakamura, headed the TRON Project, a large cooperative effort based on this idea.

Java's roots are in embedded systems and consumer electronics. From the first, it was also intimately associated with networking. Jini brings these threads together to provide a model for networking arbitrary devices.

Many systems for distributed computing run afoul of the seven fallacious assumptions identified by computer scientist Peter Deutsch:

• The network is reliable.
  
• Latency is zero.
  
• Bandwidth is infinite.
  
• The network is secure.
  
• Topology doesn't change.
  
• There is one administrator.
  
• Transport cost is zero.
  

Jini provides explicit support for the difficulties and failure modes that these assumptions try to hide. The result is a powerful mechanism built on a few simple ideas and protocols. Because it builds on Java, Jini leads developers to this mechanism along a short, familiar path.

Here is a slightly oversimplified explanation of what Jini is and how it works. It begins when someone starts a lookup service, which is essentially the only piece of system administration required. Devices that have services to offer can register with a nearby lookup service when they connect to a network. They don't need to know its location in advance.

Registering means leasing space on the lookup service for a small proxy program to be downloaded to devices seeking services of the registered provider's type. The proxy knows how to communicate with the provider and implements a standard interface for services of that type.

Jini has a concept of remote events. It is a simple model that separates the event mechanism from event policy, leaving the latter to individual applications. It facilitates the use of third-party event listening services, and it supports Jini transactions. Transactions are the key to designing robust, reliable distributed applications.

This brief overview of Jini doesn't capture all of the details--even all of the major details. I hope it gives you the general idea.

Core Jini by W. Keith Edwards (Prentice Hall, 1999, 812pp, www.phptr.com, ISBN 0-13-014469-X, $49.99)

Keith Edwards is a researcher at Xerox PARC, where he works on distributed object technology and user interfaces for information management. He was an early Jini user -- long before its first public release. He understands the underlying issues and philosophy, and he explains them clearly in this book.

Edwards' book is especially valuable, because he combines an intelligent discussion of the underlying concepts with a clear explanation of how to perform the basic tasks. He understands what developers need to know, and he explains the material patiently, using complete, working examples to illustrate the points.

Edwards sees Jini as resting on five key concepts: discovery, lookup, leasing, remote events, and transactions. He explains these concepts lucidly and shows how they fit together to make a complete workable system. If you read this explanation carefully, you will understand Jini at a significant and useful level.

On one hand, I'd like to say that everyone should read this book. This is surely true of the first 120 pages, which cover the conceptual material. On the other hand, this is a highly technical book. If you're not a working Java programmer, most of the book will make difficult reading. With that caveat, I recommend it highly.

Java

Java Power Reference by David Flanagan (O'Reilly, 1999, CD-ROM, www.oreilly.com, ISBN 1-56592-589-0, $19.95)

The Java Power Reference is a CD-based top-level quick reference for the Java 2 platform. It provides useful functionality not available elsewhere, but it falls short of what Flanagan could have done with the material he has already produced for his books.

Flanagan's Java in a Nutshell (see Micro Review, June 1996) has grown into a series of four books, making quick access and effective cross referencing difficult. The material cries out for an online approach. Rather than taking this approach, Flanagan has decided to leave the detailed material to the books. He says:

So, while Java in a Nutshell contains a paragraph or two about each class and interface, the Java Power Reference contains a paragraph or two about each package.

At 107 megabytes, the Java Power Reference falls far short of filling the CD. I think Flanagan would do his users a service by copying those extra paragraphs from the books onto the CD. In fact, I'll be surprised if he doesn't do something like that after he brings all the nutshell books up to date.

The best thing about the Java Power Reference is that it gives you an overview of the Java 2 platform and lets you explore it. You can find a lot of tantalizing packages, but you won't find many words about what they do and how the designers intended you to use them.

The other important thing the Java Power Reference gives you is a search capability. You can search for any package, class, method, or field name, without having to hunt through the hierarchy for it. You can even perform wildcard searches for names you're not sure of.

The Java Power Reference is a useful supplement to the online documentation that comes with the JDK distribution. It's not everything it could be, but it's well worth the price.

WinWriters

The WinWriters organization (www.winwriters.com), based in Seattle WA, specializes in training and supporting developers of online help systems. Their principal, Joe Welinske, is an expert in the field and a good organizer. In May, 1999, I attended their JumpStart Conference for JavaHelp Technology.

JavaHelp is one of many HTML-based formats for online help. Because the JavaHelp API is based on the Java foundation classes (JFC), the JavaHelp format is well suited to providing online help for Java programs. It provides many excellent capabilities not available in other formats.

All the major vendors of online help authoring tools have announced support for JavaHelp, but Sun is not supporting the JavaHelp API aggressively. You can find the JavaHelp page on the java.sun.com website if you already know the URL, but the main pages have no obvious links to it. The field of HTML-based online help methodologies is extremely competitive, so JavaHelp is unlikely to succeed if Sun's support remains lukewarm.

Despite JavaHelp's uncertain future, I'm glad I attended the JumpStart Conference. WinWriters put together a focused series of presentations that covered the material. They integrated vendor presentations with talks by relatively impartial (and highly regarded) online help developers. They accommodated questions, but kept the program on schedule and deflected the occasional "I just want to hear myself talk" contributions.

WinWriters puts on many conferences of this sort. I haven't attended others, but I have heard only good reports of them. The WinWriters website contains summaries and supplemental information from recent ones. Be sure to visit it if you are interested in online help systems.

Adobe Acrobat

Adobe's PostScript language created the desktop publishing industry. It decoupled publishing applications from printer drivers by providing a universal output format. It made WYSIWYG possible by carrying the same output format to display screens.

While PostScript works well for communicating between computers and printing devices, PostScript files are not very good for document storage and interchange, because they are large and difficult to manipulate. Adobe's portable document format (PDF) addresses this situation. Adobe Acrobat, and its companion program, the distiller, convert PostScript files into much smaller PDF files. The freely available PDF viewer allows anyone to view or print PDF files.

These programs have been evolving for several years, and Adobe has just brought out version 4 in a convenient package.

Adobe Acrobat 4 (Adobe Systems, www.adobe.com, $99 upgrade)

Because the PDF reader is freely available and many websites provide some documents in PDF, I assume you are generally aware of the features and capabilities of version 3. Version 4 provides substantial improvements in many areas.

Acrobat 4 facilitates collaborative review of PDF documents through its support of annotations and digital signatures. PDF places annotations in separate layers on top of the original, so you can always see and recover the original. It lets you view and manipulate annotations in a number of ways. Acrobat 4 includes many annotation tools (pencil, clip art, highlighter, and so forth) that were not available in earlier versions.

Acrobat 4 also provides better and clearer options for font bundling and file compression. These were sources of problems with prior versions. It is increasingly likely that high-end print shops will accept PDF 4 documents as input. Adobe provides a mechanism for print shops to specify packages of options to allow you to prepare PDF files to their specifications.

You can convert documents to PDF much more easily than with earlier versions. In many cases you can simply drag documents to the distiller icon. Microsoft Office 2000 programs can all write PDF directly.

One of my favorite features is Acrobat's ability to capture individual HTML pages or entire websites. The resulting document contains all of the links in the original but resides in a single file. You can view or print it in formatted pages, without the usual awkward breaks of printed HTML pages.

Acrobat 4 is a significant improvement over Acrobat 3. It will make many people's lives a lot easier. If you haven't got it yet, rush out and buy it. It's a real winner.