Welcome to UCOSP!

UCOSP is a program that brings together students from across Canada to work together on open source projects. Students learn how open source software development takes place, practice distributed development, and have the opportunity to work on project with knowledgeable industry or faculty mentors on software with real users.

Dec 15, 2015 - Getting Ready for the New Year

As we prepare for the next group of students who will start in January, we are seeing some turnover in the project offerings for UCOSP, so I’d like to welcome the newcomers and thank the project mentors from the past term.

The project mentors for Waterbear, CodeIgniter, and Mylyn are all based in Vancouver which makes it more difficult to attend a code sprint in Toronto.  It has been great working with Dethe, James and Sam, and I hope we will have a chance to work with you again in the future!

We are also saying goodbye a long-term project: Phonegap.  Tim Windsor has moved to a different job and is not able to supervise students this term.  Tim has been a terrific mentor over several years, and it would be a great pleasure to work with him again.

We are welcoming two new projects this term, both from Mozilla: Jupyter Notebooks for Data Analysis, and Code Coverage Explorer.  I’m excited to see what students will do on both of these projects.

Apr 2, 2015 - CodeIgniter checks in

Xing Zeng from UToronto who has been working on the CodeIgniter project checks in on this term.

I am working on the CodeIgniter Project. More specifically, our team is spending most of our time in developing Netbeans plugin for CodeIgniter developers.

CodeIgniter is a light-weight PHP framework, loosely based on the popular Model-View-Controller development pattern. It is the 4th most widely-used PHP framework throughout the Internet[1]. Despite this, there has been no IDE plugin for it on any major IDE, where lots of other PHP frameworks, including the famous Symphony and the not so famous Nette2, all have IDE plugins specifically designed to work with the features of their library. That’s the reason why our team decided to work on it.

The first platform we choose to implement our plugin was Netbeans. It is a fast and flexible IDE and it is among the preferred choice of many CodeIgniter developers as well as the IDE being taught in the CodeIgniter class at BCIT. It has tons of libraries and APIs for you to develop plugins conveniently to work with Netbeans. Since Netbeans was programmed in Java, our Plugin is also written in Java, created in Netbeans IDE as a Netbeans Module Project. Some other supplementary files were written in PHP.

This is the first time I have ever worked on an open source project as well as the first time I ever started working on an open source project from the ground up. We use Github as our major tool for issue tracking and source control, just like a lot of other open source libraries including CodeIgniter itself. So I really feel excited about this golden opportunity, and I do feel I learn something from it. The following are two examples of what I have learned from participating in this project.

The first target I set was to implement a view navigation functionality. It is a fairly easy task since Netbeans has already provided you the interface HyperlinkProviderExt for you to implement. So I approach this naively at first, directly go into the package of code navigation to do all my coding work. I did kind of realize that this is not the correct way at the beginning of implementing a somehow complicated software, as some of my functionality in parsing Hyperlink and retrieving files may also be required by other parts of the program. But I did not have a chance to think about it carefully until I have decided how am I supposed to integrate the interface in HyperlinkProviderExt with the functionality I want. This turn out to be a problem later, when one of my team members came to me and ask me how to tokenize the PHP file, which is a functionality I have implemented after I finished my code. The result of not having a consensus prior to working on the code is a minor refactoring required in my code to make the system work and a major one is still ongoing for both my package and the shared package to make the code more clear and robust.

Then I switched to working on the auto-completion functionality. For this part, I realized that learning from other open source projects on Netbeans IDE Plugin is extremely useful, which is also a major reason why people promote open source. This is even more essential in my case since, for some reason I don’t know, Netbeans APIs does not have javadoc with it and it takes so much time to manually go over its online documentation. So, I looked into some other open source projects, including the source code for the Yii Plugin, wojciech-holisz plugin, as well as the Sprint Autocompletion file and the structure of the Zend Plugin. They gave me lots of help on providing me a basic idea of how the structure of my CompletionProvider class could be and showing me what kind of API calls as well as pre-defined object would be convenient for me to use. This allowed me to finish the coding of this part early and understand how each part could  work together.

In conclusion, I feel like working for CodeIgniter is a really great opportunity and I do feel I learned a lot from it.

**

[1] http://www.sitepoint.com/best-php-frameworks-2014/**

Dec 10, 2014 - UMPLE Experiences

Karin Ng from the University of Toronto gives us her experience working with UMPLE this term.

Umple merges UML modeling and programming to facilitate Model-Oriented Programming. The models include class diagrams, state machines, and composite structures. My primary project is to create a generator that takes in current Umple semantics to produce GraphViz (open source graph visualization software) code of an entity-relationship diagram. After I have completed the generation, I hope to look into refactoring all the generators and extracting commonalities into a generation library.

Since the entity-relationship diagram generation is a larger project that requires the knowledge of how to use GraphViz, I decided to begin with a smaller issue, dealing with modifying the tooltips of current implementations of GraphViz diagrams. Believing it would be a relatively simple task, I was surprised when I took a deeper look into the code and realized that the entire structure of the diagram being generated had to be modified to accommodate the new tooltip requirements. The surprises for the seemingly simple task didn’t end there. After modifying the code, creating test cases, and testing my implementation on a clean version of the build, I was satisfied with its reliability. Though I believed that my testing was rigorous enough, I failed to notice that the code I modified was used to create the Meta-Model (a model of the Umple compiler, using Umple). The Meta-Model creation was not tested within the build and, naively trusting the lack of fails within the build, I thought myself safe. The result was a broken Meta-Model that wasn’t noticed until after the faulty code was committed. Mortified by my error, I tackled the problem as soon as I received the email notifying me of the glaring issue. After much correspondence with my mentor (including tips and encouragement), the problems were ironed out and I learned not only the technical skills I had hoped to gain concerning GraphViz, but the value of truly rigorous testing and mentorship.

In a less technical sense, I also encountered difficulties with juggling my schedule. I had decided from the beginning that I would allocate time for Umple every week on my calendar. However, having taken 6 courses, I found it easy to let my scheduled Umple time slip, especially when other seemingly more pressing assignments with hard deadlines and midterms presented themselves. I also vastly underestimated the time required to get the code working 100%. Much of the work during my internship involved the creation of new features, and I rarely had to greatly modify old code. As such, the modification of the diagram generation and its problems came as a shock to me. Though implementation itself may not have taken too much time in of itself, the time requirement easily doubled when taking into account all factors (such as the design and creation of tests, the re-working of the implementation after exposing bugs from the tests, ensuring compatibility with any updates during the entire process, and applying changes from feedback from mentors).

Regardless, the complications were vastly overshadowed by the immense satisfaction and joy of getting something working (no matter how small) that will impact hundreds of people. Having discovered all the possible obstacles that may get in the way of a timely commit, it only took a small reformation of my schedule and a little more mindfulness to adequately fit in some Umple development. The fun-factor of Umple development certainly helped in squeezing in more time (even if in the wee hours of the morning) to tackle the next bug or problem. The lessons have been innumerable, from working with a team scattered across the country to things as simple as not being afraid to ask questions, and I am endlessly grateful for the opportunity to be part of UCOSP.