Apart from your obvious fixation on spaghetti :)
The only problem about these types of recipe books is that it is
well-nigh impossible to guess
all the recipes that will be required: after all, if it were, there
would be no original programs
or ideas within programs.
While answers to questions such as "how to I clear a field of data?' may
be straightforward, and,
almost everybody is going to ask that question sooner rather than later,
questions such as
How to I download pictures, music and film clips from seven different
websites, arrange them
across a number of cards, embedding some of the imported data in fields
according to type,
and export selected parts into a variety of image formats?
Are rather more difficult to foresee, and may not always be capable of
being broken down into
lesser questions demanding less elaborate and specific answers.
All of us have come across books with titles such as "Moron's guide to
Spaghetti", and, apart from
the fact that the title's sound rather insulting, they do tend to
"talk down"
provide a 2-dimensional view of things
which may be all well and good if all you want to do is belt out endless
plates of spaghetti-cheese
and spaghetti-with-some-indefinable-unidentifiable-brown-sludgy-sauce;
but misses one of the
main points about cooking (and, oddly enough, computer programming); the
creative possibility
that makes all the difference between the type of people who used to
dish up some 'orrible filth
they passed-off as 'Four Seasons Spaghetti' at my school, and REAL cooks
who make you rush
back for more.
Surely, one of the joys of cooking is the possibility for endless
experimentation.
Aah . . . wait a minute . . . I seem to remember one Dr Alex Comfort . .
. who wrote a book . . .
about . . .
Hey! "The Joy of Runtime Revolution" complete with line illustrations
of all sorts of interesting
object layouts.
Peter Alcibiades wrote:
Someone suggested entering 'empty' into the dictionary. Try it. You get
30-40 entries, with 'empty' as a property, and one with it as a constant,
and two with it as an option on commands. One of these may or may not tell
you how to set a variable to empty.
This is a bit like setting out to make spaghetti carbonara, and discovering
that you can look up spaghetti in the manual. There are lots of entries for
the diferent sorts of spaghetti, thick, thin, fresh, wholewheat... You look
up bacon. Lots of entries, back, streaky, smoked, pancetta..... What you
need is a book organised by Things You Want to Make. Carbonara, Bolognese,
Cheese. Broccoli and achovies, Putanesca... I am getting hungry thinking
about it.
So similarly what Rev needs is a book which does not, when you look up
'empty' have all those 40-50 entries. Instead it has some along the lines
of 'How to empty a variable, field.....'.
Carla's book is a model. Here is her table of contents
http://oreilly.com/catalog/9780596006402/toc.html?CMP=ILL-4GV796923290
And here is an excerpt to show exactly how it works:
Problem
You need to know what files are installed on your system when you install a
program from source code, so that you can find and remove all of them if you
decide you don't want them anymore. Some program authors thoughtfully
include a "make uninstall" target to perform a clean uninstall, but many do
not.
Solution
You can use standard Linux utilities to generate a pre-installation list of
all files on your system. Then generate a post-installation list, and diff
the two lists to make a list of newly-installed files. This example uses
JOE: Joe's Own Editor:
# find / | grep -v -e ^/proc/ -e ^/tmp/ -e ^/dev/ > joe-preinstall.list
Compile and install your new program, then generate the post-installation
list:
# find / | grep -v -e ^/proc/ -e ^/tmp/ -e ^/dev/ > joe-postinstall.list
Then create a list of files installed by Joe by diffing the two lists:
$ diff joe-preinstall.list joe-postinstall.list > joe-installed.list
There are a few more examples here:
http://www.linuxdevcenter.com/pub/a/linux/excerpt/lnxckbk_1/index.html
Its all organized along the lines of, you are engaged in doing something and
find you would like to do X, This is how to do it. Sometimes (as in this
case) there is a discussion (here omitted) afterwards about how it works and
what to be careful of.
You can see, its a dictionary, but organized by problems which in turn are
all grouped under tasks. You need both kinds. I am not criticizing the Rev
materials, which are (a) much improved and (b) excellent as what they are.
But you do need both. Especially for those starting out with it. My own
example was a problem which Jim Ault was kind enough to show me how to
manage, using 'filter'. Filter was there in the dictionary all the time,
I'd just not realized that this was what you used or how you used it to
solve my problem. But had there been an entry on the lines of, how to
eliminate dupes, or some ways of doing lookups and matches, it would have
been in there.
It would be natural to get contributions in the form of a wiki, and then
have someone edit them into a structure. Most of the material is probably
around somewhere, just not organized like this.
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
