ChangeLog: May 21, 2020 — Trial Limit Increases, New Releases, Student Wrap-Up

If you’re a regular follower of ChangeLog, you’ll notice we’ve gone from weekly to semi-monthly, and may be wondering what’s going on. Don’t worry, we’ll return to our regularly-scheduled ChangeLog in time.

We’ve been focusing heavily on wrapping up Review Board 4.0 development, testing things internally, and helping many of our support customers get out from under a backlog of internal support requests within their companies.

And just taking care of ourselves during a global pandemic.

So here’s some of what we’ve been busy with lately:

  • Increasing Power Pack and RBCommons trials
  • Several new releases (RBTools, kgb, and introducing babel-plugin-django-gettext)
  • Review Board 3.0.18 release preparation
  • Review Board 4.0 beta and RBTools 2.0 beta preparation
  • Wrapping up our semester with CANOSP students

Higher Power Pack/RBCommons Trial Lengths

We’ve increased the amount of time you have to give Power Pack or RBCommons a try. Now, when you download a Power Pack license, or sign up for a team on RBCommons, you have two full months to fully explore and use the products.

We’ve applied the new trial period to all existing RBCommons customers who are still in their trial.

If you’re a Power Pack user, and have a trial license, come talk to us for an extension.

New Releases

RBTools 1.0.3

Last month, we released RBTools 1.0.3, which was long overdue. We’re going to try to release RBTools releases more frequently going forward, and we have some good stuff prepared for 1.0.4 for Perforce users coming up soon.

We also have two new releases for some tools we use to help build Review Board: kgb, and introducing babel-plugin-django-gettext.

kgb 5.0

kgb is a Python module that helps with writing unit tests, adding support for function spies. This lets you spy on any function or method, whether in your own code or elsewhere, and track all calls made to the function and inspect the results of those calls.

It’s also used to override what happens when a function is called, mocking results or behavior. This goes far beyond the capabilities of Python’s own mock patching, and instead alters things at a bytecode level. Super useful when you want to fake results from urlopen, for example.

kgb 5.0 introduces support for:

  • Python 3.8
  • New spy assertion methods, providing detailed output when they fail
  • Support for spying on “slippery” functions (functions generated dynamically when referencing the function itself — common in some API-wrapping Python libraries, like Stripe)

babel-plugin-django-gettext 1.0

We use Babel to let us build modern JavaScript and export it to older browsers. Something Babel allows for is custom plugins to transform JavaScript, and we’ve introduced a new plugin to help us write better localized text.

babel-plugin-django-gettext lets us mark up strings using modern JavaScript tagged template literals (backtick strings) and convert them to use Django’s gettext localization methods.

When using the standard gettext support, lines are not allowed to wrap, meaning you end up with some very long lines of text to maintain, and if you want to include the contents of variables in the text, you have to wrap in this interpolate() call, which is a pain.

This plugin takes all the annoyance out of this. Instead of writing:

var s = interpolate(
    gettext('This is localizated text, and we can freely wrap lines how we want, or include variables like %(foo)s.'),
    {'foo': foo},
    true);

We get to write:

const s = _`
    This is localizated text, and we can freely wrap
    lines how we want, or include variables like ${foo}.
`;

Better, right?

If you use Babel and Django, give this plugin a try.

We’ll be releasing a new version soon with even better support for ngettext (used for strings that are based on singular/plural values) and combining with other tagged templates (like dedent).

Review Board 3.0.18 Release Prep

We’re getting close to a new Review Board 3.0.18 release. There’s a lot going into this one, but some highlights will include:

  • Preparation for GitHub and Bitbucket API/feature deprecations
  • Compatibility fixes for GitLab, Subversion, and Perforce
  • Improved API support for working with repositories
  • Faster SSH communication
  • Faster condensediffs for large MySQL databases
  • Lots of bug fixes

Expect 3.0.18 within the next two weeks.

