When we generate survey reports for clients, along with online reports with interactive graphs we also generate PDFs that clients can print out and share. Converting our online reports-each of which sometimes has several hundred graphs spread across multiple pages-to PDFs has been an interesting challenge.
We use Sidekiq Pro to manage all background jobs in our Rails application. While Sidekiq has built-in support for prioritizing jobs of different types, the framework does not inherently support prioritization for jobs of the same type. So we built out that feature ourselves!
Our Sidekiq setup involves workers split into a few different worker types differentiated by memory availability and the concurrency with which jobs are processed. Initially, workers belonging to each worker type had a single designated queue they pulled jobs from. For example, consider two types of jobs, FancyJobA and FancyJobB that are both processed by the same type of worker type_a_worker.
In a project we recently completed, we had to refactor an object so that one of its foreign key associations referred to a new model. We use Ruby/Rails and deploy code to Heroku with Preboot enabled. Implementing this change safely without any downtime was surprisingly tricky to get right (in fact we didn’t at first, and ended up with a brief outage in a part of our product, although fortunately no data was lost). Pedro Belo’s post on hot compatibility lists some patterns to make basic data migrations zero-downtime deployment safe. As Belo mentions at the end of his post, hot compatibility needs to be addressed at the application level, and often takes a lot of planning and work. This article describes a reusable pattern to safely make a change to a foreign key reference with no downtime.
At Panorama, one of our core company values is to contribute to the communities we are a part of and in the spirit of this value, one of the goals of the engineering team this quarter is to further this culture of giving back to the community. As part of this goal, we are undertaking initiatives to get involved with the thriving local developer community in Boston.
We identified CodeAcross Boston 2015, a civic tech hackathon organized by Code for Boston, as a cool local developer event to attend; David, Geoffrey and I represented Panorama at the weekend-long hackathon. Our goals for this event were twofold: first, get acquainted with other developers around Boston, and second, hack on a project that we believed could benefit the people of the city.