done.

Well. I just took my last final--that will be all.

I didn't do as well as I'd hoped, but I survived (mostly) and I'm going back for more.

Some things I learned this semester:

• how to create simple and moderately complex programs in Visual Basic, bash, and C
• how to document my code
• how to work with conditional statements, subroutines, loops, functions, and arrays
• how to use server-side includes in a web page
• how to write (simple) algorithms from scratch
• how to do just about anything in bash
• how to take a PC apart and put it back together
• how to install Ubuntu on a laptop

Some other, less tangible things I learned:

• How you study and prepare for, and how you're evaluated in computer science courses is very different from how you study and prepare for and are evaluated in humanities classes. This should have been obvious to me, but it wasn't. It's even had me questioning whether, when I was an undergrad with a GPA of 3.8, I was even a very good student, because it seems to me that college wasn't very hard for me at all, that my major just wasn't very challenging. (I suppose that might also be true for a lot of mathematically or technically oriented students who bragged about being able to pass a course without ever cracking a book, but couldn't write their way out of a paper bag.)
• Deeply connected to that first point is that time management was a huge issue for me. Too often, I underestimated how much time it would take to complete an assignment or study for exams--there was a lot of late night panic that probably wouldn't have been necessary had I really been better at gauging the time required.
• I realized that I actually do care about my grades, and that it's OK--more than OK--to care about them. I don't really have a lot of respect for my two prior degrees, because despite a stellar academic record (at least on paper), I don't feel as though they've really gotten me all that far, so I'd kind of given up on caring whether I got A's or not. But it turns out that I do care, actually...and if I ever want to get a graduate degree in computer science at Major Midwestern Engineering School, I will have to care, quite a bit. In any case, I think A's in these classes will actually be more of a measure of achievement than the A's I got for my bachelor's and master's in English. Those grades really only measured how well I could snow my professors with my writing ability. These grades really will measure how well I understand and demonstrate tangible, useful skills.
• I can do this stuff. If it takes me a long time, if I feel like I'm swimming through molasses, it's because I've never done it before, not because I'm stupid. If I keep practicing, I will get better. Most of all, I don't need X or anyone else to hold my hand.
  
• I really need to restructure my life to accommodate both this and my work. Some things are just going to have to go by the wayside. Meals are going to get a lot simpler. Everyday routines are going to have to be a lot more streamlined. There will be no time for sloth or fussing of any sort. This is not a bad thing. I can see now why the uniform of the programmer/developer/computer scientist is a t-shirt and jeans or, in my husband's case, khakis and oxfords. "I don't have to think about what I'm going to wear," he says, standing before his rack of identical white or blue shirts and beige trousers. But I hope to still be able to bake French bread every once in a while. There should be some pleasure to life, after all.

OK, now I have to turn my brain off and stop thinking about computer science for a weekend. On Monday there will be plenty of time for that sort of thing. Class starts Tuesday, and I intend to show what I'm capable of.

you are going to be a stunning programmer someday...

I heard this today, quite out of the blue, from a cow-orker who has been coding since I was in junior high school. I'd mentioned earlier in the conversation that I'd just written my first C program (it's very basic) and now had a better understanding of compiling and running C programs from the command line (one of the topics covered in the tutorial I'm working on), and so he asked me what I was learning in my coursework, and what my background was.

"English," I said, half apologetically. "Completely nontechnical."

"Wow," he said. "You are going to be a stunning programmer someday. Better than a lot of programmers who come from science and math backgrounds."

His reasoning was that with a strong grasp of language, grammar, syntax, and stylistics, I would become very good at it over time...and that I'd be able to do something that programmers from technical backgrounds often didn't--make my code readable, easy to understand and update. "Never mind the math," he said. "You can look it up, learn it later."

I don't know if that happy state of affairs will ever come to pass, but it's encouragement I really needed to hear right now. I am still fighting a tendency to see technology as something that's off limits to someone like me, to see a huge yawning gap between him (a subject matter expert) and me (a mere technical communicator). But when I mentioned the networking course I'd be taking, he said, "That's the kind of course that is a great leveler. You don't need a scientific background to understand networking. You'll be leaps and bounds ahead of people who don't have a formal background in networking."

And maybe it's a bit of a challenge: you will be a stunning programmer someday. An expectation to live up to. In other words: this is something that should, actually, come easily to me. And perhaps, if I force myself to to see it as a potential to reach rather than as a set of odds to beat, it will start to come more easily.

