Posted by rtholmes on April 9, 2012
Wilson Yeung from Review Board writes:
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.
Posted by rtholmes on March 26, 2012
Steven MacLeod writes:
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
Posted by rtholmes on March 13, 2012
Wei Lu Liu writes:
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)
