UCOSP brings together students from coast to coast to work together on joint capstone projects. Students learn first-hand what distributed development is like. Each team has students from two or three schools, and uses a mix of agile and open source processes under the supervision of a faculty or industry lead. Find out more about UCOSP.

Latest news

Enhancing ReviewBoard with TogetherJS

Peter from UofT checks in:

ReviewBoard is a web service which facilitates code review amongst developers
within a repository (Git, SVN, etc). The project I am working on is an
implementation of TogetherJS, an extension (or plugin) that organizations can
choose to install within their instance of ReviewBoard. TogetherJS is a
javascript library that allows multiple users to discuss a webpage through
text and voice chat and live cursor interaction. A demo is available here.
<https://www.youtube.com/watch?v=tEfbREmTBjc> It is similar to screen sharing
on Skype but has limited capabilities. Some of the features I have been
assigned to implement are to decouple this service from the Mozilla servers
and to reduce dependency on WebRTC. There will be an interesting balancing act
between taking advantage of all the available tools from the library and
keeping the extension a standalone project that services the needs of
ReviewBoard. The objective of this project is to help multiple developers
discuss a single commit in real time while in remote locations.

The most important lesson I have learnt in UCOSP is that this is not a course.
There are supervisors from the faculty, mentors of the project and peers.
However, there are no lectures, no assignments, no deadlines, no tests.
Throughout undergrad, attending lectures, keeping tabs on assignment and test
deadlines, and starting early to meet these demands helped me succeed. However
this does not work well with UCOSP. UCOSP requires a different type of
dedication. You really need to set aside time to work on it on a regular
basis. Furthermore you need to ask questions frequently. It’s very unintuitive
because with regular courses, the more time you spend on a problem on your
own, the more you learn. The opposite is true here. The more time you waste
trying to solve something on your own, the worse your overall performance. It
is much more productive to consult your mentors at every roadblock. Some
people may find asking many little questions bothersome but the mentors love
it. If they did not like helping, they would not have become mentors. The
UCOSP learning experience is really different, but there is no reason you can
not succeed because there is so much help available if you take advantage of
it.

UCOSP: How I learned to stop worrying and love open source development

Olessia Karpova from the University of Toronto summarizes her UCOSP experience:

First steps


The first step after being accepted into the program is picking the project. This year there were over 20 projects, how do you choose the right one? This is something you’ll be working on for a considerable amount of time – think about what your priorities are: is it to dive deeper into a topic you are already comfortable with? Dive into something completely new?It will be challenging either way – I thought that being familiar with the technologies used in the project will make the experience less overwhelming. This turned out to be completely wrong – jumping in on a project with a big existing code base is always overwhelming at first. The lesson to learn as quickly as possible is to ask questions. Personally, I’ve always preferred working things out on my own and not have to bug anyone. It takes some time to get used to the idea that the mentors are happy to answer questions, and that really, instead of spending hours trying to figure something out it is much better, for the project, if you spent ten minutes talking to someone who knows the code inside out and will probably be able to figure out what the block is from as vague a description as “the tests in file x all suddenly fail, and I didn’t do anything” (true story).

Working habits and expectations


Throughout my university experience I’ve been quite organized so I had no concerns about being able to put in the required number of hours each week, and keeping up with the workload without having to set aside specific time to work on the project. This turned out to be only partially true – I quickly realized that while I had no problem putting in the hours throughout the week, it was best to set aside a day when I could focus solely on the project. As students, we do not usually feel this with regular course assignments since they are usually rather small units of work, but with bigger and more complex projects it takes some time to get into the ‘zone’, so to say. It’s simply less productive to break up the 8 hours into 2 hour chunks if every time you have to take 20 minutes just to get back into the mindset and start working.

It is easy to get stressed in the first few weeks, feel unproductive, and completely overwhelmed with code base.
It is important, however, to manage your own expectations. It is completely OK to feel that way, no one expects you to start contributing code to the main branch in the first week. It is completely OK if fixing your first bug takes an entire day. Or if you spend the day trying and failing to solve a problem. The most important thing is that you’ll probably learn more in that one day then in a few weeks of a software engineering class. This really is the most important lesson to take away – and it took me a while to fully appreciate it – we learn best by failing. After struggling through something, we not only learn which solutions work and which ones don’t, but also how to change the approach to the problem, how to step away and look at it at a different angle, how to apply prior knowledge and when to search for new approaches. While failing _is_ learning, it is also important to know when to step away from the issue and ask for help. That’s a balance that can be hard to strike, but if you run out of ideas of what is going wrong it is definitely time to start asking questions.

Preparing the tools