Review Board 4.0 Release Prep

Work continues. We’ve had some people test 4.0 early, and found some regressions that pertain to extensions. We don’t want to release with those regressions in place, so we’re still iterating, but the good news is that the core product is looking pretty good now.

Remember, this release is a major architectural rewrite of the product, with equally major dependency updates, so there’s a lot to get right.

Meanwhile, we’re getting RBTools 2.0 ready for beta. This is meant to be used with Review Board 4.0, and features all the multi-commit review support, from posting changes to landing them. We’ll be shipping both at the same time.

CANOSP Student Wrap-Ups

We’ve talked before about the CANOSP student program we work with in Canada. Well, we’ve wrapped up our semester, and I can speak for the team when I say we’re going to miss working with this group.

By the way, if you’re looking to hire some strong developers coming out of college, we have plenty we can refer.

To wrap up their semester, they’ve put together some final demos of the work they’ve done, and we’d like to show them off.

Hannah Lin

Hannah worked this semester on a prototype for a new first-time setup guide for administrators, and some keyboard accessibility improvements in the diff viewer and modal dialogs, amongst other improvements. She’s also continuing on after the semester, working on a formatting toolbar for input fields.

Katherine Patenio

Katherine worked away on RBTools for most of the semester, fixing some bugs that shipped in RBTools 1.0.3, and completely reworking the rbt setup-repo experience (which we hope to ship in RBTools 2.0).

She also did a lot of work on investigating improvements to supporting users with different kinds of color-blindness, which she covers in this demo.

Monica Bui

Monica focused primarily this semester on keyboard navigation improvements in the New Review Request page (part of a big effort toward improved accessibility), and prototyping new guidance for filling in fields on a blank review request. We think that will pair nicely with work planned for Review Board 5.0.

Xiaohui Liu

Xiaohui worked on standardizing how we handle keyboard shortcuts, introducing a new registry on the page that anything can plug into to register shortcuts. This even offers a handy help screen, giving users an overview of all the keys can happily press to get their work done faster.

Xiaole Zeng

Xiaole’s projects covered help and accessibility improvements, such as adding a new Help menu to the top-right of every page (which could provide access to useful, relevant documentation), and making the review request infoboxes on the Dashboard less annoying and more keyboard-friendly. We’re looking to ship some of this in 4.0.

And that’s it for the moment

We’ll be back to a weekly format once we’ve gotten some of these releases wrapped up, and of course any time we have something pretty exciting to talk about.

In the meantime, if we can help with anything, reach out. You can also follow us on the community forum, Reddit, Twitter, Facebook, and YouTube if you want other ways to keep up with Review Board and Beanbag.

Read More

ChangeLog: April 2, 2020 — Catching Up

This is our first ChangeLog in several weeks. As you all know, the current pandemic has resulted in a lot of changes and hardships in the world. We’re doing fine here, and our team has stayed healthy and safe, if a little less productive than we’d like as we adjust and take care of our families.

David building a playground for the kids

Still, work never ceases, and it’s time to start keeping you all up-to-date again. Here’s a breakdown of what we’ll be covering today.

  • Support options for Review Board
  • Upcoming increases to RBCommons and Power Pack trial lengths
  • Upcoming releases of RBTools 1.0.3 and KGB 5.0.
  • Review Board 4.0 progress
  • New student demo videos

Getting Support for Review Board

More companies than ever are in full-on work-from-home mode, and this brings with it a lot of new work challenges that are, right now, often mixed with personal-life stresses.

We can help with at least some of that.

Our company offers support contracts for Review Board, which can be tailored to meet your company’s needs. We help with anything from basic Q&A and troubleshooting to custom builds and assistance with developing in-house integrations.

If you’re managing Review Board at your company, and are feeling a bit overwhelmed right now, please reach out. We can help. And we take support seriously.

Basic Support

