lawitzke@msudoc.UUCP (01/30/87)
As a system manager, I face the same problems many other people face; how to educate the new UNIX users. It's just not right to send them off with a couple of book references, (like McGilton). I've been developing a short series of seminars on the UNIX system to present at our site. Instead of jumping right in with definitions of the file system and throwing commands at them, I start with a very short history of UNIX. Then I demonstrate how to connect to a machine over our network. (I'm fortunate in the fact that one of our classrooms has a terminal connected into an wall projection monitor so I can demonstrate things). Then I cover logging in, changing your password, and logging. All fairly standard things. The, instead of filesystem, etc. I show them some of the conviences of the UNIX system. I talk about learn and demostrate the learn program briefly. I then move on to on-line documentation. I talk about man and man -k. I demonstrate both commands and explain the format of a manual page. I also explain the "classical" UNIX manual sections. Since we have SUNs here also, I talk about the SUN tutorial manuals. I also mention some local documents we've been generating. Then I move onto the mail command. I demostrate the basics of sending mail and reading mail. This along with a few questions manages to fill out one hour nicely. The second and third sessions consist of an introduction to the file system, file manipulation commands, file creation and modification commands, network commands, utilities, and languages. I would appreciate hearing what others have done to educate new users. Post to the net for the information of others. -- John H. Lawitzke UUCP ...ihnp4!msudoc!eecae!lawitzke Division of Engineering Research Michigan State University Office: (517) 355-3769 E. Lansing, MI, 48824 Home: (517) 332-3610
rbl@nitrex.UUCP (02/04/87)
In: Message-ID: <1097@msudoc.UUCP> John asks: >I would appreciate hearing what others have done to educate new users. >Post to the net for the information of others. > >-- >John H. Lawitzke UUCP ...ihnp4!msudoc!eecae!lawitzke >Division of Engineering Research >Michigan State University Office: (517) 355-3769 >E. Lansing, MI, 48824 Home: (517) 332-3610 > > For about 10 years before joining industry, I taught UNIX to graduate students. Most of these students were M.D.s and nurses, but their computer literacy varied quite a bit. For 5 years in industry, I've been asked to present UNIX seminars within the corporation a number of times. These (typically) are to information systems managers and technical types. Assume computer literacy here, but with a strong IBM/DEC-VMS/COBOL-FORTRAN perspective and to be considered as new UNIX users. Two lines of thought here --- one on UNIX for new-to-UNIX professionals; one on UNIX for students. Maybe neither one really hits the UNIX-for- general-users problem, but VMS is the prevailing culture here. Guidelines for successful UNIX presentations to new-to-UNIX users: o NEVER try to get very technical. A little bit of why UNIX is better might be backed up with diagrams explaining some deeper technology, such as how the I/O and disk block caching work, but it will never be well understood. Cartoons help get a fuzzy understanding across. (I use a Macintosh to do the diagrams/figures/comics.) o For a {IBM, DEC, other vendor}-oriented audience, explain why UNIX "works better" for the user. Here I focus on: - Software tools and use of the shell for putting prototypes together very quickly. I note that this breaks the classic 18-month system development cycle and tends to produce systems that better meet client needs. (Apparently this is now being picked up by some of the higher-priced guru/consulting groups. Management's perception of the value of an idea may be influenced by what they paid for the idea. :=} ) Very receptive audience here. Note that VMS/IBM/... lack a "pipe" construct and that standard input/standard output/pipe/shell are essential to the fast prototype approach. o Explain and demonstrate some commonly used tools. grep against a data file to show that one may NOT require an expensive DBMS to handle data storage/retrieval problems. Show how secondary selections can be done by piping to a second grep, awk, sed or whatever. Stay away from the arcane and obscure, such as nroff, that look much harder than we know they are. You might mention that tools like yacc, lex, awk, sed ... can help convert an application from one vendor/language/4th GL to another vendor/language/4th GL. It seems IS managers are ALWAYS facing conversion problems! o Mention that ALL files in UNIX just look like byte steams. No worry about long lines, embedded new lines, internal file structures. o Show result of an 'ls' and explain the permission codes allowing sharing, superuser permission, read-only, ... o Talk about how dataflow analysis, structured design and fast prototyping fit together in a logical way and show how changes in system requirements can be accomodated easily. o If you want to REALLY impress a group of IS managers, show how a data file retrieved from an IBM system can be combined with a data file from yet-another-vendor's system with a 5 - 10 line shell! For Students: For computer-naive students, John's approach seems to be the one that works best. A little bit at a time, start with some of the easy but interesting commands (ls vs. ls -a vs. ls -l; who; cal; date; ... ) About the 3rd session, explain the output of a ps -elf and talk about how this shows what the operating system is doing to handle all the users (I use color pictures where each user's tasks are one color and move from main memory to disk). This seems to help them understand why the same task takes longer when there are more users. There are now a number of excellent books with good exercises to familiarize students with APPLYING the UNIX features. I only wish there were a better way to edit, as the editor seems to present the major conceptual hurdle for naive students. (No doubt this could be the start of another flaming discussion!) We found (in academia) that an entire M.S. program in Computer Applications could be built around UNIX and structured concepts. We taught: - Introductory computer and information concepts (hardware, software, Shannon, what's an operating system, some data communications, and IMPORTANTLY autopsies on some system disasters.) - C via pseudocode and elementary data structures - Structured system analysis and design - Relational data base management systems - A real project applying these techniques Now, this is not your ACM curriculum, but looking back on what the graduates are doing today, I'm pleased --- but I'm not an objective observer. For our introductory VMS training, we've typically used a half-day of presentation in a room full of terminals and a video projector. The rest of the day is for students to do exercises and try their own thing, with an instructor roaming around and looking over their shoulder. This is an important piece of training, for there appear to be very limited introductory VMS manuals/texts versus the very many UNIX manuals/texts on the market. We also maintain a telephone hotline for users, (which I use a lot) for everything from "how do I change my directory" to "the system won't let me login". DISCLAIMER: These views have not been reviewed/approved for public distribution. However, they are my own personal opinions. They very likely do not reflect the opinion of my employer, nor of anyone else in the corporation. Robin B. Lake (also Adjunct faculty here and there) decvax!cwruecmp!nitrex!rbl ihnp4!cbatt!cwruecmp!nitrex!rbl (216)-581-5976
hxe@rayssd.UUCP (02/05/87)
John (I'm sorry, I forget your last name) asked what approaches
people use for teaching UNIX to beginners. I am the "Supervisor of
Training and Development for the Software Development Lab" at a
largish (~3500 employees) company, and I am solely responsible for
training all employees who want to know the ins and outs of UNIX.
My environment seems to be slightly different from the ones
described so far, in that this is not academia and so my `students'
are not "students", but rather people who have discovered that they
need UNIX to do their jobs. Their reaction ranges from wild
enthusiasm to bitter resentment. I also don't do a lot of `selling'
to managers in the context of training (that's a separate function
altogether), so my audience is committed -- like it or not -- to
learning UNIX.
I have two basic types of students: people who have never touched a
computer before and computer literate people who just haven't used
UNIX before. Obviously, I have very different approaches for the
two types.
The "never touched a computer" types tend to be secretaries and
clerks who will use UNIX almost exclusively for text processing and
file manipulation. In a six-day course of all-morning sessions, I
devote the entire first day to a basic "what is a computer" lecture
so they don't feel so dumb about jargon, a demonstration of the
difference between the terminals on their desks and the computers
in the computer room (most novices do not know that a terminal is
not a computer, and thus get confused when presented with the
concept of a multi-user system with a computer someplace where they
can't see it), a discussion of how computers are used here at our
company, and our network and port selectors. I then ease them into
the concept of multi-user systems, what an account is and why their
login is unique, and, finally, how to log in. We then do very
basic commands just so they'll learn how to type a command -- who,
date, talk (or write, depending on the system), and hangman (to
help them conquer their fear of the strangeness of it all). We
finish up with a tour of the computer room so they can see where
their files are really stored. I use props (disk packs, tapes,
floppies, you name it) and flip charts and hands-on sessions and
anything to liven up the class and to make concrete analogies for
these abstract concepts.
I have found that a first session with no real UNIX or job-specific
topics eases a lot of the tension. It has made a world of
difference in the level of retention of my students. (I didn't
used to do this, so I have a basis for comparison.)
On the second day I introduce them to the concept of files and
directories, using the office filing cabinet analogy, and teach
them all the file and directory manipulation commands, such as ls,
mkdir, cp, cd, mv, rm, and rmdir. We practice pathnames forever
and ever, moving up and down and all around the file system, so
they have a concrete understanding of where they are and what is
"home."
On the third day we learn vi, and they get to practice that until
they're blue in the face. I try to give them fun files to type
(like bad lightbulb jokes), so they don't get bored. By this time
they have typed the "cd" command so many times that it is
practically instinctive for them to change to the correct directory
before they begin to type their new files.
On the fourth day they learn to use vi to insert nroff commands in
their files, and then do some very basic text formatting. In this
session I stress again and again the difference between vi and
nroff, which seems to confuse some people.
On the fifth day we reiterate the nroff lessons, add a few troff
commands, and then learn to create some basic tables using tbl.
On the sixth day we return to the operating system and discuss
pipes and funnels and foreground and background processing. By
this time they have an actual need for all this (redirecting nroff
output and the like), so it makes a lot more sense to them and
tends to stay with them longer. We also set up a few startup files
(like .profile and .exrc) and learn how to use mail, man and apropos
(man -k).
All in all, it is a *lot* of information packed into 6 sessions,
but I give massive amounts of documentation (most of which I wrote
myself) and *always* give them the means to find out more
information, either by looking it up in the reference materials or
by calling me. Also, their lab session/homework assignments are
designed to be used as step-by-step reference guides when they are
through.
I think the MOST IMPORTANT thing, and I can't stress this enough,
is that I remember what it was like to learn something from
absolute scratch, so I break everything down into its most basic
concepts. I find this to be the biggest problem with people who
were computer science engineers first and trainers later -- they do
not get basic enough. It simply DOESN'T WORK to assume a level of
technical sophistication or savvy on the part of your students if
common sense tells you they don't have the background. No, I don't
talk down to my students; I simply break everything down into
manageable, concrete descriptions of abstract concepts. I also try
to make class a lot of fun. We joke a lot, I use the students in
all my examples, etc. So far it has been a resounding success.
This is way too long for me to discuss how I train the people who
already know computers but need to know UNIX, but if anyone wants me
to post that, I'll do it in a separate posting.
--Heather Emanuel
{allegra,cci632,gatech,ihnp4,linus,raybed2}!rayssd!hxe OR hxe@rayssd.ray.com
--------------------------------------------------------------------
I don't think my company *has* an opinion, so the ones in this
article are obviously my own.
--------------------------------------------------------------------
"The woods would be very silent if no birds sang except those that
sing the best." --Thoreau