Women in CS a Big Success!

Although it's been a couple of weeks since the event was held, I wanted to update you all on how successful the women's evening I organized ended up being! If you happen to be a female in a computer program at your school, you might be able to get funding from your department to hold a similar event. Trust me, when the girls stay until 8pm on a Friday evening and are excited for the next meet up, it's worth the effort!

Our get together featured a Carleton computer science alumnus named Melissa. She graciously agreed to spend her Friday evening telling the current collection of female students about her experiences both at Carleton and at her new job as a software team lead. The audience was relieved to hear that being one of the few women in the field was not really so bad. In fact, other than the occasional effort on the part of the males to speak a bit less brusque around her, she found it to be perfectly ok to be different!

One really good piece of advice from Melissa was about finding some time to be girly. You won't necessarily have much opportunity to do that nine to five, so trying out some other activities where you either simply get to interact with other women or actually do girly things is important. For example, Melissa sells Mary Kay products because of the meetings with other women who do the same. You might enjoy book clubs, photography groups, and so on.

Of course, this event was made possible thanks to the Google Ambassador Program! Google supplied the pizza and, as an added bonus for this specific event, some neat giveaway swag as well!

Each participant received a Google umbrella and sticky notes with the Google Women logo. In addition, a few lucky winners were drawn for a really nice mug!



A huge thanks to Carleton's School of Computer Science, Google, Melissa, and everyone who attended this event, and hope to see you next time!

Why I Like Grad School

As I sit here in a momentary pause between one major end-of-semester project and another, at my dining room table because my office desk has become so piled up with 'to-do' stuff that I can't even use it until after the holiday clean-up, I can't help but reflect on my first semester of grad school.

Sure, the work can accumulate pretty quickly and unexpectedly at the end of the term, but here's the good part: this is the work that you pick out for yourself! Term projects, while they obviously have to fall into the realm of the courses they are assigned in, can be also related to anything you want.

Take my GIS class as an example. I could have chosen a project that would help me remember some of the material I learned in the computational geometry grad class I took in the last year of my undergrad. Or perhaps I could explore some interesting user interface programming and design. Or maybe learn a whole new data structure for storing massive amounts of spatial data. Instead, I decided to do a project that uses artificial intelligence techniques. It's an area that I've been somewhat intrigued by but know little about. I'll get into more details some other day, but the teaser is that I will be using Self-Organizing Maps to select relevant roads from a road network.

The other nice bonus about these projects is that you usually only have to choose a journal or conference paper and implement something described therein. In certain cases, this is a godsend, as it is slightly less dangerous (and hopefully less work) than researching something completely new. This is the route I took for the GIS class. On the other hand, you usually can go the research route and try something new. I did this for my other class on Entertainment Technologies, but I don't want to give any details yet on the off chance that I can actually go somewhere with that research.

All in all, it's not so bad being busy working on something you're interested in. Stressful, yes, but also kind of fun. Remember that when selecting a topic for your next school project.

Career Day

A local high school is hosting a career day tomorrow, and I am going to be presenting with my supervisor here at Carleton's School of Computer Science. I am hoping that this opportunity to talk about what computer science is all about in front of two different groups of high school students will help me determine which topics they are interested in and use that information when preparing for the mini-course I'm giving this spring.

The presentation as it already exists is pretty good. The main idea is to show the students various aspects of computer science -- from graphics and geometry to computational biology to networking and security (and a few in between) -- using some fun examples the students can relate to.

I added a few fun slides in hopes that we might be able to keep their attention for the whole 40 minutes we have to talk. For example, after mentioning games and graphics, I stuck in a video trailer for Grand Turismo HD, which showcases the best graphics I've ever seen for a video game. To tie together the slides on networking and security, I added a snapshot of Facebook. I'm hoping to add just a little bit about audio because not many people realize how well computer science and music can tie together.

Here's hoping that we can convince a few young adults to consider pursuing a career in computer science, particularly here at Carleton!

Geek Envy

I recently received my Google Summer of Code t-shirt in the mail. Here are a couple of photos showing its awesomeness:



In related news from the Why Google Is So Well Loved department, I also received some swag for my Women in CS event coming up in December. I got enough umbrellas and sticky notepads for everyone who signed up (and for my guest speaker), and a few really nice mugs that I will probably draw names for. All of this has the Google women's logo, which I have never personally even seen before, making it rare in my eyes, and all the more special. I am certain that everyone who attends our event in a couple of weeks is going to love this stuff!

Anita Borg Scholarship

I plan to apply to this scholarship from Google, and if you are a Canadian computer science student, you should too!

Google Expands Anita Borg Memorial Scholarship to Canada!

http://www.google.ca/anitaborg/


Dr. Anita Borg (1949 - 2003) devoted her adult life to revolutionizing the way we think about technology and dismantling barriers that keep women and minorities from entering computing and technology fields. Her combination of technical expertise and fearless vision continues to inspire and motivate countless women to become active participants and leaders in creating technology. In honor of Dr. Borg's passion, for the past four years, we have sponsored a scholarship with the Anita Borg Institute for Women and Technology in the U.S., and more recently, Europe and Australia.

This year, we're excited to announce the expansion of the program to include Canada, where we're very pleased to offer an opportunity to both undergraduate students and postgraduates. Scholarships will be awarded based on the strength of candidates' academic background and demonstrated leadership. A group of female undergraduate and graduate student finalists will be chosen from the applicant pool. The scholarship recipients will each receive a $5,000 CAD scholarship for the 2008-2009 academic year. The remaining finalists will receive $1000 CAD each.

All scholarship recipients and finalists will be invited to visit the Google engineering office in New York, on May 1-3, 2008 for a networking retreat which will include workshops with a series of speakers, panelists, breakout sessions and social activities.

We are looking for women who will carry on the legacy of Dr. Borg, with strong academic backgrounds and demonstrated leadership qualities.

Tell your friends, or apply yourself, at http://www.google.ca/anitaborg/

From the Google blog: http://googleblog.blogspot.com/2007/10/anita-borg-scholarships-expand-to.html

Mini-Course Accepted!

I just got the good news about my proposed mini-course "Computer Science and Games: Not Just For Boys!" -- it was accepted! I was a little bit worried that it might not make it because there were apparently many more applications than needed courses, and some colleagues proposed a course on game design at the same time. I'm really excited to start hashing out the details of my many ideas for this course. Will keep you all updated!

More Tangible User Interfaces

Thanks to the wonders of Reddit (a link submission and ranking site), I found an article from Smashing Magazine that outlines what they consider to be the user interfaces of the future. I find it interesting that almost all of them are very clearly what I would call tangible user interfaces, which I wrote about earlier this month.

First up is the Cheoptics360 XL 3D video screen. Though it's difficult to tell exactly what's happening in the press video as opposed to seeing it in person, it looks like this setup will essentially present a video that can be viewed from any angle as you walk around the structure. It's not clear whether the video will look 3D to the viewer. The creators of this technology seem to tout it as a good way to get product information out there, and Smashing Magazine thinks it is the future of gaming. I'd like to add a third possibility: education. Can you imagine how great it would be for a museum to present video of an artifact in life size rather than having to physically display it? This is especially true for those things that can't be brought indoors, or that don't exist anymore; for example, you could present the streets of Germany after the WWII bombing in a war museum, or have an interactive view of dinosaurs in a natural history museum.

