5 Tips for your RBTools workflow

Christian Hammond 1 Comment

If you’re a Review Board or RBCommons user, you’re probably familiar with RBTools, our handy set of command line tools for working with Review Board. (If you’re not using RBTools, I’m going to tell you how to get started with it in a bit.)

You’re probably most familiar with rbt post, or post-review in older versions. This is the tool that helps you quickly get a change onto Review Board, or to update an existing review request. It’s pretty handy, but how much do you really know about it? Or about the other commands included with RBTools? (Yes, there are others!)

I’m going to show you five of my favorite tips and tricks for RBTools that you may not know about.

5. Opening a browser after posting with rbt post -o

When you run rbt post, you usually get something like this:

$ rbt post
Review request #123 posted.

https://reviewboard.example.com/r/123/
https://reviewboard.example.com/r/123/diff/

Those links for opening the review request or diff are useful, but you can save yourself a step by having RBTools open your browser for you. Just pass -o to rbt post, like so:

$ rbt post -o

Your browser of choice will open, ready for editing. Want to do that automatically, every time? Add this to your .reviewboardrc in your home directory:

OPEN_BROWSER = True

4. Check your open review requests with rbt status

At some point or another, you’ll want to see what review requests you have open, either as a draft or currently pending review. I myself need to do this at times to help me remember if I’ve already posted something for review.

Sure, you could dig through the dashboard and check. That works great, but it means leaving the command line. That’s where the rbt status command comes in:

$ rbt status
   r/6676 - Add release notes for Review Board 2.0.12.
   r/6258 - Add release notes for Review Board 2.1 beta 1.

rbt status will show you all open review requests for the current repository – their IDs and their summaries. Pass --all and it’ll show you all open review requests across all repositories.

3. Attach files to review requests with rbt attach

Review Board makes it pretty easy to drag-and-drop files onto a review request in order to quickly upload them, but it does mean having the file manager and web page open. If you’re a command line junkie like me, you’d probably rather avoid that as much as possible.

rbt attach will let you upload a file to a review request with a single command. Just give it the review request ID, the file to upload, and an optional caption, and you’re done.

Let’s try it.

$ rbt attach 123 screenshot.png
Uploaded screenshot.png to review request 123.

Want to give it a caption?

$ rbt attach --caption "UI screenshot" 123 screenshot.png

2. Apply a review request’s diff to your tree with rbt patch

If you’re an open source developer, or you like to thoroughly test other people’s patches as part of reviewing their code, then this tip is for you.

rbt patch pulls down the latest patch (or a specified revision) from a review request and applies it to your tree. It can even create a commit for that patch, if using Git or Mercurial, by running rbt patch -c.

$ rbt patch -c 123
Changes committed to current branch.

We use this when accepting contributions from our own Review Board server. After a thorough review, we run rbt patch -c, edit the commit message as appropriate, and push it.

As a bonus, this will append a Reviewed at <url> line to the bottom of the commit message. If you’re using repository hooks to auto-close review requests (admins, see the “Hooks” link next to a repository in the administration UI), pushing this commit will take care of closing that out for you.

1. Easily update review requests with rbt post -u

If you’ve been using RBTools for a good long while, you’re probably used to passing -r <ID> to rbt post, in order to tell it which review request to update. This means having to look up the ID and making sure you don’t type it wrong.

In RBTools 0.6 or newer, we have a much simpler solution. Just pass -u. RBTools will automatically find a matching review request, asking if it’s not completely sure it’s a match, and update it for you. Let’s compare:

$ rbt post -r 123

vs.

$ rbt post -u

It’s much nicer. Get in the habit of using -u. It’s the wave of the future.

What if I’m not using RBTools?

Use it!

Seriously, RBTools is the best way to get the most out of Review Board. You can follow our installation instructions to get started. We’ll soon be announcing new installers to make this easier.

Learn more

The RBTools documentation is a great resource. You can learn about all the RBTools commands, our Python API for interfacing with Review Board, configuration options, and more.

We’ll be posting a new batch of tips and tricks for RBTools soon, plus some advanced Git and Review Board tips.

If you’re not already on our mailing list, subscribe today to keep up with the latest releases, tips, and strategies.

And now, we’d like to leave you with this:

Isn't it cute?

Read More

Practicing effective self-review

Christian Hammond 5 Comments

It’s nearly midnight. The end of a long coding session. Your code seems to work pretty well; all tests pass and it doesn’t blow up when you use it. It was a hard-fought battle, and you’re feeling great! The only reason it’s not already in the product is because your team has fostered a culture around code review.

At this point, you may be feeling ready to just post your code for review and move on to something else, waiting for the feedback to roll in. Is that what you do? Well, stop it! You’re only making things harder for yourself.

