Author Archives: sampson.chen

About sampson.chen

Computer Science student at University of Waterloo!

To You, New UCOSP Student at Review Board

So you made it into UCOSP and Review Board; Woot! Exciting times! What’s next?! You are already in a fantastic place for having chosen Review Board: here you will spend the next four months learning a ton about Python, Django, Javascript and, most importantly, code reviewing and industry best-practices.

I believe Review Board is the best project in the UCOSP program, but not for my bias of having been a contributor for the past few months: here, you are given the rarest opportunity of having mentors review every line of code you produce, and teach you how to do things better whenever possible (and who better to review your code, than the people who are passionate enough about code reviews to be part of Review Board?). I can think of no other way to help you learn and grow faster as a programmer than to tackle relevant and interesting problems and receive constant feedback from others with more experience.

Now that you are super pumped about your time here, some advice I wish I could have given myself at the start:

Get started:

The key sticking points are:

  1. setting up your environment,
  2. getting your first patch landed, and
  3. sinking your teeth into your first project.

Everything is going to appear totally confusing and insurmountable at first. That’s okay! Breathe! Take little steps but make sure you keep pushing forward through the difficult parts; and ask for help if you get stuck! Once you get a tiny bit of bearing and traction, you’ll immediately start having fun: time really flies once that happens.

Smart time-management:

If you only have 30 minutes to an hour that day to work on your project – save it; put it toward another task you must fulfill. Pool together uninterrupted three-to-six hour periods when you can remove all distractions and just get in the zone for some serious Review Board work.

You’ll be more productive overall, more efficient, less stressed, and have more free time left later. Win-win. (Additionally, talk to Mike Conley about time management: he will give you great advice)

Ask for technical help:

Google and StackOverflow are your new best friends.

Most generic problems with Python, Django and Javascripts you run into can be resolved with a little research or a quick question on StackOverflow.com, since it’s more likely than not that someone else has asked the exact same question as you before.

If you cannot find a solution (or at least somewhat promising leads) within 30 minutes, ask a mentor (especially if it’s related to reviewboard, djblets, or rbtools). They would rather that you stay unblocked.

Ask for non-technical help:

I flopped around for a while when starting my second project because I couldn’t quite wrap my head around the idea of hooks, and how they were used as part of Review Board’s architecutre. I felt a loss of motivation for not having a solid grasp on where to even get started.

Eventually I decided to talk to Mike about the trouble I was having. He helped me clarify the things that confused me, quizzed me on the concepts from code-reading to let me connect the dots in my head, and worked out a simple, step-by-step plan to get me started.

What followed were the most productive weeks of my time at Review Board. I wish I’d known to ask for help sooner; removing the mental block to get started and just “dive in” will get you sooner to the “having fun” part. It makes all the difference.

Spend time reading this blog

Previous students of UCOSP have left little gems of posts that would potentially save you a lot of frustration and energy. We went through the same things you are / will be going through. Take some time to learn from the mistakes we made, and it will save you more time in the end!

 

Happy hunting, and have a great term!

Advertisements

UCOSP Blog Post – sack and other developer shortcuts

Introduction:

Hello! My name is Sampson Chen. I just finished 3rd year Computer Science at University of Waterloo and I am currently on a Fall co-op term with Research In Motion.

Coming from a mostly Windows background (and working solely with IDEs for school work), participating in UCOSP + ReviewBoard so far is providing me with invaluable exposure to industry tools and practices such as Linux, bash, vim, git, Python, Django, and code-reviewed / test-driven development. The amount of material to learn may seem overwhelming, but it is also exhilarating to feel so empowered from learning how to use new tools. I find it especially exciting to contribute to a project whose purpose & vision you can believe in.

“sack” – a shortcut tool for ack / grep:

While I was learning and working with the Review Board codebase (reviewboard + rbtools + djblets) in Linux and the bash shell, I find myself having to rely on the grep tool constantly to help navigate my way through the code. It was not long before I realized that I spent a lot of time on:
1) typing out the file paths from the grep search results,
2) typing out the same flags for grep every time, and
3) moving between directories to initiate a search from the codebase root, and then having to move back to the directory (pressing tab a number of times) that I was originally working in:


(“arggghh!!!!!”)

Mental context-switches are expensive. Often, by the time I refocus my attention to actually typing out the long file paths (at times making silly mistakes with cd like in the above screencap) and open the needed files, I have already lost my train of thought. The time cost is now greater than just the 30 seconds from keying out a long file path.

