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.

Caching strategies for Rails applications

Caching strategies for Rails 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.

Be proudest of your under-engineering
The Technics SL-1200 MKII turntable has had the same mechanically simple design for 37 years, yet its quality, performance and reliability are considered unmatched.

Be proudest of your under-engineering

I am an under-engineer-er. The default lens through which I approach problems is one that prioritizes Less Code.

Usually the highest-leverage additions to your app are not complex ones, though having already increased your complexity surface area for nebulous ends or a distant vision will quickly make them so.

I am a student of Martin Fowler’s First Law.

I am also a strong believer that the documentation of any mature framework you may lean on inevitably proves an order of magnitude more comprehensive and approachable than that which your team may draft for any home-grown framework.

Rails 5’s best feature is one you may not have noticed

Rails 5’s best feature is one you may not have noticed

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”.

Finishing Is Credibility

Finishing Is Credibility

One of the things I am most proud of, and that I am most surprised to find distinguishes me when I look around at other people in my professional circles, is how often I finish things. To me, finishing is credibility, and a person’s record not just of starting or working on projects, but of finishing them, should be a factor in the weight you give to their opinions or the degree of leadership you entrust them with.