I believe this next example has been around for some time now, but it still impresses me. The Reactable "is a collaborative electronic music instrument with a tabletop tangible multi-touch interface." What an amazing idea for a totally new kind of music making device! It appears that even Icelandic singer Björk is on board with this one, using it in her Volta tour. The fact that this system is easy to learn without any manuals or instructions makes it a perfect way to help children learn about music. After all, no parent loves the sound of their kids learning the recorder!

The example photos of the showcased research on multi-touch interfaces can really remind you of the movie Minority Report. Check out this video, presented by a company that spun off from the research linked to by Smashing Magazine, Perceptive Pixel. Now, many of the tangible user interfaces discussed today make use of the multi-touch paradigm, so this isn't necessarily all that unique; however, the video really gives you a good feel for what multi-touch is all about. Notice the many different ways the hands are used to interact with the data presented on the screen: zooming, panning, drawing, tilting, and so on. These movements are very natural in a real-world kind of way.

Finally we have the BumpTop. This interface ditches the usual GUI desktop paradigm, which doesn't keep the connection between what documents laid out on a real desk look like and how they can be arranged on the screen. With BumpTop, you can pile your files up just like in the real world, organizing your stuff just how you want it. It is claimed that these piles and arrangements convey information about the data in themselves.

It is examples like these that continue to convince me that the future of user interfaces lies in the innovative solutions that bridge the gap between the physical and digital world. Long live tangible user interfaces!

Fun With Accelerometers

Accelerometers: Teeny little chips that can be found in more places than you probably imagined. And trying to actually write code that makes use of them? You either love 'em or you hate 'em... or maybe a bit of both.

As many of you know, the Wii remote has an accelerometer built in as one of several sensors used to enhance game play. Apple's iPhone uses an accelerometer to sense how the device is tilted; that's how it's able to change the orientation of its screen based on how you are holding it. Robots can use them to keep their balance, and Nike's shoes can count your steps with them. And that's just the beginning - there are tons of applications for this simple little device!

I recently had the 'pleasure' (if you can call it that) of working on a course assignment using a Kionix accelerometer encased in a little joystick-like cover. I'm not sure what model it was; it may have even been a demo or evaluation version our teacher was able to obtain. Anyway, this is where the love-hate thing comes in. The ideas behind what you could do with these devices are really cool, but the reality kind of hurt. It's really hard to make them work!

Our assignment had us first code up some basic calculations you can do with an accelerometer. Tilt wasn't so bad to figure out. In fact, you can determine pitch and roll, rotation around the x and y axes respectively, and tilt, the angle the z-axis makes with the vertical. What you cannot compute, however, is yaw - that's why many inertial systems also use gyroscopes.

Image from http://en.wikipedia.org/wiki/Flight_dynamics

The second set of calculations to implement used integration equations to find location based on the rate of change of velocity (i.e., acceleration). We tried out several methods of doing this: Euler, Verlet, and Beeman equations. Through an experiment of our own design (I used the known properties of free fall in what I thought was a clever way), we comparatively evaluated the accuracy of these. Incidentally, I found that the Verlet equation (the velocity version for those keeping track) performed the best of all of them.

At this point I could tell that there were going to be some real limitations when trying to use the accelerometer in any practical application. The tilt calculations actually worked fairly well when measuring the orientation of the device when it wasn't moving. The two limitations of this are not being able to figure out yaw (as mentioned), and the fact that you can't tell the different between acceleration due to gravity, which is what allows you to compute pitch and roll, and actual movement in some direction.

The former is an annoyance only in the sense that in many of the demo applications I played with, yaw was the most natural direction to move the accelerometer to accomplish what I wanted! When I wanted to move a character in a game, for example, I always tried to use the yaw rotation for left and right movement.

The second limitation of distinguishing between movement and gravity can't be that bad if all these phone companies are able to implement their screen orientations functionalities so well. Still, I imagine things gets hairier when you want to use the same accelerometer to measure actual movement in addition to tilt orientation. Again, this is probably why so many systems use gyroscopes too.

Ok, so now onto the fun stuff. The second half of the assignment involved applying these calculations in fun and useful ways (can you sense the joy?). In the first question, we were to implement a simple gesture recognition system. In the second, we would use the accelerometer in some application of our choosing (or of our own creation), and think about how this would affect the users of the application.

I can tell you right now that although position information seems the most natural choice for most applications, the calculations alone are not good enough! Besides the annoyances of inaccuracies, consider this: If I start moving my accelerometer with increasing speed, the acceleration being read is a number strictly above zero. So far so good. Now I stop moving the device. Maybe there is some deceleration for a short while, but eventually I should get a reading of zero. Fine, makes sense. Except for one thing. Because you are relying on acceleration alone, you don't get any information that would tell you your velocity is actually zero now, too. No, a zero acceleration simply means a constant velocity, so unless your reading came at exactly that point in time that your velocity was also being calculated as zero (which is unlikely as it turns out), your velocity will keep on pumping out changes in position. Sigh.

So tilt orientation it is.