Basic Support is pretty well-suited for smaller companies that need general troubleshooting, installation/upgrade assistance, or may have other questions.

We guarantee a response by the following day, but always aim for same-day (just depends on the support load).

Unlike our community support forum, all your support requests are handled privately on a dedicated support tracker, where you can manage tickets, provide confidential attachments, and more.

We don’t farm out our support to some outside party. We, the developers of Review Board, will handle your support. You’ll probably hear from me personally quite a bit.

Premium Support

This is a better option for the larger companies.

Or if you’re working on any in-house integrations or need priority bug fixes or need to use an older version of Review Board but may need some custom builds with fixes on occasion.

Or have some terrible emergency that needs to be resolved quick.

With Premium, there’s a same-day guarantee, 24/7/365. We’ll usually respond within an hour, especially if it’s an emergency. I will personally wake up and take care of your issue at 4AM if you need something.

So again, if things are crazy right now and you need a hand, contact us and we’ll talk options with you.

Increases to Trial Lengths

Since things are slower-moving right now (again, with the work-from-home status of so many companies), we want to make sure that you’re not in as much of a rush to evaluate either RBCommons and Power Pack.

So we’re going to be increasing the trial lengths of both from 30 days to 60.

This isn’t done yet, as we’re still preparing the codebases to change this over. In the meantime, if you’re a trial user of either, we’ll try to make sure to be proactive and increase your trial period manually.

If you’re already trialing either of this, contact us for a trial extension.

Upcoming Releases

RBTools 1.0.3

We’re finishing up this release now. It’s a big feature and bug fix release that we’ve been ironing out for a while.

The highlights are:

  • rbt land support for Mercurial
  • A much better commit editing experience (for rbt land and rbt patch)
  • Several bug fixes for various source code management systems and for Python 3 environments

We should have this release out next week.

KGB 5.0

KGB is our Python module for using function spies in unit tests. This lets you track when a function is called, with what arguments and results, and to even override what happens when that function is called.

It’s extremely powerful, and is a big part of how we maintain our large test suites.

We’re preparing a 5.0 release, which adds:

  • Python 3.8 support, with positional-only arguments
  • Workarounds for very corner-casey situations with method decorator that generate a new function every time it’s accessed (what we’re calling “slippery functions,” because they’re hard to hold on to)
  • Probably some new helpers for asserting the results of calls (TBD)

This should be released in the coming weeks. If you’re a Python user, I highly suggest giving KGB a try.

Review Board 4.0 Progress

Almost there.

We were going to get 4.0 in beta form by end of March. That was the goal. We hinted at this last time, and we were feeling good about it, but the impact from the pandemic changed some priorities.

So it’s delayed… I’m not going to give a new date at this point, but nearly everything is ready for beta. We just want to hammer on it some more first, make sure we’re pushing out a solid beta. Pretty much everything, including our extension ecosystem, is ready to go.

Student Demos

As you may know by now, we work with CS students every semester, mentoring them and helping them learn to contribute to real-world code bases through Review Board development.

They recently completed their second demo videos for the semester, showing off what they’ve built. Please take a look. I’m sure they’d love to hear some positive feedback on their videos:

Stay Safe, and Wash Your Hands

(Definitely the catch phrase of 2020, but it’s important!)

Again, if we can help with anything, reach out, or follow us on the community forum, Reddit, Twitter, Facebook, and YouTube if you want other ways to keep up with Review Board and Beanbag.

Read More

ChangeLog: February 20, 2020 — Accessibility, Student Demos

Hi everyone, and welcome to this week’s ChangeLog. This week, we want to talk about accessibility improvements for Review Board 4.0, and show you what this semester’s students are working on.

If you want to watch some videos instead of reading a bunch of stuff, jump down to Student Demo Videos!

Accessibility in Review Board

As we revise parts of our UI, introducing new features and designing new CSS Components, we have a goal of improving accessibility. We’re aiming to better support screen readers, improve keyboard navigation, and help people with visual impairments.