Your first reviewer should never be another person. It should be you!

Self-review saves time and increases quality

A typical code review cycle can easily take anywhere from an hour to a couple days. If your code isn’t perfect and your team is thorough, you will go through at least one cycle with at least one developer.

Likely more, since developers are often distracted by the tiny problems (style issues, typos) and ignore the larger problems (algorithmic issues, design flaws, bigger picture tasks) when reviewing. Oh they’ll get to the larger ones, but it might take another full review cycle or two.

Self-review can save you at least one cycle. Maybe more. The other reviewers will get to spend more time focusing on the more interesting issues instead of the little flaws, making them more likely to want to review the code. Plus, it’s far easier to convince people to look at your code when they think they’ll get through it quickly.

Let’s summarize the benefits:

  • Your code lands faster.
  • The feedback is more useful.
  • People will think you’re awesome for not wasting their time and will bake you cookies as thanks. Probably.

Now let’s talk about how to do self-review well.

ProTips for self-review

You may be used to reviewing other people’s code, but it’s going to be a bit different reviewing your own. You’ve already built up a mental state of how your code works, and won’t be reading it for the first time. You’ll have a bit of a blind spot that other reviewers won’t have, making it more difficult to see the flaws.

You can do something about that. Here are a few tricks we’ve learned.

  • Review your code in your code review tool, not your editor.
    This will help put your brain in review mode, and take you away from your editing environment. This little context switch can be enough to help catch problems you wouldn’t have seen before.

  • Wait to post the code for review.
    If there’s no rush to land the code, wait a day, work on something else, and then come back to it. You’ll have paged some of it out of your head by then. You might be surprised by what you notice.

  • Re-learn, don’t remember, how your code works.

    Pretend you’ve never seen your code before. Read the code line-by-line, character-by-character. Don’t make any assumptions. You may catch some confusing variable names, documentation, or bad logic this way.

  • Use checklists for code review.

    Keep a checklist of problems to look out for. Your team’s style preferences, possible edge cases, possible memory leaks, exception handling… Anything you can think of that may apply to your changes, or that of your team’s. This will help take a load off your sleep-deprived brain.

  • Read documentation, comments, and displayed text out loud.

    You should read through every error message, every piece of documentation, and every comment out loud. See if it makes as much sense as you thought when you wrote it. If it helps, try explaining it to a rubber duck.

  • Take the opportunity to write more documentation.

    If your code is low on documentation/comments, this is a good time to write some. Go into detail, cover corner cases, or anything that may be valuable to another reviewer.

    By being forced to write about your own code as you read it, you’ll not only help ensure your code does what you expect, but you’ll help other reviewers get through a review cycle much faster.

    This also works pretty well for unit tests.

These are a few of our tips we use when reviewing our own changes. What are yours?

Read More

RBTools 0.6.3 is released!

Christian Hammond

Today’s release of RBTools 0.6.3 fixes a handful of annoying little bugs across Git, Mercurial, Subversion, Perforce, and ClearCase. If you use any one of these (and there’s a good chance you do), it’s time to upgrade!

In past releases, failed post operations could leave behind incomplete review requests, which wasn’t always obvious. RBTools will now print out the review request after a failure, making it easier to fix things up without creating a new review request.

We’ve also fixed a bug in the Python API for Review Board that resulted in errors when performing HTTP DELETE operations.

See the release notes for the complete list of fixes.

While this is a fairly small and bug-oriented release, we’re happy to announce that RBTools 0.7 is coming soon, with several new features and native installers for Windows and MacOS X!

Read More

Auto-closing review requests when pushing changes

Christian Hammond

We’ve launched a new feature today for simplifying your code review workflow.

If you’re using GitHub, Bitbucket, or Google Code, RBCommons can now automatically close your review requests when you push your commits to your repository, making use of the service’s “post-commit” hooks. You’ll no longer need to click Close -> Submitted, saving time and keeping your dashboard clean.

 

Usage is simple

Once you’re set up (and we’ll go into that in a minute), all you need to do is include the following in your commit message:

Reviewed at https://rbcommons.com/s/<your-team>/r/<id>/

Or:

Review Request #<id>

Just commit, and your review request will be automatically closed, along with a message containing the commit revision and which branch it was committed to.

 

Setting this up

Setup depends on which service you’re using for your repositories, but we’ve worked to make it pretty simple.

We’ve added some new buttons to your Team Administration -> Repositories page. You’ll see a “Hooks” button next to any supported repository. Click that, and you’ll see instructions on turning this feature on for your repository. In just seconds, your repository will be set up!

This feature is still new, but has been undergoing testing for several weeks. If you hit any snags, let us know and we’ll help get you going.

Read More

RBCommons and this week’s security news