taking a breath...

Yeah, I need to post more. But coursework got in the way, and so did life. Work on the project I began with in January ramped up and then ended abruptly, and then, serendipitously, I hooked up with another group that needed a lot more documentation-type stuff. There will, hopefully, be some design work a little later, but for right now I'm enjoying getting to do what I like best: making information accessible to larger groups of people...and applying some of my new skills.

Currently, I've taken over a tutorial (which is probably less than half complete) for new users on a distributed system of supercomputing resources around the country (currently, we have two such machines here at Major Midwestern Supercomputing Center). Users are mostly scientists from a huge range of disciplines and their undergraduate and grad students, and many are new to scientific computing, so in addition to getting them used to using the user portal, I have to help them get used to working with the UNIX shell.

So right now, as a matter of fact, I'm putting together a section on shells of various kinds that users are likely to encounter at different institutions: mainly, csh, tcsh, and bash. I'm still puzzling over how to explain the differences between the shells in a way that is useful and will make sense. But I'm also working on creating a very basic tutorial on getting around in UNIX, because I've noticed that existing documentation often instructs users to do things like this:

rm -rf directory/subdirectory

If you don't know that rm -rf should be used with caution and type a wrong filename, the results could be disastrous. Oh, and you could accidentally clobber files while trying to redirect output, and make a lot of mischief with tar and other utilities if you don't know what you're doing with them.

Besides, when I don't know a system, cookbook-style instructions, which often seem to communicate, "Just do this, don't ask questions, and everything will be OK," make me feel helpless and disoriented. And the man pages are not really written for novices. I know that I could probably just link to half a dozen Linux tutorials for beginners, and I will anyways, but that also seems like it could be overwhelming, so my plan is to take the commands and utilities I find sprinkled throughout the original documentation and devote a screen or two to each one, just to explain what it does, some of its common options, and what users might want it for later on.

So my coursework is yielding tangible results already. I think the feeling of being a novice user is also helpful and something I want to hold onto for a while--part of the reason such tutorials are necessary is that the original authors of current site documentation are mostly technical experts and seem to have forgotten--or perhaps never known--what it's like to see UNIX and computing in general as a black box.

Objectified

want to see this. Desperately.

yep, same guy who made Helvetica. Go figure.

For this I blame my friend and cow-orker b., who is taking a break from graphic design for a little while to go collect his sweet baby boy from Korea.

How To Take Your Computer Apart

How to Take Apart a Computer -- powered by eHow.com

I think it's funny that this guy prefaces this video tutorial with "Don't know why you'd want to take it apart, but..." when so many final exams in beginning computer hardware classes, like mine, involve taking apart a computer and putting it back together. (Of course, I think it's the reassembly that's the real challenge.)

Fun with cat

When I started learning about the Bourne shell this semester in my Intro to Linux class, I discovered cat. No, you can't get a whole book out of it, though this interview (with the accompanying proposed O'Reilly cover) was my favorite April Fool's Day joke.

However, cat is actually pretty useful. Short for "concatenation," it directs standard output of a file or a command to the terminal. The most basic use of cat is to type the command at the bash prompt, followed by a line of text. Here's what happens:

$ cat print this line of text
print this line of text

The command line is "standard input." The line that prints out to the shell is "standard output."

Use cat to quickly view files.
OK, maybe that's not incredibly useful, at least for our purposes. But, say, what if you have a really messy home directory, with a lot of practice files? Like this:

DEADJOE
a*
a.sh*
a~*
b*
b.sh*
b~*
c*
c.sh*
cat.txt
cat.txt~
cattemp
c~*
dogs
dogs~
glupr
glurp
soopersekrit

You could go into an editor like joe or pico and open each file individually--kind of the way you have to do with most GUI word processing/text editing applications. Or you could do it much more quickly with cat:

$ cat soopersekrit
ok, here's a soopersekrit file that I'm going to copy.
seems pretty intuitive.
C-x-s saves.

That's all! I think I was trying out the joe editor with this file. Nothing to see here. But this could be really important later--say, what if you're investigating an intrusion incident and you're going through a huge number of files and directories to see if there's a nasty little rootkit script hidden away there somewhere? That can speed things up tremendously, although the security engineers I know probably use scripts that automate that process. For longer files you want to use | (pipe) and the more filter.

$ cat jeoffrey | more