For the gesture recognition, I took inspiration from these mouse gestures that can be used in a web browser. My up/down movement came from changes in pitch, and the left/right from changes in roll. My very simple system just looked at the last gesture made after a predefined dead time, and tried to make some sense of it. I was able to use the system with better than 85% accuracy, and my husband was able to succeed at performing 50% of the dictated gestures (which actually isn't bad if you consider that he had only a minute of training first).

I implemented my own application for the last question rather than seek to integrate the accelerometer into something that already existed. I created a little matte chooser program because I used to work at Ross Video, and they have a matte chooser interface for their live video production switchers. I thought it would be interesting to see how the same type of interface would work when controlled with tilt instead of knobs. Basically, you get a colour wheel that you can control by tilting the accelerometer in various ways. This worked reasonably, but I think it could be a lot better with some more fine tuning.

Looking back, the assignment was kind of fun, despite the numerous problems I ran into (not all mentioned here). I don't know how well I did yet because I only just handed in the completed assignment.

There are many potential uses for the accelerometer even in just the software I use and write. But to be honest, I think I'll probably avoid the frustration in the future and just stick with my usual mouse or game pad, and wait for the industry to iron out the bugs for me!

Tangible User Interfaces

I've stumbled upon a whole new realm of possibilities for an exciting research area: tangible user interfaces!

A tangible user interface is, according to our friends at Wikipedia, nothing more than "a user interface in which a person interacts with digital information through the physical environment." Such a simple little concept at first glance, but one that I think will eventually become a standard paradigm for human-computer interactions. There are so many applications that simply make more sense when a user interacts with something real, something they understand without a second thought.

For example, many of us have heard of Microsoft Surface by now (if not, check out this video for a really good overview of what it can do). The fact that it can be controlled with such tangible mediums as your own bare hands, everyday store bought items, and other custom tagged objects really opens a whole new world of possibility for interactivity. It's a shame that in the foreseeable future systems like this are likely to remain accessible only in commercial settings (using the cost of $15k as a good starting reason). Even when they are available to home users, a lot of reworking of the software we all know and love to fit this paradigm would be necessary. But the eventual ease of use should be worth it!

Now here's another cool example of a tangible user interface that you probably haven't heard of: Illuminating Clay. The creators of this system wanted to figure out a way to bridge the physical-digital divide that landscape architects face when they model with real clay but compute information about their models on a computer. Their solution? Let the architects continue to use clay, but have the changes made in the physical world be digitized in real time, with the results of various computations projected back onto the clay. This image from the Illuminating Clay website gives you the idea of how this looks:


This is probably the most novel user interface design solution I have ever seen. It should really help demonstrate why I am so excited about the future of tangible user interfaces! Imagine how many applications there must be for this paradigm. (Post some comments with your ideas!)

Now, some of you may be wondering why I would be so interested in user interfaces when my profile claims that I care about computer vision and geometry and such. The truth is that I have had a pretty keen interest in the effective design of user interfaces, but little time to study it further. Pair this interest with the fact that both the examples above, and many others beyond it, require extensive computer vision and geometric computation techniques to bridge that gap between the real world and the computer, and you've got a pretty attractive research area for a girl like me!

Women in Computer Science (Event)

The second initiative to encourage women in computer science that I mentioned back in October is taking shape now. (Recall in my last post that I submitted a course proposal for the enrichment mini-course program.) I have my room reserved, my guest speaker booked, and Google swag ready to go whenever the number of RSVP's comes in. Check out my poster that I'm using to advertise the event, and if you happen to be a female computer science student at Carleton or elsewhere nearby, feel free to join us!

Computer Science and Games: Not Just for Boys!

I mentioned previously that I was planning to submit a proposal for an all-girls course about computer science and games for the Mini-Course Enrichment Program. The theory is that perhaps girls will feel more comfortable signing up for a course on technology if they knew there wouldn't be any boys (particularly the stereotypical nerdy gamer type). We may soon see, but first the course needs to be approved.

Here is the description:

Computer Science and Games: Not Just for Boys!

Are you a girl who's ever wondered what computer science was all about, but was too afraid to ask? Whether you are geeky or the opposite, this is your chance to find out! To learn about computer science, we're going to see how it is involved in the design and development of video games. After taking a quick look at the state of the industry and how women are involved, we will cover such topics as usability and design, graphics, audio, and artificial intelligence. Best of all, you will get to work on making your own game to take home at the end of the week! And don't worry, you won't need to do any programming all week.

As Usual, We Need More Women in Computer Science

I see headlines for articles about how computer science needs more women so often that the notion has become clichéd to me. But the cold, hard truth recently made the problem seem so much more real, and got me thinking about some potential solutions.

According to an article written at the end of December 2005, the highest number of female computer science graduates was 37 percent (this occurred in 1985). During a few of years leading up to the article, this number was around 27 percent. These statistics are confirmed by the graph at the end of this article written in 2006.

It turns out that our undergraduate program has only about a 10% female population (based on observations). The story can't be much different from other universities. Kind of a big drop, isn't it?

Why? How can we stop it??

Time and time again people try to come up with the answers. I've even tried to do the same, albeit for open source rather than education. So why do the numbers seem to only go down, if anything?

I really don't have any more answers than the countless others who have written on the topic. All I can do is attempt to improve the outlook that young females have toward computer science, and try to improve the atmosphere for those already here.

To accomplish the latter, I have used my contact for the Google Ambassador Program to secure some sweet Google swag for an all-women's social gathering. From the same program I also have some money left to provide free food. The idea is to provide a informal, fun forum for girls in the School of Computer Science to get together and do whatever happens to work - gripe about things we don't like about being female in computer science, discuss ideas for finding work or going to grad school after convocation, and so on. Kind of a solidarity thing, I suppose. I've even invited a successful alumni of our program to talk about her experiences with life after Carleton.

There are many programs in our area I have recently discovered that help encourage young women to consider science and technology in their career options. As just one example, Pathmakers has post-secondary female student volunteers make presentations to elementary and high school students to help them explore these opportunities. Our undergraduate advisor is already looking into participating in one of their bigger upcoming events in December.

In addition to what's already out there, I was recently inspired to submit a proposal to create and teach a mini-course that our local universities offer to grade eight and high school students. I have actually taken some of these courses when I was in high school, but didn't realize I could teach one as a grad student. I wanted to provide a course just for girls so they wouldn't be intimidated by the probability of being in a class with all (potentially geeky) boys. The course would somehow give a flavour of some of the main topics in computer science, showing the girls that the area can be interesting and fun. I decided that computer games is a perfect medium for doing this, and plan to submit my proposal next week. I will post the course description here once I'm done.

Whether these programs and ideas will make much difference in the numbers of incoming female computer science students one day, I cannot say. Perhaps I will never know. But given the dismal percentages we face today, I will feel better knowing that I have tried.

Watching Sports Your Way

One option for my Masters thesis is to explore the use of computer vision in a real industrial production system. Thinking in terms of sportscasts, on the simplest end, one could automatically track players and objects (remember that annoying -- and short lived -- blue highlighted hockey puck?). On the more ambitious end, broadcasters might be able to give viewers novel and exciting viewpoints, such as a particular play from a particular player's perspective.

Imagine my disappointment in seeing that the latter had seemingly been solved already (assuming the former is relatively simple in comparison). I was recently directed to a copy of a paper called Virtual Viewpoint Replay for a Soccer Match by View Interpolation From Multiple Cameras by Naho Inamoto and Hideo Saito, where I found not only Inamoto and Saito's work on the topic, but of course, many references to related research, as well.

Ok, so maybe it's not really such a surprise that work on this area has been done in the past -- it would be naive to think otherwise [:)]. But at first glance, this paper seems to cover a method that might be well suited to the broadcast industry, thereby coming much closer to the realm of my possible thesis topic. But as we will see, there is still much room for improvement, and therefore still work available if I do end up taking this direction.

What It's All About

The basic premise of this research is to be able to watch a sports game (soccer in the case of this particular paper) from angles that weren't explicitly captured on camera. Computer vision techniques would be employed to determine what an intermediate camera between two real ones would be seeing. A user of an on-demand video system could potentially guide his own camera and see the entire game from that viewpoint, or a broadcaster could simply present a new and interesting shot of a particular play for the audience.

In the past, the methods used to synthesize these new shots fit into three categories (according to Inamoto and Saito):

1. Model Based Approach. Using the geometry of the scene, a 3-D reconstruction with a synthesized texture could be created and then reprojected into the desired novel view. The accuracy of the results depends on how well the model can be constructed, which in turn depends on having many calibrated cameras. This method is not well suited to large areas like a soccer stadium.
   
   
2. Transfer Based Approach. Instead of a 3-D model, morphing techniques can be employed to obtain the new viewpoint between two images, or a trifocal tensor can be used for image transfer. Either of these require dense correspondences between the known views, hence the two known images must be static or only slightly varying.
   
   
3. Approach Using the Plenoptic Function. The plenoptic function "describes all the radiant energy that is perceived by an observer at any point in space and time." With this function, it is possible to allow users to arbitrarily pan and tilt a virtual camera, and the resulting shots will be based on a collection of sample images. Since the plenoptic function is seven dimensions, though, it requires data reduction or compression in practical use. This makes it less suitable for the soccer example because it would be impossible to describe all the radiant energy in the stadium scene.

The New Research

Inamoto and Saito's proposed method generates images of arbitrary viewpoints "by view interpolation among real camera images." Multiple cameras will be capturing a soccer match, and when a user chooses a new virtual viewpoint, the two or three cameras closest to it are used to find correspondences and perform view interpolation. Because the field and the soccer stadium itself are fixed, they can be considered static, and processed separately from the dynamic objects (players, the ball, etc). Furthermore, much of the processing time can be done ahead of time, including the determination of the camera geometry.

Several videos that show the results of this method can be found on this research web page. In addition to simply creating new viewpoints for the user, the videos demonstrate that the method allows for effects like that seen in The Matrix, where the camera spins around stationary players.

The performance of a developed system using this method was tested on a Pentium 4 3.2 GHz desktop with 2 GB of memory and an ATI Radeon 9800 graphics card. On average, the system could process 3.7 frames every second. The processing time is linear in the number of dynamic objects contained in a scene at a given time.

What It Means For Me

Here I'd like to discuss some aspects of the reported research that I'm not sure would be entirely suitable for the production industry, and could thus be interesting areas for me the explore for my thesis. Some of these I have not mentioned above, but are still part of the discussed research, and more information can be found in the associated paper.

It's worth noting that, being Canadian, we wanted to explore the application of virtual viewpoints in the context of hockey games rather than soccer. How cool would it be to put yourself in Daniel Alfredsson's skates as he flies to the net and puts a puck in top shelf?! Keep this context in mind as you read the issues I raise below.

First, the proposed method requires that several cameras are fixed and calibrated ahead of time. The first problem with this is not too serious: there is a requirement for the stadium or arena to invest in more cameras. This is due to the fact that almost all cameras at a sports event are constantly moving to follow the action or to switch its focus to another point of interest. It is possible that this is a reasonable investment, provided that the results are worth the extra money. As will be discussed in a moment, this certainly isn't the case at this stage.

The second issue with fixed cameras could, in my opinion, be slightly more problematic. The manual work required to calibrate these cameras requires broadcasting technicians to spend time identifying corresponding points between the cameras, and identifying the static regions (such as the field or stadium in the case of soccer) in the image captured by every camera. This work takes an hour for just four cameras, and you may need more cameras than that to get a high quality result. Now, this extra work may not be relevant after all if you consider that once the cameras are calibrated, they don't need to be calibrated again because they are fixed. I'm just wondering whether there is the possibility of these cameras being taken away at the end of each game, thus forcing this task to be redone before the next game when the cameras are replaced. The possibility of human error each time could seriously affect the results for that game; for example, being slightly off on the point correspondences throws off the whole geometry of the cameras!

Next, consider a requirement that allows soccer players to be identified on the field. It is essential that the color of the ball and the players (including the uniform) be different from the field. It would seem that most soccer teams have jerseys that avoid this problem, but this is certainly not the case in hockey. Even my favorite hockey team wears white on away games, so it would be difficult to distinguish between the jersey and the white ice surface. I also believe there could be new issues when using this method for hockey related to the reflectivity of the ice. Surely the light absorbing properties of ice and turf are different, so shadows might need to be handled differently, and reflections might get in the way.

Finally, the critical issues outlined in the paper must be addressed before such a system could be used for real broadcasting. For example, players can occasionally disappear from the scene when they have not been filmed in at least two of the cameras. Problems also occur when four or five players overlap. While this may not happen quite as often on a wide open soccer field, the smaller hockey rink would have this happen all the time!

Conclusion

It's pretty clear that the issues outlined here, as well as generally improving the speed and quality of the resulting virtual video, provide a lot of potential research for an enthusiastic Masters student such as myself. I'll let you all know what I end up doing for my thesis as soon as I know!

Read the question

I recently finished grading my very first batch of assignments as a teaching assistant. Previously I had worked as a special kind of "general help" teaching assistant that wasn't assigned to any particular course, so I didn't needed to mark anything before this semester.

Most students fared rather well on their first attempt at understanding functional programming using Scheme. In fact, I only gave one failure, though it was clear this person either forgot to do the assignment until 30 seconds before it was due, or simply planned to drop the course soon anyway. A grand 1% is what they earned. By and large, the class did a good job.

But they could have done better if only they had read the questions more carefully!

Everybody forget something. Maybe it was the substitution model they were supposed to show for their multiply procedure. Or maybe they missed the fact that they were supposed to program in an iterative style. Perhaps they ignored the fact that 25% of the grade was specifically allotted for testing and documentation.

This kind of thing is common, but I never realized how many students it affected until I marked all of their work.

Ah well -- my many comments will hopefully serve as a reminder to be more careful in the next few assignments, and if nothing else, I now know myself to reread my own assignments a few times more before rushing to answer!

Heap Trick

I learned a neat trick regarding heaps today. Here's how it goes:

• Take the number of nodes in the heap and write that number down in binary.
• Erase the most significant bit.
• Starting at the root, go to the left child when you see a zero, and go to the right child when you see a one.
• When you run out of binary digits, you will be at the last node.

So if you don't feel like storing a pointer to the last node in a heap, you can use this little trick instead. Try it, it works!

Blondie24: Playing at the Edge of AI

Imagine this scenario: You have recently befriended a visitor from Mars. Martians have no knowledge of human culture, let alone any experience with our board games. But somehow your new pal has heard of checkers and desperately wants to learn how to play. So much so, in fact, that you question his "friendship" as he demands success while waving around his ray gun menacingly.

An uneasy situation to be sure, but what if in addition to having to teach the visitor far from home how to play checkers from scratch, eventually making him an expert player, the only information you were allowed to tell him is where the game pieces were allowed to be on the board and how they were allowed to be moved. After a series of games, you would tell him how many games he had won, but not which games they were.

Could you do it?

David B. Fogel faced this very same challenge, albeit without the Martians and ray guns. Instead, Fogel aimed to have a computer learn the game of checkers in this very same way. We all know how dense computers are -- they certainly won't do anything other than exactly what you tell them -- so we can see that this task is still daunting nonetheless.

In Blondie24: Playing at the Edge of AI, Fogel describes how he used evolutionary computing algorithms to have a computer teach itself checkers. In the process, he manages to give a good introduction and general review of the state of artificial intelligence, to provide interesting insight into what it truly means for software to act intelligent, and to detail how he and his colleague Kumar Chellapilla managed to evolve a neural network that could play checkers competitively with the experts.

If you have studied AI at all in the past, then you probably remember spending a lot of time on subjects like decision trees, expert systems, and search tree algorithms such as A*. Indeed, topics like these seem to be at the forefront of the field, and capturing human knowledge and reusing it in an effective way constitutes, for many, the essence of artificial intelligence.

But does the use of our own knowledge really demonstrate intelligence? As Fogel points out, not really. These kinds of programs are simply acting like we do. They make no contribution to understanding what intelligence really is, nor how it develops in the first place.

Fogel offers an alternative. He believes that mimicking what nature has done so well is the key to having software learn for itself; that is, we should be focusing on evolution.

And that's exactly what Fogel uses to create a checkers program that can win against very high ranking players. He sets up a neural network with a somewhat arbitrary configuration, using the piece placement on the squares of a checkerboard as inputs. Several networks are created with random weights between neurons; this becomes the first generation in the evolutionary process.

The networks play against each other based on the most basic rules of how pieces can move from particular squares and when the game is over. They don't know when they lose or win a game; instead, they are assigned a final score for the series of games they have played. Then the half of the generation with the lowest scores is thrown out. The better half is copied and slightly randomly mutated. This new set of neural networks becomes the next generation, and the process begins again.

I'm definitely simplifying things here (for one thing, the neural networks don't play checkers, but rather evaluate a particular board configuration), but suffice it to say that these neural networks, after many generations of evolution, could actually play checkers very well. This is quite remarkable if you think about it -- just from random mutation and survival of the fittest, we start with something more or less random that knows nothing about checkers, and eventually get something that can beat some of the best. Nowhere have we instilled our own human expertise or knowledge into the program like the creators of Chinook did, or those of Deep Blue in the case of chess.

