Programming Posts

Taking Cloud66 for a spin

Taking Cloud66 for a spin

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.

File uploads in Rails 5.2 with ActiveStorage

File uploads in Rails 5.2 with ActiveStorage

The forthcoming Rails 5.2 release will ship 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 mostly regressive

Chatbot UIs mostly regressive

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.

Fully-cacheable edit controls in Rails

Fully-cacheable edit controls in Rails

The Ruby on Rails framework provides extraordinary, deeply-integrated caching faculties. A challenge that I’ve inevitably encountered in every content-driven Rails application I’ve ever worked on is the selective exposure of admin controls in cached views.

For example, an application may have a user profile page. Most users of the application should see an identical version of this page, so it is an excellent candidate for caching. For the account owner, we may wish to expose an “Edit Account” control, or several controls throughout the page to edit various elements of the account (i.e. “Update profile picture”, “Change display name”, etc.). In this article I will introduce a robust approach to this problem that has served me well many times over.

Caching strategies for Rails 5 applications

Caching strategies for Rails 5 applications

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.

Practical vs correct
A low complexity surface area and building atop mature frameworks makes high-leverage wins like moving to dedicated hardware much more achievable.

Practical vs correct

In our work as software developers we regularly have to evaluate architectural tradeoffs. We have voices, either external or internal, telling us to think about, for example:

  • Going API first
  • Building to accommodate horizontal scaling
  • Building with the most modern tools
  • Building with tools and frameworks that let us hire the best (or sometimes “Building with tools and frameworks that let us hire the cheapest”)

There is often a tension in these matters between practical and “correct”.

Estonian E-Residency and refactoring government

Estonian E-Residency and refactoring government

Marshall McLuhan once said “Our Age of Anxiety is, in great part, the result of trying to do today’s jobs with yesterday’s tools”. There’s not a lot of technology that we interact with on a day-to-day basis that’s stayed in continuous operation for 230 years. The faculties by which we interact, gather, and exchange ideas in social and professional realms have dramatically evolved in this span of time. Our systems of government, at both philosophical and practical levels, largely have not.

Every day I work with teammates in Germany, New York, California and British Columbia. “Presence” means something quite different today than it has for much of human history. It is a divided concept, and virtual presence often has equal or greater consequence than physical presence.

Optimizing for less code with UJS and data-behavior

UJS is a small javascript library that manages interactions with endpoints implementing SJR (Server-generated Javascript Responses), in addition to providing a few behaviors such as non-GET HTTP verbs for links, simple confirm UIs, and the disabling of elements with optional loading text while remote requests are processing. UJS and SJR are a fantastic solution for keeping a web application’s frontend code minimal, in an age where wild over-engineering in this area is increasingly the norm.

UJS behavior binding is declarative, and happens via data attributes (for instance you can use the attribute-value pair data-disable-with='Processing' to disable a submit button with the loading text “Processing” during a form POST).

For all that is great about UJS, one thing that it does not offer is any formal suggestion of a practice for introducing your own custom unobtrusive javascript behaviors to your application. For this we need to look beyond the library and to the broader developer community surrounding Rails and UJS.