Mother: So, what did you learn in school today?
Son: (Excited) We learned to do one takeaway one!
Mother: Really? What is one takeaway one?
Son: (with obvious pride) Zero!
Mother: Are you sure?
Son: (slightly flustered) Uh, yeah ... Zero ...?
Mother: One takeaway one is ten. They're teaching you wrong, aren't they?
The first boils down to a misunderstanding of how the Linux file system hierarchy works. (For a refresher, you might want to check out my Linux Planet article Navigating the Linux Filesystem.)
The second problem is due to forgetting the rules of shell grammar. Every shell sentence needs a verb, just like every sentence in English. In the shell, the command is the verb: what do you want to do? The arguments, if any, are the verb's direct object: What do you want to do it to?
(For grammar geeks, there's no noun phrase for a subject because shell commands are imperative. And yes, I ended a sentence with a preposition, so go ahead and feel superior if you believe that's incorrect.)
The thing is, both mistakes are easy to make, especially when you're new to the shell, perhaps coming from a "double-click on the file and let the computer decide what you should do with it" model. The shell model is a lot more flexible and (in my opinion) better -- you, not the computer, gets to decide what you should do with each file -- but it does take some getting used to.
But as a newbie, all you know is that you type a command and get some message like "Permission denied." Why was permission denied? How are you to figure out what the real problem was? And why can't the shell help you with that?
And a few days ago I realized ... it can! Bash, zsh and similar shells have a fairly flexible error handling mechanism. Ubuntu users have seen one part of this, where if you type a command you don't have installed, Ubuntu gives you a fancy error message suggesting what you might have meant and/or what package you might be missing:
$ catt /etc/fstab No command 'catt' found, did you mean: Command 'cat' from package 'coreutils' (main) Command 'cant' from package 'swap-cwm' (universe) catt: command not found
What if I tapped into that same mechanism and wrote a more general handler that could offer helpful suggestions when it looked like the user forgot the command or the leading slash?
It turns out that Ubuntu's error handler uses a ridiculously specific function called command_not_found_handle that can't be used for other errors. Some helpful folks I chatted with on #bash felt, as I did, that such a specific mechanism was silly. But they pointed me to a more general error trapping mechanism that turned out to work fine for my purposes.
It took some fussing and fighting with bash syntax, but I have a basic proof-of-concept. Of course it could be expanded to cover a lot more types of error cases -- and more types of files the user might want to open.
Here are some sample errors it catches:
$ schedule.html
bash: ./schedule.html: Permission denied
schedule.html is an HTML file. Did you want to run: firefox schedule.html
$ screenshot.jpg
bash: ./screenshot.jpg: Permission denied
screenshot.jpg is an image file. Did you want to run:
pho screenshot.jpg
gimp screenshot.jpg
$ .bashrc
bash: ./.bashrc: Permission denied
.bashrc is a text file. Did you want to run:
less .bashrc
vim .bashrc
$ ls etc/fstab
/bin/ls: cannot access etc/fstab: No such file or directory
Did you forget the leading slash?
etc/fstab doesn't exist, but /etc/fstab does.
You can find the code here: Friendly shell errors and of course I'm happy to take suggestions or contributions for how to make it friendlier to new shell users.
It went okay, but not as well as I'd hoped. This year's class was more distractable than classes of past years -- and, judging by their career goals, less interested in computers or engineering, unfortunate in a program run by the Society of Women Engineers.
In the morning, we had a hard time getting them to focus long enough to learn basics like what a variable was. After a caucus at lunchtime, we decided to skip the next exercise (looping over an array of colors) and spend some time drilling on the basics, and keep at it 'til they got it. It took a while but we eventually got through. We needed more examples in the morning, more interaction, some visceral way of explaining programming basics so they really get it.
They do better working as a group on a concrete problem, like the final whiteboard exercise, "How do we figure out whether the click was on the flower?". That always ends up being a highlight of the class, even though it involves (gasp) doing math. This year was no exception, but it did take a while to get through. Using variables lost them completely ("is the mouse's X coordinate bigger than or less than the flower's X?") but when we used actual numnbers and ran through several examples, things eventually clicked. "The flower starts at (2, 5) and is 200 pixels wide. If the mouse click is at (34, 45), who thinks it's inside the flower? Raise your hands. Who thinks it's not? Now what if I click at (300, 24)?" A couple of them got it right away, but it took a long time to bring the whole class along.
I'm not still sure how to use that method for more basic concepts like "what is a variable?". Perhaps some sort of role-playing? Watching William Phelps guide the girls through planet motions in our astronomy workshop Wednesday, each girl playing the role of a solar system object, inspired me. I'd used role-playing like that with little kids, but William says it works even with adults to get concepts across, and after seeing him with the high schoolers I believe it. But how to adapt that to programming concepts? A recent Slate article on teaching programming had some interesting ideas I want to try.
Printed handouts for GetSET may be a waste of time. Nobody was even bothering to look at them, despite the fact that they had complete instructions for everything we were doing. Do schools not give students printed assignments or homework any more? Last year, they used the printed exercises but not the quick reference guides; this year they wouldn't even read the exercises. On the other hand, it might be worth it for the handful in each class who really love programming. I always hope some of them take the handouts home and try some of the extras on their own.
Finally, the class would be so much easier if we could teach it on a less pointy-clicky OS! Or at least on machines where IE isn't the default browser. The first 3-4 exercises go painfully slowly, guiding a roomful of girls through many GUI navigation steps:
Then the helpers have to go around the room ensuring that the girls have the correct file loaded in both Wordpad and Firefox. This took way too long with only four people to check the whole class, especially since we had to do it for every exercise. Invariably some girls will doubleclick instead of right-clicking or dragging, and will end up in whatever HTML editor Microsoft is pushing this year, or with an IE window instead of Firefox (and then the Error Console won't be there when she looks for it later).
Suggestions like "Keep that window open, you'll need it throughout the class" or "Try making that window smaller, so you can see both windows at once" don't help. The girls are too used to the standard Windows model of one screen-filling window at a time. Keeping two apps visible at once is too foreign. A few them are good at using the taskbar to switch among apps, but for the rest, loading new files is awkward and error prone.
In postmortems two years ago we talked about having them work on one file throughout the whole workshop. That would solve the problem, but I'm still working on how to do it without a lot of "Now comment out the code you just wrote, so you won't get the prompt every time, then scroll down to the next block of code and uncomment it."
I couldn't help thinking how on Linux, we could just tell them to type
leafpad whatever.html; firefox whatever.html and be done.
Or even give them an alias that would do it. Hmm ... I wonder if
I could make a Windows .bat file that would open the same file in
Wordpad and Firefox both? Must try that.
![[Mediun earnings]](/blog/images/mediun.jpg)
One of the local community colleges sent out glossy flyers
advertising their program, with the tag line "College pays
for itself; don't put it off!"
To prove how valuable college can be, they include a helpful table showing the "Mediun earnings" for people with various education levels.
West Valley actually has a decent sciences program, and some
other interesting programs like Park Management (ranger training).
But I suspect I should stay away from their English and Statistics
classes.
Every summer I volunteer as an instructor for a one-day Javascript programming class at the GetSET summer technology camp for high school girls. GetSET is a great program run by the Society of Women Engineers. it's intended for minority girls from relatively poor neighborhoods, and the camp is free to the girls (thanks to some great corporate sponsors). They're selected through a competitive interview process so they're all amazingly smart and motivated, and it's always rewarding being involved.
Teaching programming in one day to people with no programming background at all is challenging, of course. You can't get into any of the details you'd like to cover, like style, or debugging techniques. By the time you get through if-else, for and while loops, some basic display methods, the usual debugging issues like reading error messages, and typographical issues like "Yes, uppercase and lowercase really are different" and "No, sorry, that's a colon, you need a semicolon", it's a pretty full day and the students are saturated.
I got drafted as lead presenter several years ago, by default by virtue of being the only one of the workshop leaders who actually programs in Javascript. For several years I'd been asking for a chance to rewrite the course to try to make it more fun and visual (originally it used a lot of form validation exercises), and starting with last year's class I finally got the chance. I built up a series of graphics and game exercises (using some of Sara Falamaki's Hangman code, which seemed perfect since she wrote it when she was about the same age as the girls in the class) and it went pretty well. Of course, we had no idea how fast the girls would go or how much material we could get through, so I tried to keep it flexible and we adjusted as needed.
Last year went pretty well, and in the time since then we've exchanged a lot of email about how we could improve it. We re-ordered some of the exercises, shifted our emphasis in a few places, factored some of the re-used code (like windowWidth()) into a library file so the exercise files weren't so long, and moved more of the visual examples earlier.
I also eliminated a lot of the slides. One of the biggest surprises last year was the "board work". I had one exercise where the user clicks in the page, and the student has to write the code to figure out whether the click was over the image or not. I had been nervous about that exercise -- I considered it the hardest of the exercises. You have to take the X and Y coordinates of the mouse click, the X and Y coordinates of the image (the upper left corner of the <div> or <img> tag), and the size of the image (assumed to be 200x200), and turn that all into a couple of lines of working Javascript code. Not hard once you understand the concepts, but hard to explain, right?
I hadn't made a slide for that, so we went to the whiteboard to draw out the image, the location of the mouse click, the location of the image's upper left corner, and figure out the math ... and the students, who had mostly been sitting passively through the heavily slide-intensive earlier stuff, came alive. They understood the diagram, they were able to fill in the blanks and keep track of mouse click X versus image X, and they didn't even have much trouble turning that into code they typed into their exercise. Fantastic!
Remembering that, I tried to use a lot fewer slides this year. I felt like I still needed to have slides to explain the basic concepts that they actually needed to use for the exercises -- but if there was anything I thought they could figure out from context, or anything that was just background, I cut it. I tried for as few slides as possible between exercises, and more places where we could elicit answers from the students. I think we still have too many slides and not enough "board work" -- but we're definitely making progress, and this year went a lot better and kept them much better engaged. We're considering next year doing the first several exercises on the board first, then letting them type it in to their own copies to verify that it works.
We did find we needed to leave code examples visible: after showing slides saying something like "Ex 7: Write a loop that writes a line of text in each color", I had to back up to the previous slide where I'd showed what the code actually looked like. I had planned on their using my "Javascript Quick Reference" handout for reference and not needing that information on the slides; but in fact, I think they were confused about the quickref and most never even opened it. Either that information needs to be in the handout, or it needs to be displayed on the screen as they work, or I have to direct them to the quickref page explicitly ("Now turn to page 3 in ...") or put that information in the exercises.
The graphical flower exercises were a big hit this year (I showed them early and promised we'd get to them, and when we did, just before lunch, several girls cheered) and, like last year, some of the girls who finished them earlier decided on their own that they wanted to change them to use other images, which was also a big hit. Several other girls decided they wanted more than 10 flowers displayed, and others hit on the idea of changing the timeout to be a lot shorter, which made for some very fun displays. Surprisingly, hardly anyone got into infinite loops and had to kill the browser (always a potential problem with javascript, especially when using popups like alert() or prompt()).
I still have some issues I haven't solved, like what to do about semicolons and braces. Javascript is fairly agnostic about them. Should I tell the girls that they're required? (I did that this year, but it's confusing because then when you get to "if" statements you have to explain why that's different.) Not mention them at all? (I'm leaning toward that for next year.)
And it's always a problem figuring out what the fastest girls should do while waiting for the rest to finish. This year, in addition to trying to make each exercise shorter, we tried having the girls work on them in groups of two or three, so they could help each other. It didn't quite work out that way -- they all worked on their own copies of the exercises but they did seem to collaborate more, and I think that's the best balance. We also encourage the ones who finish first to help the girls around them, which mostly they do on their own anyway.
And we really do need to find a better editor we can use on the Windows lab machines instead of Wordpad. Wordpad's font is too small on the projection machine, and on the lab machines it's impossible for most of us to tell the difference between parentheses, brackets and braces, which leads to lots of time-wasting subtle bugs. Surely there's something available for Windows that's easy to use, freely distributable, makes it easy to change the font, and has parenthesis and brace matching (syntax highlighting would be nice too). Well, we have a year to look for one now.
All in all, we had a good day and most of the girls gave the class high marks. Even the ones who concluded "I learned I shouldn't be a programmer because it takes too much attention to detail" said they liked the class. And we're fine with that -- not everybody wants to be a programmer, and the point isn't to force them into any specific track. We're happy if we can give them an idea of what computer programming is really like ... then they'll decide for themselves what they want to be.
The class meets on a Saturday once or twice a month, so there's plenty of time to forget things between sessions, and most of the kids don't have a lot of prior computer experience (I'm told many of them are behavior problems or otherwise "at risk", but I sure wouldn't have guessed that from their exemplary behavior in class.) Despite the obstacles, the kids have learned some impressive image editing skills in a very short time! Lots of them have figured out how to set their Edubuntu desktop background; I've seen abstract patterns, photographs decorated in various ways (today one girl was painting a mouth, hair and jewelry on a photograph of a chimpanzee's face, and it came out looking very funny), photos of the students themselves pasted into exotic locales, and so on.
It's also an interesting exercise for me in seeing what beginning users find difficult to understand and what aspects of GIMP's user interface are difficult to explain. An additional challenge is that this classroom has no projector or centrally visible screen. So you can't just demonstrate how something works; everything must be explained slowly in words while the students follow along with each step, and then we have to go through the room helping students as they try to remember the steps.
One of the first tasks they take on is combining images: start with a photo of themselves, or of an animal or car, select it and paste it into another image. What's the easiest way of explaining selection of arbitrary shapes? Which method can be explained in less than a minute, and yet they'll remember how to do it after you leave and move on to the next student?
There are three obvious candidates for a general-purpose selection tool: the intelligent scissors, the paths tool, and the quickmask. We had a miscommunication in one of the early classes and didn't discuss which technique to teach, so I taught some students the paths tool while Christian was teaching others the iscissors. I found that both methods had some serious problems.
With Bezier paths, it's easy to click points around your object. Students get a little flustered the first few times they accidentally drag rather than click and drag handles appear, but they can get over that. The part that's difficult comes at the end, where they have to click Path to Selection, then Feather as a separate step (they don't need to feather the first time, but eventually they'll need it). And then there's the problem that the path as well as the selection remains visible, a distraction that they don't understand.
When I saw that Christian had been teaching some students the iscissors while I was teaching others paths, I thought, gee, good idea. Iscissors should be more straightforward, no? Well, no, as it turns out. New students have great difficulty making an iscissors selection. They're fine as long as they're clicking their points; the problem comes when they get to the last point, when in order to make a selection you must click carefully on your first point, then click again inside the figure. A lot of students don't understand this no matter how many times you explain: they don't remember which was their first point (it doesn't look any different from the others), they can't see it anyway (it usually doesn't contrast much with the image), and they can't tell whether they clicked it successfully.
At that point they try to click inside the image and get a spurious extra point -- and then they panic and start clicking all over the place, ending up with a mess that is (as far as I've been able to tell) unrecoverable. The only fix is to toss out that figure and start over, but even that isn't easy to do (click on another tool then back on the iscissors tool button). Basically, the iscissors tool is far too confusing and most students need to be personally walked through it at least three times (some of them a lot more than that) before they get it.
Anyone who's read my writing on GIMP probably knows that I'm a quickmask zealot. I'm a born again quickmask prophet: I used GIMP for years without really understanding the quickmask, and when I finally grokked it, it made a huge difference in ease of selection. I sometimes joke that "the quickmask changed my life", and that's hyperbole, or course; but it sure did change my GIMP editing. People seem to fear the quickmask so I usually don't present it first, but maybe I should. These students are very eager and competent at painting, and I think they'd take to the quickmask very easily with far fewer stumbles than the other two methods have given them.
There's one other variant of shaped selection that I didn't list: the lasso tool in add and subtract mode. The lasso tool is terrifically hard to use to try to select a whole figure from an image. You'd have to have a preternaturally steady hand, plus you can't zoom in and scroll around since the whole figure has to be completed in one movement. But what you can do is make a rough selection with the lasso, understanding that you'll have some errors; then alternate between Add mode and Subtract mode as you use the lasso on smaller areas to get the selection just right. It's nearly as easy as the quickmask, and doesn't require a big conceptual shift. The only reason I'm leery is that I suspect the three modes would confuse a lot of students -- especially since the mode buttons have no labels, merely tooltips.
While I'm on the topic, there's another issue that gives the students trouble besides selection: the floating selection that results from a paste. There's really no way to explain to a schoolkid why it's there (heck, maybe some day someone will explain that to me). And it's useless to try to get them to keep their Layers dialogs visible. (They don't even keep the toolbox visible most of the time; it's always covered by image windows. Most of these Edubuntu machines are working at 800x600 resolution, and there just isn't room on the screen for the normal GIMP window collection.)
So I try to drill them that "Every time you paste, you have to find the Layers window and click that button on the bottom left." Understandably, they often forget that step, then get into trouble because they can't see all their pasted layer, or some functions are greyed out.
Aside from selection and paste, the students seem to cope with GIMP remarkably well. Some of them have been exploring the menus for fun plug-ins, others are trying different patterns to make interesting backgrounds, and one even discovered how to make interesting effects with some of the specialized gradients. At the beginning I wondered if teaching GIMP might not be too ambitious, and maybe something simple like Tux Paint might be better. But GIMP is working out just fine except for those few stumbling blocks. The kids have a refreshing willingness to explore and try things, and the result is a whole lot of really fun images.
I have no particular talent for (non-computer) languages, and in particular I have trouble learning vocabulary. By Lesson 2 I could see already that I was going to have trouble with the vocabulary lists. What I needed was flash cards!
There are probably a bazillion flash card apps around. But it's such a trivial problem, why not re-invent the wheel for the bazillion-and-oneth time? It's more fun to spend an hour hacking Python than to spend an hour googling and tossing out all the Windows and Mac and Java and web oriented solutions looking for something that's small, self-contained and runs on Linux.
So ... my trivial flashcard in Python. It doesn't make you type in the answer -- you just think of the answer and hit return, and if you got it right, hit return again for the next word. If you got it wrong, type something else (. or space or x or whatever) followed by return, and it'll remember that you got it wrong, increase the liklihood of showing you that word again, and print a list of words missed at the end (when you type q to quit).
I needed the
# -*- coding: utf-8 -*-at the beginning to keep it from complaining about the various accented characters in some of the Spanish words, but that doesn't automatically make it print those characters correctly. With LANG=C, it translates them into plain ASCII, which is okay with me most of the time. With LANG=en_US.UTF-8, which you'd think would work, it tends to print garbage characters or hexadecimal codes -- not so okay. The trick turns out to be to set it to Spanish:
export LANG=es_ES.UTF-8Perhaps I can force that in the script. But not right now ... I'm off to She's Geeky, a conference on Women in Tech going on in Mountain View today and tomorrow.
Anyway, the interview is great for anyone interested in the general question of math education. They get into questions like "Why study math?" and "Why do people find word problems so hard?"
She talks about a survey she passed out to middle school girls while she was working on the book. Some of the questions had to do with what they thought of smart girls and dumb girls, and on the latter, the most common answer was "There are no dumb girls -- they're just pretending to be dumb."
She was shocked by that. If you play dumb, she tells girls, you'll get into the habit. If you play dumb to get that guy, you'll have to keep playing dumb to keep him, and it'll become more and more ingrained. Eventually you'll start believing it. You'll feel worse and worse about yourself and you might not even realize why. And stopping it later might be a lot harder than you think.
She had a great analogy about that from her days on The Wonder Years. One episode involved people teasing her character for being a goody-two-shoes, and in particular her good posture. She read the script and was mortified -- "I do sit straighter than everybody else! Oh, no! I'm not cool! I should slump more!" She practiced for weeks, sitting hunched over in the cafeteria and in class so that by the time the episode came out, people at school would say "Oh, well, she was just acting -- see, she really slumps like everybody else so she's actually cool." She made it a habit.
Now, ten years later, she's noticing back problems and trying to get over that habit and fix her bad posture, and it's not easy! And of course, at the time nobody noticed and it didn't make a bit of difference to her school popularity.
On word problems, her book offers a table helping people in mapping
real-world word problems to the right equation (for example, if it
says "a third of", that means 1/3 *).
She also stresses using problems
about subjects students care about. Co-host Justin
comments that word problems in school math books always tended to
be obsessed with trains leaving station A and arriving at station B,
which doesn't relate to most kids' lives very much. Why not,
Danica suggests, design word
problems about buying magazines or sharing chocolate bars?
Anyway, it's a great interview, and I hope her book sells well and changes the world. I have a presentation coming up myself to a middle school girls' group in a few days (on astronomy) and I'm going to pick up a copy to make sure the girls know about it.
McKellar's website is mathdoesntsuck.com and you can listen to the whole interview on the TWIS podcast. If you like science podcasts, you'll want to check out TWIS anyway. They cover cool stuff and they do it well, with the nice bonus that it's hosted by a very sharp woman, Dr. Kirsten Sanford (plus goofy guy sidekick Justin Jackson). This particular episode starts with a fun and detailed discussion on listener responses to the "falling through a tube drilled through the center of the Earth" problem before they get to the interview. Check it out!
The American Association of University Women runs a program with some of the local high schools to encourage girls to study science, math and engineering. I've volunteered at the star party at their "Tech Trek" summer camp at Stanford quite a few times; the girls at the camp are always energetic, smart and enthusiastic.
Last summer I asked the camp organizers whether they did any programs during the school year. Before I knew it, I was (gulp) signed up to run one!
AAUW's format: the girls rotate among four different "stations", spending about fifteen minutes at each station. That wasn't long enough to do any real problem solving or teach them any mathematical techniques, so I had to stick to fairly simple concepts while trying to give them a taste of several different aspects of astronomy.
Then the school played a dirty trick on us, and told us when we showed up at dawn-thirty that most of the girls were having an important test (having something to do with state standards) that day and so we'd only get ten girls instead of 25. What, do they not plan the standards tests any earlier than the day they give them? It seemed rather rude of the school to spring this on a group of volunteers who have to show up early in the morning for a program that's been planned for months.
The stations:
Telescopes: I showed them several different types of telescopes, and explain the difference between reflectors and refractors and what each is good for. My little Coulter CT-100 came in handy since it's so open that it's easy to see the arrangement of the mirrors. For the refractor, I used an 80mm f/7 because it's easy to transport and set up (though something on an equatorial mount would have been nice). Then I had my cheapie homebuilt 6-inch f/4 Dobsonian so that they could play with a dob mount and see how it was built (and to show that telescopes don't have to be expensive). I had hoped to show the sun through the 80f7, but the sky didn't cooperate (no big surprise, in November). I also had a collection of eyepieces and binocular parts for them to disassemble and play with. Some girls were a lot more willing to play with things than others; several didn't seem to want to look or touch until specifically instructed "Stand there, look there, push there".
Mars: With Mars just past closest approach, of course there had to be a Mars station. I had them make Mars icosohedron globes and brought a selection of "Mars rocks" (mostly red oxidized basalt). They liked learning that Mars is red because it's rusty, but some of them had trouble assembling the icosohedrons.
Moon: A 100W light bulb and some ping-pong balls created a model of why the moon goes through phases, and what the difference is between phases and an eclipse. (I think the adult AAUW helpers may have learned as much from this exercise as the girls.) Moon maps and displays and "moon rocks" (basalt) rounded out the station.
Spectra and the Doppler Shift: A few weeks ago I made a "Doppler ball" to illustrate the Doppler effect with sound. Split a whiffle ball in half (the hard part here is finding one: toy stores and Target only sell them in quantity, but I found a 2-pack at a dollar store). Then install a buzzer (from Radio Shack) and a 9-volt battery inside the ball (and a switch, plug, or some other way to turn it on). Tie a string to the ball and whirl it around your head, or have people toss it back and forth, and listen to the frequency change according to whether the ball is coming or going. It's very effective!
In addition, we had diffraction gratings (from Edmund Scientific; there doesn't seem to be any place in the bay area where you can just walk in and buy consumer-quality diffraction gratings) and prisms, and incandescent lamp and fluorescent (mercury vapor) lamps to show the difference between a line spectrum and a continuous one. One of the other women got the idea to burn calcium citrate tablets to show a calcium line, but I didn't get a chance to see how that worked. Another woman brought a wonderful bell: she's in a bell-ringing choir, and showed how you can demonstrate the Doppler effect and also, by immersing a low-frequency bell in water, illustrate sine waves very effectively. Cool stuff!
(I had tried out the Doppler ball and the gratings on my Toastmasters group a few weeks earlier, and it worked well there too. The ball swinging, one spectrum, and some discussion of why spectra are important and what they can tell us about the universe, all just barely fit in a seven-minute speech.)
Overall the day went well, considering that we started late and had a much smaller group than we expected. The smaller group meant that we got more chance to talk and explain things and encourage them to play around. The evaluations were all fairly positive, there weren't any stations that seemed unpopular or just didn't work, and lots of them said they liked all the activities. (I was too busy running the telescope station to get a chance to peek in on any of the others, alas.)
I'd like to get a chance to lead a group of girls in a project with more depth, where they actually have to solve a problem, build something, or calculate something. That would require a few hours rather than fifteen minutes. But the "several small stations" approach is great for someone inexperienced in leading school programs, like me, or when you're not familiar with the girls and their interests and capabilities. It wasn't nearly as scary as I thought it would be, and was fun for all concerned.
I'm taking Field Geology, something I've wanted to take for years. I've been reading geology books for years, but there's a wide abyss between reading about limestone and olivine, and being able to identify random rocks in any location we hike.
So far, two weeks in, the class is great. The instructor is enthusiastic and interesting. Most of the students are geology fans like me, taking the course out of fascination for the subject. (Not all kids, either; several are returning students, like me. Is that a euphemism? Hey, Akkana, why don't you just say "old farts"?) Yesterday's lab was "Here's a box of sedimentary rocks, here's a bottle of acid, identify the rocks." Fun! I can hardly wait for the field trips. (Dave: How was your class? Me: We dropped acid! Dave: Really? Is it too late to sign up? Me: On the rocks.)
I brought in a rock collected from our last Utah trip, from the plateau rising out of the eastern edge of the Bonneville salt flats. Dave and I both guessed it was limestone. With the HCl it fizzed like mad. Cool -- we were right!
One minor amusement about being back in college: a lot of students now eschew the traditional backpack in favor of rolling luggage. Walking around campus you hear these rummmmmblings that sound like an onrushing skateboard, and it turns out to be some kid plodding along with luggage in tow. Well, maybe they have bad backs.
That was yesterday. Good things that happened today: I won our Toastmasters club table topics competition, so I get to compete at the next level. Also I posted lesson 3 in the gimp course (a fun one, making a Valentine's day card) and finished my planet column on Iapetus. Bad things: more Iapetus diagrams to make, and when I got home I discovered I had a slight fever. I feel better now, so maybe it won't turn into anything.
The workshop went really well, better than I expected. The girls were all bright and motivated, and they all managed to complete all the programming exercises. At the end we talked about open source a little bit (I was glad I'd brought the linux laptop along).
Some of the girls found out they don't have the patience needed for programming or debugging, which is fine -- not everyone is interested in wrestling with obscure compiler error messages. Others dove right in, and freelanced a little, changing "Hello world" strings to messages talking about themselves or their friends.
The girls who had the most difficulty apparently struggled either due to poor typing skills, or, perhaps, poor vision. I saw a lot of girls typing colons instead of semicolons, or periods instead of commas, or 0 or O instead of (), and of course the compiler error messages didn't give a first-time programmer much clue that that was what the real error was.
The only criticism I had was that it was a little too "cookbook". Mostly they were given the code, and had only to type it in. Since there were lots of exercises and everyone was working at different rates, any theory presented in front of the class was likely either ahead of or behind the exercise that any given girl was working on at the time.
This is a difficult problem to solve. Having lots of small exercises, where everyone progresses at her own pace, works out really well; but not being able to explain theory means that a lot of the girls were just blindly retyping, and didn't understand things like curly braces (I saw a lot of compiler error messages caused by "import" statements inside a class, or statements outside any class method, or simple unbalanced braces).
I wondered, during our postmortem after the girls left, whether it might be better, rather than having the girls complete 13 exercises then work on some extra tasks if they have time, instead having some extra tasks which they could complete at the end of each exercise, so the fast-working (or fast typing) girls would have something interesting to do while the others caught up, but everyone would still be on the same exercise and then the instructor could explain the next one to everyone all at once.
This would of course require more prep work, coming up with interesting extras for each exercise.
Other points:
They used Codewarrior for the exercises, and it took a lot of mouse clicks to change from one source file to another, and it has to be changed in two places. A lot of girls ran into trouble there. I found myself musing on how much easier it is just to type "javac filename" and then "java filename" to run it. (I'm sure Codewarrior is fine when you have a full project already set up and you're used to the interface.) Besides, javac (either from Sun or IBM) is free and Codewarrior isn't, so if any of the girls are interested in following up, which one would be easier for them to use themselves?
The last exercise actually did use javac, though, and it turned out that the software had been installed to an unexpected place, and so the pathnames in the instructions ended up not being right. I don't know what the procedure is for having software installed on lab machines at a school, nor whether there's much chance to test the setup before it gets used for the actual class. It sounds like a fairly complicated thing to coordinate. Of course I found myself thinking about whether customized knoppix CDs could be used for such a purpose (though they would probably be too slow).
If I ever get to design a course like this, I might try less "printing to stdout" and introduce GUIs earlier. GUIs are harder to program, but there was so much provided code anyway that it might not hurt to just provide a framework and say "This is how you bring up a window; don't worry too much about the details" and then start introducing buttons and text fields and so on -- rather like the approach taken in the O'Reilly X and Motif books, starting with a small "hello world window" example then gradually adding things to it. I think building up a medium sized program, with a window with lots of elements in it, might be more fun for a beginning programmer than just doing one short program after another.
The girls could have used some sort of help interpreting the compiler error messages, but I don't know of a good solution to how to teach this. Compiler errors tend to use fairly technical programming terms, which wouldn't have been appropriate to try to explain to someone with a few hours' programming experience. Even some of the volunteers had trouble figuring out the error messages. I wish there were a language for which this wasn't true, but python, perl, JS, all have fairly esoteric error messages which are difficult for a beginner (and sometimes even an experienced programmer!) to understand. The only clue I can think which might have helped them is a rule such as "if the compiler gives you an error you don't understand, carefully check the line with the error and a few lines for typos or incorrect punctuation marks." Perhaps followed by rule 2, "If that doesn't solve it, or especially if the error seems to have nothing to do with the line where the error is reported, check everywhere for balanced parentheses, curly braces, and square brackets." Those two would have handled at least 80% of the errors I saw.
Finally, the big question: how do you make the process creative, starting with students who have never programmed before? Learning is much more fun when you have problems to solve, or if you can look at it as a friendly competition or a game. That's hard when you're trying to cover a lot of new technical material in a single day. I don't have any ideas yet, but I'm going to give it some thought.
| < | March 2010 | > | ||||
| Su | Mo | Tu | We | Th | Fr | Sa |
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | 31 | |||
Aggregated on:
• LinuxChix Live
• Planet Ubuntu-Women
• Women in Free Software
• Graphics Planet
• Planet Openbox
• Planet LCA2009
Friends' Blogs:
• Ups & Downs
• DailyBBG
• Long
Live the Village Green
• Dan Heller
• Morris "Mojo" Jones
• Jane Houston Jones
Random Blogs:
• DevChix
• Scott Adams
• Dave Barry
• BoingBoing (Cory Doctorow)
• Young Female Scientist
About:
![[feed]](http://shallowsky.com/images/logos/feed-icon-14x14.png){kind=icon}
RSS
Follow me on Twitter
Shallow Sky Home
Contact Akkana
Powered by PyBlosxom.