Christian Hammond

This has been an interesting week on the Internet, security-wise. A vulnerability in the Bash shell (named “Shellshock”) was announced that allows remote execution of code on unpatched servers with certain configurations. Separately, an undisclosed vulnerability in Xen forced AWS and Rackspace to announce mandatory reboots of many of their customers’ servers. (See Amazon’s announcement and Rackspace’s announcement for more details.)

We’d like to give an overview of how all this is affecting RBCommons and, in turn, you.

We keep a close eye on all security updates available for the software and libraries we use, and are quick to patch our servers as fixes roll out. We’ve also performed many tests to ensure that malicious Shellshock HTTP requests do not impact us. Your data is safe.

Some of the services we use were affected by the mandatory AWS and Rackspace reboots. Earlier today, our mail provider, Mailgun, was temporarily down during the outage, which may have resulted in missing or delayed e-mails for those working on Sunday.

We’ve had a few rare DNS lookup failures, resulting in errors when visiting pages or otherwise interacting with RBCommons. There have only been four so far, and are temporary. If you see a random error loading a page, please just try again. We know this failure has affected a number of other AWS customers as well.

Tonight at 11PM PST, Amazon is scheduling some of our servers for a 6 hour maintenance window. This isn’t the first set of our servers to have undergone the mandatory maintenance, and we aren’t expecting any interruption to RBCommons during this time. However, we may be running at reduced capacity for about 20-30 minutes. We will be monitoring things closely.

If you are repeatedly hitting problems with RBCommons, please contact us!

We’ll post further updates if there’s anything to report.

Read More

Announcing unlimited repositories, PDF document review, and 30-day trials!

Christian Hammond

We’re very happy to announce some exciting improvements to the plans offered on RBCommons.

 

Unlimited repositories!

We’ve removed the restrictions on the number of repositories your team can set up. You can now add as many repositories s you need without hitting a limit, and at no additional cost. Add all your Git repositories, your forks, open source projects you contribute to, or whatever you like.

This applies to all plans from Starter to Enterprise. If you’re running on the old Micro 2012 or Small 2012 plans, you’ll need to upgrade in order to add unlimited repositories.

 

Upload your PDFs for review

We’ve also introduced support for reviewing PDF documents. Simply drag-and-drop a PDF file into your review request and wait for the PDF to be processed. Reviewers will be able to read through the PDF and comment on any section, just like they can already do with code and images today.

This feature is available on Medium and higher plans. If you’re on a smaller plan, you can upgrade to take advantage of PDF review by changing your plan in your Team Administration page. If you’re interested in trying out PDF review first, contact us and we will temporarily enable it for your team.

 

More time to try RBCommons

For the new teams out there, we’ve increased our trial period from 14 days to 30. This should give you more time to get set up and comfortable with RBCommons.

If you already have a trial subscription, we’ve already gone back and increased your trial to 30 days. You should have received an e-mail from us already. If not, please let us know.

Read More

Welcome to RBCommons 2.0!

Christian Hammond

It’s here!

We’re so excited to announce the all-new RBCommons 2.0. This is a major update that improves the service in so many ways that we won’t be able to fit it into one post. It’s faster, more reliable, easier to use, and full of polish.

Let’s go over a few of the new features.

 

A super-charged diff viewer

The first thing you’ll see in the new diff viewer is a new file index. At a glance, you’ll see not only what files were changed, but the complexity of the changes. The ring icons beside each file show the proportions of inserted lines, deleted lines, and replaced lines. The thickness of the ring shows how much of the file has been modified.

 

 

In most diff viewers, indentation-only changes look just like any other changes. You have to spend time checking to make sure that the content didn’t actually change along with the indentation.

Not here! Now, indentation-only changes are shown with little markers, which show exactly how many spaces or tabs were used. You won’t have to spend any time looking at whether the text in the line has changed. You’ll know at a glance.

 

 

We’ve also improved the quality of interdiffs (especially when dealing with merges), made moved line detection much smarter, and added an easy-to-use revision selector to quickly jump between diff revisions and interdiffs without reloading the page.

 

The new “New Review Request” page

We’ve completely rewritten the New Review request page, making it simpler to upload your diff and check it for errors. We’ve also gone further and added one-click posting of committed changes for review. Simply select a branch, browse through your commits, and click to post. In seconds, it’ll be up and ready for review.

 

 

Detailed change histories

When you’re working on large changes with several iterations, it’s important to know exactly what changed. We’ve always provided change histories, but they were pretty basic. Now, they’re anything but.

 

 

A slicker dashboard

We cleaned up the dashboard navigation and layout to help you jump between your incoming and outgoing review requests. The sidebar is less cluttered and confusing, and actually useful.

