![[IMAGE 063-065_MPW_Tips_html1.GIF]](063-065_mpw_tips_html1.gif)
The days of the solitary hacker are long past. While this reclusive species is still spotted in the
wildernesses of academia and shareware, today's commercial engineers roam the virtual plains in
herds, overcoming the incessant problems of bloated software projects by sheer force of numbers.
Like all human groups, software teams are tied together by a shared language and environment. On the Macintosh, this common ground often contains a set of MPW scripts and tools. While most developers prefer the faster compilers offered by third-party vendors, the scripting and source control capabilities of MPW make it an indispensable workhorse in team software projects. It even serves as the cornerstone of many cross-platform efforts involving both the Mac OS and that other operating system.
Following a few simple principles will greatly reduce headaches resulting from maintaining a team's MPW configuration. These guidelines may seem obvious, but I have yet to see a project that followed all of them.
ENGINEERS ARE USERS, TOO
While we may be accustomed these days to thinking
of a user interface as a sequence of pictures, a build environment in MPW is as much a user interface
as any other software system. Like all such projects, designing it naively invites the wrath of your
users --
in this case, the engineers on your team. And unlike most users, they have your direct telephone
number and know where you park your car!
The primary principle of user interface design is to stop thinking "I want to make the best X ever," whether X is a text engine, file system, image processor, build environment, or gorgonzola sandwich. That narrow form of thinking leads to excellent solutions to technical problems but systems that are difficult to use, because the model of the problem adopted by an engineer is likely to be different from that applied by an end user. For instance, to an image processing expert, rotating an image is a problem of accurate and rapid approximation across a grid, but to a scanner operator, the problem is one of deciding when to rotate, whether to do it automatically, whether to do it before or after other operations, and so forth. A technically superb rotation algorithm may completely fail to meet the requirements of the operator in a print shop if it wasn't originally designed with that environment in mind.
Balance technical problem solving by thinking through in detail how the system will be used to accomplish specific tasks. Spell out particular scenarios and make sure your solutions work in them. Otherwise, they probably won't. So, to keep the needs of your various users in mind, you need to consider not only a normal build, but auxiliary tasks such as the following:
Never assume that smart people make fewer errors. A rule of thumb is that the number of errors made is proportional to the number of possible errors, not to the skill of the user. Error prevention should be one of your guiding principles in any system design. For instance, don't require three commands in a particular order to complete a build; a single build should be a single command. If you have user interface design staff, get them involved with the development environment; their familiarity with principles such as error prevention and nonmodality could be very helpful.
Most of all, talk to your users. Ask them what they need and what their problems are. Sometimes their suggestions will be ones you can use directly; more often they won't hold up to scrutiny as actual designs, but they always indicate a legitimate area of concern that you'll need to address. Design your system on paper first, and have your users review your drafts. This time will pay off later in increased productivity.
Many of the principles of modern software design were originally developed for traditional command-line systems. See The Elements of Friendly Software Design: The New Edition by Paul Heckel (Alameda: Sybex, 1991). *
CHECK IN THE SYSTEM
An obvious, but flawed, approach to organizing a system of tools and scripts is to put them all on a
server where everyone can reach them. Each engineer is responsible for synchronizing his or her
local configuration with the latest files on the server, and anyone can improve the scripts in their
copious free time. In addition, everyone can customize their own system as much as they like.
In practice this simple scheme wastes the time of everyone on the team, because no one ever has the same configuration as anyone else. A typical frustrating conversation under this system would be:
I can't build the SuperWidgets library. Does it build for you?
Sure! Maybe you didn't get the new SourceGrinder script?
No, I got that yesterday, after I couldn't build Pat's latest brilliant changes to WhizzySnork. Let's take a look at your copy of the MungePrefix tool.
Hmmm. It seems to match yours. Gee, I don't know what the problem could be. Let's both do a complete reinstall and try again.
(Repeat until hysteria ensues.)
The solution to the problem of synchronization is to keep the build system itself under source control. When people run into problems, they'll make sure that they've checked out the current scripts and tools as well as the current source files,before they bother you about it. If they don't, they'll look silly. Since that will probably bring back unpleasant memories from the playground, they'll try harder next time.
For complex projects, you'll probably want to institute a regular build process with versioning and source archiving. When you archive the sources for a build, don't forget to archive a matchingrevision of the development environment! You may need to reproduce that build in the future, for which you'll need the source code and the exact build system.
In some larger projects, the development environment may be maintained by a group separate from the programmers who use the system. In that case, it may not be practical to archive the environment as part of a project build. The environment group needs to archive the system with named versions, and the project team needs to always build with respect to a named version of the environment. The project team also needs to record in its release notes which version of the development environment was used for each archived build. This allows the build to be reproduced from the two archives.
HAVE AN INSTALLED COPY HANDY
Bootstrapping an MPW configuration for a new engineer can be painful. There is a chicken-and-egg
problem with any script-based installation of an
MPW build system. The scripts you want to use for installation are checked in, but how does the
first-timer get to them? You can write out careful step-by-step instructions, but few engineers can
resist the temptation to improvise. You'll wind up doing it for them after all when they fail.
Instead, keep an up-to-date copy of a preconfigured MPW on a convenient server. The new user simply copies the entire MPW folder from the server to the local disk (remember those licensing restrictions,though!), edits the configuration file, and is ready to run.
THE DREADED USERSTARTUP*PERSONAL FILE
It's perfectly clear to the development environment designer that the user needs to type his or her
name where it says
Set MyName "Your Name Here"
but no one ever seems to fill in the blanks correctly without hand-holding.
It may be worth your while to write a mini-application that sets up the personal configuration file in the MPW folder. An hour or two creating a setup application witha nice, clear modeless dialog will pay for itself a few newhires down the road. More simply, you can use MPW's Request, GetFileName, and GetListItem commands in a setup script -- but a single dialog is friendlier.
This application or script should also be stored on the server where you have the preconfigured MPW folder. With a little clever scripting, you can easily arrange for the application to be run automagically if the personal configuration file hasn't yet been set up.
There are a few kinds of setup that can be done programmatically. For instance, if a script needs to know the monitor size, don't ask users to type it in themselves; an MPW tool can look at the graphics device list and figure it out by itself.
ESCHEW CLEVERNESS
One of the best programming tips I ever got was from an introductory LISP text I read a few
centuries ago as an undergraduate. It warned against cleverness in coding. On the surface this would
appear to be stupidadvice. Isn't cleverness a requirement for programming? The problem is that
when our own code strikes us as clever, it usually involves some trick or back door that's both fragile
and hard to understand, not only for the next poor sap who inherits the code, but maybe for
ourselves a month or three from now. Yet these clever tricks are rewarding. Not only does a trick
resolve a sticky problem in one swell foop, but it reinforces our belief in our own intelligence and
resourcefulness.
LISP, being inherently weird, lends itself to clever solutions. So does object-oriented programming. (I'll spare you the name of a program that buries its resolution of conflicting filenames -- dialogs and all -- deep in the bowels of a general-purpose string class.) Scripting languages such as those of MPW andcsh also encourage cleverness. Remember the scripts to accelerate launching in last issue's MPW Tips and Tricks? The form in which they were passed to me used a very clever method of signaling a cold boot: it aliased the built- in End command to Quit, bypassing the state-saving code in the Quit script. Needless to say, the potential for side effects was enormous, but no doubt someone enjoyed thinking of it! I changed the cold boot sequence to write an empty file called DontSaveState in the MPW folder, and the Quit script to detect and remove this file. It takes perhaps a tenth of a second longer, but it's comprehensible and free from harmful side effects.
KEEP IT SIMPLE, STUPID
Another common class of difficulties results from redesigning the basis of MPW. It can be tempting
to make big changes to the system, such as by changing the default value of a built-in variable like
Exit, or permanently blanking variables like CIncludes and RIncludes to prevent conflicts with local
headers.
The problem is that this turns a multifunction system into a single-function system, making MPW useful solely for the build tasks you've planned. Scripts from other sources won't work anymore, and the existing techniques and skills of people on the team may become hard for them to apply in the oddly mutated environment. Getting rid of RIncludes might make some part of your build sequence easier to manage, but what happens when an engineer wants to DeRez something by hand?
The solution is to avoid changing the underpinnings of the MPW Shell. If you need to add variables, add them as new variables -- don't mess with the old ones. Don't install patches that let you add whizzy graphical menus and floating windows if they interfere with the ordinary AddMenu and Open commands. When you do need to change something, change it only in the scope of the script where it's needed.
Among other reasons, you may someday need to have more than one build system installed. Suppose your company is acquired by the Gizmonics Institute and they have their own MPW configuration. Would you rather throw away yours and try to figure out how to shoehorn your source code into their system, or be able to run them both in the same MPW Shell? Or suppose (and I admit this is pretty unlikely) you start talking with the weirdos down the hall instead of just snickering about them behind their backs. Before you know it, you'll be drinking beer together and trying to integrate your build systems. Don't laugh; it happens.
THE JOY OF THEFT -- SHARE AND ENJOY
There are various sources for useful MPW scripts. Instead of trying to do it all yourself, you can
impress your manager by ripping off scripts from CDs, computer networks, friends, and so forth.
Sometimes even magazines have good stuff.
Apple already distributes quite a few useful scripts, such as those in the folder called DTS MPW Goodies on this issue's CD. Posting a note on a Usenet newsgroup may get you just the script you wanted in a matter of hours or days (even though you could have done it better yourself, of course).
Remember to share a little of your own work to balance the karmic load. This is the philosophy of UNIX®, and unfortunately it's better developed in that culture than in ours. Don't forget the others in the virtual herd!
TIM MARONEY has been tempered in the forge of computer networks, acquiring a rough, cast-iron finish that's often
mistaken for obnoxiousness. His favorite animal name is "Kittens," his favorite food is anything dead, and his favorite new
game involves building globe-spanning conspiracies out of overpriced trading cards. Tim supplements his seven-figure
earnings from writing for magazines by developing software for Apple. *
Thanks to Shad Ahmad, Dave Evans, Arnaud Gourdol, and Eleanor the Wonder Gerbil for reviewing this column. *
