UCOSP Blog Post

Hi! I’m Wilson Yeung and I’m in my last semester at Simon Fraser University where I am pursuing a Bachelor of Science in Mathematics and Computing Science.  I joined the Review Board team because an opportunity was presented to  the computing undergrads at SFU to join UCOSP.  Despite having high expectations, I am still surprised at how fulfilling this experience is.  Being enclosed in a controlled learning environment at university, I was excited to work on something that had real life applications and meaning to the outside world.

I have grown quite a bit since I started working on Review Board.  Prior to Review Board, I rarely did anything on the command line, haven’t used a linux OS, half decent at Python and Java, and a beginner in some other generically known languages such as HTML and C.  (Yes, I was a noob) Throughout this term, all those things have changed.  With tons of hard work and the comfortable learning environment, I’ve improved lots.  Albeit I’m not a pro at everything, but I’m comfortable with running Ubuntu from the command line, and I’ve read a hundred-ish pages of documentation on Java, JavaScript, Django, HTML, and much more.  Not only did I learn through reading documentation this semester, but I was given invaluable experience from the mentors and team members of Review Board.

If you didn’t know, Review Board is a web-based tool to do code reviews.  Due to the nature of the purpose of  Review Board, it becomes an invaluable tool in any project.  It tracks changes while giving you a bunch of tools to give critique or approval.

Throughout the semester, I’ve committed most of my time reading documentation on different languages to work on a certain project.  That project involved creating a setting in a user’s profile that would reflect changes in the comment boxes generated when you want to comment on some code.  Although it doesn’t sound very complicated, the architecture of Review Board can make the problem quite complicated.  The project forced me go through every level of the architecture in Review Board as well as access the database on the server.  While taking into consideration not only python files, but also JavaScript files and HTML files, it was difficult to maneuver between different file types and languages.

To conclude,  the Review Board team is awesome.  I wish there were more powerful words to explain how great the team is.  Everyone is intelligent, hard-working, and has a good sense of humour.  I would like to thank the UCOSP steering committee and the SFU liaison professor, Dr. Ted Kirkpatrick for making this possible for me.  Extra kudos to our mentors; Mike Conley, Christian Hammond,  and David Trowbridge, for being all-knowing, yet chose to guide us rather than spoon-feed us.  None of this would be possible without their time and their commitment to UCOSP.  I would highly recommend any comp sci undergrad to apply for UCOSP (ESPECIALLY Review Board) if they want to get a running start on their career in the computing science field.

Warmest Regards,
-Wilson Yeung

UCOSP Blog Post

My experience with UCOSP has been very fulfilling thus far. I’ve met a lot of great people, and have enjoyed working on the Review Board project more than I ever would have expected. One of my favourite aspects of the program is the feeling that your contributions are significant; The code you write is distributed to and executed by real users. This is in stark contrast to the usual work which is done in university.

UCOSP gives you the chance to work on some really interesting projects, and I’d like to give on overview of what I’ve been working on thus far.

Review Bot:

The main project I’ve taken on for UCOSP is something I’ve dubbed “Review Bot”. The goal of Review Bot is to automatically execute static analysis tools on code that has been posted for review on Review Board. Basically, it will review code using external programs, and then post any issues it finds to Review Board.

Thinking through the design, and receiving feedback from the community looking to automate static analysis using Review Board, I came up with a plan of attack. My initial aspirations for Review Bot are illustrated below:

How Review Bot was envisioned - Warning: Imagination Required

Yeah, that’s a code reviewing, go-go-gadget armed robot with a jet-pack. It reviews code written in any language, and can solve the halting problem. I considered allowing it to review its own code, but the risk of it becoming sentient and enslaving the human race was too great. But in all seriousness, I planned to make a highly versatile code reviewing bot, which other developers could extend to support the static analysis tools of their liking.

However, it can be hard to properly scope a project when dealing with an unfamiliar code base. I quickly realised this as I ventured deeper into Review Board’s API and extension support. Once I’d begun working through the implementation of Review Bot, it became apparent that my project was going to be a lot of work! Review Board lacked some of the features necessary to support the Review Bot I had envisioned. My first order of business was to fix this; I set out to extend the Web API and expand the feature set of the extension system.

Review Board’s extension system is powerful, young, and light in the documentation department. The lack of online documentation was a little worrisome at first, but prior developers had commented their code very well. Combine this with some very knowledgeable and helpful mentors, and hacking on extensions proved to be a blast. Even though Review Board is a mature code base, I was able to work on something fresh and exciting; you don’t have to worry about backwards compatibility when the feature isn’t in use yet. My time spent with the extension system has given me the expertise needed to document it, and my beginner’s guide for future developers is nearing completion.

All this related development has kept Review Bot on the back-burner for a lot of the term. To give you an idea of Review Bot’s current state, here is an artists rendering of the progress I’ve made:

What Review Bot can accomplish at the moment

All right, I might be selling myself a little short with that picture. While it is true that Review Bot can’t actually analyse any code yet, progress should be quick now that Review Board has the features needed to support it. By the end of the term Review Bot should be automatically analysing Python code with the pep8 style checker. Some features, such as allowing tools to analyse the entire code base and not just the modified files, had to be dropped – but I’m still happy with how the final product will look.

In Closing:

I really can’t stress how happy I am to be participating in this program, and I recommend it to any students given the opportunity to participate. I’d like to thank the UCOSP steering committee for organizing everything.  Also, a very big thank you to the Review Board mentors: Christian Hammond, David Trowbridge, and Mike Conley. These guys have made this experience awesome, and I really appreciate all the time and effort they have committed to the program.

Thanks for bearing with my artistic “ability”,

Steven MacLeod

UCOSP Blog Post – March 12, 2012

My name is Wei Lu Liu. I joined the Review Board team this semester as an undergraduate computer science student from Simon Fraser University. Gaining some open source development experience is what drove me at first, but being part of Review Board is far more than this. Throughout our development, we employ

- Git for revision control

- Google Groups/Code/Wiki/Blog for administration and reporting

- IRC/PasteBin for instant Q&A and discussing

- Review Board !!

Here comes the unique and interesting experience about working on Review Board: we are using Review Board itself in our development, which gives us first-handed feelings and feedback. With the “free” feedback, we can make Review Board better satisfy the developers as well as ourselves. With the goal of making our own lives easier, everyone in the team seems to have great interest and motivation.

So far I have had my hands on three bugs or projects. I would like to discuss my experience about each of them.

*  Adding “confirm password” fields to Review Board installation

The Review Board installation process has a couple of pages that ask the user to enter a new password, but the users do not have the chance to confirm their password. This project is a little different from others, as it is majorly about PyGtk. Without a whole understanding of PyGtk, I got stuck right after I added the “confirm password’ fields to the pages. I was trying to find some functions in that page class that validate the new field. I spent several hours but was still blocked. It is lucky that my mentor pointed out that the validation should be a widget. It turned out he was right, and we quickly worked it out.

This small  bug fix taught me that the Review Board is a quite big project that utilizes many third party packages like PyGtk. Although I considered myself good at Python, it is far from enough to handle the whole project.

* Tracking the users that change the review request

This project is about the product itself. It covers most of the main features of Django. The first thing I was faced with was to alter the database, more specifically, to add new fields to the tables to store the information and alter the restrictions and relations among the fields and tables. Django abstracts a table as a class, but adding a field to the table does not simply equal to adding a variable to the class. We have to make it happen to the real database using a tool called Django Evolution. I got stuck here again. I tried many tutorials online but just could not make it work. After consulting our mentors, I solved the problem and found that it was because I wrongly understood what Git does. In our case, Git only controls the source file types such as .py/.html/.js. The database file, .db typed, is not in its charge. So when I switched between branches the database file stayed the same. I learned that the details are important; I need to get more familiar with these software development concepts.

Altering the database successfully made it possible for me to quickly realize the user tracking features.I thought the project was about to finish, until our mentors raised some concerns: what if multiple users are making changes to the same review request? Whose change gets published? This is the famous race problems in transaction control. We decided to have a banner to tell the user not to confirm if there was another user editing the same page. This experience taught me that testing is so important in software development. Without the help from my mentors, I may think I was done with the project. Review Board has a unit test for every app, running and analyzing them is extremely import if I want high quality work. I was quite interested in those test cases and would see if I could learn writing some by myself.

* Weekly email updates

“Finding out what’s been happening on Review Board isn’t always easy. It might be worthwhile to have users be able to opt-in to weekly email updates from Review Board that tell them useful things about the groups that they belong to.” This is the idea why we want this feature. Django actually has really good email support. Review Board extends it and have specifically customized email methods itself. You should have realized that this project is more of administration level. I will write an admin command to realize it. I am just starting with it, and it looks interesting for me.

It is only one month left in this semester. I feel that I wasted a lot of time when I got stuck. I thought too much but did not ask enough questions. I have the shortcoming that I always want to have some basic idea before I ask questions. However, it usually turns out that I can not even have correct basic ideas if I just keep thinking and not asking, since the industry project is way more complex than the academic projects we do at school. Fortunately I have really helpful and friendly mentors and students in our team. After asking a couple of stupid questions, I got myself more familiar with the whole project. Now I can ask more meaningful questions after some self-exploration at first.

