November has been a tremendously busy month for the JudgeApps team! In addition to last week’s major maintenance, we’ve made many improvements and bug fixes throughout the month. I’m really excited to share them with you all! I’d also like to recap some of the bumps we hit during the maintenance, how we resolved them, and how we’ll avoid them in the future.

So, with no further ado…

The Good

Upgrade to Django 1.8! Django 1.8 is a long-term release for Django, the web framework on which JudgeApps is built. Although many of the changes from the upgrade will be invisible to end-users, it represents a significant step forward in JudgeApps’ security and stability, as well as use of new features.

More Detailed Judge Autocomplete. Ever tried to add Matthew Johnson to your event or judge project? It turns out there are three of them on JudgeApps, so finding the right one was quite a challenge. Now, instead of just showing judges’ names, the autocomplete box will also show the level and location of matching judges. For example:

Judge Map Improvements. When we rolled out Roles, the Judge Map became more confusing to use, and started display multiple markers for the same judge. We’ve added some text to clarify how the Judge Map filters on roles and levels. And while having more Toby’s would have been nice, we also enusred that each judge only created one marker.

When we rolled out Roles, the Judge Map became more confusing to use, and started display multiple markers for the same judge. We’ve added some text to clarify how the Judge Map filters on roles and levels. And while having more Toby’s would have been nice, we also enusred that each judge only created one marker. More Helpful Event Statistics. An event’s judge manager(s) can see detailed statistics on the applications they’ve received, including breakdowns by level and region. However, these statistics ignored judges who were added to the event directly, without an application. This made accounting who’s actually at an event more difficult than it needed to be. We’ve added an extra column to show the more detailed stats!

An event’s judge manager(s) can see detailed statistics on the applications they’ve received, including breakdowns by level and region. However, these statistics ignored judges who were added to the event directly, without an application. This made accounting who’s actually at an event more difficult than it needed to be. We’ve added an extra column to show the more detailed stats! Faster Exemplar Data Export. You can download all the recognitions from an Exemplar wave all…but as Exemplar waves have gotten bigger, the export function was making so many queries that it wouldn’t finish. Some SQL magic reduced the number of queries from over 9,000 to just 8, leading to very snappy exports.

You can download all the recognitions from an Exemplar wave all…but as Exemplar waves have gotten bigger, the export function was making so many queries that it wouldn’t finish. Some SQL magic reduced the number of queries from over 9,000 to just 8, leading to very snappy exports. Faster Judge Search and Event Staff Lists. More SQL magic has significantly reduced the time it takes to use the Judge Search and to load the list of judges on staff for a given event.

More SQL magic has significantly reduced the time it takes to use the Judge Search and to load the list of judges on staff for a given event. JudgeApps is Sass-ier. We are now using Sass on our frontend, a more powerful alternative to traditional CSS.

We are now using Sass on our frontend, a more powerful alternative to traditional CSS. Avatar Caching. Looking up a user’s avatar will be faster.

Looking up a user’s avatar will be faster. Clearer Account Review . Before being approved, all JudgeApps accounts are reviewed by an L3 judge or JudgeApps development team member. We’ve made several improvements to this function so it’s easier to use.

. Before being approved, all JudgeApps accounts are reviewed by an L3 judge or JudgeApps development team member. We’ve made several improvements to this function so it’s easier to use. Event Histories. We’ve removed an inaccurate warning on events that judges have manually added to their event history.

The Bad

Judge Search. After maintenance, Judge Search broke in a very particular way: it became case-sensitive. So typing in “Paul Baranay” would find the expected result, but “paul baranay” would not. This was both unintended and undesirable, so we fixed it! Kudos to Dan Collins for jumping on the issue, to Ben Harris for spotting the root of the problem over Slack, and to Johanna Virtanen and Chris Rumore for reporting the bug.

The Ugly

JudgeApps Emails. I neglected to thoroughly test JudgeApps’ email notifications during the maintenance period. As a consequence, JudgeApps did not send out email notifications for about 24 hours. For the same period, replying to a forum post via email did not work. Fortunately, fixing the issue also allowed us to re-send the skipped email notifications. Huge thanks to Dan Collins for his assistance resolving the complex and layered set of problems underlying this bug. In the future, testing email will be a more significant part of our maintenance process.

While developing and maintaining JudgeApps is a team effort, a few people deserve special recognition this month for their contributions. First, thanks to Jernej Lipovec for his continued work on the frontend (Sass) project. Second, kudos to Ben Harris for his improvements to event statistics. And finally, I’d like to recognize new developer Dan Collins , who has put in yeoman’s work over the past two weeks. I’m especially grateful for Dan’s relentlessly working to optimize our queries and make JudgeApps run faster and smoother for everyone.

That’s all for now! As always, thanks for using JudgeApps. We welcome any feedback or other suggestions via the site’s Feedback Form.