I decided to take Cloud66 for a spin recently, after finding myself dissatisfied with the bespoke configuration management solutions I typically work with. I felt that there had to be something that gave me a Heroku/12-factor -like admin experience but atop hardware of my choosing. I have found this solution in Cloud66, and I am stunned that this tool doesn’t receive more attention. My impression is that, for applications of a certain shape, it is the solution that many companies are looking for but don’t know exists.

Author’s Note: I have tried my best to keep this article up to date, but be aware that ActiveStorage is under very active development and the interface is still evolving. I recommend referring to the official guide that has been released in the time since this article was first published.

As of version 5.2, the Ruby on Rails framework ships with ActiveStorage, a simple module for handling file uploads either to your own host or to third-party services like Amazon S3 and Google Cloud Storage. If you have worked with Rails, you are likely familiar with gems like CarrierWave and Paperclip. ActiveStorage achieves a similar but more limited end as these libraries.

When writing in the past about ActiveJob, a job queue interface introduced in Rails 4.2, the framework’s author/maintainer David Heinemeier Hansson explained that it is central to the philosophy of Rails that any function that your web application will almost certainly end up incorporating should ship stock with the framework. In the case of ActiveJob, it was recognized that nearly every web application will need a job queue. ActiveStorage is presumably now a consequence of the recognition that nearly every web application will incorporate file upload and storage features to some degree.

Chatbot UIs have been gaining a foothold in an increasing number of niches. The one that is most relevant to my work as a developer is the area of SysOps. Things like kicking off builds, deployments and miscellaneous other infrastructure-related tasks are increasingly delegated to chatbots. In a distant time, long before AI was being hyped to the mainstream, when development teams were using Campfire or Hipchat if they were using anything at all for internal team chat, Github created what I consider the granddaddy of today’s chat bots with their internal tool Hubot (now long since open-sourced).

Instead of going to a interface – whether bespoke, PaaS-furnished (like Heroku’s “git push to deploy”), or living in a dedicated web-based utility like Cloud66 or DeployBot – teams issue an incantation to a bot that lingers in one or all of their chat channels to perform certain ops and deployment-related tasks.

One of the tremendous benefits of building with a high-level framework like Ruby on Rails is that you are afforded both mental space and an abundance of tools to optimize your application with a thoughtful caching strategy. Caching can be done at several levels in the stack and I wanted to provide an overview of the most common caching strategies for Rails applications and the tradeoffs inherent in each.