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

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/

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.

Reflecting on UCOSP

Andrew Hong from the University of Toronto gives us his impressions of the program.

It has been almost two full months in the Undergraduate Capstone Open Source Projects (UCOSP) program and now that I look back, it has been an amazing experience. If you are reading this, you probably have an idea of what the UCOSP program is about and are looking to find out more. UCOSP is basically where you get to work on a distributed open source project for a semester with a team of students and mentors. The mentors and students are likely from all over the country so do not expect to see them in person regularly. You will do most of your communication online with your team through whichever method is preferred; audio, video, text chat, etc. UCOSP is very different from your typical course, you work however you want, and whenever you want. There are deadlines to be met so it keeps everything and everyone in line. Expect to work about 8-10 hours per week and sometimes more, when it is necessary. You do not get any marks until the end of the course but you will receive feedback along the way so you know how you are doing in relation to your mentor’s expectations. You can always ask them how you are coming along just in case you think you are slacking. If there is one takeaway I want you to get out of reading this, it is: enroll into UCOSP now, you will not regret it!

The code sprint this year was held at the Mozilla office in Toronto. It was a phenomenal and busy three days. We had all the students enrolled in UCOSP all in one space and separated into our respective teams. For ReviewBoard, we worked on bugs, started projects for the term and made sure everyone was on track. We, the students, were all set up with our environments so there was little time wasted there. It was an awesome experience to meet your fellow students and mentors so you can easily put a face to those internet nicknames that you are always chatting with :) I believe the code sprint was crucial to UCOSP. It makes people familiar with who they are working with and thus making it a more comfortable working environment for all. Food and drinks were provided so no need to worry about thirst or hunger strikes. After hours was up to the team, we decided to wander around the city in search of good food and a good time. Since I was the only Toronto student in my team, I gave them a mini tour of the downtown core, without trying to be touristy. We went for hidden gems and not-so-typical dining spots and by the end of it all, it sounded like everyone had a great time!

I am currently working on a project called ReviewBoard (https://www.reviewboard.org/). In short, it is a web based collaborative code review tool. I am not going to get into much detail about the project itself since you can find out everything from their homepage. The mentors for this project have been fantastic so far and to be quite honest, I cannot ask for any better. All our mentors have been helpful and always willing to lend a hand whenever possible; I am very fortunate to be working on a project with such great folks. We have our team meetings on IRC and in the chat, there are usually a couple of mentors ready to answer any questions we may have. Some prefer audio/video conferences but I have found that it has worked extremely well for us to just use IRC to do most of our communication. It allows other mentors and students to chime in on an issue or just discuss anything in general; it saves all the pain of trying to schedule a meeting with everyone that is involved in a discussion. I started on ReviewBoard doing simple bug fixes just to get familiar with the code base and working with Django. I have never worked with Django but once you get started on bugs and projects, everything will start to fall into place. Be sure to ask questions when you are stuck! I, for one, like to figure things out

by Googling so I sometimes spend hours figuring out the problem and realizing at the end that it was an easy fix. Sometimes when you are really stuck, dig around for yourself first then ask questions once you have given up searching. I think most people in UCOSP will agree: it is best to work in chunks than to give an hour of your time here and there. It may be tough to find a chunk of time but if you try both and compare the two approaches, you will find that you are much more productive working with chunks of time.

For those interested, I will dive a bit deeper into ReviewBoard so you get a better glimpse of what goes on behind the scenes and what I have learned so far in regards to the technical side of things. As mentioned earlier, ReviewBoard is a free collaborative web based code review tool. It is currently being used by many big players in the industry such as Cisco, VMware, Twitter, LinkedIn, Amazon and many more. As you can probably tell, ReviewBoard can work with companies and organizations of any size. For me, ReviewBoard was not too difficult to get a grasp of; the code base is very clean and organized so locating pieces of code is easy once you get the hang of it, they are where you will expect them to be. The ReviewBoard code base also consists of Djblets and RBTools. Djblets (pronounced jiblets) are a set of useful extensions that ReviewBoard uses, this includes a datagrid, logging utilities, site configuration tools and much more. On the other hand, RBTools is a set of client tools that allow the user to perform tasks in the command line without accessing the interface. All three code bases are very well organized and documented, so it makes things easier if you are trying to figure things out on your own.

My first easy fix bug was an issue with the user/group autocomplete functionality where it would be too ‘aggressive’. More specifically, the autocomplete functionality was selecting the first item that matched and once the user typed any more text, it would still autocomplete to the first item that it matched. Python was very familiar to me but not Django so I had to spend some time at the beginning to get used to the code I was reading. I found that the Django documentation on their homepage (https://docs.djangoproject.com/en/1.7) were helpful in getting started and understanding how Django works as a whole. If you are more of a visual oriented person then YouTube has plenty of good videos that explain more or less the same thing the documentation covers. Your browser’s developer tools are also a great tool to have under your belt. Without knowing where anything in the code base is located, you can use the developer tools to find out some key information (id, class, etc.) of what you are trying to modify then using that to perform a search on your code base can lead you to the right spots in the code to modify. There will be a lot of “aha!” moments once you see how everything is organized. Once the bug isfixed we check it into our local repository managed by git and post it up for review using RBTools. I realized that I did not know git fully when I had worked with it in a distributed project like ReviewBoard. It starts to bring out the all the things I thought I knew, but really did not, if that makes sense. It truly is a one of a kind learning experience that you cannot obtain from your typical Computer Science course.

The first project I started to work on for ReviewBoard was allowing users to download all file attachments associated with a review request. First thing I did was brainstorm what I had to do, plan out each step and where the code should be placed. I like to make empty functions as

placeholders so it will help me visualize how the entire feature will work in code. The way Django works is by having a URL dispatcher that determines which view to be called depending on which URL it matched. A view in Django takes a user request and returns a response, usually the response is filling in a template with the appropriate information. This feature did not need a template since all it needed to do was send back a zip file of all the file attachments. The feature was relatively straightforward to implement except handling files from external sources. ReviewBoard allows the administrator to set up where user uploaded file attachments are stored, it can be locally on the server, on an Amazon S3 instance or an OpenStack Swift instance. I knew a lot of the code would be similar so I tried to make sure I coulddo it as easily as possible without duplicating code. It turns out that I could leverage file-like objects (StringIO package) to read local and external files into an object and then write it out to the resulting zip file. After some extensive testing, and a few peer reviews, it should be ready to ship!

Next up for my student project, I will be working on adding functionality for the command line tools (RBTools), to enable the tools to search for the matching review request for a given commit. This is helpful when a developer makes new commits to their repository and needs to update the review request, they no longer have to manually input the review request ID and instead the tool can automatically find it for them. The function already exists for some RBTool functions so I will reuse the existing code to implement it for other functions that are missing this feature.

So that is it! This is my UCOSP experience so far and I hope you learn a thing or two from my experiences. I am definitely looking forward to the rest of the term but sad at the same time that it will be over shortly :(

TL;DR enroll in UCOSP and ask questions!

If you have any questions, please feel free to ask!
The UCOSP steering committee are a great bunch, so don’t be shy!