If you are the least bit curious of the details on how Fogel and Chellapilla achieved this, I highly recommend reading his book. I couldn't help myself feeling at least as enthralled with the progress of the artificial checkers player as I have with any fictional protagonist. Fogel does a wonderful job of providing the necessary background of the field, and repeats the key points just enough so the reader doesn't get lost.

More importantly, I hope you can share in the excitement surrounding the possibilities of evolutionary computing. Though it's been around for decades, I'm not sure that it's been used to anywhere near its potential. As hardware speeds up and complicated problems can be evolved more efficiently, we might find ourselves being able to create something closer and closer to true intelligence.

If you ask me, this sounds a bit less frustrating (or dangerous) than trying to do the same with our extra terrestrial companions mentioned earlier...

Creating Mazes from Images

This semester, I'm taking a systems engineering course for my Masters. It's called Entertainment Technology, and aims to cover some pretty interesting stuff, from image processing and compositing, to using accelerometers like those in the Wii remotes, to watermarking and other content protection schemes.

In a couple of weeks, we will be giving a presentation to our classmates on a technical paper of our choice. Mine will be Image-Guided Maze Construction by Jie Xu and Craig Kaplan from the University of Waterloo. Since the topic is pretty cool, I thought I'd share what it's all about!

Artists have long been creating beautifully artistic mazes. Take Christopher Berg as a modern example. He's been at it since the fifth grade, starting with countless varieties of amoebas as the basis for his mazes. Check out some of his more recent marvels, found on the Amazeing Art website:



