[Guest post: Cam Macdonell is an Instructor of Computer Science at Grant MacEwan University in Edmonton, AB. He completed his PhD from the University of Alberta in 2011 and began teaching at Grant MacEwan in September, 2011.] In September, I began teaching my first upper-level University course at Grant MacEwan University. Having taken some (and heard about some other) lack-lustre undergrad Software Engineering courses, I really wanted to make this course practical, project-based and interesting for the students. One inspiration was the Undergraduate Capstone Open Source Project (UCOSP) where final-year students select a project and are mentored by faculty across Canada to work on an open-source project for course credit. I also loved the practical approach of the Software Carpentry course taught by Greg Wilson and Paul Lu, which I was involved in a few Summers back and frankly preferred to some of the “Ivory Tower” Software Engineering that is common in undergrad courses. It was Greg Wilson that pointed me to Ushahidi, and I felt Ushahidi’s humanitarian focus would be a great added benefit to my students. Computer science is so often focused on science, business, marketing and advertising that I felt this was an opportunity to show my students how a small group of dedicated people can use software to make a difference in humanitarian way. There were other great projects suggested too, such as the Sahana Foundation, but I made up my mind to go with Ushahidi once I was introduced to Heather Leson and got to peak in on a Ushahidi hack-a-thon from Nairobi via Skype. The energy of the group was obvious and very exciting.

Organizing the Curriculum

With much enthusiasm, I jumped into trying to build a course using Ushahidi as the core project component. The first major hurdle was that 3rd year computer science students have minimal system administration experience. Except for a few exceptions, they haven’t run a database or a web server on their own. Moreover, PHP is not part of a course curriculum. The sysadmin challenges were answered by using Harvard’s CS50 Virtual appliance. This VM is based on Fedora Linux and comes with PHP, Apache and MySQL already installed. The VM runs on VirtualBox, which is free so students could install it on their laptop (this is how most students ran it). As for PHP, I felt that PHP was accessible to undergrads coming from a Java background. It’s syntax and object-oriented are quite similar to Java. Our courses at Grant MacEwan involve a weekly three-hour lab component. The first lab was used to introduce PHP with some sample programs. The second lab was used to introduce Kohana and the MVC framework. After the second lab, the first assignment was given. The first assignment consisted of 4 simple tasks

• Apply a patch to get Ushahidi to work with non-clean URLs
• Change the site name and tagline on the admin page to match the main page
• Modify the labels in the API stream
• Add a ‘’pirate’’ response type to the API

These assignments helped the students become familiar with how MVC web servers work. I also felt that the API was an important concept for them to understand well. In the end, this assignment was a bit too easy in some ways. In general, it’s very challenging to judge the level of difficulty when working with an existing code base. To this point, most of my students would have only written programs from scratch (similar to most undergrad CS courses). It was also to determine what kind of hints to give. For example, problem #4 from above become quite trivial once you show students how to search (using grep) through a code base. Without that hint, students will try to trace the code manually and search manually. So the dividing line between dozens of hours of work and 10 minutes is literally the knowledge of how to use grep effectively. Once the students had completed the first assignment, it was time to throw them head first into Ushahidi on some more significant projects.

Picking the Projects

One advantage I had was that there were only 10 students, which enabled students to work on separate projects based on their interests. Mistakes with a course of 10 students are much more fixable on the fly than with, say, 40 students. In trying to gather project ideas, I searched the feature requests on the Ushahidi development site and also I asked the Ushahidi community for ideas for projects. Projects from the feature request list included selecting multiple categories and multi-coloured dots. Others came from the Ushahidi group, such as 2-way SMS communication, OpenStreetMap integration and white-labeling the J2ME app. Some were my own creation, such as the SQlite back-end. In general, is very difficult to carve 10 appropriate projects from an actively developed open-source project like Ushahidi for the following reasons:

• Ushahidi developers are focused on moving the project forward, adding real features that users care about. As such, they are typically not willing to risk those features not being developed by leaving them to an undergrad. Course projects are in 3 month blocks whereas actual development in the project focuses on small increments or “many months away”, so carving off a piece that fits nicely into a 2-3 month course project is hard because that is not how developers think. Developers, from what I gather, focus on the next few week or two, or they may focus on large scale goals (significant re-writes of subsystems) which again are difficult to break down into course projects.
• The knowledge gap - real developers know the code, my students do not. This gaps adds to the difficulty of developers creating projects that can be handed off to an inexperienced student to complete.

