Concerto 2 was an ambitious plan to rebuild our application from the ground up, fixing all the little corners we backed ourselves into with the first version of Concerto. Most importantly, Concerto 2 needed to be something that anyone could set up and start using, instead of an application hardcoded to the idiosyncrasies of our university in upstate New York.

I think we achieved those goals, but looking back on the past 10+ years of development (wow, has it been that long!) there are a few decisions I made that hampered our ability to perform ongoing maintenance and development of the Concerto 2 codebase.

As I atone for my mistakes with a “LTS” focused version of Concerto, I wanted to debrief on what went wrong. Maybe you can avoid the same mistakes I made.

Frontend Frameworks

I consistently picked the losing horses of 2010’s frontend frameworks.

We started with Google’s Closure Compiler which provided a very “correct” implementation, with all the benefits of type checking, tests, and robust set of common libraries that modern day developers have come to enjoy.

Unfortunately it was quite complicated to get setup and working right. The JavaScript that got written was verbose and hard to understand if you weren’t living and breathing in the framework. I’m looking at you goog.provide and goog.require.

We transitioned to web components powered by the Polymer Project. The idea of web components was great; different content types, like Graphics and Videos, could have their own self-contained web component. This helped establish clear interfaces between different layers of the frontend player which was sorely lacking in Concerto 1’s jQuery-based frontend.

As far as I can tell Polymer never really took off, leaving us with a limited ecosystem of documentation and examples to draw from. It felt like we were often pushing the bounds of what was possible in Polymer, and that was more representative of how limited the ecosystem was than how advanced our use cases were.

Eventually, Marvin kept up with the times enough to realize that Vue made a great choice for a frontend and started building a much more reasonable implementation. I’ve drawn heavy inspiration from his early work building out the new Vue 3 frontend.

Plugin Maintenance

Concerto 2 has a robust plugin system. Worried about polluting the core of the application with extra or optional functionality, we pushed lots of features to be developed as standalone plugins - largely powered by Rails Engines to be packaged and installed as gems.

This achieved our goal of keeping the core as lightweight as possible, but made maintenance and ongoing nightmare thanks to the dependency tree. When there’s a security update in a common library - like rack - we need to update versions across each plugin and re-release them. For example, the latest rack vulnerability requires updates and releases across 9 different repos.

Dependabot makes this a tractable problem, but keeping up with all the different repositories became a lot of overhead for a volunteer project.

This was further compounded by Rails version updates. When a new major version of Rails was released we needed to update each of the plugins and often fix subtle behaviors to keep them working. We didn’t have great integration tests to catch these cases so someone needed to have all the plugins installed, configured correctly, and able to tell what it meant for them to be working vs not.

In hindsight, we should have had more conversations about the functionality we wanted to support in Concerto and brought the vast majority of these plugins into the core application.

Dynamic Installation

Installing someone else’s Ruby on Rails application has historically been more of an art than a science. In the days before Docker and Kamal, we wanted to avoid System Administrators having to muck around in Gemfiles, .rb environment files, or yaml configs. After installing Concerto, perhaps via our .deb or Virtual Machine, the admin would only need to click though our friendly web UI to configure everything.

To make this happen, we wrote hooks deep into the initialization process for Rails. These hooks injected critical information from the database, like a list of Gems to be loaded (those plugins!) and how auth should be configured.

It was brilliant engineering work by some of the best developers I know.

Somewhere along the way, Rails (or maybe Ruby?) overhauled the initialization process. It’s better, faster, more effecient… I dunno, I didn’t keep up with the change. The side effect was that many of our clever hooks were broken in very subtle ways, and it was far enough in the rear-view mirror that nobody remembered exactly what we did, how it worked. and how to get it working again.

We were clever. Being clever is not always a great idea.

Explicit goals of my current work including being as boring as possible and doing things the “rails way”. Optomistically, that will minimize our surprises when Rails ships updates. Or maybe I’ll be writing another one of these posts in 10 years. Only time will tell.