Xu and Kaplan state early on that Berg was an inspiration for them. Unfortunately, the techniques that Berg uses to draw his mazes don't translate well to computational algorithms. The computer (with some help from the maze designer) must create lines that will artistically convey the tone, texture, and form of the original image. But in addition to this, there must be spaces between the lines that actually make the drawing a maze!

In an interactive system designed by Xu and Kaplan, a maze designer is able to identify various areas of the image they want to turn into a maze. Each of these regions can have a particular texture applied to them; that is, the maze can follow the general direction of lines in the original image, spiral in on itself, have random direction, or be completely user-defined. Once the mazes in these regions are created, they will be interconnected by breaking a hole in the "walls" between the regions. In addition, the designer can plan out a general solution path to ensure both an interesting and challenging puzzle.

To see how to construct a maze algorithmically, you can first imagine a grid laid out within the area the maze will be created (a planar subdivision). The faces of the grid (which isn't necessarily orthogonal) are called cells, where the edges between two adjacent cells are called cell walls.

Next, consider the dual of the grid, the cell graph, where each cell is represented by a vertex, and cells that share a wall are connected by an edge. Now if you want to get a maze from the grid that doesn't contain any cycles, you simply need to find a spanning tree of this dual and erase the walls between cells connected by the spanning tree in the cell graph. A random spanning tree could be generated, or certain walls could be biased such that they are more likely to be broken first.

Finally, notice that the four maze textures described above can be used to create the grid from which to generate a maze.

In the case of directional mazes, the walls of the maze should flow in a general direction that resembles what it happening in the image the maze is based on. This is done using vector fields, from which "streamlines" are placed. Then, streamlines perpendicular to these are added, thus creating a grid. The distance between the streamlines can be adjusted, helping depict the desired tone.

For regions marked to have spiral textures, the computer will create shrinking concentric rings of the boundary shape. Radial lines are added at regular intervals to complete the grid.

The random texture is created first as a square grid, and then relaxed using an algorithm created by Singh and Pederson. User defined textures obviously must be created by the maze designer.

Here are some examples of what Xu and Kaplan's system have created, taken from their maze design project page:

Summer of Code: Final Report

Today is the official end of the Google Summer of Code program. I've been both excited and nervous about the culmination of three months' worth of work on this judgment day. But no sense in worrying any longer; I will find out soon enough if I am to receive the coveted t-shirt and very useful final payment.

Here, I would like to share a summary of everything that I've done this summer for Inkscape. A written summary is made even more crucial by the nature of what I did in the second half of the program. While I laid down an important foundation for changes that can now be made much easier in the near future, there is not as much for the user to see quite yet.

Many of you already know my midterm impressions. As a quick reminder, during the first half of the summer, I implemented support for the <tref> element, as laid out in the SVG specification. This will let you use any character data from within the document in your own <text>, and as a bonus, any character markup from the original text will be ignored so you can easily add your own. You can't quite do this with <use>.

The work done in the second half is notably more complicated to explain. The end goal was initially twofold:

1. Many fonts used in professional design can not be represented within the constraints of CSS. Take a font with a Shadow variant, such as Gill Sans, as an example -- there is no way to describe Gill Sans Shadow with CSS, as you can see in the CSS2 Spec. By adding our own Inkscape-specific information, we hoped to be able to use fonts like these at least within Inkscape.
2. When it comes to listing font families and faces (aka styles) in our UI, we use Pango's answer to the question "which part of this font name is the family?" Unfortunately, this does not always lead to an ideal situation. What often happens is that several different faces that should be grouped together in the same family aren't. For example, you might see "Futura Bk BT", "Futura Hv BT", and "Futura Lt BT" listed as separate families, but would rather they were grouped together. We wanted to customize this process so we could control how families and styles were grouped together.

Ironically, neither of these two improvements is visible to the user in my latest code. It turns out that the first goal is almost certainly impossible to accomplish given the current state of Pango. The second goal is actually very much in reach, and can easily be implemented once the Summer of Code projects are complete.

What do I mean by the "current state of Pango" you ask? Well, as it turns out, the structure that is fundamental to our use of Pango, the PangoFontDescription, will only describe fonts that fit into the confines of CSS. So until the good folks at Pango decide to expand on what Pango can represent, we're stuck with what it already supports. (And yes, a little later on, I do plan on speaking with these good folks to find out why it is the way it is, and try to offer a helping hand to enhance it if that's what makes sense.)