This will not be 100% implemented by 4.0, since we do plan to release sometime soon, but we will have laid the groundwork, working toward eventually being fully compliant with the Web Content Accessibility Guidelines (WCAG) 2.1.

There’s a lot that goes into accessibility on the web, but there’s two key areas that are important to get right, and are becoming a core part of our design and CSS component specifications: ARIA attributes and keyboard navigation.

ARIA attributes help screen readers and other assistive technologies understand, navigate, and communicate parts of the UI. They can communicate the intent of a UI component, provide more suitable labels or hints to screen readers, notify as important content updates, and more. They’re important, and we haven’t been good at using them, but they’re now being baked in to the design of any new UI we write.

Keyboard navigation is also very important. Not everyone can or wants to use a pointing device to navigate the UI, and we’ve identified several places where keyboard navigation (and focus presentation) is subpar or flat-out broken. So we’re making this a first-class citizen in new UIs, adding new keyboard shortcuts for important content areas or operations, and fixing cases where navigation is just busted.

To be clear, these aren’t the only focuses — there’s a lot more to the accessibility work than this. Improving accessibility is a long-term goal, and Review Board is a big product. We aren’t holding up 4.0 for this, but rather expect to spend time throughout the 4.0.x release cycle to gradually work on this.

And it’s a current focus of some of our student projects.

Student Demo Videos

In an earlier ChangeLog, we announced our new team of students working on Review Board. The big focuses this semester are on keyboard accessibility and first-time setup improvements.

They’ve been working hard for a month now, and have just completed their first (of three) demo videos. We’d like to show them off.

All videos are uploaded to our YouTube channel. Subscribe to keep up with content as we upload it.

Hannah Lin

Hannah’s been working on implementing keyboard navigation for file attachments, letting users focus on the attachments and control the pop-up menu (for reviewing, updating attachments, deleting, and downloading). That was her first warm-up project.

Her main project for the semester is working on a first-time setup guide, for new Review Board administrators. The goal is to help them get a new server up-and-running fast by walking them through the main setup steps as they progress through the administration UI.

Katherine Patenio

Katherine’s first demo covers some initial bug fixing work for RBTools on Python 3, addressing a problem where --help didn’t always work. She’s fixed this up and added a new layer of unit tests we can build upon.

Her main project for the semester isn’t covered here, but she’s going to be working on the rbt setup-repo command, helping streamline getting a new repository set up with Review Board.

Monica Bui

Monica’s also working on keyboard accessibility. Her focus in this demo is improving the New Review Request page, making sure that all elements can be tabbed to and navigated entirely by keyboard.

Xiaohui Liu

Xiaohui’s first project fixes up tab key navigation in the review request page. Previously, tabbing to fields would prioritize the fields on the right-hand side of review requests (Branch, Bugs, etc.) before the main fields (Description, Testing Done), which wasn’t really intuitive. His fix brings some sanity back to tab orders.

His second project is to implement common support in the UI for keyboard shortcuts, making it much easier for us to bake in better keyboard support on every page with less code to worry about.

Xiaole Zeng

Xiaole’s working on improving help within the product, giving users both a single place to go to when needing to find documentation or other useful information, and finding places within the UI where we can offer better inline guidance. For the latter, she’s working on adding helpful descriptions and documentation links when configuring repositories, based on the selected hosting service or repository type.

Next Week

We’re getting a new RBTools release ready to ship, so you’ll see that soon. We’re also testing 4.0 beta 1, and are getting that beta release on the calendar.

If you want to know more, have any questions, or are curious about anything else, please reach out on our community forum.

We’re also on Reddit (/r/reviewboard), Twitter, Facebook, and YouTube if you want other ways to keep up with Review Board and Beanbag.

Read More

ChangeLog: January 23, 2020 — Student Sprint and Django Upgrade