I sent the following email to the Concerto team mailing last week, and wanted to share it here as well. It’s also a great test to see if we can still post new content to this blog or not. Stay tuned!

Hello Hello!

Long time no email :) I hope your December is off to a good start.

I wanted to send a heads up that I’m planning to rename the Concerto “master” branch to something like “2.x”, and substantially overhaul the codebase on a new “master” (or maybe “main”) branch in the coming week or so.

If you have pending changes for the existing Concerto 2.x codebase, now would be a great time to ship them - or be on the lookout to change your target branch.

I’ve been slowly chipping away at bringing Concerto up to modern standards - Rails 8.1, Vue 3, TailwindCSS, etc and I almost have enough features working locally that I’m comfortable with an MVP to start getting feedback from our users. Demo link to come when the initial page load performance is less embarrassing.

Given the very inconsistent attention I’ve dedicated to the project over the past… decade?… I’m trying to optimize for long-term stability; stripping away all of my complicated ideas around plugins and modularity in favor of one big application that dependabot can keep updated on a weekly basis.

If you’re interested in helping out, let me know - I’ll also be cleaning up Github Issues to track different work items you’re always welcome to grab.

Let me know if you have any questions, comments, or concerns!

Some weeks back, we released Concerto 2.3.4. This release contains fixes for many bugs and updates to the calendar and weather plugins. For the full list of changes, compare the commits between this release and 2.3.3. Of note, this release contains fixes for how we upload graphics, particularly disabling the submit button while a graphic is uploading. We have also enabled content to have custom edit forms. At this moment Ruby 2.4 is not supported in this version of Concerto. We are targeting it for 2.3.5. Please look forward to it.

Today, we’re releasing Concerto 2.3.3. The main change in this release is a fix for the image rotation issues we’ve had reported to us that were causing images to display much more often than expected. This release also contains a number of bug fixes for how we handle large images, group membership, and the list of screens. Those installing from source should also know that because of updates to Rails and many of our gem dependencies, Ruby 1.9 is no longer supported. Concerto is now tested on Ruby versions 2.0.0 through 2.3.0.

Some weeks back, we released Concerto 2.3.0, the first release the feature the new frontend plugin (written using the Polymer framework). This removes the previous javascript frontend code from core Concerto and allows future plugins to provide alternative HTML to displays, perhaps a lightweight version suitable to systems like the Raspberry Pi.

Shortly after releasing 2.3.0, we found a few shortcomings, the biggest being that assets from an upgraded frontend plugin weren’t getting updated (resulting in blank screens) and that some users had their core Concerto version out of step with their content and frontend plugins. After we made a few complex and interdependent changes amongst Concerto and the various core plugins, we decided to go to version 2.3.1 to avoid further issues. In the future we  intend to also disallow the installation of plugins not compatible with older versions of core Concerto.

With the release of 2.3.1, we have fixed the asset updating issue, Github API overage errors, some minor security issues, and a variety of other tweaks. We’ll also be making some basic upgrade instructions available to those running older versions of Concerto in the 2.x series to get up and running with the new frontend. For those running into any issues, please remember to stop by our community mailing list for help – concerto-digital-signage@googlegroups.com.

Today’s release of Concerto 2.2.5 will likely be the last in the 2.2 series. It comprises a large contribution to the state of internationalization in Concerto, CSS to remove the cursor from the frontend, and numerous bugfixes. This is thanks primarily to the contribution of code and suggestions from our wonderful user community.

The 2.3 release, which will hopefully be along soon as our team members work to familiarize themselves with the new framework and toolchain we’re using to architect the frontend. Our main priority in this respect will be having a performant frontend that doesn’t leak memory (which has led to crashes on low powered computers) and is feature-equivalent to our previous frontend incarnations.