We’ve also addressed two of our most-requested features: Issue counts in the dashboard, and batch closing of review requests.

The Ship It column now shows the number of open issues filed against a review request, if any. These always take precedence over any Ship Its, helping you know at a glance if there’s any feedback you need to address.

 

 

The all-new “Select Rows” column in the dashboard lets you select multiple review requests and close them in one go. It’s very useful when trying to clean up your dashboard if you’ve gotten behind in closing review requests, or if a former teammate leaves. Simply click the pencil in the top-right of the dashboard to add this column, and drag it where you want it.

 

Lots more!

This post is getting pretty long, so we’ll wrap it up. Basically, a lot has changed, and we only touched upon a few of the features. Some others include:

  • Markdown support in all text fields
  • Faster posting of review requests from RBTools
  • Retina icons
  • New support for reviewing different text-based file attachments
  • Reviewers can close issues they filed
  • Easy download of files in the diff viewer

In the coming weeks, we’ll go into more detail on some of the more useful additions in this release, including tips and tricks on how to get the most out of RBCommons 2.0.

This was a pretty major release, so if you have any issues, please contact us immediately so we can resolve them!

Read More

RBCommons 2.0 is coming this weekend!

Christian Hammond

Updated Saturday, 1:50AM PST: We had some issues with one of the new servers, and had to roll some things back temporarily. This is extending our maintenance window. Hopefully nobody will be too badly affected, but we’ll be down until approximately 5AM PST.

 

We’re making a huge update to RBCommons this weekend. The site will be down for up to 4 hours starting Friday at 11PM PST, as we begin our upgrade to the all-new RBCommons 2.0.

This new update is based on Review Board 2.0, and brings some major improvements to the dashboard, diff viewer, review request change histories, performance, and more. A few of the new features you can expect include:

  • Fewer full-page reloads
  • Faster load times
  • Better, more accurate interdiffs
  • Markdown input for all text fields
  • Indentation markers in diffs
  • Smarter moved line detection in diffs
  • A nicer dashboard, which better displays when changes are approved, or if they have pending issues still open
  • Bulk-closing of review requests through the dashboard
  • Easy posting of existing commits on your GitHub or Subversion repositories, right from the New Review Request page
  • Faster posting of changes using RBTools
  • Better display of exactly what changed in updates to review requests
  • High-DPI icons for those on Retina or equivalent displays
  • Review of text-based file attachments

That’s just a few of the features that this release will bring. We’ll go into more detail after everything’s deployed.

On top of this, we’re moving onto much faster servers, which should help with some of the growth spurts we’ve been hitting lately.

So wrap up your work before this Friday at 11PM PST (Saturday, 6AM UTC). We’ll be shutting down the servers for up to 4 hours as we move to the new servers and begin the upgrade. It shouldn’t take the full 4 hours, but we want to allow for any issues that come up.

Read More

This weekend’s upcoming server maintenance

Christian Hammond

This weekend, we’re beginning a series of upgrades to our infrastructure that should resolve some stability issues we’ve periodically hit with our database server on AWS. It should also help to improve performance across the site.

This work will start Sunday, August 17th at 6AM UTC (that’s Saturday at 11PM PST for those in California). We’re blocking off two hours for the work, at which point the site will be down. It shouldn’t take nearly that long, though.

Going forward, we’re gearing up for a big update to RBCommons. Along with this, we’re planning some further hardware upgrades that should do a lot to further improve performance. We’re planning this for some time in the next two weeks. We’ll announce the details when we’re closer.

If you are worried that your team is going to be horribly impacted by this maintenance window, please let us know!

Updated Sunday, 12:33AM PST: Maintenance is complete, and we’re back up and running!

Read More

RBCommons 2.0 Beta!

Christian Hammond

A few months back, we finished up the release of Review Board 2.0, a major release offering features such as Markdown text editing, an improved diff viewer, easy posting of existing commits for review, open issue integration in the dashboard, and more.

We’ve been working to update RBCommons for the Review Board 2.0 codebase, and are happy to announce that the first public beta is ready! We’re trying to squash any remaining bugs, so please play around with it and report back to us.

A few important notes:

  • Your review requests and reviews will not sync between the beta server and rbcommons.com. Don’t use it for production work. Your data will be lost when we switch over.
  • The database is from August 4th. Your review requests and reviews made since then will not be there. This is normal!
  • DO NOT make any changes to your billing or cancel your team or user account on the beta! This will affect your main RBCommons account.
  • If you signed up in the past week and your team or user account is not available on the demo server, contact us, and we’ll get you set up.

With that in mind, give it a try at beta.rbcommons.com! Please send us any feedback you have.

We’re planning to switch over by the end of August. We’ll give a heads-up before we go live.

Read More