What a week it’s been. We have two topics to go over: Last weekend’s student mentorship sprint, and a status update on the big Django upgrade.

The student sprint was great!

Last weekend was our student sprint for CANOSP, kindly hosted by the Startup Edmonton in Edmonton, Canada. There, we met up with our new students from the University of Alberta and University of British Columbia, and spent the weekend getting to know them, teaching them about Review Board and how we do things here, and letting them loose on projects.

Students working hard on projects

David giving an architectural overview

David giving an architectural overview (close up)

We may have been sleepy most of the time (these start early!), and VERY cold (had to sit by a stack of ice cubes to keep warm), but everyone had a lot of fun, and have since been hard at work on their projects.

The main focuses for this semester are accessibility and usability. We’re working to make the product easier to use, improving keyboard navigation, and experimenting with ways to offer useful inline help. Much of this work is slated for Review Board 4.0.

Django upgrade time!

This week also marks the end of Django 1.6 in Review Board. We’ve been working for a long time on getting onto a newer version of Django, which has been a much more complex project for us than for most, and we’re finally ready to bump our Django requirement to 1.11.

Diff showing the change to upgrade to Django 1.11

For those paying attention, Django itself is at 3.0.2, but 1.11 is the last version to support Python 2.7. While Python 2.x is now end-of-life’d, that doesn’t mean it’s not in active use in enterprise, and frankly, many of our users are just not ready to upgrade. So Review Board 4.0 will continue to be providing compatibility for 2.7.

By the weekend, we should be on 1.11, and then we’ll be getting ready to test this in production. If all goes well, a beta will follow soon.

If you build extensions for Review Board, you’re going to need to make some changes to support Django 1.11. We have a bunch of useful information on Django updates on our wiki, which we’ll also include in the release notes. Make sure you give the beta a try and begin porting early.

We offer support contracts that cover development assistance, if you need it.

Back to work!

If you have any questions, or anything you’re curious about and want us to cover, please reach out on our community forum.

We’re also on Reddit (/r/reviewboard), Twitter, Facebook, and YouTube (featuring student project videos!) if you want other ways to keep up with what we’re up to.

Read More

ChangeLog: January 16, 2020 — Review Board Status and New Students

Hi everyone. Welcome to the first ChangeLog of 2020! We skipped last week due to the new Review Board 3.0.16 release, so let’s dive in and get caught up.

Review Board 3.0.16

Last Tuesday, we released Review Board 3.0.16. It’s been a long time since 3.0.15, and there are two reasons for this:

  1. Most of our attention of late has been on completing the remaining architectural work on Review Board 4.0 (Python 3 and Django 1.11 porting) and RBCommons user roles and billing updates.
  2. We’ve been trying to carefully design and implement some large backend improvements for repositories and repository configuration, in collaboration with another vendor, and wanted to get it right before we released.

We’ve discussed the repository improvements before, so read that if you want to learn a bit more, but the gist is that we’re giving SCMTools (repository backends) a lot more flexibility in how they present repository configuration, how they’re registered for use in Review Board, and how extra data for repositories get stored. This will lead to some significant improvements in the coming months for a couple of our supported repository types.

Now unless we find some major bug fixes in 3.0.16, it’ll probably be a little while until 3.0.17. We have a backlog of RBTools work we plan to release, and we’re still trying to get 4.0’s architectural rework done.

Review Board 4.0 Status

Most of the rewritten administration UI is in a usable state, and we’re just getting it all ready to be reviewed and landed. After this, we’ll be bumping our Django dependency and performing a bunch of real-world usage tests, just to make sure there isn’t some big breakage some place.

(If you want to learn more about the administration UI work and how it relates to Django and the release, read the ChangeLogs from October 24, 2019, October 31, 2019, and November 7, 2019.)

Once we’re happy, we’ll ship 4.0 Beta 1. Almost there!

New Semester, New Students