I am really grateful to UCOSP. I think it is a really good program for undergraduates. I did some internships before, but I felt that I could learn so little about the details of software development there. The internship employers, at least in my case, tend to put us on the works that are less risky for us to do. After all, they have too many things to consider, and we usually could not learn as much as we want. The UCOSP program is different, since everyone in the team have the same interest and goal: to learn and to contribute. In our case, the Review Board, if we can make it a better tool, it would be for the benefit of all the developers using it. Due to this reason, I think UCOSP is a really good program that compliments our academic and internship experience. I hope this program can continue evolving and benefiting more and more students.

Cheers,

Wei Lu Liu (Willer)

UCOSP Blog Post – February 27, 2012

I am Ruirong Chen and currently in my last term of pursuing Bachelor of Computer Science in University of Waterloo. I joined the Review Board team around two month ago as a part of UCOSP program. The Review Board is a great tool for web-based code reviews and offers a smooth interface and a variety of extensions. I picked Review Board because I think it would be a great way to gain more knowledge with Python and the Django framework. In addition, as I am more interested in web front-end development, I feel like it would be a great fit for me.

I participated in the Code Sprint and started off with several small bug fixes and an easy project. After finishing my first project, I quickly dive into a much more complex project which would require me to understand the core components of the Review Board. It involves understanding how the system of comparing two files (diff) works in Review Board, from generating the diffs in the backend to actually rendering them in the front end. Once I have a grasp of how the system functions, I can implement a diff system for other non-file-based information such as the description field of code review. This project would serve as a nice introduction to the inner working of review board since it touches a bit of everything in the program stack.

As I gradually pick up more and more piece of the code base, I realize how complex it is in the backend to build up something that’s easy to use and start to appreciate the beauty behind the Django framework, which is a popular web framework for building up dynamic websites. It not only does a lot of the grunt work in backend development for web developers, but also provides a rich, flexible template language that enables developer to quickly build up web pages in the front end. The more I dive into the code base, the more I am amazed by what it is capable of.

In addition to the Django framework, Review Board also utilizes several other open sourced libraries and tools, such as Djblets, jQuery and Less, to help simplify the development process. This not only poses interesting challenges since I need to work with several external components when I am developing for Review Board, but also makes up for a great learning experience as I am exposed to new technologies and workflows.

I am excited to learn more about the systems and technologies behind Review Board as I develop and contribute to it. It is definitely a rewarding experience for a web developer and I really appreciate UCOSP for organizing the program and make it possible. Besides, Review Board itself is a great tool to use among software development teams and I am proud to be one of its contributors.

Ruirong (Jim) Chen

UCOSP Blog Post – February 13, 2012

We all know Review Board is great for allowing a distributed team to effectively ensure only high quality, standards complaint code is integrated into the end product. But what else makes Review Board great?

From my experiences on the team I can safely say it gives new developers a leg up on the learning curve when starting. I was able to leverage Review Board to quickly learn exactly what  I should, and should not be doing in my code. Through each new code review I was determined not to repeat the same mistakes that were made in my previous review. The intuitive review interface clearly communicates these mistakes back to the developer, allowing them to make the changes and learn from their mistakes.

Review Board also acts as an effective communication platform for any distributed team utilizing it, as it allows the entire team to see the progress of each component, and add their own input to how the end solution should look. This is very important, as communication is one of the toughest aspects when working with a team not based in one site.

I started off in the Code Sprint by getting my feet wet with a couple bugs and a small project. Due to the fact that I haven’t used Django recently, and that the Review Board code base itself is quite large and complex this meant I was in for quite a steep learning curve. I have now moved on to my second project, which itself comes in two parts. The code based part of the project is a rating extension which will allow users to leave anonymous feedback on the quality of the code reviews they receive, while also tracking their own aggregated results over a period of time. These results will allow users to reflect on their code reviewing habits, and make improvements if necessary. This project will be leveraging brand new scripts to simplify the extension building process, by tempting out the base code required for an extension to exist in a Review Board instance.

The second half of this project will involve writing documentation to guide others using these scripts on how to take their extension stub and turn it into a functional and integrated part of their Review Board environment. A lot of developers get the idea that by adding this “one feature” to the project, it will vastly improve their experience using Review Board. This has many problems however, because if every one of these features are added they will start to bloat the code base, making Review Board run slower and harder to maintain. This also requires developer hours, which could be spent working on other features which would benefit more than just a handful of developers. Adding this “one feature” also runs the risk of alienating other developers with features or functionality they don’t need, want, or understand. The great thing about extensions is that they allow these developers requesting the feature to easily create and add the feature to their own instance of Review Board, without impacting everyone else’s experience.

It’s great to be able to work on such a far reaching project like Review Board, and know my improvements are being used all across the world. The project could not be nearly as successful without the big effort put in by each of the mentors. Their ability to offer prompt code reviews, technical guidance, and project ideas really makes working on Review Board a lot of fun. Due to their efforts, more time is spent in the learning or “eureka” phases of development than stuck in a frustrating roadblock.