Shallow Thoughts : tags : education

Letter to the New Mexico Public Education Department on Science Standards

For those who haven't already read about the issue in the national press, New Mexico's Public Education Department (a body appointed by the governor) has a proposal regarding new science standards for all state schools. The proposal starts with the national Next Generation Science Standards but then makes modifications, omitting points like references to evolution and embryological development or the age of the Earth and adding a slew of NM-specific standards that are mostly sociological rather than scientific.

You can read more background in the Mother Jones article, New Mexico Doesn’t Want Your Kids to Know How Old the Earth Is. Or why it’s getting warmer, including links to the proposed standards. Ars Technica also covered it: Proposed New Mexico science standards edit out basic facts.

New Mexico residents have until 5.p.m. next Monday, October 16, to speak out about the proposal. Email comments to rule.feedback@state.nm.us or send snail mail (it must arrive by Monday) to Jamie Gonzales, Policy Division, New Mexico Public Education Department, Room 101, 300 Don Gaspar Avenue, Santa Fe, New Mexico 87501.

A few excellent letters people have already written:

• Stephanie Garcia Richard, NM representative for Los Alamos and surrounding counties
• Erin Taylor, a teacher
• LWV of New Mexico

I'm sure they said it better than I can. But every voice counts -- they'll be counting letters! So here's my letter. If you live in New Mexico, please send your own. It doesn't have to be long: the important thing is that you begin by stating your position on the proposed standards.

---

Members of the PED:

Please reconsider the proposed New Mexico STEM-Ready Science Standards, and instead, adopt the nationwide Next Generation Science Standards (NGSS) for New Mexico.

With New Mexico schools ranking at the bottom in every national education comparison, and with New Mexico hurting for jobs and having trouble attracting technology companies to our state, we need our students learning rigorous, established science.

The NGSS represents the work of people in 26 states, and is being used without change in 18 states already. It's been well vetted, and there are many lesson plans, textbooks, tests and other educational materials available for it.

The New Mexico Legislature supports NGSS: they passed House Bill 211 in 2017 (vetoed by Governor Martinez) requiring adoption of the NGSS. The PED's own Math and Science Advisory Council (MSAC) supports NGSS: they recommended in 2015 that it be adopted. Why has the PED ignored the legislature and its own advisory council?

Using the NGSS without New Mexico changes will save New Mexico money. The NGSS is freely available. Open source textbooks and lesson plans are already available for the NGSS, and more are coming. In contrast, the New Mexico Stem-Ready standards would be unique to New Mexico: not only would we be left out of free nationwide educational materials, but we'd have to pay to develop New Mexico-specific curricula and textbooks that couldn't be used anywhere else, and the resulting textbooks would cost far more than standard texts. Most of this money would go to publishers in other states.

New Mexico consistently ranks at the bottom in educational comparisons. Yet nearly 15% of the PED's proposed stem-ready standards are New Mexico specific standards, taught nowhere else, and will take time away from teaching core science concepts. Where is the evidence that our state standards would be better than what is taught in other states? Who are we to think we can write better standards than a nationwide coalition?

In addition, some of the changes in the proposed NM STEM-Ready Science Standards seem to be motivated by political ideology, not science. Science standards used in our schools should be based on widely accepted scientific principles. Not to mention that the national coverage on this issue is making our state a laughingstock.

Finally, the lack of transparency in the NMSRSS proposal is alarming. Who came up with the proposed NMSRSS standards? Are there any experts in science education that support them? Is there any data to indicate they'd be more effective than the NGSS? Why wasn't the development of the NMSRSS discussed in open PED meetings as required by the Open Meetings Act?

The NGSS are an established, well regarded national standard. Don't shortchange New Mexico students by teaching them watered-down science. Please discard the New Mexico Stem-Ready proposal and adopt the Next Generation Science Standards, without New Mexico-specific changes.

Tags: science, education, politics, government
[ 10:16 Oct 12, 2017    More politics | permalink to this entry | ]

Everyone Does IT (and some Raspberry Pi gotchas)

I've been quiet for a while, partly because I've been busy preparing for a booth at the upcoming Everyone Does IT event at PEEC, organized by LANL.

In addition to booths from quite a few LANL and community groups, they'll show the movie "CODE: Debugging the Gender Gap" in the planetarium, I checked out the movie last week (our library has it) and it's a good overview of the problem of diversity, and especially the problems women face in in programming jobs.

