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.

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.

I noticed something curious when I booted my first project atop Rails 5 in development mode: that when the development server was idling, the title bar on Terminal.app would read “fsevent_watch”.