But even if the PangoFontDescription did support what CSS can't, that doesn't really help us, right? After all, our SVG files use CSS to describe the fonts we're using anyway. That is true, and that's why I am adding a new attribute to an object's style string: -inkscape-font-specification. Here we will store a string that can fully represent a font no matter what its face is. The CSS will be updated as best it can be and used if there is no font specification available.

As for the second goal of cleaning up the family and style lists, the framework that makes this possible is in place, and only the code for converting the full font specification strings into the desired family and style for the UI needs to be set up. A fellow summer of coder has written code that may be appropriate for this, so after the deadline his code can be evaluated and re-purposed for this use. Everything should work well with only some possible minor tweaking.

So what does the user get to enjoy as a result of this work? Gone are the days of duplicate styles in the UI and styles that seem selectable but that just can't be used. Those fonts that Pango cannot handle aren't even listed, and those that just needed a little extra help now work. That means that every style listed in the Text and Styles dialog is now selectable! Hurray!

In conclusion, though it may not seem terribly exciting on the surface, this portion of my project has unlocked the door for some really great changes to be made in the very near future. Look forward to a more desirable grouping of families first, and hopefully we can get Pango to do for us what we really want next: support ALL fonts!

Looking Forward to School

The summer is flying by! What with Summer of Code and trying to plan my wedding (which is on August 24th), I haven't even had a chance to ride my motorcycle more than a few times this season let alone keep up with this blog.

Still, as the calendar flips over to August, thoughts of "back to school" start swimming in my head. Oddly enough, I always look forward to hitting the books again each September. This year is no different in that regard, but there is a new excitement in the fact that I will be returning to Carleton as a graduate student.

I've already registered for the five courses I will be taking in the first two semesters. I figured I'd share the title and description and see if you had any comments on the topics covered (love it or hate it, never heard of it, etc).

Computational Aspects of Geographic Information Systems

Computational perspective of geographic information systems (GIS). Data representations and their operations on raster and vector devices: e.g., quadtrees, grid files, digital elevation models, triangular irregular network models. Analysis and design of efficient algorithms for solving GIS problems: visibility queries, point location, facility location.

Advanced Topics in Computer Systems (from Systems and Computer Engineering)

Recent and advanced topics in computer systems. The course will generally focus on one or more of the following areas: specification, design, implementation, and modeling/analysis. Students may be expected to contribute to lectures or seminars on selected topics.

Applied Computational Geometry

Computer-based representation and manipulation of geometric objects. Design and analysis of efficient algorithms for solving geometric problems in applied fields such as Computer-Aided Design and Manufacturing, Cartography, Materials Science, and Geometric Network Design.

Topics in Medical Computing

Introductory course on data structures, algorithms, techniques, and software development related to medical computing (in particular spatial modeling). Topics may include: computational geometry algorithms for cancer treatment, medical imaging, spatial data compression algorithms, dynamic programming for DNA analysis.

Selected Topics in Computer Science: Computer Graphics

[No description available.]

Summer of Code: Halfway Through

Midterm evaluations begin today for Google's Summer of Code program, so what better time than now to reflect on the program so far? Here I hope to give some insight into my progress thus far, why it is thus, and where I feel I stand. This will inevitably provide a good idea of my impressions on open source up to this point, albeit indirectly.

Back at the end of May, the official program start, my plan was to write up a tutorial on how to use Eclipse on Windows to debug Inkscape, tackle a quick bug from a list my mentor provided, then move on to some of the work that was contained in my application proposal. I never expected to have that bug take me to the middle of the program. I am certainly not new to large software projects, so it has been interesting to experience such a steep learning curve.

Despite my relatively slow progress, I can say that I have learned much in the process. I have discovered both how some of Inkscape’s general architecture works, and the basic workings of the code that handles text. I feel very well equipped to tackle my next task with an efficiency and grace that would not have been possible had I jumped into it head first back in May.

More importantly, I have a genuine desire to stick around after the summer. There would be no sense in whipping up some fast and dirty code just to get paid by Google and then move on. Therefore, I try to look at the time spent thus far as an investment.

(By the way, the bug I’m referring to is really more of a small feature. I’m adding support for the tref element, as you may have read about in an earlier post about some frustrations encountered.)

There are several factors that I feel have hindered my progress. These are things that I have personally taken some time to get used to, not necessarily inherent flaws in the way Inkscape is built or managed. In fact, some of these issues are a direct result of working with Windows when the code is much better suited to development in Linux.

Builds Take Forever

Even if I change just one line of code, I have to wait ten minutes to rebuild the code. This is incredibly frustrating and a huge time waster. Often, I can’t move on to work on the next thing while waiting because I don’t know what the next thing is going to be before I try the code I am building for in the first place. Especially when just learning the code, I find myself needing to experiment with different one line changes constantly. Perhaps I wouldn’t need to do this so often if the next issue – debugging – were non-existent.

Debugging Stinks

Stepping through code, watching variables, breaking on assertions – this is the sort of thing that can really speed up the learning process for a new piece of software. I wasn’t too enthusiastic about debugging with gdb on the command line, so I very fortunately managed to set up Eclipse to debug using the CDT plugin. This essentially gives a GUI front end to gdb. (I’ll note that this took some fighting back in March when I was getting my Summer of Code application together. Others were also having a hard time setting it up; this is why I spent the first few days of the program writing a tutorial about it.)

Now, I don’t know if it’s gdb or simply Eclipse’s use of it, but debugging in this manner is very flaky. In debug mode, I can’t open files (though this has been proven to happen on the command line as well). Breakpoints often won’t work unless they are set before the application is launched. While stepping through code, the lines being executed seem to jump backwards a line or two unexpectedly. The debugger doesn’t break on crashes and can’t be arbitrarily suspended. Sometimes the application just doesn’t feel like launching. And these are just the issues I can remember!

Documentation is Thin

Not a big surprise here, though more up to date documentation would be nice. Assuming that I just haven’t been too dumb to find it. ;)

Online Communication Can Be Tricky

I have to admit that the fully online nature of the project has been difficult to adjust to. I tend to try to figure things out myself in the early stages of a new project. I find this to be a very effective philosophy and helps me learn the basics in a way that they will stick in my mind long-term. Still, there are times when a quick question to a team member can clear things up very quickly. The only problem is, when questions can only be asked online, asking isn’t always fast.

I’ve often preferred communication via the written word. It gives you an opportunity to think out what you want to say. However, there are times when sitting in front of a screen with another person is invaluable. If I don’t know the correct or recognizable terminology for something, for example, I can just point at the code instead of describe it. We can watch the behaviour of the running software at the same time and talk about it realtime. We can even sketch little diagrams to explain what we’re talking about. Some of this sort of thing can be done online, but it is impersonal and often cumbersome.

Another thing I really miss is weekly team meetings. Sure, they don’t seem so great while you are waiting for them to end, but hearing about other peoples’ problems and the technical discussion that often follows can be really beneficial. Some of this comes through in emails sent to the team, as it does in an online-only community, but you get something extra with in-person meetings it seems.

***

