ISO-8859-1 to UTF-8 file conversion...

In an effort to get all the educational materials ready for the classes in El Salvador, I've found myself battling on two fronts today with character encoding not working. Fortunately, both problems turned out to be easy to solve, and both turned out to be the result of having ISO-8859-1 when what I wanted was UTF-8.

The first one was that the Spanish translation of materials generated by sphinx did not render properly on the Open Book Project site, even though the exact same materials rendered fine when I viewed them on another website.

I filed an ibiblio trouble ticket, and within an hour Donald Sizemore fixed the problem:

ibiblio's DefaultCharset is still iso-8859-1 - we tried to change it to UTF-8 during our last major upgrade, but it broke too much of our older content.

I've changed the DefaultCharset setting for openbookproject.net to UTF-8 and the page looks good to me. Check behind me? You may have to hold down Control- or Shift- and click Refresh in your browser to pick up the changes.

Cómo Pensar como un Informático now renders characters just fine on the OBP site.

A bit later in the day I began working on helping Gregorio Inda with his translation of the GASP Python Course. When running sphinx-build on the launchpad checkout of his latest work, there were over 150 warnings from one file, one for each accented charater and inverted question mark in the file.

I couldn't figure out what was going on, since sheet 1 looked the same as sheet 2 to me and didn't report any errors. A colleague suggested comparing the two files using the unix file command, and sure enough that revealed the problem:

$ file *
1-intro.rst: UTF-8 Unicode Java program text
2-tablas.rst: ISO-8859 Java program text

ISO-8859 is haunting me today! Fortunately, this web page told me what I needed to do to fix the problem:

$ iconv --from-code=ISO-8859-1 --to-code=UTF-8 2-tablas.rst > temp && mv temp 2-tablas.rst

Problem solved.

Where do all the geek girls go?

Teaching Summer enrichment classes at ACC for the past two weeks and 3 days has already been a fascinating experience. It's been years since I taught Summer classes, but what I discovered the last time I did it still holds: students volunteering to spend some of their Summer learning tend to be more highly motivated and skilled then their average counterparts in similar classes during the regular school year (duh!).

I am teaching "Creative Computer Exploration with Scratch" to 4th, 5th, and 6th graders from 8 am to 12 noon, and "Games Programming with Python and GASP" to 7th, 8th, and 9th graders from 12:30 to 4:30 pm. Each session runs two weeks, and there are two sessions during July, so we just completed our 3rd day of the second session.

I'm sure I'll be reflecting on my experiences with these classes for some time to come, particularly as they relate to the creation within Arlington Public Schools (APS) of a computer programming pathway -- a sequence of educational experiences for APS students beginning in elementary school and ending in programming careers in Industry. One of the reasons I'm so happy to be teaching these classes is that it gives me an opportunity to impact the early stages of the pathway, which until now I have not been able to touch.

What I want to focus on here, however, is one question, simple to state but elusive to answer: Where do all the geek girls go?

I've been a CS teacher for 13 years now, and I'm acutely aware of the assumption permeating my field that computer programming is a "boy thing". My typical class of 25 students over the years has had at most 2 or 3 girls in it. That has never varied from year to year, and I've seen no recent trend suggesting that it is changing. The attendees at the annual Python conference have a similar gender imbalance among participants, but there I have noticed concrete signs of improvement over the last few years, with more (albiet still very few) women programmers showing up each year.

Despite a keen interest in understanding the causes of this gender inequity and a strong desire to do whatever I can to address it, I have yet to figure out an effective approach. Teaching the Summer enrichment courses has given me new insights into the issue. Here is what I've observed:

