HyperCard Headstart, Part One
by J.R. Mooneyham
ORIGINAL PUBLICATION DATE: SUMMER 1994
_______________________________
_______(Free JavaScripts provided by The JavaScript Source)_______
|
Introduction
HyperCard Headstart is meant to help bridge the gap between absolute novice and
moderately experienced scripter; a gap which might otherwise prove difficult for
some users of HyperSavvy v1.0 (the companion stack to this piece) to surmount. Although
presented in the format of a separate stack from the magazine, and made available on America
On-Line as a separate download for user convenience, HyperSavvy is an integral part
of the FLUX Summer 94 issue; so if you don't have it, you only have roughly half
of this issue of FLUX.
HyperSavvy v1.0 is powerful template stack, brimming with scripts and techniques
useful to serious stack developers. However, HyperSavvy probably qualifies as being
in the intermediate to advanced level in regards to scripting instruction; ergo,
the purpose behind this article.
All this being said, this article is not intended to substitute for the HyperCard
User manual or other reference texts. It is solely designed to provide beginning
scripters with a look at HyperCard through the eyes of an experienced scripter and
programmer, in an attempt to hasten their personal progress, and help them better exploit
HyperSavvy specifically, and HyperCard in general.
If there's any discrepancy discovered between the explanations given in HyperSavvy,
and those given here in the Headstart series, let HyperSavvy have the final say.
Why? Because in HyperSavvy the scripts are "live", so if I overlooked something,
or momentarily forgot a bit of syntax in my writing of the instructions there, the malfunctioning
script would instantly get me back on track, causing me to correct my error. Here
in this article though, I can offer you only the same level of accuracy other articles or books on the subject do, since there are no live scripts to call my attention
to flaws in the text.
Those of you familiar with other references on HyperCard, or even for other programming
languages, will recognize what I'm talking about. It's not unusual for a user to
find a script or program listed in a text to be flawed or incomplete, due to some
detail overlooked by the author. Even in the best of texts, like Danny Goodman's HyperCard
Handbook series, users will occasionally type in a script from the book only to find
it doesn't work as it's supposed to. The problem is the thousands of details in syntax, and the non-digital nature of the human mind. For example, not long ago I found
I was typing
lockscreen
in this piece when I should have been typing
lock screen
. What's the difference? HyperCard has no idea what the first version means, when
it's used as a standalone command; it requires the space in the middle to understand
what I'm talking about. And yet, in the second way of setting that value, by saying
set the lockScreen to true, it is
proper to leave out the space! See how easily I or any author can cause you possibly
hours of frustration with the tiniest lapse in memory? We try to minimize such things,
but it could literally require the rest of our lives to insure that every last mistake was squeezed out of a book or large article like this one-- so if we did everything
possible to make these things absolutely perfect they'd never be published in time
for you to use them! This article won't be worth squat 25 years from now, because
everything will have changed so much. Heck, it may be obsolete just within a year or
two, if something extraordinary happens among Mac authoring tools. So all I or any
author can do is give you the most and best we can, as quickly as we can-- and hope
you'll forgive our human errors.
In order to get hands-on experience with the levels of HyperCard discussed here,
a user will require either the HyperCard Development Kit from Apple, or an issue
of FLUX magazine, issue Summer 94 or later, along with HyperCard Player 2.1.
This article addresses HyperCard from the standpoint of version 2.1-- two versions
older than the latest currently available (2.3). There's a few differences between
the versions that will directly affect some of the instructions given here-- but
not much. For example, v2.2/2.3 makes it slightly easier to create default buttons in stacks;
not a great leap from the technique described in the Headstart articles. As for the
hoopla over the added animation and color capabilities of 2.2/2.3 compared to 2.1,
well, the reader will see by the end of this series many reasons why those elements
may not be very important to a great many stack developers; at least, not as important
as a HyperCard compiler, or across-the-board platform compatibility would be.
HyperCard's strengths
HyperCard is a powerful, high level, visually oriented programming language.
By powerful, I mean you can often create in weeks a simple application that could
require months or years in another environment. By high level I mean the syntax is
much closer to plain english than many other programming languages. By visually oriented, I mean HyperCard is heavily slanted towards visual presentation, or a GUI (graphic
user interface).
Object orientation.
Virtually everything you do in HyperCard is oriented towards the modification or
description of a particular object: a button, a card, a text field, etc. Almost any
object in HyperCard can possess its own script, or separate program. This fact usually
makes it much easier to develop, debug, and understand a HyperCard program than is the
case with many other languages.
Development speed.
As mentioned before, many kinds of programs can be completely developed and released
in HyperCard format before they even get out of the planning stage in another language.
The learning curve in HyperCard may offer the gentlest slope of all high level
programming languages available today.
The gentle slope means scripters rarely must endure the same levels of frustration
other language users do, while learning. But be forewarned; this is a relative comparison
only; that is, other languages are often so awful in this regard that they can make learning to speak Japanese seem easier. So when I say HyperCard offers the easiest
learning curve in existence today for high level languages, that's like saying it's
better to be shot with a .22 caliber pistol than a .45-- the real difference may
not seem like a lot at the time, for beginners. No matter what language you commit yourself
to learning, there'll be some pain and anguish involved. I guess the best way to
say this is that HyperCard is to programming what the Mac is to personal computing;
both are far from perfect, but both are also a lot better than the alternatives available
at the moment.
HyperCard is an industry standard for multimedia authoring tools-
- and as such is king of the hill in add-ons and the size of the knowledge base in
general. For several years one of Autocad's chief advantages was touted as its position
as the industry standard-- which meant it enjoyed the greatest third party support
in add-ons and overall knowledge base concerning CAD usage. HyperCard itself enjoys
many similar advantages in its own domain, with literally thousands of different
stacks available, many offering up new and unique scripting techniques, XCMDs, and
XFCNs, as well as numerous reference and instructional texts, and even magazines (like FLUX)
which all serve to expand and deepen HyperCard's potential usefulness and accessibility
to everyone.
Almost every Mac user is potentially a HyperCard user.
Since its inception, HyperCard has been bundled (in one form or another) with virtually
every Mac sold. For the first few years, the bundled HyperCard was the full-blown,
programmable version, which greatly encouraged the development of applications and
other types of stacks. After that, Apple begun bundling only a runtime version of the
program-- HyperCard Player-- and selling the programmable version separately. The
initial wide and free availability of the full HyperCard helped create the current
industry standard position of the program, and spawn similar high level language efforts
on the other major computer platform-- Intel based PCs. It also made HyperCard the
highest level, highest capacity, and most flexible universal document exchange system
for any personal computer platform, period. Not until the mid nineties did any other universal
document software even begin to approach HyperCard's status in this area. As of this
writing (June '94), no other product (on any platform) yet matches HyperCard's circulation, library of compatible documents available, and power and versatility
offered to developers/ authors in the environment.
HyperCard's power can be expanded or extended with add-on modules developed in
other languages.
Those versed in other programming languages like C, Pascal, or BASIC can expand upon
HyperCard's basic feature set by writing external commands or functions for their
stacks (XCMDs and XFCNs). In other words, your HyperTalk program can delegate certain
tasks to other language programs as desired for reasons of speed, or special capabilities.
HyperCard runs exclusively on the Mac.
Later in this piece, this same element is listed as a weakness. But it's also a strength.
Because Apple's long held insistence on Mac interface guidelines, among other things,
have made the Mac the closest thing to a 'plug'n play' personal computer around, which means users will rarely have to walk through a mine field of technical problems
in order to get to your software, as they might on an Intel-based machine. One aspect
of this is that when writing a script to do something like a custom print job, the same script will likely work with practically any printer a Mac user might have attached
to their machine. If you were developing on an Intel machine, you might require dozens
(even hundreds!) of different scripts, each dealing with a different possibility in the printing department-- and still there could end up being thousands of users
for whom your program would not print correctly. Microsoft and other developers have
been striving heroically to remedy such situations on the Intel machines for years
now, with some success. However, you have only to examine typical articles on real usage
of the systems by people like Jerry Pournelle in BYTE, or others, to see the substantial
difference that still exists between the Mac and Intel platforms, across-the-board.
HyperCard's weaknesses
While the learning curve in HyperCard is not very steep, it can be as long as that
of any other programming language.
Before, in listing HyperCard's strengths, I mentioned the gentle slope of its learning
curve. The flip side of that is the total time required to reach complete mastery
of the language, which may be about the same as that required for any modern computer
language-- though those users with a natural talent for visually based programming
may enjoy a significant edge in attaining expert status.
Low end graphic output.
As of versions 2.1 through 2.3, HyperCard is heavily biased towards monochrome video
output-- and low resolution output at that, at 72 DPI (dots-per-inch). It also uses
a default screen size of 512 x 342 (the screen dimensions of the original Mac). While
this makes virtually any stack display compatible with almost any Mac ever made, it
also severely limits HyperCard's (and so stack authors') capacity to exploit the
display capabilities of newer Mac systems. This shortcoming is gradually changing,
with successive HyperCard versions; 2.x may support card sizes several times larger than the
512 x 342 of bygone days, as well as support various QuickTime operations dealing
with TV-style video; 2.x also added some badly needed support for color and grayscale
images in stacks-- though this support is not yet of the caliber most scripters might
expect.
HyperCard's future surely will include more advanced imaging capabilities and flexibility.
This aspect of HyperCard's future may be more certain than any other.
Little or no support for object-oriented graphics and mid-range to high end animation.
HyperCard's built-in support for object-oriented graphics is almost non-existent;
a shocker when you consider how object-oriented the language is in other ways. This
grave restriction extends to animation capabilities as well, leaving stack authors
little choice but to use QuickTime video for such things, as restrictive and inflexible
as that is for many purposes. What little HyperCard offers in true animation power
amounts to little more than screen-flipping, automated painting, and programmed manipulation of buttons and fields (toggling visibility of icons and text, and changing sizes,
shapes, and positions). The dependence on bitmap graphics (as opposed to object-based
images) also means a bigger appetite for storage space on disk than might otherwise
be the case, and thus is partly responsible for the big disk area many stacks often
require. Of course, part of this big disk footprint is due to the overhead involved
in any program file as versatile and user-friendly as a HyperCard stack can be.
As expansion of animation powers and support for object-oriented graphics are often
closely related, any change in either will tend to boost the other. As one of HyperCard's
stated reasons for being is multimedia, it's difficult to imagine it remaining as limited in animation and object-based graphics as it currently is, for much longer.
Plus, the arrival of the Power Macs should make such expansions a lot more feasible
from Apple's point of view.
Slow execution speed and lack of compilation capabilities .
These elements are closely related, as a compiled HyperCard stack would be a lot
faster in execution than is presently the case. Computer languages come in two flavors:
compiled and interpreted. BASIC and other high level programming languages have traditionally been interpreted, primarily because compilation of their more user-friendly
elements required substantially more effort on the part of language developers than
the closer-to-machine talk elements of languages like C. This has begun to change
in recent years, as developers obtained more powerful tools and techniques with which to
tackle the complexities involved. Unfortunately, HyperTalk remains an interpreted
language today, although some third party tools such as Compile It! from Heizer Software
are gradually taking on the job. All compiling would do is permanently translate the
close-to-English format of HyperTalk to the almost incomprehensible gibberish of
assembly code. Such assembly code makes it a lot easier for your computer to complete
the translation to its own preferred lingo, which looks a lot like "10101011010010101".
As amazing as it may seem, your computer can run your program a hell of a lot faster
as "10101011010010101" than it can in the form
go to next card
. Interpreted languages, on the other hand, force the computer to do a 100% translation
of your program to its own language of ones and zeros each and every time your program
runs. See the difference? A compiled program is already mostly translated, so the machine zips happily through it, at near to its maximum speed. With an interpreted
program however, first the computer must go through the painstaking process of translating
it, and then and only then do what the program instructs it to-- for each and every statement in the program. Compiled is close to one-step, interpreted is possibly
many steps. What's the difference in perceived execution speed between the two? Maybe
as little as 100%. Maybe as much as 3000%! So a compiled HyperCard would be a much
more capable and versatile HyperCard. But we don't have a compiled HyperCard, so stacks
which perform tasks even moderately complex can slow to a crawl in relation to user
perceptions. For this reason, few truly ambitious projects (such as advanced artificial intelligence programs) are undertaken in HyperCard today. To be fair, however, it
is possible to write special purpose XCMDs and XFCNs, as described above, to speed
up particularly slow procedures in HyperCard, by directly using compiled code or
something similar. Possible? Yes. Practical and easy? Often no. Remember, you'll need expertise
in some language other
than HyperTalk to write your own XCMDs, etc.; or else find one from a third party
that does what you need.
The speed limitations on HyperCard may become moot as Mac hardware gets faster
and more powerful. Too, there may be full scale compilation in HyperCard's future,
if Apple decides to make it a more integral part of their system software.
Restriction to a single platform.
HyperCard is exclusively a Mac language and development environment. This means
anything you produce with HyperCard will only work and be accessible for Mac users.
Since Macs account for only some ten percent of all personal computers today, this
means your HyperCard-based products will only be applicable to ten percent of the computer-using
population. This limits your potential market and audience.
Limited choices in some important lower level parameters and capabilities.
Like most other high level languages, HyperCard suffers from a variety of utilitarian
limitations-- some a direct result from the high priority placed on ease of use and
rapid development time. For instance, HyperCard possesses little flexibility in the
types of files it can produce. Basically, you have only a choice of the standard stack
file, or a pure text export. Recent upgrades to HyperCard have extended this somewhat,
but not by much. If your application calls for a highly custom file format, you'll
have to resort to XCMDs and the like to do it with HyperCard-- in other words, you'll
have to use another language entirely.
Apple is hard at work on maximizing cross-platform compatibilities in many aspects
of its operating system; why not HyperCard too? This may well happen, if only indirectly,
through the OpenDoc standard. So this restriction may not stand very much longer, either.
Weakness in variable arrays and other database type functions.
HyperCard also suffers weakness in the areas of variable arrays and certain other
variable references you might be accustomed to using in other languages, like BASIC.
This shortcoming can have significant impact on capabilities like large database
manipulation or artificial intelligence programming.
The purchase price of the HyperCard Development Package.
For any other development package as powerful as HyperCard, sporting a street price
of roughly $100, this would not be listed as a weakness, but as a strength. For virtually
all development packages require purchase. But Mac users have long memories, and the programmable HyperCard began life free, bundled with all new Macs sold. So those
familiar with history may be excused for seeing the purchase price of HyperCard as
a liability today. Fortunately, the price is not tremendously expensive-- yet. As
HyperCard becomes more powerful the price may inch its way up to less acceptable levels.
So what about those users who'd like to dip their toe in HyperTalk, but aren't planning
anything ambitious enough to justify purchase of the development kit? Luckily, there's another choice: using the Magic palette, which makes its debut in this issue (Summer
94) of FLUX. With the Magic palette users may create, move, and resize buttons and
fields, as well as examine and modify their scripts, and various property settings.
In other words, the FLUX Super Stack offers users its own mini version of the HyperCard
development environment-- for free!
Large disk space overhead and potential compatibility problems.
A final weakness of HyperCard stacks comes from their dependence on a runtime module
or the parent HyperCard application being present on a computer in order for them
to run. This is related to the topic of compilation mentioned earlier, in that a
compiled program would require no such help. This necessity for a runtime module or the parent
application means an additional 750K or so of disk space is required, beyond the
space necessary for the custom stack itself. It also means that users can purposely
or accidentally remove the HyperCard application from their disk, rendering non-standalone
stacks unable to run. Since HyperCard itself is not an integral part of the Mac's
operating system, it can be deleted or erased like any other application, thereby
making that particular Mac incompatible with any HyperCard stack that requires the parent
application.
As discussed earlier, such problems as these may vanish if Apple integrates HyperCard
more fully into its operating system, which it may well do. The substantially greater
power, speed, and storage space available on newer Macs today could handle it easily, and the flexibility such a move would add to Apple's system software, and the
support of stack developers, would be of considerable competitive value for the company.
At the moment this void is filled partially by the free availability of HyperCard
Player with new Macs, and version 2.2/2.3's capacity to produce standalone stacks (essentially
attaching a full-size HyperCard application to a stack-- a stop gap measure for the
moment, until something better may be done).
HyperCard's different levels of user difficulty and access
Most of us have had at least a bit of experience with video games. In that entertainment
form there will often be several different levels of difficulty the player may tackle
in the course of a game. HyperCard too possesses varying levels of difficulty, where both programmers and users are concerned.
1. The easiest (but most restricted) level is browsing, or level one. Any stack
set to this level will not permit a user to do much of anything beyond simply looking
at the pictures and reading the text displayed within a stack. The user will be able to click buttons to obtain some additional functionality, if such has been previously
programmed into the stack by its creator, but that's it. Browsing level is good for
stacks which should be read or seen, but not changed in any way.
2. The next level (level two) is typing. This level is suitable for database
style stacks, allowing users to type new information into the stack, and perform
searches of information in the stack. Anything else, such as creating images or programming, is not allowed at this level of access. Successively higher levels always include
all the capabilities of the levels that preceded them; so level two is essentially
level one with the ability to type in additional information as desired.
3. Level three is painting. Here a user may not only move through the stack,
reading text and admiring pictures, as well as type in new information, but also
add to or change the images they find there. Level three is the highest level available
in the stripped down version of HyperCard bundled with new Macintoshes these days, called
HyperCard Player. Full blown HyperCard applications, which allow the higher levels
described below, may be purchased separately. An alternative to such purchases is
obtaining a FLUX Super Stack equipped with the FLUX Magic palette, which offers access
to many of the capabilities of HyperCard's userLevels 4 and 5, free of charge.
4. The fourth level is authoring, which adds to level three the ability to create
new buttons, fields, cards, and therefore interface screens, but only a bare minimum
of programming capability to enliven these objects. Specifically, about the only
programming you can do at level four is instruct a button to move the user to a different
card when clicked upon.
5. Finally there's level five, or scripting. Level five is the whole enchilada,
the entire shebang, offering you all the power you're smart enough to squeeze from
the current version of HyperCard. Level five gives you access to the programming
language of HyperCard, called HyperTalk. Wherever I list actual program code in this series,
it is in the HyperTalk language.
The Biggest Problems in Getting Started Scripting with HyperCard
1. Your number one problem may be getting hold of the programmable version of
HyperCard,
since it's no longer bundled free with all Macs. However, this obstacle is not a
large one, since the programmable HyperCard is usually available for a street price
of around $100 (from mail order discounters). If $100 is more than you can chew at
the moment, consider the latest version of the FLUX Super Stack, usually available free or
at low cost from a variety of sources.
2. Your second biggest potential problem getting started with HyperCard will be
an unfamiliarity with the Macintosh interface in general.
If you're not accustomed to icons, buttons, menus, palettes, and your desktop and
finder, you'd best stay out of HyperCard until you are. Diving into HyperCard authoring
or scripting is like going up another level in the general Macintosh GUI (Graphical
User Interface). If you're not yet accustomed to the lower levels of Finder and desktop,
you'll probably have problems in scripting or authoring in HyperCard.
3. Your third biggest potential problem will, ironically, be the solution to the
second
-- that is, after you've become familiar and comfortable with your Macintosh interface,
and how most of its programs work, you'll discover some inconsistencies inside HyperCard.
For example, your Mac's Finder will often require you to click twice on some icons to activate them, yet in HyperCard only one click will usually be desirable.
4. Another perhaps unexpected item will be HyperCard's automatic saving of changes.
HyperCard saves the latest changes every time you move from one card to another,
or perform other typical actions in the program. This can interfere with some of
your normal back up habits and expectations in that vein. It also reduces the flexibility
for those users accustomed to depending on a lack of file updates as a last resort "Undo"
capability. With most Mac applications you can back out of all the file changes made
since the last manual save command, either by selecting a "Revert" command in the
File menu, or quitting without saving, and then reopening the non-updated file. With
HyperCard this technique generally won't work, as your stack is updated as a background
process, rather than manual save. While this maneuver can be desirable for some novices, or those customarily lazy about updating files (since it should reduce the risk
of lost work), it conflicts a bit with the practices of knowledgeable users with
experience based on more primitive computer technologies (even on the Mac, most mainstream
applications still require manual save actions these days). The way I personally deal
with this idiosyncrasy is to perform any manual saves desired by moving to another
card in the stack, and then back again-- this forces one of HyperCard's automatic
saves to take place. As for the ability to revert to a previous state of the stack, my
own personal backup practices almost always allows this, no matter what HyperCard
or any other application does in regard to saves (This is fully explained elsewhere).
Luckily, updating object scripts in a stack during editing of same is much more conventional
in nature (with actual "Save" commands), thereby avoiding the strangeness of the
more general stack save operations.
5. Compacting.
In order to deal successfully with the many complex elements involved, HyperCard
stacks require periodic compacting to reclaim space no longer needed on disk, due
to changes. Compacting, unlike saving, is not performed automatically unless you
specifically instruct the stack to do so (via script). If you neglect compacting on a regular
basis, you run a greater risk of suffering a "corrupted" stack, which could cause
you to lose important work by eventually refusing to function properly.
6. The next few problems in getting started are the same as with any new programming
language-
- unfamiliarity with language syntax, understanding how to create (and stop) repetitive
loops, and providing the meticulous level of detail a program requires to function.
All programming languages, including HyperCard's HyperTalk, require that programs
or scripts be written from a particular perspective. The perspective rules are:
A. Your program is a list of instructions; a 'how-to' manual of sorts. It is
meant to explain to a very young person-- about 6 or 7 years old-- how to perform
a certain task.
B. Any comments in your code are meaningless to the child-- comments are for
your use only, and will be ignored by the child.
C. In your instructions, you must use words and processes with which the child
is familiar. In every case, the child is a prodigy in the computer language you're
working in, but knows little of normal english language conventions and phrasing.
Your primary avenue of communication with the child is the child's own language-- and so
the burden of correct syntax and phrasing falls wholly upon you-- not the child.
D. Your instructions must be highly detailed, explaining every nuance of what
you expect the child to do. The child has a perfect memory and will forget nothing
you tell it, but it also will follow your instructions to the letter-- even if that
letter turns out to be obviously mistaken upon execution.
E. In 99.9% of the cases, any and all problems you encounter getting your instructions
across to the child will be your own fault; for this particular child is a model
of discipline and logic, and damn near perfect in how it follows its instructions. The child is utterly non-emotional, and will do even the most repetitive of tasks
millions of times without complaint; only the instructor's own mistyping, lack of
effort, or misunderstanding of the child's vocabulary will be the source of problems
in most cases.
Initiating and ending repetitive loops
Repetitive loops in HyperCard are a lot like those in BASIC, but more convenient
and relaxed in syntax. Here's a sample loop in a HyperTalk handler, profusely explained
via commented lines (HyperCard ignores anything after two dashes and a space character):
[NOTE: please forgive the strange formatting below; it's very difficult to get script
formatting to carry over correctly from HC to a word processing document, for some
reason]
on mouseUp
global totalLines
-- below i will be the counter, or the variable
-- the loop uses to keep track of how
-- many times it's cycled through its instructions
put 1 into i -- here I provide the first value for the counter
repeat until i > totalLines
-- above I tell the handler to keep doing this until
-- the value of i is greater than the value of
-- the global variable totalLines
-- which I declared above that I planned to use here
add 1 to i -- here I add 1 to i; if I fail to do this I get
-- an endless do loop- a definite no-no in programming
-- the counter i variable is the only way the loop has
-- of knowing that time is passing; so if i is not
-- incremented time stands still inside the loop
-- leading to the loop continuing to run unless
-- some value involved becomes too great
-- for HyperCard to swallow, and it crashes
-- or the user manages to abort the loop somehow
-- such as with a reset of their Mac or pressing the Apple
-- and period keys simultaneously (this last might not always
-- work- it can be disabled in a script, for example)
end repeat
end mouseUp
Just to make things clear, below is the same handler shown above, only without
the comments:
on mouseUp
global totalLines
put 1 into i
repeat until i > totalLines
add 1 to i
end repeat
end mouseUp
Another problem relevant to all programming languages is that beginning programmers
might be dismayed at how much work it requires to get their program to accomplish
apparently simple tasks.
Some frustration in this area is pretty much inevitable for everyone, novice and
expert alike, as most of us will tend to muddle our way through with a minimum of
manual references, with few of us capable of successfully guessing at the syntax
and vocabulary of the language we're using. These two things will result in a lot of useless
or obscenely lengthy code, as well as script errors-- if you can get the program
to run at all that way.
Sooner or later anyone seriously interested in programming will acknowledge the
importance of the manuals, and make use of them, while everyone else will give up
entirely.
Programming is definitely not for the closed-minded or weak of will.
As mentioned elsewhere, you should try to modify already existing scripts to serve
your purpose, in many cases. This practice will save you enormous time and effort,
as well as teach you a lot.
Start with a script that already works.
Then make only small and limited changes, fully testing the script for flaws in execution
immediately after each change. If errors are found, deal with them immediately, rather
than postponing-- or worse yet, proceeding to add still more code to the already malfunctioning script.
Religious back up of incremental versions can be worth its weight in gold.
Only recently I witnessed an excellent example of this, when I discovered an awful
bug in code I'd thought damn near perfect. A quick examination of the script and
consideration of error information revealed no obvious fix, so I began backtracking
through backup files in search of the last working example of that particular part of my
program.
I was shocked to find out how deep into my backup library the last working example
was-- over 40 versions back! Of course, the error had slipped by me for that long
because I'd failed to test the script immediately after a very minor script change,
and for the next 40 plus versions I was working on a different area of the program entirely,
satisfied that all else was in wonderful shape. Just how close did I come to NOT
having a working version of that bit of code still in my library? There were around
twenty older versions than the last functional file; so I retained a significant safety
buffer even 40 versions deep. But still, it was much too close a call, considering
the importance of that particular project.
Fortunately, my own method of backing up stacks has never yet let me down. Here's
how I do it, in case you'd like to do the same...
One User's Low Cost, Comprehensive Back up Method:
Every two or three minutes...
I update the stack I have open at the time by moving to another card and back again,
or saving the current script I have open via the File menu.
Every five minutes...
I compact the currently open stack.
Every ten to fifteen minutes...
I create a new incremental version of the stack. Incremental versions of a stack like
HyperSavvy might have looked like this on my disk:
HyperSavvy.34
HyperSavvy.33
HyperSavvy.32
HyperSavvy.31
HyperSavvy.30
(I almost always view my files in my Mac Finder "By Date", so that the latest
versions are usually near the top of the list).
At the same time
I create a new incremental version on my hard drive, I copy the previous version
to a floppy for backup. When the floppy gets full, I store it in a box labeled "HyperSavvy
v1.0 Pre-Release", placing the disk in the front of the box-- so latest versions
are always near the front, older versions towards the rear.
It might surprise you to know that I don't usually label individual floppies in
my incremental backup library-- I don't have the time or energy to spare. Plus, affixing
a label to a disk pretty much ruins its flexibility, since labels are difficult to
remove.
How exactly do
I index my backup floppies?
I have a big cardboard box, about 1.5 feet wide, 2.5 feet long, that sits with
its narrow side to the front on a sturdy platform near my computer. The walls of
the box are maybe 7 inches tall-- or about 2 inches taller than a floppy disk. There's
another large piece of cardboard I use for a dust cover over the backup box, that roughly
matches the dimensions above, but is just a bit narrower and shorter, with edges
along the sides that fold down and slip inside the side walls of the box below when
the whole contraption is closed.
Inside the large box are maybe 48 original cardboard floppy disk boxes-- or their
bottom halves, anyway. Most of the boxes contain around 10 disks each. There's a
bit less than a dozen major backup libraries in my really big box, with a lot more
minor ones. A major library might be composed of several floppy disk boxes, with newer backups
towards the front, older ones to the rear. In the very last box bringing up the rear
of a single library column, I'll have a piece of paper sticking upright, from behind all the disks it shares the box with. This paper is about 4 inches square, and has
scrawled on it the name of that particular backup library.
The result of all this is when I raise the dust cover I have instant access to
full backup libraries of virtually every ongoing project in my life.
How deep do I let incremental backup files get on my hard drive?
This depends on how large the program I'm working on is, as well as the size of
the hard drive itself. Ideally, if I had Gigabytes to play with, I'd let incremental
backups pretty much pile up all the way from version one to final release. But given
real world conditions, a program currently in development and roughly one percent the
size of my entire hard drive (one Megabyte), might get as deep as ten incremental
versions on my main drive-- though that would be pushing me pretty hard, since I
rarely have more than six to ten Megabytes free at any one time.
The smaller the file is, the more lenient I am in how many live backups I allow
myself to keep. If only half a Megabyte in size, I might keep twenty incremental
versions handy on my hard drive.
How deep do I allow my incremental backup library on floppies to get?
At this moment I have several projects under development, with attendant backup
floppies in my library. The number of floppies backing up a particular file changes
drastically after that program sees public release. Release means the latest version
of that software passed every conceivable test, and so very few (if any) known bugs are
present in the latest version. That version is archived in at least three separate
floppies, and placed in a fire proof safe. Then, the rest of perhaps dozens of disks
that might form the incremental backup library are placed in a box marked as "disks ready
for recycling". The backup files on them are replaced as needed with backups of a
new ongoing project, and the floppies then placed in the appropriate new library
box. In this way practically my entire library of incremental backup floppies eventually
gets recycled. To get an idea of how deep I allow incremental backups to get, I have
a handy example of a stack about 225 K in finished size, that within the last week
(of this writing) went into general public release. There's 24 floppies containing incremental
backups of the stack, with each floppy averaging around five different versions held.
This makes for a total or roughly 120 incremental versions available to me near the end of the developmental cycle, for that particular product-- or nearly every single
version ever created, from the first to the last. To accomplish the same depth with
a much larger stack, like an issue of FLUX magazine, a lot more floppies would be
required-- almost one floppy per each incremental version, as the issue nears completion.
So sometimes I match this depth with larger stacks, and sometimes I don't; but I
like to try.
Because there's nothing I hate worse than losing a significant amount of work--
and that's exactly what happens if your backup library is inadequately maintained.
Not might
happen-- will
happen.
As I have mentally blocked out the event due to its horrific nature, I can't recall
many of the details. But I do know that once, many years ago, I lost some three to
four months of grueling computer work in less than sixty seconds-- because I was
not adequately backed up.
Most users have to endure a personal disaster of some sort to become reasonably
disciplined in matters of backup. I sincerely hope you are not
one of this majority.
What about catastrophic insurance for my backup libraries?
What happens if a fire in the computer room melts my libraries, or a tornado comes
and blows them all away, or a thief steals them?
First of all, I periodically deduct a single disk from the backup library of a
currently open project, to store it in an entirely different room, away from the
office. A bit less frequently, I put the latest versions of all projects currently
in development into a fireproof safe (switching them out with any predecessors of their ilk).
Then, of course, when a project is completed and going into general release, I archive
three copies of the final version in this same safe.
In addition to all of the above, the latest versions of all our software will usually
be on computers belonging to my associates as well, transferred either by modem or
sneaker net, for possible testing or other purposes-- but also as an additional form of backup. Most all these machines are miles away from one another, so the chances
of all copies being zapped simultaneously are low.
Finally, there's the distribution copies of the software, that go out to direct
customers, user groups, shareware distributors, CD-ROM publishers, and the like.
And copies uploaded to services like America OnLine. Through these channels copies
stream out to literally thousands of users like yourself-- a few of which would probably be
glad to send me back a copy of my own program if they learned I was in dire straits.
If God really took a disliking to me I could lose access to all these backups,
one way or another-- but I try not to tick Him off in such a manner.
Using tiny test bed stacks to develop a script before installing it into your main
stack.
Sometimes your main project stack may be getting pretty large, and therefore cumbersome
to easily make incremental backups of. And yet, that's precisely the conditions under
which you require incremental backups the most, as a single bad bug cropping up could delay the project's release for months. Or, the particular script you're working
on may be getting complex, and difficult to debug within the main stack itself, with
all the distractions of other handlers and such present. In both these cases it may be wise to copy the problem script from the main program, and paste it into its own
tiny test bed stack to grow for a while.
The advantages of this are many. One, you'll be able to much more easily, cheaply,
and quickly make incremental backups of the developing script. Two, you won't be
endangering your major project as much with the necessary trial and error. Three,
you'll suffer far fewer distractions as you attempt to make the script work.
The above article(s) come from and make references to a collection copyright © 1993,
1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002 by J.R. Mooneyham (except where otherwise noted in the text). Text here explicitly authored by J.R. Mooneyham may be freely copied and
distributed for non-commercial purposes in paper and electronic form without charge if this copyright
paragraph and link to jrmooneyham.com are included.
Back to the Table of Contents of the Signposts Timeline
Back to J.R.'s
WebFLUX Page (the magazine)
Back to J.R.'s
WebWork Page (A hefty catalog of links to almost everything)
Site Map for the
WebFLUX and WebWork pages