Every semester, we take on a batch of CS students eager to work on some real-world project, currently as part of the CANOSP program run by the University of Alberta, Canada.

It all starts this weekend at a get-together in Edmonton, Canada, where we’ll be helping five new students get set up, go over architecture and standards, and start them on their projects.

We’ll talk more about what they’ll be working on next week, but they mostly center around quality-of-life improvements to Review Board.

Wrapping Up The Week

If you have any questions, or anything you’re curious about and want us to cover, please reach out on our community forum.

We’re also on Reddit (/r/reviewboard), Twitter, Facebook, and YouTube (featuring student project videos!) if you want other ways to keep up with what we’re up to.

Read More

ChangeLog: December 5, 2019 — Student Projects, Repository Config

Welcome back, everyone! We’re here with another ChangeLog, this time focusing on a couple things that just wrapped up: This semester’s student projects, and a series of behind-the-scenes repository configuration improvements.

End of a Semester

Last month, we talked a bit about the CANOSP student program run out of the University of Alberta, and showed off some of the work our CANOSP students have done on Review Board.

They’ve all been hard at work improving our Review UI support (custom review UIs for different types of file attachments), building up both the underlying capabilities of a Review UI and creating prototypes of new UIs for new types of files.

They’ve just wrapped up their semester and completed their final demo videos. We’d like to show off their hard work.

Nicole Hagerman

Nicole’s focus has been the underlying Review UI support, allowing Review UIs to be more dynamic and to not be limited to a single URL. This work has been a backbone of other student projects this semester, so we’re covering it first.

On top of this, she’s built a new Review UI for more easily viewing JSON files, both in their source form and in a structured tree-based form.

Adil Malik

Adil built a series of new Review UIs designed for reviewing:

  • XML files, with options similar to the JSON file Review UI built by Nicole
  • Jupyter Notebooks, a popular tool in the Python world
  • Audio files, complete with waveforms and histograms, offering both diffing and commenting

These have come along really nicely, and show the power of our Review UI support (and the work done by Nicole Hagerman).

Ceegan Hale

Ceegan split his time between some improvements to our diff viewer and to our Review UIs as well:

  • Improved the diff viewer’s display of minified files (e.g., .min.js files)
  • Iterated on our in-progress support for showing Review UIs in the diff viewer
  • Built a prototype Review UI for viewing archive file attachments (e.g., .zip, .rar, etc.).

Repository Configuration Improvements

A good chunk of my own time these past few weeks has been to rework the code behind the repository configuration page. Along with an assortment of bug fixes, we’re working to make it easier to configure plain (non-GitHub/Bitbucket/etc.) repositories.

Historically, plain repositories all shared the same set of configuration fields. You had your “Path” field, “Mirror Path,” “Username,” “Password”. A few had special fields like Perforce’s “Use ticket-based authentication,” but they were baked into the repository form and dealt with specially. Third-party repository support couldn’t add their own fields, and administrators had to translate concepts like a Git Clone URL into our concept of a “Path.”

As of the upcoming Review Board 3.0.16, each type of repository will be able to provide its own configuration form. For instance, down the road, Git repositories will have a dropdown for selecting CGit, GitWeb, etc. as the repository content access method, instead of forcing people to type in a cryptic URL.

Here’s a mockup:

Bottom line: It’s going to be easier to configure repositories in upcoming releases.

There’s a lot of under-the-hood work that’s been done to enable this, and that work is also going to lead to some future improvements we’re looking forward to building in the Review Board 5.0 timeframe. Can’t wait to write about it.

Wrapping Up

That’s another week done. We’ll be back next week!

So what do you think so far? Are the ChangeLogs interesting? Boring? Is there something else you want to hear about? Please let us know on the community forum so we can improve these going forward.

We’re also on Reddit (/r/reviewboard), Twitter, Facebook, and YouTube if you want other ways to keep up-to-date.

Read More