• The number of "geek girls" in the Scratch class (11 of 30) is much higher than in the Python class (4 of 30), suggesting that the geek girls drop out somewhere between 5th grade and 7th grade.
• The girls in the Scratch class are true geeks in every sense of the word (and in case you haven't figure it out by now, I mean that as the utmost compliment): they have the same interest in problem solving and desire to make a computer do their bidding as their boy counterparts. They also have many of the same geek quirkinesses I've come to expect from the students with whom I work.
• The girls are awesome programmers. Here is a program that 4th grader Rachel made after three days of using Scratch. I would say the girls have been better programmers on average than the boys, in part because they seem more mature and have longer attention spans.
• I have noticed differences in the kinds of things the girls and boys want to work on, with boys more interested in games (with lots of bombs and blood and stuff), and the girls more interested in telling stories. No hard and fast rules here. Some of the girls made games with plenty of gore, and some of the boys made stories, but there were clear and noticible differences on average between what the boys and girls chose to do.
• The girls in the Scratch class seem to be having lots of fun. Several of them spent hours at home working on their projects and learning to use the XO computers we gave them to use during the class. While I didn't do a survey, the evidence that the girls found their work with Scratch and Sugar to be enjoyable and engaging was unmistakable.

So..., where do all the geek girls go? Why don't they continue building on their enjoyment with Scratch to go on to higher levels of computer programming? I don't have any answers, but I do have a few ideas:

• We haven't been doing Scratch for very long, so we may help open up new opportunities for geek girls by offering this early programming experience.
• Scratch lends itself to the kinds of projects the girls seemed to find interesting. It permitted them to use their programming logic to become story tellers. The Python class does not support this kind of problem solving very well at all, particularly the way I am presently teaching it, where the focus is on programming games. The Sugar project, which is developing Activities in Python for story telling, may provide help in this regard.
• We may have particular cultural expectations to overcome, which tell girls, even geek girls, that it is not cool to be involved in computer programming once they reach the middle school years. I've noticed that this cultural expectation does not seem nearly so pronounced in the immigrant and African American student populations with which I've worked, so it may just be historical baggage we have to overcome.
• A large part of the historical baggage keeping geek girls from pursuing their interests may just be a matter of unlocking the clubhouse door. I've seen instances of boys actively attempting to exclude girls and make them feel unwelcome throughout my years of teaching computer programming. It is certainly the case that part of the effort to include more girls in computer programming classes involves a good old fashioned battle against sexism.

I've got a lot to think about from my Summer experiences teaching Scratch and Python. I am eager to see what I learn teaching the same topics in rural El Salvador this August.

Stay tuned...

XS Progress

The most exciting new from yesterday is the work Josh did on the XS server. Since he posted about it on his own blog, it will suffice for me just to link to that here.

When he showed me how we can use Pigeon to view connections to our jabber server, I was thrilled! I've given Josh the task of becoming one of the world's foremost experts on the XS. Since there are only a handful of people who have ever set one up before, that lofty goal may be within his reach ;-)

GASP Python Course

This first two week session of our Summer enrichment program has provided a great opportunity to use the GASP Python Course with real students. Sheet 5 needed major surgery to be usable, which I completed last night just before midnight. On the last day of the class, we will take a stab at working through sheet 6, which develops a version of a Pac-man like game called chomp.

This weekend I'll be contacting Gregorio Inda, who has kindly offered to help translate these materials into Spanish. I hope to have some of them ready in time to use in El Salvador.

Exploration continues...

Most students continued exploring Sugar Activities yesterday, while a few others expressed a desire to return to Scratch. Here is what 11 year old Satya had to say:

One of my favorite programs on Sugar is the Scratch program. On Scratch, you can create short videos and share them with other people and vise versa. You can also animate stories or make cartoons. Even though Scratch is great, there is one thing I would do to make it better. I would have created Scratch so that you can type your own short commands, have the computer recognize them, and follow that - versus you having limited choices on the moves you can make. This Summer, I became interested in Scratch after exploring a XO I got for Christmas last year. Thinking the computer was slow and boring (seeing it had no computer games) it was cast aside and not used. but classes at the Career Center showed me what Scratch is about and how fun it can be. It has inspired me to want to grow up and become a cartoonist. To simplify it: Scratch is Magic.

The problem is that to use Scratch effectively, you need to be able to download other people's Scratch programs from the http://scratch.mit.edu website and take them apart, modify them, and remix them. Despite days of trying, we have not been able to find a way to download a file from Sugar's Browse Activity to a place where Scratch can find and open it.

With that in mind, I'm moving the students interested in Scratch off the XOs and onto a regular Ubuntu 9.04 desktop. I thought about just focusing more on Turtle Art and Physics 2, but since Sugar lacks the very powerful ability for learners to easily share their creations through the web, it made more sense to return to Scratch.

What Sugar Should Learn from Scratch

It seems to me that there are two very powerful, but at the same time different kinds of sharing that make discovery learning work:

1. Direct, immediate, peer-to-peer collaboration: Sugar is quickly becoming the best learning environment anywhere to support this kind of sharing. It is what Sugar was designed to do, and it does it very well.
2. Learning by investigating previous practice: Scratch does this better than any learning environment I have ever seen. Anyone interested in what Scratch can do can simply visit the Scratch website and see thousands of programs written by others. Find one that you like, and you can down load it, look at how it was written, change and remix it to suit your needs (and then upload your changes so others can see them too). Other users can post comments about what you've shared -- what they like and didn't like, other things to try, etc. It also permits a one to many sharing in a classroom environment where each learner can take the floor and show what they have done to the rest of the class. Anyone in the class can easily grab what they see and explore it themselves.
   

Sugar does not yet support this kind of learning well. If it did, I think Sugar would become the most compelling learning platform in existence. With that in mind, I suggested on the #sugar irc channel that Sugar Labs, DC might be able to make that challenge its main focus. Here is the conversation that followed.

The Experts Weigh-In

We started the day yesterday by showing everyone in the Scratch (now really more Sugar) class how to install new Activities from the website. Everyone then had the session to explore the available activities. Here is a list of Activities that were tried and rated by our crack team of experts (since no one is better able to evaluate how much fun a learning Activity is than the learners themselves):

• Tux Paint +
• Physics 2 ++
• Breakout +
• Colors +
• Bounce +
  
• Micropolis -
• Horse Game -
  

Yet to be rated Activities include:

• XoIRC
• Cartoon Builder
• Joke Builder
• Food Force 2
• Pac man
• Bridge
  

I also had the time to finish Sheet 5: The Robots are Coming from the GASP Python Course. Today in the Python class we will finish that sheet, and move on to Chomp for the rest of the week.

I can't describe what a thrill it is to be laying the tracks just before the train arrives! ;-)

Sugar Labs DC Producing Results

Our evening activities with Sugar Labs DC are producing results:

• Josh Eddy has our XS (School Server) up and running and is studying all he can about the jabber protocol so he can better understand how it works.
• Jamie Boisture is improving GASP each day is response to user feedback from our afternoon Python class.
• David Morris installed GASP on Patricia Paul's XO, and then installed Sugar inside virtualbox on my laptop.
• The kids in the morning Scratch (now more Sugar, really) class are providing us with a wealth of experience using Sugar with kids (I'm afraid they all have sweet teeth by now ;-)

Douglas Cerna wrote us to let us know the XOs are finally out of customs in El Salvador, and they were picked up yesterday by folks from the Buena Vista community, so we are moving forward on that front as well.

Developing a Sweet Tooth

After a week of working with Sugar with 13 young learners in our Scratch programming class, I'm beginning to develop a sweet tooth. I'm well aware that I should have done this much earlier, but is hard for me to focus on things that are not immediately relevant to the rest of what is going on in my life, and Sugar would have been just a curiosity until now.

The first week of the two week class went very well, dispite (or perhaps because of) our need to react each day to what happened and figure out from there what to do the next day. Here is some of what we learned / accomplished last week:

• The kids love to share Activities and seem to be very happy whenever they are let loose to share freely with the other kids in the class.
• Within a few days of meeting each other for the 1st time, our baker's dozen young folks have begun to develop a feeling of community in the classroom. Both my colleague, Dr. Ann Kennedy, and I strongly suspect that the peer to peer collaboration among the students made possible by Sugar is largely responsible for this.
• The mouse pads on our XOs are flaky, and having a mouse pad that didn't work was a show stopper. The level of frustration built quickly to the point where the kids started saying they didn't want to use the XOs.
• Once the UI works, they loved using their XOs. We attached USB mice, which solved the touchpad problem. There was an immediate and dramatic change in attitude of the users toward their learning devices.
• The favorite activity so far is Chat, which students get on whenever they can. We have built plenty of free exploration time into the class, so we can see what they do when left to their own devices. I am curious to see whether the enthusiasm for Chat wanes next week as the novelty wears off.
• Our own School Server (XS) made collaborating work smoothly. Network connection issues seem to have diminished precipitously once we had the XS on our local network.

I'll try to get back to blogging on a more regular basis. There has been so much going on that I haven't had the time to write about it, though I realize that is an important part of the process.