As with all things, it’s much easier to state what’s wrong than what’s right. There are some aspects of this kind of work that I really like. Working from home has its challenges, but it is darned nice to avoid the half hour commute to work in the morning. It’s also pretty amazing to see how well people can make friends online, without possibly ever meeting each other. There is a real sense of community.

I was fortunate enough to meet some developers in person at Libre Graphics Meeting, which made the comradery more real for me. I also try to make myself visible in the community, participating in pertinent mailing list discussions and helping users on the IRC channel.

Given all of this, where do I stand? I’m not sure how well I’ve performed compared to the other Summer of Code students in terms of actual code produced, but I have felt fairly productive in terms of learning. I’m hoping I will feel as fast the second half of the summer as I felt slow during the first half.

No matter what happens, if I can finish the summer with a prestigious Summer of Code t-shirt and a fun open source project to work on, I will be a happy programmer.

Learning Computer Science Through Games

We've been hearing a lot about the declining numbers of students enrolling in computer science in university these days. I know that the School of Computer Science at Carleton University has only recently begun to recover from the dot com bubble burst, though the quantity of admitted students is still quite a bit lower than it used to be. The reasons why this is happening are much talked about; lately, I've been much more interested in what's going to be done to fix it. I'm seeing from several different sources that gaming is going to play a big part in the comeback of computer science as a desirable degree to hold.

We probably all know that issues like job security, off-shoring, and more moderate pay are making high tech a slightly less desirable field to enter than it was in the boom. Furthermore, the mathematical nature of the subject (in its more pure forms at least) can make it seem somewhat dry. Besides, who wants to sit in front of a computer all day... right??

As is often the case, knowing how what you're learning applies to something you enjoy in the real world can make any subject [even computer science! ;)] seem fun. So let's see... what's a technology that almost all people under twenty have enjoyed at least once in their life... that young people almost universally seem to understand...

It is definitely not true that anyone brave enough to enter computer science is going to be a big gamer. However, it does seem that we've all experienced games at some point, and can easily relate to them as a real-world application. Even I, a total gaming dummy, have taken to playing Mario Party 8 on our Wii. I even somehow managed to win a match once.

An article from the site Software by Rob suggests that one way to attract new students is to "show the steak, not the slaughterhouse." The article points out that "software is responsible for MySpace, iTunes, YouTube, and SecondLife; this is what the youth need to hear about." Imagine sitting through one of those recruiting presentations that some universities do at high schools. It's fairly obvious that flashing images of all the cool stuff software has given us will result in more excitement (and ultimately admission applications) than a discussion on how you will learn algorithms, algebra and programming paradigms. Video games will inevitably be a part of that "cool stuff" list.

But is it enough to simply talk about the fun things the industry has brought to us? Somehow, I can't see this cutting it with most kids. After all, they would still have to survive four years of algorithms, algebra and programming paradigms. The dream of possibly making video games at the end of it all just may not be enough for a lot of would-be students.

Enter brand new programs that focus on game development, such as the Game Development Stream that will begin this September at Carleton University.

Although Carleton now has one of the only programs of its kind in Canada, the notion of incorporating games into lesson plans is not unique. The University of Calgary offers a computer science degree with a concentration in computer games; its web page claims that "the philosophy of this concentration is to provide students with a solid foundation in Computer Science while providing them with a thorough background in all aspects of computer game development and design." South of the border, this article from Computer World describes the research of two colleagues given "grants to create interactive computer game models and sample course curriculums that colleges and universities could use to inspire would-be techies." These researchers are suggesting the likes of creating games as course projects that incorporate many key computer science topics from networking to artificial intelligence.

I see two big ways in which the game development stream, as it is laid out at Carleton, can specifically benefit students:

1. Their degree designates that they have completed this particular stream. This may not seem useful when you consider that almost all the courses taken in this stream are the same core subjects present in all the streams. However, only in this stream are you guaranteed to have taken all the game related courses, and this could help when looking for a job in the industry.
2. Applications in gaming can be worked into even the most difficult courses of computer science. Studying randomization in an advanced algorithms course? Discuss how it can be used in the analysis of binary space partition trees, a data structure used extensively in the game Doom. Not quite getting through with the concept of A* search? Explain how it can be used in the AI for chess. The list goes on. These kinds of applications should motivate and provide the necessary tools for the budding game developer, and may even make things more interested for the other students as well.

It should be interesting to see how many schools follow suit and provide game related curriculum, and more interesting still to see how successful it is. In particular, I will be watching the new stream's progress at Carleton as I begin my Masters there in September.

The Dangers of Copying

When I'm first learning a code base, I often make use of existing code, using it as an example to help speed things up. I don't do this blindly, of course -- that would probably result in many more problems than its worth. Still, it can be easy to fall into the trap of taking the example code as ground truth.

This happened to me yesterday while working on Inkscape. I'm adding new support for the SVG element <tref>. Because this element is similar in concept to <use> in that both refer to other elements, I have been looking at the code for <use> as my model.

I needed a class to represent the link between the <tref> object and what it refers to. The <use> element simply subclasses URIReference to accomplish this, so I made a new subclass for my purposes, initially just duplicating the <use> version. When I tried to build the code, I got a linker error telling me there was no virtual table defined for my new class.

Cursing and hair pulling may or may not have followed.

Finally, I looked up URIReference to see what it had to say about the matter. Lo and behold, the function being overridden had a slightly different signature. There was an extra const in the parameter list in the <use> version. Removing it from my class solved all my problems. Sigh...

Why the code compiles and links properly with the extra const in the <use> rendition of the subclass, but not in mine, I will never know. But let this be a reminder to be wary of the dangers of using existing code as your example. Look around elsewhere in the code base and remember to question everything.

Convocation

I am now able to officially call myself a graduate student. Until I shook Marc Garneau's hand (Marc being Carleton University's chancellor) , I could only be called a "graduand." The timing couldn't be better, really, as the class schedule for grad school courses has just been released.

On June 12th at 9:30 a.m., the first ceremony of Carleton University's 130th Convocation began. After the P.h.D. and Masters degrees were awarded, I was second in line to receive my degree. The official degree I earned is this:

Bachelor of Computer Science
Highest Honours
Software and Computing
Minor in Mathematics
Co-operative Education

Later in the ceremony, I also received a Senate Medal for Outstanding Academic Achievement. Something around 150 graduating students out of three or four thousand received this honour.

The reception that followed had fruit smoothies and cupcakes decorated with grad hats.

My parents with me in Alumni Park:


My grandparents with me at the reception:

Behind the Screen

Look, Ma! I'm famous!

Graduation is coming up very soon and Carleton University's monthly, Carleton Now, is capturing all the excitement once again. And one of the articles is about me! It's called Behind the Screen; check it out!

Working Environments

I mentioned an article about working environments in Women and Open Source (the first of two posts about the topic), but couldn't find it at the time. I recovered the link this morning. The article is called Report: Tech's Gender Gap Widened by Uninviting Workplace.

From the article:

For years, word has circulated of a significant gender gap in the technology workplace, where women are greatly outnumbered by men. The blame is typically placed on low interest on the part of women to pursue computers and engineering, but the actual experience of women working in technology is rarely addressed. A report released May 14 stands to shift this perception by drawing attention to the fact that tech workplaces may not be the most favorable environments for women to work in.