Even with the above challenges, our results show that it is possible and extremely valuable to use real software in an undergraduate course project. I believe that our projects on Ushahidi went as well as I could have expected for three main reasons: The Ushahidi developers cared enough to try and suggest projects. Some projects were fine just as suggested while others could at least give me ideas that I could try and distill into projects. In the end, my responsibility is determining and setting the educational goals, so this worked well. The developers were of a great help, quick to respond to questions and supportive of the students, and I can’t thank them enough for this. My students were willing to accept the “ups and downs” of this kind of project. They knew the alternative was a canned, built-from-scratch project that no recruiter would care about. I was able to convince them that saying they had worked on (and got patches accepted to) a real software project would be of at least some merit over a typical SE course project. There were certainly some bumps in the road in terms of some projects being too easy (to which I would assign further work) or too hard (a completely working project was not required in some cases). In then end, the students were able to make significant progress on some real problems that the Ushahidi community cared about.

Student Project Review

All that said, let’s talk about the projects, cause they’re really cool. Dale Douglas (code) added the ability to allow reports to be edited on the main display. His implementation was not secure by any stretch, so may not be deployment ready, but was an interesting project. Dale wished that plugins could overwrite system files so that he wouldn’t have to modify the main Ushahidi codebase. Brett McKay (code) white-labelled the J2ME app. He also discovered that the J2ME app was in the middle of re-write. So he added the functionality to the new re-write version to add a deployment site and fetch reports. This an example where a student had to take on additional tasks once his initial task (white-labelling) was complete. Brett was challenged in there is actually no documentation of the J2ME app at all Richard Laan (code) added the ability to select multiple categories on the main map page. Richard’s learning curve was even steeper in that he had to learn Javascript for this project. In the end, a very successful implementation. Tracing the javascript was the most challenging aspect for Richard. Joel Joseph (code) added a search functionality to the API. This feature allows an API query to search and return results for particular keyword. Joel’s first project was a refactoring suggested by one of the developers. This was another example of a project that needed to be extended once the initial task was complete. Ranjoat Panesar (code) added a plugin to support 2-way SMS communication between an SMS user and the system. For example, the could stop and start notices or search for incidents related to a keyword. The motivating idea was having a user search for incidents around their current area, but we didn’t get that far. Alex Molzhan (code) Alex added a button that allowed the incidents to be shown in their incident colour when being displayed under All Categories. Richard Laan is currently continuing to work on this feature in relation to his “Select Multiple Categories” project. Chris Proulx (code) Chris added an AJAX-based interface to the reports editting page under the administrator. The features chris avoided reloading all the reports when one was deleted. His changes made the reports editing noticeably snappier. Wilson Liang (code) Wilson created a standalone Java app for the desktop. His application would follow a particular deployment. It may be useful in a situation when connecting to a particular deployment may have intermittent connectivity. Ruben Estevez de Freitas (document) Ruben worked on getting OSM installed locally and working with Ushahidi. Most instructions for OSM are for Ubuntu, so Ruben learned about the mess that is Linux package management and the difficulty in translating Ubuntu package names to Fedora package names. Ruben’s submission is not a github repository, but simply a document describing all the steps to get OSM working with Ushahidi on a Fedora virtual machine. Andrew Gergely (code) worked on creating an SQLite-based database for Ushahidi. Andrew ran into two major issues. The first was that the configuration scripts presumed MySQL and were difficult to debug. The second issue was that MySQL and SQLite SQL queries are not completely compatible with each other. The lessonhere was that "standards" such as SQL are sometimes not that standard. The course ended with project demos some of which the students put up for recording. The students have all made their code available and some are continuing to work on their projects. I think I can say that the students all enjoyed working on a real software project and found it valuable. There were certainly challenges that the students mentioned. The most difficult was the lack of an up-to-date, detailed technical description of how everything works. The lesson here is that such a document rarely exists, especially on open-source projects. For one, the document would be too massive to read or to keep updated. Updating is especially difficult due to the incremental nature of open-source development where developers’ time is already stretched thin. Know-how comes from mostly from doing and playing with the code, not from documents. Although, as always, more documentation would certainly be helpful both in the code itself and external to it. In particular I think a “How to get started with Ushahidi” document would be helpful for new developers. Second, I think a curated “To do” list for various levels of experience (new, novice, advanced) perhaps on the new wiki, would help with new developers looking for a way to get involved (or for a university professors looking for projects :)). In the end the course went extremely well. I learned a lot about Ushahidi, got to interact with some great people and, of course, some great students. A big thank you to Greg Wilson, Heather Leson, Dale Zak, David Kobia, and Aaron Huslage for all their help and interaction over the last several months. ******** Contact Cam Macdonnell via email To Cam, all the students and Grant McEwan University: Thank you being the first class of students to focus an entire semester on Ushahidi open source software development. Your hard work has taught us much about how to integrate Ushahidi software development into classrooms. We are close to launching more changes to make it easier for people to contribute, including more Git love aka a "To Do" list. And, a special thanks to Greg Wilson for advocating open source in Canada's universities. To the Ushahidi Community Developer Skype Chat folks: Thank you for supporting this initiative and answering Cam's and his student's questions. We hope to do more of this in the future and hope that you will join us on that journey.