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

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!

Sharing my UCOSP Experience

Yifan Ren from the University of Waterloo provides this overview of his UCOSP experience:

I Participated in the BB10 PhoneGap team and was working on porting native plugins for BlackBerry10. I had an enjoyable and rewarding time working on the project, and experienced real-world software engineering practices and open source collaboration.

One thing I really appreciate about the BB10 PhoneGap project is its tasks. It has a list of independent tasks, and each one requests to build a complete plugin project of a useful feature, for example, zip file extraction and compression, barcode scanner, and system dialog. We had a chance to select one that interested us most, and would deal with the whole project, including configuration, source code, build, documentation and tests.

The first task I selected was to finish the Distimo plugin. Distimo is a mobile app analytics firm, and that plugin helps application developers to track users activities. The project was partly done, and my job was to finish the configuration and add several features. It took my some time to get familiar with the whole system including the Cordova frameworks, the plugin interface, the JavaScript implementation, the native C++ code, and how everything is connected. Fortunately, everything was well-documented, and Tim, our mentor, was extremely helpful and very experienced at the BB10 plugins. By the end of the code sprint, I had finished the configuration, made the test app run, and got some idea about the remaining works.

Once I was working on a feature called Applink. It gets app id from the Distimo server and shows that app in the blackberry Appworld. I figured out that its implementation needs http requests and http header settings, and I had just learned these early that week in a university course. At that moment, I felt strongly that this project was a great opportunity to apply my knowledge and skills learned in class to the real-life.

My second task was to build the system dialog plugin, which allows users to prompt global dialogs with buttons from their applications. Thanks to the handy templates and detailed documents, the starting steps were quite easy, while the rest of the work was a little bit challenging but also interesting.

When I was working on this plugin, I was introduced to the Qt library and its signals & slots mechanism of objects communication. I found that to be extremely useful and planed to import that library to my personal project. Moreover, I did learn a lot about fundamental aspects of projects building, such as project structure, configuration, Makefile, and documentation.

Help is always available. We had weekly team meeting to report our process and ask questions. Tim was also available and helpful during the rest of the time. I often received timely feedback and really useful suggestions.

At the final words I can say that working on the BB10 PhoneGap plugins and participate in the UCOSP was a big step for me. Not just for the fact that I developed practical skills and got a deeper understanding of the real-world projects; I also gained open source experience and made contribution to the community. I certainly enjoy working in the team with these awesome people, and would strongly recommend computer science students who wish to get involved themselves and gain open source expensive to apply for UCSOP and contribute!