As you already read, I figured that the environmental issue may apply equally as well -- though in a different form -- to open source development as it does to high tech in general. Feel free to read the article and let me know what you think.

Women in Open Source II

My previous post, Women in Open Source, received an interesting comment just hours after I wrote it. The commenter Chris suggested that my thoughts on the issues preventing more women from entering open source were perhaps sexist and too stereotypical. In fact, this is probably true, and is why I even wrote the piece in the first place.

We live in a politically correct world where certain issues have become taboo. It seems that many are somehow afraid to bring up the inherent differences between men and women lest they come across as sexist. Sometimes, this can be a good thing, but sometimes it can do a great disservice. After all, according to the studies, treating everyone in an open source community the same, without considering gender, is one reason that women don't get involved.

So where are these 'studies' anyway? Well, Chris pointed me to a project called Free/Libre/Open Source Software: Policy Support. Linked to from this home page, I started to read their first listed deliverable, D16 - Gender: Integrated Report of Findings. After reading through the Executive Summary, I came to realize that this report was essentially saying the same things I did, just in fancier words.

The opening paragraph of the key findings reads:

Listed below are the factors significant in excluding women from F/LOSS communities. These factors are nearly all underwritten by a central cultural dynamic within F/LOSS. F/LOSS participants, as in most scientific cultures, view technology as an autonomous field, separate from people. This means that anything they interpret as ‘social’ is easily dismissed as ‘artificial’ social conditioning. Because this ‘conditioning’ is considered more or less arbitrary, in their view it is supposed to be easily cast aside by individuals choosing to ignore it. F/LOSS also has a deeply voluntarist ethos which values notions of individual autonomy and volition. As a result participants largely do not believe that gender has anything to do with their own individual actions. The situation is thereby perpetuated in spite of the expressed desire for change.

Here is the first hint that the issue is highly related to the social aspects of open source communities. Notice that the culture underlying the communities is described as having a lack of any real social environment, since anything considered social is simply cast away and ignored. This quote also implicitly tells us that the social aspects of the community are indeed important to women.

Let's examine two of the key findings. (The others are equally as interesting and relate to what Chris said in his comment, but are less directly associated with my previous post.)

F/LOSS communities actively perpetuate a ‘hacker’ ethic, which situates itself outside the ‘mainstream’ sociality, but equates women with that mainstream. Women are treated as either alien Other or (in online contexts) are assumed to be male and thus made invisible. Women are seen as innately more able to organise, communicate and negotiate among F/LOSS projects as well as with the outside world. Thereby they become carriers of sociality that is seen in a contrast to the 'technical' realm ascribed to men. Additionally F/LOSS women receive a high level of attention due to their gender which decreases their feeling of acceptance as community members as well as their willingness to further engage with the community.

I feel that this finding correlates nicely with my earlier notion that even when a satisfactory social environment might exist, women may not be able to come to realize it. Nobody wants to feel like an outsider, yet becoming invisible isn't going to facilitate the social interaction most women seem to desire.

The reliance on long hours of intensive computing in writing successful code means that men, who in general assume that time outside of waged labour is ‘theirs’, are freer to participate than women, who normally still assume a disproportionate amount of domestic responsibilities. Female F/LOSS participants, however, seem to be able to allocate a disproportionate larger share of their leisure time for their F/LOSS activities. This gives an indication that women who are not able to spend as much time on voluntary activities have difficulties to integrate into the community.

This one touches upon what I was saying about women not generally wanting to come home from work and continue programming. Interestingly, this point seems to suggest that it is the domestic responsibilities, whether perceived or real, that make women feel they don't have enough free time to contribute effectively to open source projects. I figured that women simply wanted to take on activities outside of technology moreso than men, and maybe this gives a possible reason why. If women have been responsible for certain aspects of home life for many centuries, then it is not hard to believe that they would feel even today that they did not 'own' their free time in the same way as men, even if in modern times these responsibilities don't always exist.

And now for a couple of key recommendations.

Provide tangible resources to help women devote time to their F/LOSS activities. This means both funding helping women to take part at specific F/LOSS events, as well as continuous support to enable women to take part in F/LOSS projects over a longer period of time.

Women would probably feel less like they are interfering with life outside of their careers when developing for open source if they had, say, financial resources. Funding for attending conferences would help increase face to face social opportunities.

The European Commission, and EU Governments should use their commissioning role to encourage a greater variety of working methods in the production of software.

These methods could include ways that boost the social interaction of community members. For instance, web cast meetings might be considered, and when feasible, more in-person encounters.

It should be fairly obvious by now that this report supports the ideas from my previous post. Social interaction and a good working environment do matter to women, and is one aspect that has been keeping women away from open source development. Furthermore, not realizing the importance of this issue because the sexism card might be played can clearly cause more damage to the open source industry than good. After all, it seems that everyone agrees -- open source needs more women!

Women in Open Source

The discussion started with one simple stat: only 4% of Summer of Code participants are women. Comments suggest that the numbers for open source software in general are even worse and that, although not ideal, the field of computer science in general does seem to be doing somewhat better. The question posed was simply this: why are women interested in development shying away from open source in particular?

My first thought on this was that women tend to appreciate social contact. And I'm going to guess that this means face to face, bona fide real-life interaction, not just the virtual variety. There seem to be relatively few opportunities to meet other members of an open source project's community other than the occasional conference. Would most women enjoy working with people they've never met, knowing only their online personalities?

A timely technology news update from ACM included an article about why there aren't more women working in high-tech in general. Sadly, I can't find the article now, but the main point was that many women are turned off by the working environments found in most high tech places. With open source development largely happening online only, it goes without saying that there isn't much of an 'environment' at all. No lunches with coworkers, no fun days, and no jokes during team meetings. It is also possible that the virtual environment created by the community would be suitable, but that women aren't able connect to their fellow developers in a meaningful enough fashion to discover this. This comes back to the whole social contact thing.

Finally, ask yourself which gender is more likely to come home after a long day of work (possibly of coding) and fire up the laptop to scratch that burning itch by working on some project that doesn't result in any kind of financial gain. You're picturing a guy, aren't you? Even women without families seem to enjoy taking on activities that have nothing to do with work during the evenings and weekends. It's not that they didn't enjoy the programming they did during the day; it's just that there are so many other things to get done after the steam whistle has sounded.

I know I can relate to each of these three issues myself. I definitely appreciate the social aspects of a regular job. I always look forward to fun days out of the office, and getting together with coworkers over lunch. Heck, I even enjoy meetings because of the opportunity to interact with others! I have found that even regular high-tech companies can often fail to satisfy my social needs - too many employees don't tend to want to do anything except work on their piece of the project. And yes, these tend to be the males!

Having said that, however, I can also say that I can enjoy working on my own as well. So far, I don't mind the 'reclusiveness' of open source too much; I guess we'll have to see what my feelings are at the end of an entire summer of doing it. I can absolutely see myself contributing beyond the Summer of Code, but I could never put in the huge amounts of time into open source (or any coding project) that I see some guys doing. After all, I have to save time for laundry, gardening, motorcycling, taekwondo, yoga, snowboarding, ...