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.