There are a few things you can do to make the term more productive and get a head start. Most importantly, if you are not familiar with the version control system the project uses it is a good idea to get comfortable with it. You will definitely need to know how to update the repository, create branches, and commit your work.
Most of the version control systems have GUI’s these days, but it’s best to be familiar with the main operations and be able to do these from the command line.
Another suggestion is to find a good IDE for the language you’ll be primarily working with, and get familiar with its features. For python development I highly recommend PyCharm by JetBrain. (This advertising is based on a year of working with PyCharm and is not sponsored by anyone. By the way, IntelliJ for Java is also great.). As for features, take a look at how to do refactoring, finding declarations and implementations, code formatting and completion, setting up virtual environments, and many others. I find that it’s easy to get into sort of routine, where you’re comfortable with the tools and the workflow you’re used to, but there’s always, I think, a room for improving the workflow by using better tools, and using the tools you have better.

Final thoughts


It’s been a great semester and I learned a lot from the UCOSP experience.

I had a chance to be involved in cool project, do real, useful work, and meet and work with a number of great people.
It was by no means easy, but it was a great learning experience I would highly recommend getting involved in UCOSP to anyone in the Computer Science program. I am looking forward to sharing my work on the demo day in a few weeks.

Extending MediaWiki using extensions and hooks

Wen-Chien Chen from Waterloo fills us in on his work with MediaWiki extensions:

MediaWiki is a versatile wiki software package written in PHP that powers websites where users write collaboratively. It is used in a variety of applications, from Wikipedia to the online documentation of Arch Linux. The extension architecture of MediaWiki allows it to adapt to the needs of different applications: while the core portion of the software is already powerful, it can be augmented with modular extensions. In particular, MediaWiki allows extensions to define hooks, and to register handlers for hooks defined in MediaWiki and other extensions. We used this feature to add the ability to send thank you notifications to other users for their comments on discussion boards powered by the Flow extension, leveraging existing code in the Thanks extension.

On a Flow discussion board, each comment has several interaction links for editing, replying and other functionality. In the Flow extension, the code that generates the interaction links is similar to the following:

public function postInteractionLinks( $replyButtonClass, $editButtonClass ) {
	$items = array();

	// Generate the HTML code for reply and edit buttons and append them to $items
	$replyButton = $this->replyButton( $replyButtonClass );
	if ( $replyButton ) {
		$items[] = $replyButton;
	}
	$editButton = $this->editPostButton( $editButtonClass );
	if ( $editButton ) {
		$items[] = $editButton;
	}

	// Construct and return formatted HTML containing the interaction links
	return implode(
		Html::element(
			'span',
			array( 'class' => 'flow-post-interaction-separator' ),
			wfMessage( 'flow-post-interaction-separator' )->text()
		),
		$items
	);
}

To allow other extensions to add more links, we added a call to wfRunHooks() immediately before the return statement:

// $this->post refers to the comment and $this->user refers to the viewing user
wfRunHooks( 'FlowAddPostInteractionLinks', array( $this->post, $this->user, &$items ) );

wfRunHooks() is a global function in MediaWiki that calls each hook function registered to handle an event—in this case, one we just defined as FlowAddPostInteractionLinks. Multiple handlers, which would be called in sequence, can respond to the same event. The contents of the array are passed as arguments to the hook functions. Note that a reference to $items is passed in, in order to allow handlers to modify the items array.

In the Thanks extension, we added a static method to the ThanksHooks class. It handles the event by appending a link to $items, returning true on success:

public static function onFlowAddPostInteractionLinks( $post, $user, &$links ) {

	// Perform permission checks and other processing

	// Generate the HTML code for a thank buttons and append it to $items
	$links[] = Html::element(
		'a',
		array(
			'href' => $this->getThanksApiUrl( $post->getPostId ),
			'data-post-id' => $post->getPostId()
		),
		wfMessage( 'thanks-button-text' )->parse()
	);
	return true;
}

To register the method as a handler so that it would be called during the call to wfRunHooks(), we appended its name to the relevant entry in $wgHooks, which is an associative array that stores the handlers registered for each event. (In general, variables in MediaWiki with the wg prefix have global scope.) This was done by adding following line to Thanks.php, which contains setup instructions for the Thanks extension:

$wgHooks['FlowAddPostInteractionLinks'][] = 'ThanksHooks::onFlowAddPostInteractionLinks';

And that’s pretty much all that needs to be done to integrate the two extensions! After doing the above, a link for thanking the author will be appended to the interaction links for each comment. The hooks system makes it easy to add new functionality to MediaWiki and its extensions, and enables interaction between different parts of the software.

Aside from defining hooks ourselves by adding calls to wfRunHooks(), the core code of MediaWiki defines a number of events that extensions can respond to. A partial list is available at the Hooks manual page.

In my time working with MediaWiki so far, I have found writing and modifying extensions to be a great way to learn about hacking MediaWiki. Aside from the hooks system described here, there are numerous other features in MediaWiki that simplify the work needed to create an extension. The Developing extensions manual page is a good starting point for learning about extension development, and MediaWiki.org, along with the class reference, provides extensive documentation about the internals of the software. Happy hacking!