At ClassDojo, we’ve been working on getting visibility into bugs that get deployed to our production React webapp. Catching errors in our data layer is pretty straightforward, but the view layer presents more of a challenge.

Errors in your React code can happen in a variety of places such as

• render functions
• lifecycle methods (componentDidMount, componentWillUpdate)
• event callbacks (onClick , onChange)

Our goal was to cover all of these cases without adding boilerplate to every component.

• Errors
• Programming
• React

Class Story is one of our core product features at ClassDojo. It allows teachers to post photos and videos that parents can view, like, and comment on, and teachers around the world use it to share cute, funny, or exciting moments from their classrooms. Since we’re approaching the end of the school year, we wanted to provide teachers with a something memorable and engaging to send home. But with a ton of new projects we’d like to ship before back-to-school in August, we also wanted something we could build quickly.

We settled on a photo collage of a classroom’s top posts throughout the year. We generated collages for all classrooms with at least 9 posts this year and surfaced them in-app for teachers to share with their parents. We hope parents, teachers, and students everywhere will enjoy seeing a year’s worth of memories!

Here’s an example of one of the collages, using posts from our internal Class Story:

In the process, we wrote a simple npm module, photo-collage, which generates photo collages. You can view it here, and see the source code here.

• Programming
• Node.js
• Highland
• Canvas
• Redshift
• Streams

At ClassDojo, we've recently been building out our push notification infrastructure. Our plans required a rate limiter that met the following criteria:

• Distributed: The rate limiter can be shared across multiple processes. This necessitated the use of a external key-value store - we chose Redis, because we use it elsewhere in the stack.

• Rolling Window: If we set a maximum of 10 message per minute, we didn't want a user to be able to receive 10 messages at 0:59 and 10 more messages at 1:01.

• Minimum Distance Between Messages: Regardless of what overall rate we chose, we wanted to also enforce a minimum distance between consecutive messages, so that teachers wouldn't get an annoying burst of several sounds or vibrations while busy in the classroom.

We looked around at the available rate limiting options, but what we found on NPM didn't meet the above requirements. So we decided to write our own, which you can download here.

• Programming
• Node.js
• Redis