This issue led me to thinking: “Gee, it sure would be nice to have a tool to handle these menial tasks automatically for me”. The search for such a tool on Google (and among CS friends better versed in Linux) yielded no results. So I decided to just write a short script for it: Can’t possibly take that long, right?

I originally started with sgrep, as in “s(hortcut)grep”. However, upon discovering ack (http://betterthangrep.com/), the replacement for grep, I decided to write sack – “s(hortcut)ack” instead.

(sack on github: https://github.com/sampson-chen/sack)

Here is how sack can save you valuable time and mental effort:

Similar example to the one before, but using sack instead:

Notice that it uses preset flags (“-i”) for the current profile (“RB”) and performs the search under a set of pre-specified directories.

(If you prefer not to use any preset flags / search directories, there is a empty profile called “no_profile” for using sack exactly the same way you would with ack / grep.)

Now for the fun part! See the little tags that prefix the search results? sack adds those to the search result of ack: instead of typing out a long file path to access the 59th result, simply do:

user@linux:~$ F 59

on the prompt and it will open the correct file with vim, and then even go directly to the line corresponding to the search result for you:

Note that whenever you perform a search in any terminal with sack, you can use the shortcuts in all other terminals (including new ones). So now you can use one terminal to keep the search results open for reference, and use other terminals to open the files of interest, via shortcuts!

Huzzah, productivity!!!

Using profiles is easy. For example, here’s switching profiles in sack:

There are a number of other things you can do with profiles, such as renaming a profile, setting preset flags / search directories for a profile, adding new profiles – these are documented on the github page for sack (and sack –help on the command line).

I shall leave the rest for you to explore. My hope is that this will make your life easier when navigating around a large codebase such as ReviewBoard’s. If you have any suggestions on how you would improve this tool, please don’t hesitate to let me know! =)

P.S. Other shortcuts for common dev tasks on ReviewBoard: https://reviewboardstudents.wordpress.com/2012/09/23/convenience-scripts-shortcuts-for-rb-development/ (updated)

P.P.S. It was pointed out to me that the install one-liner for sack on github was broken. This has now been fixed.

Status Reports! (Sept 30th; UCOSP Code Sprint)

Sampson Chen

Currently

  • Working on fixing webapi/tests.py related to the ship-it=0 bug (see roadblocks below)
  • Learned about using virtualenv / git to change the environment for developing on a release branch.
  • Posted my first review-request today, huzzah!

Roadblocks

  • Stuck on a weird LocalSite error when running the ship-it=1 test using fixtures.
  • Had a weird problem where the prepare-dev.py script was creating the db file in /reviewboard/reviewboard/, instead of /reviewboard/ – Steven helped me find a work around for it.

Next

  • Look into more EasyFix Bugs; these give helpful insights into the Django / RB architecture.
  • Get started on thumbnail renderer project

Questions

  • If fixing 1 issue causes changes to multiple source files, is it possible use 1 review-request to collect all the diffs? Or is it supposed to be 1 review-request per diff, so we have multiple review-requests tied to 1 issue on a bug tracker?
  • How do we actually add to the data set when updating fixtures ( http://www.reviewboard.org/docs/codebase/dev/unit-tests/fixtures/#updating-fixtures)? I am under the impression that we don’t directly manipulate the data via the web interface once we load the data in.

Tina Yang

Currently

  • Waiting for the ship-it on my very first code review for review board 😀

Roadblocks

  • Mike, David and Steven helped me lots on my roadblocks and I’ve learnt that (correctly me if I’m wrong)
  • Django will recompile/restart the server if any of the model/core python logic is touched, but not when templates are modified
  • file.fragment is cached as a string
  • Need clarifications on the Inline File Attachment Project (eg. Which part of the description overlaps with the thumbnail renderer? What will the typical workflow for using this feature be? An use case or user story would be very helpful)

Next

  • Looking into more EasyFix Bugs and clarification for the project

Questions

  • How many ship-its do we usually need for code reviews?
  • Can we peer-review other students code (in additions to mentors reviews)? Would you consider that useful?
  • Should we always merge in new changes constantly? Even if we have to submit another revision of the code, (meaning that the new revision will contain other people’s new changes)?
  • Is there a way to subscribe to the repo and get email notifications for who committed what?

Allyshia Sewdat

Currently

  • With some help from our mentors, set up virtualenv and created a 1.6.x branch for bug fixes (had to resolve some issues there).
  • In reproducing a bug, ended up investing some time learning about the work flow of uploading diffs, etc. to reviewboard
  • Investigated the bug by reading through some code, located the general area of the fix.

Roadblocks

  • Hoping to get some feedback/guidance from one of our mentors on whether I have correctly understood how the ReviewBoard API works. That will help me push forward with my fix.

Next

  • Submit a fix + review request for this bug and get some clarification for the project

Questions

  • None at the moment; more will come out today during the day.

John Sintal

Currently

  • At the sprint, getting acquainted with codebase.

Roadblock

  • Stuck with a regex “easy fix” bug

Next

  • Work with Mike on the bug, submit and hopefully get a shirt

Questions

  • none atm

Aamir Mansoor

Currently

  • Fixed an EasyFix bug and got that merged in
  • Started another EasyFix bug (Increase hit target for expand/collapse button) and making progress through that

Roadblocks

  • None

Next

  • Finish “Increase hit target” fix and get that reviewed and merged in

Questions

  • None

Michelle Chuang

Currently

  • Trying to pass unit tests for my second bug fix. (Well, technically first because the other one wasn’t really a bug.)

Roadblocks

  • None.

Next

  • Looking into what code I should be familiar with to start working on Pluggable UIs.
  • Talking with Amir to figure out which file types we will start off with for our projects.

Questions

  • None.

Wesley Ellis

Currently

  • Working on landing a patch for Reviewbot avoiding the need to hardcode the reviewboard url

Roadblocks

  • None

Next

  • Try writing some unit tests for ReviewBot
    Start brainstorming how to report worker status

Questions

  • How many roads must a man walk down before you call him a man?

Karl L.

Currently

  • Finishing up a patch that adds validation for repository issue tracker URL.

Next

  • Start work on my project (SSH key association)

Roadblocks

  • None.

Questions

  • None. All answers are available at the code sprint.

Jesus Zambrano

Currently

  • Working on my project. I’m trying to change the logic of review_header.html to have both “publish” and “draft” boxes hidden on the window.

Roadblocks

  • None

Next

  • Use jQuery to hide/show the boxes to avoid a post_request full reload.

Questions

  • None

Meeting Minutes for September 23rd

Announcements:

  1. Upgraded our version of jQuery: so keep your eyes out for weird behaviour in ReviewBoard over the next few days. (Please report bugs!)
  2. Added a more specific list of automated static analysis projects to the ideas page. So if you were interested in that project, you should check it out.
  3. Making good progress on the basics for pluggable UIs, so we’ll try to get that in before anyone begins their work on it.

Project Assignments:

  • aam1r: Pluggable UI*
  • michee: Pluggable UI*
  • slchen: Thumbnail Renderers (Pluggable UI* + Inline File Attachment)
  • yangtina: Inline File Attachments
  • Allyshia: Automated Static Analysis**
  • tahnok: Automated Static Analysis** / ReviewBot
  • jzamb: Fewer Page Reloads
  • johns187: RBTools / Client Scripts
  • Karl-L: SSH Key Association

* Pluggable UI will be broken down into the individual file types: e.g. plaintext, XML, etc. We’ll assign one for each Pluggable UI student.

** The static analysis: look at the subprojects that smacleod posted, and talk with him about which ones you want to do.

Questions / Answers / Tips:

Tip: We typically don’t go around more than once unless it’s really necessary. If you have questions, you should ask them on your turn.

Tip: Typing out questions in advance during Q&A helps keep things going.

Q: How to: write minutes for meetings?
A: After the meeting:
– Look at the log
– Write up the salient points
– Boil it down
– Examples: https://reviewboardstudents.wordpress.com/category/meeting-minutes/

Q: Is the thumbnail renderer’s description listed somewhere? or is that a pluggable UI?
A: We have two classes. One defines a review UI, which handles rendering a page and loading in comments and such. Another defines a renderer for a file type to provide a thumbnail. It’s related, but it’s its own class.

Q: Do we have pluggable UI for any file type at the moment?
A: One for screenshots is up for review, one for images (as file attachments — replacing our screenshot-specific support) will be up soon.

Q: Are we assigning pluggable UIs now or at the sprint?
A: We need to figure out which make sense first. There are some we know we probably want, like plaintext, XML, .doc. For now, you guys can look at the reviews and get a feel for the architecture, get a sense of what is being done, and how – both server-side and client-side:
http://reviews.reviewboard.org/r/3337/
http://reviews.reviewboard.org/r/3341/
http://reviews.reviewboard.org/r/3342/
– Come to us for questions
– We’ll determine your file types and give them to you soon

Q: I may have found a bug and mentioned it in IRC last night, how I should I go about reporting / assigning the bug? Do we use google code review for that and review.reviewboard.org for code submission reviews?
A: Bug reports should go on google code http://code.google.com/p/reviewboard/issues/, but talk to us first:
– Use reviews.reviewboard.org for code review
– Only use Google Code for the wiki (sometimes) + the bug tracker.

Q: Where can we find more information about the project to which we are assigned?
A: Talk to us about it. There’s no docs anywhere. This is all bleeding edge!

Q: Every time we sync from upstream, do we have to go through all of the installations again for djblets / reviewboard / rbtools?
A: You shouldn’t have to do any installations in general on those.

Q: Overview of the the code review process at RB?
A: Starting with your git clone:
– Create a feature branch, and work on your bug / project. You commit to that branch, merging in updates from master periodically
– Then, when you’ve got something you’d like people to look at (it doesn’t have to be done – review early, review often), use post-review to toss it up on RB
– Bug us to look at it. We give you feedback, you make corrections / revisions
– Eventually, we give it a Ship It, we take your patch, and commit it to master.
– If it’s not done, though, say so in the description and say what’s left
– If possible, break your project up into distinct parts that can go in individualyl without breaking things (Smaller, atomic review requests are good, if they can be managed).

Q: So as long as the patch doesn’t break existing functionality for other people, we can submit patches for a feature that’s still incomplete, as long as the remaining items are listed?
A: Your patch, when landed *might* break other people’s. That’s sort of the challenge though – have to watch the tree, and get a sense of what people are working on. If you think you and another person are touching the same code, coordinate. In some occasions, we may just commit to a branch and not master for such projects (Someone else [i.e. a mentor] would create a branch on the main repo, if necessary – but you’ll never need us to).

Q: What was meant by: “Someone else would create a branch for me on the main repo, if necessary – but you’ll never need us to?”
A: You can do all your work for your project on your own branches. There’s nothing you *need* upstream, branch-wise. What was meant was that: if you’re working on a large project, and getting pieces of it in, we may decide not to commit anything to master until it’s all done; but we may decide to put it in a branch, just to make sure we don’t lose track of that work

Q: How do we host ReviewBoard on our local machine so we can test our code changes. Any guidance/docs that I can go to?
A: Getting Started guide should cover that. You want to run the ./contrib/internal/devserver.py script (see http://www.reviewboard.org/docs/codebase/dev/getting-started/#development-web-server)

Tip: You should all be able to access your local instances of Review Board and tinker with them. We want you to be able to do that before you reach the sprint. If you still need help getting that set up, please let us know, and we’ll dive in and help.

Q: The static analysis project “Implement manual triggering of Review Bot Tools” : is it purely a UI project? I understand that adding analysis tools is part of another project, so is this project really just adding an interface for manual trigger?
A: Mostly an interface. It might involve some other more backend stuff, but that is secondary (like adding places you can hit with ajax to trigger a review). It adds the UI to support manually triggering the analysis, and the corresponding backend.

Q: I am confused on how bouncers work. when I disconnect from IRC, the bouncer puts me as away. but when I come back, I don’t see any of the conversation that I have missed. Is it supposed to be like that?
A: Nope it is not. We’ll troubleshoot this after the meeting. Speak to ChipX86 regarding this if you still have issues.

Q: Fork and branch, same meaning?
A: Not exactly. Fork is an independent clone of an entire repository. Your local clone is a “fork”. (Also see http://stackoverflow.com/questions/3329943/what-is-the-difference-between-branch-fork-fetch-merge-rebase-and-clone-in-g)

Tip: If your project is still fuzzy and you don’t know how to tackle it, ask us for more information. And working on EasyFix bugs is a great way to get warmed up to the code.

Convenience Scripts / Shortcuts for RB Development

I started learning shell scripting recently and thought it would be a good idea to build a list of scripts and shortcuts that would make developing in Linux faster.

Here’s what I have so far. Would anyone else be interested in collaborating to grow this list?

https://github.com/sampson-chen/sampson-chen-util/

I’m okay with either using git to collaborate, or just through comments.