Shallow Thoughts
Akkana's Musings on Open Source, Science, and Nature.
Sat, 09 Aug 2008
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.
Tags: education, javascript, programming, speaking
[
11:54 Aug 09, 2008
More education |
permalink to this entry
]
Mon, 22 Oct 2007
I'm taking an online Spanish class. My mom talked me into it -- she
and I both periodically try to learn Spanish, then forget it again
because we don't practice enough. The hope is that if we're both
taking the same class, we'll converse with each other by email
en Español, have more fun and learn better.
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-8
Perhaps 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.
Tags: education
[
11:45 Oct 22, 2007
More education |
permalink to this entry
]
Mon, 15 Oct 2007
Last week, one of my favorite science podcasts,
This Week in Science,
had an interview with Danica McKellar. You may remember Danica --
she's written a book for middle school girls called
Math
Doesn't Suck: How to Survive Middle-School Math Without Losing Your
Mind or Breaking a Nail. You may also know her as Winnie Cooper
from the old TV show
The Wonder Years, or more recently on
West Wing, and she's also a math graduate and co-author of
the Chayes-McKellar-Winn theorem.
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!
Tags: education
[
21:16 Oct 15, 2007
More education |
permalink to this entry
]
Thu, 03 Nov 2005
I presented an astronomy program for a group of middle school girls --
and survived!
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.
Tags: education
[
17:48 Nov 03, 2005
More education |
permalink to this entry
]
Thu, 10 Feb 2005
I'm back in college, after [mumble] years away. What fun!
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.
Tags: education
[
21:29 Feb 10, 2005
More education |
permalink to this entry
]
Mon, 10 Jan 2005
Paraphrase of a recent conversation with a teacher (who might not want
her name used):
She (describing a student who was having difficulty):
... of course,
once I realized how far behind he was, I couldn't spend any more time
helping him, because of No Child Left Behind.
Me: Um ...?
She: No Child Left Behind says we have to raise our test
scores. So now the school administration decides which students are
close to being able to get an acceptable score, and we're supposed to
spend all our time on those students making sure they pass,
and not waste time on the students who are too far back.
Me: So, because of No Child Left Behind, you have to ...
She: Leave him behind. That's right.
Tags: education
[
18:10 Jan 10, 2005
More education |
permalink to this entry
]
Sat, 14 Aug 2004
I spent Thursday volunteering at
Get
SET, a program for introducing high school girls to science and
technology. I helped with the Java programming workshop.
This was my first time with Get SET (or any similar program),
but I was impressed: it's a good program, and I want to do
more work with them.
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.
Tags: education
[
12:40 Aug 14, 2004
More education |
permalink to this entry
]