I'll be at the Los Alamos Makers/Coder Dojo booth, where we'll be showing an assortment of Raspberry Pi and Arduino based projects. We've asked the Coder Dojo kids to come by and show off some of their projects. I'll have my RPi crittercam there (such as it is) as well as another Pi running motioneyeos, for comparison. (Motioneyeos turned out to be remarkably difficult to install and configure, and doesn't seem to do any better than my lightweight scripts at detecting motion without false positives. But it does offer streaming video, which might be nice for a booth.) I'll also be demonstrating cellular automata and the Game of Life (especially since the CODE movie uses Life as a background in quite a few scenes), music playing in Python, a couple of Arduino-driven NeoPixel LED light strings, and possibly an arm-waving penguin I built a few years ago for GetSET, if I can get it working again: the servos aren't behaving reliably, but I'm not sure yet whether it's a problem with the servos and their wiring or a power supply problem.

The music playing script turned up an interesting Raspberry Pi problem. The Pi has a headphone output, and initially when I plugged a powered speaker into it, the program worked fine. But then later, it didn't. After much debugging, it turned out that the difference was that I'd made myself a user so I could have my normal shell environment. I'd added my user to the audio group and all the other groups the default "pi" user is in, but the Pi's pulseaudio is set up to allow audio only from users root and pi, and it ignores groups. Nobody seems to have found a way around that, but sudo apt-get purge pulseaudio solved the problem nicely.

I also hit a minor snag attempting to upgrade some of my older Raspbian installs: lightdm can't upgrade itself (Errors were encountered while processing: lightdm). Lots of people on the web have hit this, and nobody has found a way around it; the only solution seems to be to abandon the old installation and download a new Raspbian image.

But I think I have all my Raspbian cards installed and working now; pulseaudio is gone, music plays, the Arduino light shows run. Now to play around with servo power supplies and see if I can get my penguin's arms waving again when someone steps in front of him. Should be fun, and I can't wait to see the demos the other booths will have.

If you're in northern New Mexico, come by Everyone Does IT this Tuesday night! It's 5:30-7:30 at PEEC, the Los Alamos Nature Center, and everybody's welcome.

Tags: programming, education, chix
[ 12:29 Mar 20, 2017    More education | permalink to this entry | ]

Coder Dojo: Kids Teaching Themselves Programming

We have a terrific new program going on at Los Alamos Makers: a weekly Coder Dojo for kids, 6-7 on Tuesday nights.

Coder Dojo is a worldwide movement, and our local dojo is based on their ideas. Kids work on programming projects to earn colored USB wristbelts, with the requirements for belts getting progressively harder. Volunteer mentors are on hand to help, but we're not lecturing or teaching, just coaching.

Despite not much advertising, word has gotten around and we typically have 5-7 kids on Dojo nights, enough that all the makerspace's Raspberry Pi workstations are filled and we sometimes have to scrounge for more machines for the kids who don't bring their own laptops.

A fun moment early on came when we had a mentor meeting, and Neil, our head organizer (who deserves most of the credit for making this program work so well), looked around and said "One thing that might be good at some point is to get more men involved." Sure enough -- he was the only man in the room! For whatever reason, most of the programmers who have gotten involved have been women. A refreshing change from the usual programming group. (Come to think of it, the PEEC web development team is three women. A girl could get a skewed idea of gender demographics, living here.) The kids who come to program are about 40% girls.

I wondered at the beginning how it would work, with no lectures or formal programs. Would the kids just sit passively, waiting to be spoon fed? How would they get concepts like loops and conditionals and functions without someone actively teaching them?

It wasn't a problem. A few kids have some prior programming practice, and they help the others. Kids as young as 9 with no previous programming experience walk it, sit down at a Raspberry Pi station, and after five minutes of being shown how to bring up a Python console and use Python's turtle graphics module to draw a line and turn a corner, they're happily typing away, experimenting and making Python draw great colorful shapes.

Python-turtle turns out to be a wonderful way for beginners to learn. It's easy to get started, it makes pretty pictures, and yet, since it's Python, it's not just training wheels: kids are using a real programming language from the start, and they can search the web and find lots of helpful examples when they're trying to figure out how to do something new (just like professional programmers do. :-)

Initially we set easy requirements for the first (white) belt: attend for three weeks, learn the names of other Dojo members. We didn't require any actual programming until the second (yellow) belt, which required writing a program with two of three elements: a conditional, a loop, a function.

That plan went out the window at the end of the first evening, when two kids had already fulfilled the yellow belt requirements ... even though they were still two weeks away from the attendance requirement for the white belt. One of them had never programmed before. We've since scrapped the attendance belt, and now the white belt has the conditional/loop/function requirement that used to be the yellow belt.

The program has been going for a bit over three months now. We've awarded lots of white belts and a handful of yellows (three new ones just this week). Although most of the kids are working in Python, there are also several playing music or running LED strips using Arduino/C++, writing games and web pages in Javascript, writing adventure games Scratch, or just working through Khan Academy lectures.

When someone is ready for a belt, they present their program to everyone in the room and people ask questions about it: what does that line do? Which part of the program does that? How did you figure out that part? Then the mentors review the code over the next week, and they get the belt the following week.

For all but the first belt, helping newer members is a requirement, though I suspect even without that they'd be helping each other. Sit a first-timer next to someone who's typing away at a Python program and watch the magic happen. Sometimes it feels almost superfluous being a mentor. We chat with the kids and each other, work on our own projects, shoulder-surf, and wait for someone to ask for help with harder problems.

Overall, a terrific program, and our only problems now are getting funding for more belts and more workstations as the word spreads and our Dojo nights get more crowded. I've had several adults ask me if there was a comparable program for adults. Maybe some day (I hope).

Tags: programming, education
[ 13:46 Feb 24, 2017    More programming | permalink to this entry | ]

Teaching Robotics to High School Girls at GetSET

Wednesday I taught my "Robotics and Sensors" workshop at the SWE GetSET summer camp.

It was lots of fun, and definitely better than last year. It helped that I had a wonderful set of volunteers helping out -- five women from CodeChix (besides myself), so we had lots of programming expertise, plus a hardware engineer who was wonderfully helpful with debugging circuits. Thanks so much to all the volunteers! You really made the workshop!

We also had a great group of girls -- 14 high school seniors, all smart and motivated, working in teams of two.

How much detail?

One big issue when designing a one-day programming workshop is how much detail to provide in each example, and how much to leave to the students to work out. Different people learn differently. I'm the sort who learns from struggling through a problem, not from simply copying an example, and last year I think I erred too much in that direction, giving minimal information and encouraging the girls to work out the rest. Some of them did fine, but others found it frustrating. In a one-day workshop, if you have to spend too much time working everything out, you might never get to the fun stuff.

So this year I took a different approach. For each new piece of hardware, I gave them one small, but complete, working example, then suggested ways they could develop that. So for the first example (File->Examples->Basic->Blink is everyone's first Arduino exercise), I gave everyone two LEDs and two resistors, and as soon as they got their first LED blinking, I encouraged them to try adding another.

It developed that about half the teams wired their second LED right next to the first one, still on pin 13. Clever! but not what I'd had in mind. So I encouraged them to try moving the second LED to a different pin, like pin 12, and see if they could make one LED turn on while the other one turned off.

Another challenge with workshops is that people work at very different speeds. You have to have projects the fast students can work on to keep them from getting bored while the rest are catching up. So for LEDs, having a box full of extra LEDs helped, and by the time we were ready to move on, they had some great light shows going -- tri-colored blinkers, fast flashers, slow double-blinks.

I had pushbuttons on the tentative agenda but I was pretty sure that we'd skip that part. Pushbuttons are useful but they aren't really all that much fun. You have to worry about details like pull-down resistors and debouncing, too much detail when you have only six hours total. Potentiometers are more rewarding. We went through File->Examples->03.Analog->AnalogInput, and a few teams also tried LED fading with File->Examples->03.Analog->AnalogInOutSerial.

Music

But then we moved on to what was really the highlight of the day, piezo speakers. Again, I provided a small working example program to create a rising tone. The Arduino IDE has no good speaker examples built in, so I'd made a short url for my Robots and Sensors workshop page, is.gd/getset, to make it easyto copy/paste code. It took no time at all before their speakers were making noise.

I was afraid they'd just stop there ... but as it turned out, everybody was energized (including me and the other volunteers) by all the funny noises, and without any prompting the girls immediately got to work changing their tones, making them rise faster or slower, or (with some help from volunteers) making them fall instead of rise. Every team had different sounds, and everybody was laughing and having fun as they tweaked their code.

In fact, that happened so fast that we ended up with plenty of time left before lunch. My plan was to do speakers right before lunch because noise is distracting, and after you've done that you can't to concentrate on anything else for a while. So I let them continue to play with the speakers.

I was glad I did. At least three different teams took the initiative to search the web and find sample code for playing music. There were some hitches -- a lot of the code samples needed to be tweaked a bit, from changing the pin where the speaker was plugged in, to downloading an include file of musical notes. One page gave code that didn't compile at all. But it was exciting to watch -- after all, this sort of experimentation and trial-and-error is a big part of what programmers do, and they all eventually got their music projects working.

One thing I learned was that providing a complete working .ino file makes a big difference. Some of the "music on Arduino" pages the girls found provided C functions but no hints as to how to call those functions. (It wasn't obvious to me, either.) Some of my own examples for the afternoon projects were like that, providing code snippets without setup() and loop(), and some teams were at sea, unsure how to create setup() and loop(). Of course I'd explained about setup() and loop() during the initial blink exercise. But considering how much material we covered in such a short time, it's not reasonable to expect everybody to remember details like that. And the Arduino IDE error messages aren't terribly easy to read, especially showing up orange on black in a tiny 3-line space at the bottom of the window.

So, for future workshops, I'll provide complete .ino files for all my own examples, plus a skeleton file with an empty setup() and loop() already there. It's okay to spoon feed basic details like the structure of an .ino file if it gives the students more time to think about the really interesting parts of their project.

Afternoon projects

After lunch, the afternoon was devoted to projects. Teams could pick anything we had hardware for, work on it throughout the afternoon and present it at the end of the workshop. There were two teams working on robotic cars (sadly, as with so many motor projects, the hardware ended up being too flaky and the cars didn't do much). Other teams worked with sonar rangefinders, light sensors or tilt switches, while some continued to work on their lights and music.

Everybody seemed like they were having a good time, and I'd seen a lot of working (or at least partly working) projects as I walked around during the afternoon, but when it came to present what they'd done, I was a little sad. There was a lot of "Well, I tried this, but I couldn't get it to work, so then I switched to doing this." Of course, trying things and changing course are also part of engineering ... that sentence describes a lot of my own playing with hardware, now that I think of it. But still ... I was sad hearing it.

Notes for next time

So, overall, I was happy with the workshop. I haven't seen the evaluation forms yet, but it sure seemed like everybody was having fun, and I know we volunteers did. What are the points I want to remember for next time?

• Start with small but complete working examples to introduce each new hardware component.
• Provide complete .ino files, not just code snippets.
• Skip pushbuttons, but do try to cover AnalogInOutSerial and PWM output. Or at least have printed handouts explaining the PWM outputs and LED fading.
• Turnkey kits are good: the less "connect the blue wire to pin 7, the green one to pin 8" the better. For things like cars, I'd like something already wired up with battery and shield, "Just add Arduino".
• Keep a closer eye on the afternoon projects -- try to make sure each team has something they're proud to show off.

Thanks again to the great volunteers! I'm looking forward to giving this workshop again.

Tags: robots, arduino, education, hardware, programming, maker
[ 20:36 Jun 29, 2013    More education | permalink to this entry | ]

Integrating graphics with text in Emacs

I discussed Emacs's artist-mode a few days ago as a simple, but incomplete, solution to the problem of sketching graphs while taking notes during a math class. But I've found a much better way, one that allows for including any images -- drawings, photos, or screenshots. It took a little work and some custom .emacs code, but I love the result.

Iimage mode

The key is iimage-mode, which displays inline images. In this mode, you put a line in your buffer with a reference to your image file, something like this:

file://myimage.jpg

and Emacs will replace it with the contents of that image. Marvellous!

You can use other patterns for filenames as well, but I'm fine with using URLs. Note there are only two slashes in file:// -- it's a local file in the same directory as the text file being edited.

It's a little tricky to enable it. The docs are not entirely clear on the differences between iimage-mode, turn-on-iimage-mode and iimage-mode-buffer. I found I could get a file that already had existing images to display them with:

  (turn-on-iimage-mode)
  (iimage-mode-buffer t)

Very cool! But too much to type every time. And to use it for note-taking, I needed a way to say, "Create a new image here, let me edit it, then display the image I just edited inline."

Enabling iimage-mode automatically

First, I wanted iimage mode displayed automatically on files in my note-taking directories. I normally use text-mode for these files, with spell checking and line wrapping turned on (auto-fill mode). So I defined a new minor mode based on text-mode:

(define-derived-mode text-img-mode text-mode "Image display mode"
  (auto-fill-mode)
  (turn-on-iimage-mode)
  (iimage-mode-buffer t)
  )

Then I wanted this mode to be called whenever I'm editing a file in my classes directory. So I added it to my auto-mode-alist:

(setq auto-mode-alist
   ...
      (cons '("Docs/classes/" . text-img-mode)
   ...
      auto-mode-alist) )

Inserting a new image

Next, I needed a way to insert an image URL into the buffer and call up an image editor on it. I shouldn't have to type the filename twice and keep track of it; that's what computers are for.

And I needed a drawing program. As a longtime GIMP geek, most of my computer drawing has been in GIMP. But GIMP is overkill for calling up a quick sketch window. I was tempted to use TuxPaint; it's a good sketching app even if you're not five years old, and it's fun and easy to use. But by default, TuxPaint has some features that get in the way of note-taking, like distracting sound effects. I'm sure it's possible to turn those off, and I do plan to investigate that.

I saw a reference to pinta as a lightweight drawing app, but it required a boatload of Mono libraries that I don't otherwise need, and Krita has the same problem with KDE services. So I opted for MyPaint. It works okay, though it's rather slow to start up and has some other issues, so I'm still hoping to find a more lightweight sketching app.

In any case, I fiddled around with start-process until I figured out how to use it to start a program. Then I wrote a little function that lets the user pick a filename, inserts a URL to that filename into the buffer, then calls up mypaint on the file.

(defun img ()
  "Prompt for a filename, then call up mypaint to create an image"
  (interactive)
  (let ((imgfile (read-string "Filename? " "xxx.jpg" 'my-history)))
    (insert "\nfile://" imgfile "\n" )
    (start-process "mypaint" nil "/usr/bin/mypaint" imgfile)
  ))

Worked fine! I can run M-x img, be prompted for a filename, and get a mypaint window where I can make my sketch.

Noticing that a new image has been added

But wait. I finish sketching, write the file and quit mypaint ... and the buffer still shows something like file://xxx.jpg, even if it's showing other images inline. I needed a way to tell it to refresh and load any new images. (I considered having emacs wait for mypaint to exit, but decided I might sometimes want to keep editing while mypaint was still up.)

M-x eval-expression (iimage-mode-buffer t) will do that, but that's a lot of typing to do. Obviously, I needed a key binding.

Strangely enough, C-c i wasn't taken for text buffers, so that seemed like a natural. So I added a key binding to the end of the text-img-mode. iimage-mode-buffer requires that t argument -- it gives an error without it -- so the key binding looks a little more complicated than one that just calls a simple function. I added it to the end of my text-img-mode function.

(define-derived-mode text-img-mode text-mode "Image display mode"
 ...
  (local-set-key "\C-ci" 
    (lambda () (interactive) (iimage-mode-buffer t)))
  )

But after using it a bit, I discovered that this didn't reload images if I edited them a second time. Fortunately, vwood had the answer:

(defun refresh-iimages ()
  "Only way I've found to refresh iimages (without also recentering)"
  (interactive)
  (clear-image-cache nil)
  (iimage-mode nil)
  (iimage-mode t)
  (message "Refreshed images")
 )

I added the message at the end, since otherwise the function left a distracting "Toggling iimage-mode off; better pass an explicit argument" error.

Then the key binding in my text-img-mode became

(local-set-key "\C-ci" 'refresh-iimages)

Inserting a screenshot

Wait -- one more thing. As I actually used text-img-mode to take notes, I discovered that taking screenshots would actually be much more useful than making my own drawings. Then I could copy small sections of the slides and graphs into my notes at the appropriate place, without needing to copy equations at all.

Why not write a function to allow that? The unpleasantly named scrot program fills the bill nicely, and gives me a choice of clicking in a window or dragging out an area of the screen.

(defun screenshot ()
 "Prompt for a filename, then call up scrot to create an interactive screenshot"
  (interactive)
  (let ((imgfile (read-string "Filename? " "scr.jpg" 'my-history)))
    (insert "\nfile://" imgfile "\n" )
    (start-process "scrot" nil "/usr/bin/scrot" "-s" imgfile)
  ))

This turned out to be so useful that I added a key for it in text-img-mode:

(local-set-key "\C-cs" 'screenshot)

I'm so happy with the result! Iimage mode is working great, and having text and images together is turning out to be perfect for note-taking.

My only problem now -- okay, I admit it -- is a tendency to get so excited over inserting screenshots that I get distracted and forget to actually listen to the lecture. I'm sure I'll get over that, but for now, Thank goodness vlc is good at skipping back!

Tags: editors, emacs, graphics, education
[ 13:42 Jan 12, 2013    More linux/editors | permalink to this entry | ]

ASCII graphics in Emacs with Artist Mode

I found a cool package in Emacs the other day: Artist Mode. It lets you draw ASCII graphics in your text file.

I was actually looking for the solution to a different problem: taking notes in a math-intensive Coursera class. I've been taking notes in Emacs, but a text editor is awkward for equations and even more awkward for graphs.

What I really wanted was something like the old Claris Works (or so I'm told; I never used it myself) -- something that's primarily a text editor but lets you drawings, equations, and tables when you need to. In theory, word processors like LibreOffice could do that, but in practice they're not very good at switching modes, nor at integrating several types of media into one document. Texmacs is great for the equations and apparently it can do tables too, but it can't do freehand drawing.

And none of these programs is very configurable -- I can't use my fast, comfortable Emacs bindings while typing, and that's a deal-breaker for me, because being able to make corrections quickly makes a huge difference in my typing speed. LibreOffice's key bindings are only partially configurable, and after you've spent half a day chasing down all the action names you need (the ones that are actually available), you upgrade to a newer version and discover you have to do it all over again because there's no way to migrate configuration files. Even Texmacs, ironically, is no better: the documentation claims it's possible to configure key bindings, but it doesn't appear anyone has ever succeeded in figuring out how.

Anyway, ASCII graphics aren't the ultimate solution to note-taking. And I've found a better solution for that, while I'll write about separately. But for now, Artist Mode is just so cool I had to share it.

Enable it by running M-x artist-mode. You can immediately start drawing in your buffer with the mouse. Whatever you draw gets turned into ASCII graphics.

For note-taking, it's fine for scribbling the rough shape of a curve. It takes no time to mouse in a little sketch like

       |                               .. 20
       |                              ..
       |                            ...
    10 |.                          ..
       |..                       ...
       | ...                   ...
       |   ..              ....
       |    .....      .....
       |    ............
       |.....        .............
       +-------------------------------------

It even has primitives (middleclick to get a.menu) for things like lines, rectangles and circles, and for filling regions. When you're done drawing, M-x artist-mode goes back to whatever mode you were using before.

I probably won't use it very much for note taking. But there are times when I've wanted to draw ASCII graphics -- a laborious process in ordinary text modes -- and other times when it would just be fun to play around with my buffer. I'm happy to know about Artist Mode. I may not need it often, but it sure is fun to use now and then.

Tags: editors, emacs, graphics, education
[ 20:02 Jan 10, 2013    More linux/editors | permalink to this entry | ]

High Schooler's for a Better Community

It's great to see high school kids doing public-spirited community projects like trail maintenance!

But I have to wonder if this particular group might do better spending some of that time working on studying their punctuation rules ...

Tags: humor, punctuation, apostrophe, education
[ 12:13 Nov 05, 2012    More humor | permalink to this entry | ]

Driving motors, CHEAPLY, with an Arduino

Some time ago, I wrote about my explorations into the options for driving motors from an Arduino.

Motor shields worked well -- but they cost around $50 each, more than the Arduino itself. That's fine for a single one, but I'm teaching an Arduino workshop (this Thursday!) for high school girls, and I needed something I could buy more cheaply so I could get more of them.

(Incidentally, if any women in the Bay Area want to help with the workshop this Thursday, June 28 2012, I could definitely use a few more helpers! Please drop me an email.)

What I found on the web and on the Arduino IRC channel was immensely confusing to someone who isn't an electronics expert -- most people recommended things like building custom H-bridge circuits out of zener diodes.

But it's not that complicated after all. I got the help I needed from ITP Physical Computing's DC Motor Control Using an H-Bridge. It turns out you can buy a chip called an SN754410 that implements an H-bridge circuit -- including routing a power source to the motors while keeping the Arduino's power supply isolated -- for under $2. I ordered my SN754410 chips from Jameco and they arrived the next day.

(Technically, the SN754410 is a "quad half-bridge" rather than an "dual h-bridge". In practice I'm not sure of the difference. There's another chip, the L298, which is a full h-bridge and is also cheap to buy -- but it's a bit harder to use because the pins are wonky and it doesn't plug in directly to a breadboard unless you bend the pins around. I decided to stick with the SN754410; but the L298 might be better for high-powered motors.)

Now, the SN754410 isn't as simple to use as a motor shield. It has a lot of wires -- for two motors, you'll need six Arduino output pins, plus a 5v reference and ground, the four wires to the two motors, and the two wires to the motor power supply. Here's the picture of the wiring, made with Fritzing.

With all those wires, I didn't want to make the girls wire them up themselves -- it's way too easy to make a mistake and connect the wrong pin (as I found when doing my own testing). So I've wired up several of them on mini-breadboards so they'll be more or less ready to use. They look like little white mutant spiders with all the wires going everywhere.

A simple library for half-bridge motor control

The programming for the SN754410 is a bit less simple than motor shields as well. For each motor, you need an enable pin on the Arduino -- the analog signal that controls the motor's speed, so it needs to be one of the Arduino's PWM output pins, 9, 10 or 11 -- plus two logic pins, which can be any of the digital output pins.

To spin the motor in one direction, set the first logic pin high and the second low; to spin in the other direction, reverse the pins, with the first one low and the second one high. That's simple enough to program -- but I didn't look forward to trying to explain it to a group of high school students with basically no programming experience.

To make it simpler for them, I wrote a drop-in library that simplifies the code quite a bit. It defines a Motor object that you can initialize with the pins you'll be using -- the enable pin first, then the two logic pins. Initialize them in setup() like this:

#include 

Motor motors[2] = { Motor(9, 2, 3), Motor(10, 4, 5) };

void setup()
{
    motors[0].init();
    motors[1].init();
}

Then from your loop() function, you can make calls like this:

    motors[0].setSpeed(128);
    motors[1].setSpeed(-85);

Setting a negative speed will tell the library to reverse the logic pins so the motor spins the opposite direction.

I hope this will make motors easier to deal with for the girls who choose to try them. (We'll be giving them a choice of projects, so some of them may prefer to make light shows with LEDs, or music with piezo buzzers.)

You can get the code for the HalfBridge library, and a sample sketch that uses it, at my Arduino github repository

Cheap and easy motor control -- and I have a fleet of toy cars to connect to them. I hope this ends up being a fun workshop!

Tags: arduino, hardware, education, programming, maker
[ 22:32 Jun 25, 2012    More hardware | permalink to this entry | ]

The Stanford online Machine Learning class

In case you haven't been following it, Stanford's computer science department began a grand experiment in online learning early this month: free, upper division college courses, given online and open to the whole world. There are three classes offered: Artificial Intelligence, Machine Learning and Introduction to Databases.

They've sparked an incredible response: exact numbers don't seem to be available, but rumor is that AI had about 130,000 enrolees, while ML had about 70,000. (Nobody seems to have published numbers for DB.) Update, a day later: @seemsArtless tweets that ML currently has 87,000 registered users.

Why so much interest? Surely there are lots of places to get free information (like wikipedia) and even course lectures (like MIT). And there are plenty of places to take classes for relatively low cost, like local junior colleges or ed2go.

What's different about the Stanford classes is that they cover advanced material, in far more depth than you'd find at a junior college or typical online site. They offer graded homework so you can see how you're doing, and there are other students taking the class at the same time, so if you get stuck, there are all sorts of discussion groups you can turn to. It's one thing to read a textbook or watch a video by yourself; I find a class much more helpful, and judging by the response to the Stanford classes, I'm not alone in that.

I agonized over whether to take AI or Machine Learning. They both sounded so interesting! Since I couldn't decide, I initially signed up for both, figuring I'd drop one if the load was too great. By the end of the second week, I'd settled on Machine Learning. I was starting to dread the AI class flash quizzes -- which didn't always work right, but made it hard to proceed until you'd answered the question right even if you couldn't see the question -- and to feel frustrated about the lectures, which clearly were meant as a jumping off point for students to go do their own outside reading.

On the other hand, I was really enjoying the Machine Learning lectures, and looking forward to each new one. And the real kicker: Machine Learning includes programming assignments, so students can implement the algorithms Professor Ng talks about in the lectures.

What's great about Machine Learning

Andrew Ng's video lectures are wonderfully clear, well paced and full of interesting content.

He uses a lot of graphs to help students visualize what's going on geometrically, rather than just relying on the equations. (Better yet, in the programming exercises he shows us how to create those graphs for ourselves.)

And he's great about flagging certain portions as possibly review (you can skip this lecture if you already know linear algebra) or advanced (this is some extra background for people who know calculus, but you can skip it and still do fine in the course).

The technology is simpler than that used in the AI course. If you have a slow net connection or travel a lot, you can download the lectures as mp4 files and watch them offline. You can download lecture slides as a PDF or PPT. Review questions (graded) are handled with simple HTML forms. All very simple, well-tested technology, and it works great. I've had no problems accessing the servers, submitting homework or anything else -- very impressive!

But the heart of the course is the programming exercises. ML is taught in GNU octave, a framework and language for numerical computing and matrix operations. Students aren't absolutely required to use octave, but it's highly recommended: Professor Ng says he's found that students learn much faster that way. Sounds good to me, and octave looks like a useful skill, well worth acquiring. I'm having fun learning it.

The programming exercises come with a lot of scaffold code plus a few files with "Your code goes here". The actual amount of coding isn't large. But I'm finding that it does the job: it forces me to make sure I understand the matrix operations discussed in the lectures. And at the end, you come out with something that's actually useful! From the first few weeks, I have linear and logistic regression code that I could use to analyze and visualize all sorts of datasets. Now, at the end of week 4, we're halfway through writing a neural network to recognize handwritten numerals from image data. How cool is that?

Suggestions for improvement

The class is a huge success. Who would have thought that you could teach something this advanced on such a huge scale, so effectively?

I have only a couple of small suggestions -- ways the class could be even better next time.

• An errata page. In week 3, there was an error in the lecture and notes, a - instead of a +, that made one part of programming ex. 2 quite a bit trickier than it would otherwise have been. If I hadn't noticed that the slides used + in some places and - in others, I might never have gotten that part of the assignment working. Lots of other people found that too, and there were discussions in the Q&A forum ... but you wouldn't find it without coming up with clever search terms.
• The Q&A forum would be so much more useful if it was organized by topic, and/or by week. There are some great discussions there, but the only way of getting to them is by searching for the right terms. There's no way to browse discussions, see how people are doing on assignment 3, or look for errata and similar warnings. It would help make the class more of a community, more like a real in-person class.

Hope for future expansion

I mentioned my suggestions because I fervently hope there is a "next time". These classes are a great service, and I hope the huge response isn't putting too much burden on the instructors.

"Common wisdom" among providers of online classes seems to be that there's no demand outside of enrolled university students for hard courses, courses with prerequisites, and especially courses that involve (shudder) math. Just look at the offerings from any online courseware or adult ed program -- they're long on art appreciation and "Introduction to MS Word", short on physics and econometrics. Even the for-pay online degree mills concentrate on humanities and business, not technical subjects.

Stanford's experiment has proven that "common wisdom" is wrong -- that tens of thousands of students will jump at the chance to take highly technical, mathematical courses. I'd love to see the model expanded to other subjects, such as statistics, economics, physics, geology and climate science.

And, yes, there is money to be made here. If this many people will take a free class, wouldn't quite a few of them be willing to pay? Most couldn't afford $1000 like UC Extension classes -- but how about $100, comparable to other online education classes? Would people pay more if you offered college credit?

Online education providers, take note! There's a large, underserved market for scientific and technical classes out here in the long tail.

Tags: education, programming
[ 17:31 Nov 05, 2011    More education | permalink to this entry | ]

Teaching programming with "program a person"

A few weeks ago, at the annual GetSET engineering summer camp for high school girls, I taught my usual one-day workshop on beginning programming in Javascript.

The big question every year is always how to make the class more interactive. The girls who come to GetSET are great -- smart and motivated -- but after six hours of lectures and working through exercises, anyone, of any age, is going to glaze over. Especially when it's their first introduction to programming and they only have a day to learn it. People learn better when they're asking questions, thinking and solving problems, not just listening or following instructions.

For years I've heard vague references to "programming a person" as an exercise for teaching the basic idea of programming. The idea is to get the students to come up with step-by-step instructions for someone to do something -- say, walk across the room and pick up a water bottle -- so they realize how specific you have to be. It also solves another problem: giving everyone a break from sitting still and focusing on a computer screen.

But how do you really do it? What kind of problems work best in practice? How much time should you allow? If you have a volunteer carrying out the instructions, how do you keep them from skipping steps? Surprisingly, I couldn't find anything written up to help an inexperienced would-be teacher of programming.

What I needed was a chance to try out some ideas, or watch someone with more of a clue on this sort of teaching. This year, I found opportunities for both.

First try: Toastmasters

One of the reasons I love Toastmasters, especially with a small and friendly club like Coherent Communicators, is that it offers a safe place to try new presentation techniques and get good feedback about what does and doesn't work. So I made my first try at a Toastmasters meeting a few weeks before the GetSET workshop.

I allowed 15-20 minutes for the exercise. I explained to the audience that I wanted them to get me to turn left, walk over to the easel at the side of the room, touch it, turn around, walk back to the lectern, pick up the gavel and pound it on the lectern. I would solicit a command from them, write it on the whiteboard, then carry out the command and ask for the next command.

The day's audience was a fairly even mix of techies and non. I had wondered whether the audience would be widely mixed in how specific their instructions were, but they were fairly uniform -- mostly along the lines of "Turn 90 degrees left." "Take 5 steps." "Take 2 more steps". Of course, there were a few joking suggestions from the techies, like "send an electrical impulse from your brain to your left quadriceps", that you wouldn't expect with a high school group, but mostly everyone was on the same page.

When I got near the easel, we hit "Raise your right arm". (Oops, not close enough yet.) "Um ... lean forward about a foot?" A good illustration of being specific ... just the sort of thing I was hoping for.

They got me back to the lectern, got me to pick up the gavel (I was letting them skip a few steps by this point) ... and improvised a little, getting me to knock my head rather than the lectern. That was fun, and got some laughs ... it worked well.

I had hoped to do a second run where I guided them into understanding a while loop ("while (not yet to the easel), take another step"). But seeing a yellow light from the timer, I opted for a quick explanation of how a loop would work rather than guiding the audience into it. I found out later that the timer had hit the wrong button and only given me 8 minutes rather than my requested 15-20 ... so 20 minutes actually would have been plenty of time to cover loops as well as basic instructions. Disappointing ... but I was surprised we'd gotten so much done in so little time.

Lessons learned:

• Draft a volunteer to write the instructions on the board. It was distracting and time-wasting to run back from the side of the room to write each new instruction.
• You can teach the basic concepts in less than ten minutes.

Try 2: "Program a blind robot"

For the real workshop, I had help in the form of Esther Heller, an experienced girl scout leader as well as many year GetSET veteran. Esther had done exercises like this before and was willing to take the lead; I was looking forward to learning from her. We had discussed two different variants, and decided to try both of them at different times during the day.

For the first variant, we waited until mid-morning when the class was bogging down a bit and looked like they needed a break. Esther called for two volunteers: one programmer and one robot. The girl playing the robot was blindfolded with a bandanna and escorted to the door of the room, while Esther whispered the task to the other girl. The task was something like walking over to a water bottle, picking it up, walking over to another girl and handing it to her -- though the rest of us didn't know that until it was completed.

The instructions suggested by the girls were quite similar to the ones I'd heard in Toastmasters. There was lots of "Take 5 steps" ... "take two more steps", guessing at how many steps it would take to get from one place to another. No one came up with anything like a loop or conditional. I'd wondered if anyone would try remote control -- "walk" then wait until the right moment to yell "STOP!" -- but no one did.

The blindfolding worked really well. I'd worried that with a volunteer chosen to be the robot, she might skip steps she hadn't been given. But if the "robot" is blindfolded and doesn't know the task, she can't skip steps; she can only do what she's programmed to. The only problem was that a blindfolded person told to walk straight ahead does not necessarily hold to a straight line, much to the consternation of the girl playing the programmer.

There was a lot of "turn right" ... "no, not that much, turn back left again" ... "now turn JUST A LITTLE to the right" that helped stress the need for specificity -- exactly what we were after. I had wondered beforehand whether anyone would ever suggest anything like "turn right by 30 degrees", but no one, either in Toastmasters or GetSET, ever did.

The exercise was successful and everybody seemed to have fun, so it broke up the morning well. We didn't get to loops or conditionals, though. I didn't record how long we spent, but it was probably in the neighborhood of 20 minutes.

Lessons:

• Blindfolding and choosing a volunteer definitely helps this exercise: it solves the problem of a volunteer who might skip steps.
• I wished the whole room knew what the task was ... but I'm not sure how to accomplish that. Either you have to escort the "robot" far enough away that she can't hear you explain it, or write it on the board after she's blindfolded. Extra time either way.

Try 3, in groups: "The muffin is ready"

At the end of the day, we tried Esther's favorite variant. You're watching TV, and you want to go to the kitchen, get an English muffin, toast it, put butter/jam/peanut butter/whatever on it, take it back to your seat and eat it. What are the steps?

Esther divided the girls into groups of 4-5 and passed out post-its on which to write the steps. There was some inertia getting started ... it was late in the day and everybody was tired. (That's not unique to this exercise -- it's always a challenge to come up with something that will hold the girls' interest for the last hour. It's a long day for everyone.)

Eventually they got rolling and got into it -- I saw some very long stacks of post-its from various groups. With ten minutes left to go in the session, Esther picked two volunteers from one group: one to read the instructions, one to execute them. She pointed out places where they skipped steps -- "Hey, wait, how can she get the muffins out of the cupboard without opening the cupboard first?" After a minute or two, Esther called on a new pair from a different group to continue where the first pair had left off.

As she worked through all the groups, you could see each group becoming more cognizant of steps they had skipped, and improvising them on the spot. Despite the end-of-day crankiness, you could see they were learning from the exercise.

Lessons:

• Splitting into groups allows for more discussion among the girls, and comparing various groups' answers is fun.
• Splitting into groups takes a lot of time, and you have to monitor to make sure all the groups are actually working on the problem and not just chatting.

So which is better? The muffin exercise was definitely more time consuming than the previous "robot" exercise, due to overhead of splitting into groups and bringing up volunteers from each group. On the other hand, I could see there was benefit in having them work in small groups, and in the touch of competition in comparing their group's answers with the ones from other groups.

It was hard to compare the two exercises directly to see which one worked better, because of end-of-day crankiness. But they both worked well -- I'm going to keep using some variant of this in future workshops, ideally with loops and conditionals added. Thanks, Esther, for your expertise ... and to the students and the rest of the volunteers for making it a successful class!

Tags: education, programming, toastmasters
[ 16:34 Aug 28, 2011    More education | permalink to this entry | ]

Beginning Python: Sorting lists of objects

The Beginning Python class has pretty much died down -- although there are still a couple of interested students posting really great homework solutions, I think most people have fallen behind, and it's time to wrap up the course.

So today, I didn't post a formal lesson. But I did have something to share about how I used Python's object-oriented capabilities to solve a problem I had copying new podcast files onto my MP3 player. I used Python's built-in list sort() function, along with the easy way it lets me define operators like < and > for any object I define.

You can read all about it in my post to the Courses list describing how I sorted my list of podcast objects. Or just go straight to the final program, pods.

Tags: python, programming, education
[ 19:48 Aug 19, 2011    More education | permalink to this entry | ]

Beginning Python, Lesson 9: More extras

Lesson 9 in my online Python course is up: Lesson 9: Extras (requested topics), including string operations, web development and GUI toolkits.

The web development and GUI toolkits are topics which were requested by students, while the string ops are things that just seemed too useful not to include.

Tags: python, programming, education
[ 17:45 Aug 12, 2011    More education | permalink to this entry | ]

Beginning Python, Lesson 8: Extras

Lesson 8 in my online Python course is up: Lesson 8: Extras, including exception handling, optional arguments, and running system commands. A motley collection of fun and useful topics that didn't quite fit anywhere in the earlier formal lessons, but you'll find a lot of use for them in writing real-world Python scripts. In the homework, I have some examples of some of my scripts using these techniques; I'm sure the students will have lots of interesting problems of their own.

Tags: python, programming, education
[ 14:56 Aug 05, 2011    More education | permalink to this entry | ]

Beginning Python, Lesson 7: Object-oriented programming

Lesson 7 in my online Python course is up: Lesson 7: Object-oriented programming.

This is the last formal lesson in the Beginning Python class. But I will be posting a few more "tips and tricks" lessons, little things that didn't fit in other lessons plus suggestions for useful Python packages students may want to check out as they continue their Python hacking.

Tags: python, programming, education
[ 10:28 Jul 30, 2011    More education | permalink to this entry | ]

Beginning Python, Lesson 6: Functions and Dictionaries

Lesson 6 in my online Python course is up: Lesson 6: Functions and Dictionaries.

We're getting near the end of the course -- partly because I think students may be saturated, though I may post one more lesson. I'll post on the list and see what the students think about it.

This afternoon, though, is pretty much booked up trying to get my mother's new Nook Touch e-book reader working with Linux. Would be easy ... except that she wants to be able to check out books from her local public library, which of course uses proprietary software from Adobe and other companies to do DRM. It remains to be seen if this will be possible ... of course, I'll post the results once we know.

Tags: python, programming, education
[ 17:49 Jul 22, 2011    More education | permalink to this entry | ]

Beginning Python, Lesson 5

Lesson 5 in my online Python course is up: Infinite loops, modulo, and random numbers.

It's a motley mix of topics, mostly because I wanted to have a fun homework project that actually did something interesting. I hope everyone enjoys it!

Tags: python, programming, education
[ 16:44 Jul 15, 2011    More education | permalink to this entry | ]

Beginning Python, Lesson 4

Lesson 4 in my online Python course is up: Modules and command-line arguments.

This lesson is a little longer than previous lessons, but that's partly because of a couple of digressions at the beginning. Hope I didn't overdo it! The homework includes an optional debugging problem for folks who want to dive a little deeper into this stuff.

Tags: python, programming, education
[ 20:20 Jul 08, 2011    More education | permalink to this entry | ]

Beginning Python, Lesson 3: Strings and Lists

Lesson 3 in my online Python course is up: Fun with Strings and Lists.

There may be some backlog on the mailing list -- my first attempt to post the lesson didn't show up at all, but my second try made it. Mail seems to be flowing now, but if you try to post something and it doesn't show up, let me know or tell us on irc.linuxchix.org, so we know if there's a continuing problem that needs to be fixed, not just a one-time glitch.

Meanwhile, I'm having some trouble getting new blog entries posted. Due to some network glitches, I had to migrate shallowsky.com to a different ISP, and it turns out the PyBlosxom 1.4 I'd been using doesn't work with more recent versions of Python; but none of my PyBlosxom plug-ins work in 1.5. Aren't software upgrades a joy? So I'm getting lots of practice debugging other people's Python code trying to get the plug-ins updated, and there probably won't be many blog entries until I've figured that out.

Once that's all straightened out, I should have a cool new PyTopo feature to report on, as well as some Arduino hacks I've had on the back burner for a while.

Tags: python, programming, education
[ 11:57 Jul 03, 2011    More education | permalink to this entry | ]

Beginning Python, Lesson 2 posted

I've just posted Lesson 2 in my online Python course, covering loops, if statements, and beer! You can read it in the list archives: Lesson 2: Loops, if, and beer, or, better, subscribe to the list so you can join the discussion.

I hope everybody has fun writing loops!

Tags: python, programming, education
[ 16:10 Jun 24, 2011    More education | permalink to this entry | ]

Beginning Programming in Python course starting

I'm about to start a new LinuxChix course: Beginning Programming in Python.

It will be held on the Linuxchix Courses mailing list: to follow the course, subscribe to the list. Lessons will be posted weekly, on Fridays, with the first lesson starting tomorrow, Friday, June 17.

This is intended a short course, probably only 4-5 weeks to start with, aimed mostly at people who are new to programming. Though of course anyone is welcome, even if you've programmed before. And experienced programmers are welcome to hang out, lurk and help answer questions. I might extended the course if people are still interested and having fun.

The course is free (just subscribe to the mailing list) and open to both women and men. Standard LinuxChix rules apply: Be polite, be helpful. And do the homework. :-)

Tags: python, programming, education
[ 09:51 Jun 16, 2011    More education | permalink to this entry | ]

GIMP: Build-it

Are you a GIMP user or Summer of Code student who's been wanting to get involved, but having trouble building, or a bit intimidated by the build process?

I'll be running a session on IRC to help anyone build GIMP on Linux, as part of the OpenHatch "Build it" project.

The session will take place on #gimp on irc.gimp.org (also known as GimpNet), on Fri, Apr 15, 0300 UTC -- that's Thursday night in the Americas. To convert to your time zone, run this command on your local machine:

$ date -d 'Fri Apr 15 03:00 UTC'
Thu Apr 14 20:00:00 PDT 2011

Or try this link: world time server.

This is a time that's usually fairly quiet on #gimp -- European users don't fret, since it's pretty easy to get help there during more Europe-friendly time zones. I'll hang around for at least two hours; that should be plenty of time to build GIMP and all its prerequisites.

For folks new to IRC, note that irc.gimp.org is its own server -- this is not the #gimp channel on Freenode. You can learn more about IRC on the LinuxChix IRC for Beginners page, or, if you have trouble getting an IRC client configured, try this link for mibbit web chat.

Note: The #gimp IRC channel was recently under attack by trolls, and it's possible that it may not be usable at the time of the session. In that case, I will update this blog page with the name of an alternate channel to use, and any other necessarily details.

Preparation

If you want to get your system set up ahead of time, I've put the instructions needed to build on Ubuntu Lucid and other older Linux distros here: Gimp Building Tips (for Linux). I might be able to offer a little help with building on Macs, but no guarantees.

Mac and Windows users, or people running a very old Linux distro (more than a year old) might want to consider an alternate approach: install Virtualbox or VMware and install Ubuntu "Natty Narwhal" (currently still in beta) in a virtual machine.

Of course, this isn't the only time you can get help with building GIMP. There are folks around on #gimp most of the time who are happy to help with problems. But if you've been meaning to get started and want a good excuse, or you've been holding off on asking for help ... come hang out with us and try it!

Tags: gimp, programming, education
[ 12:50 Apr 13, 2011    More gimp | permalink to this entry | ]

They're teaching you wrong

Overheard at a restaurant tonight:

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?

Tags: math, education
[ 19:13 Mar 23, 2010    More education | permalink to this entry | ]

Friendlier error messages for shell newbies

Helping people get started with Linux shells, I've noticed they tend to make two common mistakes vastly more than any others:

1. Typing a file path without a slash, like etc/fstab
2. typing just a filename, without a command in front of it

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.

Tags: linux, shell, help, education, programming
[ 15:07 Nov 08, 2009    More linux | permalink to this entry | ]

On Teaching Programming (GetSET 2009)

I survived another GetSET Javascript-in-a-day workshop for GetSET 2009.

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:

• Open the GetSET folder on your desktop
• Find the file named whatever.html
• Right-click on it, find Open With, and choose Wordpad
• Now find the window where you were just looking at the GetSET files (because everything on Windows tends to open with huge windows, it's now covered by Wordpad)
• Drag whatever.html into Firefox

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.

Tags: education, programming
[ 20:12 Aug 07, 2009    More education | permalink to this entry | ]

College Pays

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.

Tags: humor, education
[ 16:47 Aug 22, 2008    More humor | permalink to this entry | ]

GetSET: Teaching Javascript to high school girls

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
[ 12:54 Aug 09, 2008    More education | permalink to this entry | ]

GIMP for middle school kids

I've been helping out with an extracurricular GIMP class that a local Linux and free software advocate, Christian Einfeldt, has organized at a middle school in San Francisco.

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.

Tags: gimp, education, user interface
[ 23:44 Apr 12, 2008    More gimp | permalink to this entry | ]

Flash Cards in Python

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
[ 12:45 Oct 22, 2007    More education | permalink to this entry | ]

Danica McKellar, TWIS, and Why Not to be Dumb

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
[ 22:16 Oct 15, 2007    More education | permalink to this entry | ]

Astronomy for Middle School Girls

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
[ 18:48 Nov 03, 2005    More education | permalink to this entry | ]

Back in College

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
[ 22:29 Feb 10, 2005    More education | permalink to this entry | ]

No Child Left Behind

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
[ 19:10 Jan 10, 2005    More education | permalink to this entry | ]

Get SET '04, and thoughts on teaching beginning programming

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
[ 13:40 Aug 14, 2004    More education | permalink to this entry | ]