This will show you a page of a file at a time--like the one above, "For I will consider my cat Jeoffry," a long, affectionate paean from harmless 18th-century religious lunatic Christopher Smart to his feline companion. (I like to use it for playing with long files, because it's a charming poem, and because it seems appropriate to use with cat.) Just press the spacebar to proceed.


Use cat to redirect output from one file into another.
You could use cp or mv to do this, but you might find cat more expedient. Here you use the redirect output symbol (>):

$ cat fun_with_cat > fun_with_cat_backup

Always be very careful with this command, though, because if you try to redirect output into an existing file, it will replace any content in that file. To safeguard against this, you can enable a feature called noclobber, which displays an error message and won't permit the command to be executed.

Use cat as an editor.
Want to get something down quickly, without leaving the command line or opening up a new shell? Just use cat to start sending input to a new file:

$cat > notes_on_cat
Things I can do with cat:

1. Preview files quickly.
2. Redirect the output from one file into another. (careful!)
3. Use cat as an editor.

When you're done, control-d saves and exits the file. But as with redirecting output, be careful that if you return to the same file that you don't end up overwriting what you've previously stored there. To pick up where you left off, use the append output symbol (>>):

$ cat >> notes_on_cat

OK, what was I saying? Cat is a very useful command.

Cat does have limitations as an editor, though--you can't go back and edit text, and you can only delete the line you're working on. So while I first attempted to draft this entry entirely in cat, I found it a wee bit impractical. But for taking notes while playing around with the Linux shell, it's incredibly useful. There are lots of other things you can do with cat involving pipes and tees and filters, but these are the three I've found most helpful lately. I'm hoping to add more of the useful things I've gleaned from my classes here--it actually provides something of a review for me and keeps me in shape as a technical communicator.

the luxury of being alone...

"For my belief is that if we live another century or so...and have five hundred a year each of us and rooms of our own; if we have the habit of freedom and the courage to write exactly what we think; if we escape a little from the common sitting–room and see human beings not always in their relation to each other but in relation to reality; and the sky, too, and the trees or whatever it may be in themselves...if we face the fact, for it is a fact, that there is no arm to cling to, but that we go alone and that our relation is to the world of reality and not only to the world of men and women, then the opportunity will come..." --Virginia Woolf, A Room Of One's Own, 1929

Right: This nine-year-old girl currently shares a bed with two little brothers in a California motel. Her parents and a baby brother have the other bed. (Credit: Monica Almeida/NY Times)

Reading this article about families displaced by the economic crisis (can we call it a depression yet?) has been causing me to reflect on one of those privileges, generally afforded more to men than to women, and far less to kids from families in straitened circumstances: private space.

It's something I've taken for granted--X and I don't have children, so we rattle around in a 2100-square-foot, four-bedroom house. When I started coursework in computer science, though, I found myself working a lot more on the Windows box in the library, which I need for two of my classes (and now use for the third, with a PutTY connection). Being down there with X and the cats was pleasant...but, I have to admit, kind of distracting. So last week, with X's blessing, I moved the library computer upstairs to my study and realized how important it was to have a dedicated workspace where I could think and concentrate without interruption.

I've discovered now that I can work--really get lost in my work--for long periods of time without getting distracted....and that I'm not lonely--just knowing that X is somewhere in the house is comforting, but I don't have to be in the same room with him.

I think, though, how lucky I've been, mostly. Growing up, I had my own room on an upper floor in my family's house, which I did not have to share with my sister. I had a desk and bookshelves, and it was quiet. My mother, like most mothers, made a lot of noises about me spending so much time in my "ivory tower," but I was (and continue to be) rather introverted, and it was a sanctuary without which I would have gone nuts. This is what I would do when I came home: walk into my clothes closet (a tiny 4 x 6 space), close the door, breathe deeply in the darkness, and emerge into my room as though it were separate in space and time from all the craziness in other parts of the house.

I think now of women and girls who no longer have rooms of their own, who live in motel rooms and with relatives, with no place to put their books or do their homework or sit quietly and think, or write. Will they again, someday? What will it do to their hopes and dreams, all this overcrowding, this lack of lockable doors? That private space, so briefly a common expectation in shared Anglo-American culture less than ten years after Virginia's death, is now more important than ever.

Project Dignity in Southern California is helping the family of the young lady in the picture pay their motel bills each month while they get back on their feet...and hopefully, give her a room of her own sometime soon.