With the release of Concerto 2.2.2, the 2.x series is at a pretty stable place, seeing very few code changes outside of the views, but many stability fixes. Concerto 2′s web interface has been production-usable for some time, but many users are still experiencing difficulties running the screen frontend, particularly on underpowered platforms like the Raspberry Pi, where the memory leaks have been particularly noticeable. To that end, Concerto 2.3 will feature a new frontend, based on Dart, which should significantly reduce the memory issues the frontend has had in the past.

With the release of 2.3, we will also be linking to a new Concerto 2 demo and discontinuing any legacy documentation and support for Concerto 1. Links will be provided to code and documentation archives, but concerto-signage.org will be a resource exclusively for Concerto 2 deployments.

As we’ve moved through the .8 series of releases, we’ve brought Concerto 2 closer and closer to a feature-complete release. With the 0.9 series (the last before Concerto 2.0, strangely enough), and 0.9.0 in particular, we’ve fixed one of the more annoying frontend bugs (the continually refreshing time field) and are trying to work in both a way to disable text resizing and a refresh for the formidable Blue Swoosh template. Depending on the pace of development, some of the trim and polish (such as full internationalization support), may come in some additional .9.x releases, or just after the 2.0 release.

Concerto-signage.org is also in the process of being updated to reflect the latest Concerto 2 beta, and an entirely new site is on the way. While a link is provided to Concerto 1 for those still wishing to use it, an upgrade to Concerto 2 is strongly recommended, as v1 has not been maintained actively in many years.

Hi Everyone!  I’m usually excited when we’re announcing a new version of Concerto, but this version has me extra excited.  We’ve managed to pack more bug fixes, improvements, and features into our 0.7.0.IndiaIbex release than the previous couple releases we’ve put out.  If you’ve been ignoring these updates, or Concerto 2 in general, this is definitely the release to check out.  To get started quickly, you should download the latest concerto_server VM here and fire it up to follow along.

This release added some much needed security for screens with the addition of screen authentication.  Screen security, something that Concerto 1 lacked, is something we (and by we I mean Mike) spent a lot of time thinking about for Concerto 2.  I couldn’t do it justice in this short form, so we’ll dive into the details in a full post after we’ve tidied up the last few bugs.

We also added support for Capistrano-based deployments if you’re into that sorta thing.  Our external error-reporting has been fixed in this release so we should get those bug reports automatically streaming in if you’ve check the box during setup.  If you’ve tried to visit that settings page and gotten an error, we’ve fixed that as well.  The config / settings as a whole should be a lot easier to navigate as well.  The VM is properly writing logs now so you can see what’s going on in logs/production.log and the dynamic content updaters are running in the background like they should be.  Behind the scenes this release also includes some improvements to our JSON / XML API that we’ll be including in V2, it’s not quite ready for mainstream yet but we’re making progress.

You can find a full diff of the work we did here.  Our installation instructions should be up to date, but you should really just download the VM and run it for a fast start.  Alternatively, you can check out our instance running this release @ http://nightly.concerto-signage.org.  Do let us know what bugs you run into or features you’d like by writing to our Google Group or opening Github Issues.

After a few hiccups along the way (like the mysterious 0.5.0.GolfOtter release), we’re ready to share 0.6.0.HotelHummingbird with you.  It’s been over a month since our last release and we’ve been busy at work making the experience a bit snappier and improving the Add Content form.  To get started, you can find our installation to get started in our Github wiki.

Since you likely missed out on the 0.5.0.GolfOtter release you also missed a new background processing model which should make Dynamic Content processing much more robust and reliable.  Concerto now includes a script to kick off background processing using something like sudo /etc/init.d/concerto start and manage the background workers just like you would a regular process.

Some notable changes include:

• Textile support in the Ticker Text field.
• Frontend support for subdirectories, like /concerto/frontend/1.
• Slightly better garbage collection in the frontend.
• New background processing model.
• New feed selector, system-wide.
• New templated creation / editing workflow.
• New content creation experience with preview support.

You can find the full list of changes between our last announced release and this one here. Please get in touch with us via our group or issue tracker if you come across a bug or have a feature suggestion for us!