ChangeLog: November 14, 2019 — Student Demos

This week’s ChangeLog is a bit different in focus. Instead of the work we’re doing, we want to talk about some of the work our students are doing.

Want to skip the text but see some cool demos? Scroll down!

Student Programs

For over a decade now, we’ve worked with hundreds of CS students eager to get their feet wet in the industry, mentoring them and giving them cool projects in Review Board to explore. Some have turned into features you use today (such as issue tracking and extensions).

There have been multiple programs over the years that we’ve worked with:

  • Google Summer of Code
  • UCOSP (a Canadian university program we were a part of for many years, now defunct)
  • Open Academy (an experimental university program ran out of Stanford, now defunct)
  • CANOSP (the phoenix rising out of the ashes of UCOSP, currently focused on the University of Alberta)

We’re currently working with CANOSP, piloting the program and mentoring a small group of students as they build some features and prototypes for Review Board.

This Semester

We have three students this semester: Adil Malik, Ceegan Hale, and Nicole Hagerman. They’re all working on various projects that improve the review experience:

  • Review UIs for XML, JSON, and Jupyter Notebooks
  • Hiding the content for minified files in the diff viewer, by default
  • Supporting binary files in the diff viewer

These projects are considered prototypes at this stage. We’re hoping they’ll make it into a release sooner rather than later, but a big part of this work is seeing how feasible these ideas are and what sort of work still needs to be solved before rolling it into production.

XML, JSON, and Jupyter Notebook Review UIs

Adil and Nicole are both primarily focused on the Review UIs, working together on some aspects to beef up the Review UI capabilities under the hood.

Adil built a Review UI for XML files (letting you diff the tree structure, and providing options for changing how that tree is rendered). He’s also been working on a Jupyter Notebook Review UI, playing with ideas for how these would be rendered, diffed, commented on, etc.

Hey, if you’re interested in Jupyter Notebooks, he’s looking for feedback.

Nicole built a Review UI for JSON files, the counterpart to the XML Review UI. To allow for custom rendering options required by both, Nicole’s been building out our baseline Review UI support, allowing them to define utility URLs that can, for instance, re-render parts of content based on the toggle of a checkbox. Adil’s been working with her on the client side of this.

Binary Files and Minified Files in the Diff Viewer

Ceegan’s been building out a feature that we’ve been wanting to bring for a long time. Years back, when we first wrote Review UIs, we intended to use them in the diff viewer so that images, PDFs, etc. that are part of commits could be reviewed without having to upload a separate file attachment.

The base of this work existed in Review Board but was never completed. There were still some missing pieces, problems to solve. That’s what Ceegan’s focusing on: Prototyping the rest of this, getting binary files in the diff viewer working so we can see what’s left.

To get his feet wet, Ceegan built another really useful feature that will make web app developers out there happy. Minified files (*.min.js, *.min.css, etc.) no longer show up as a giant wall of text. Instead, we note to the reviewer that it’s a minifed file and they might not care about it but they can click to see the content. Just like with deleted files.

Demos!

Throughout the semester, we have our students put together demo videos showing off and talking about their work up to that point. We’ve recently completed the Demo 2 milestone, so we have a nice batch of videos to show off.

All videos are uploaded to our YouTube channel. Subscribe to keep up with content as we upload it.

And here are the videos this semester:

Adil Malik

Ceegan Hale

Nicole Hagerman

Wrapping Up

Our students work really hard for their projects, so if you have anything encouraging to say, you’d make their day by saying it on their videos 🙂

We’re hoping to get these in shape to land as part of Review Board 4.0 and 5.0, but it depends on the work that remains once the semester is over.

That’s it for this week, though. If you have any questions, or anything you’re curious about and want us to cover, please reach out on our community forum.

We’re also on reddit /r/reviewboard, Twitter, and Facebook, and of course YouTube if you want other ways to keep up with the latest.

Read More