We didn’t do too much coverage of Rails 6.1 release last week, but here’s a great write-up on the GitHub blog about how they landed a couple small PRs into the framework that dramatically changed how the company is building views with ViewComponent.

This comment was particularly noteworthy, methinks:

Inspired by our experience building component-based UI with React, we set off to build a framework to bring these ideas to server-rendered Rails views.

Good ideas propagate. Regardless of what comes next in the web UI world (or React goes from here), this single idea is so profound for building frontends that it will be React’s lasting legacy.

Maxime Vaillancourt joined us to talk about Shopify’s massive storefront rewrite from a Ruby on Rails monolith to a completely new implementation written in Ruby. It’s a fairly well known opinion that rewrites are “the single worst strategic mistake that any software company can make” and generally something “you should never do.” But Maxime and the team at Shopify have proved successful in their efforts in this massive storefront rewrite and today’s conversation covers all the details.

Ruby is my favorite tool for slightly-longer-than-one-liners, but I don’t often reach for it directly from the command line. This little cookbook might change my mind on that:

A shell utility like bash provides built-in commands and scripting features to make it easier to solve and automate various tasks. External *nix commands like grep, sed, awk, sort, find, parallel etc can be combined to work with each other. Depending upon your familiarity with those tools, you can either use ruby as a single replacement or complement them for specific use cases.

There’s a lot of information that you are ignoring from your VCS. SQL is a great way to access it.

Maxime Vaillancourt shared the background and details of how Shopify reduced their storefront response times with a rewrite.

The Rails monolith still handles checkout, admin, and API traffic, but storefront traffic is handled by the new implementation.

Designing the new storefront implementation from the ground up allowed us to think about the guarantees we could provide: we took the opportunity of this evergreen project to set us up on strong primitives that can be extended in the future, which would have been much more difficult to retrofit in the legacy implementation. An example of these foundations is the decision to design the new implementation on top of an active-active replication setup. As a result, the new implementation always reads from dedicated read replicas, improving performance and reducing load on the primary writers.

Similarly, by rebuilding and extracting the storefront-related code in a dedicated application, we took the opportunity to think about building the best developer experience possible: great debugging tools, simple onboarding setup, welcoming documentation, and so on.

DHH posted a gist sharing HEY’s Ruby dependencies for the curious. It’s a pretty stock Rails app with MySQL (?!) and Redis stores, Elasticsearch, and a few other niceties. One line that caught my eye was:

gem 'turbo', github: 'basecamp/turbo'

That points to a private repo, so there will probably be some new open source turbolinks stuff here real soon. Anything else in this Gemfile catch your interest?

This looks promising for the future of Ruby.

Meet Ruby Next, the first transpiler for Ruby that allows you to use the latest language features, including the experimental ones, today—without the stress of a project-wide version upgrade. Read the story behind the gem, discover its inner workings, and see how it can help in pushing Ruby into the future.

A nifty tool (Ruby gem) from the folks at Instacart. Designed for:

• speed - up to 4x faster than traditional tools on a 4-core machine
• security - built-in methods to prevent sensitive data from ever leaving the server
• convenience - sync partial tables, groups of tables, and related records

This is an excellent refactoring story using one of Shopify’s core classes.

As you can imagine, one of the most critical areas in Shopify’s Ruby on Rails codebase is the Shop model. Shop is a hefty class with well over 3000 lines of code, and its responsibilities are numerous. When Shopify was a smaller company with a smaller codebase, Shop’s purpose was clearer: it represented an online store hosted on our platform. Today, Shopify is far more complex, and the business intentions of the Shop model are murkier. It can be described as a God Object: a class that knows and does too much.

They use Martin Fowler’s Strangler Fig pattern to achieve the refactoring. You may recall we discussed this on our episode with Amal Hussein.

Easy to use, self hosted, no tracking, just photos.

We like to take photos and share them. Problem is it’s hard to really own your photos and how they’re represented across social media these days, so we set out to make a place for them. You host it yourself, wherever you want (Netlify, Github Pages…), you’re in control.

Mount RedisWebManager to a path in your Rails router and you’re off to the races. You can view memory and CPU usage, review and edit your keys, and check up on connected clients. There’s also some low-hanging fruit for contributions.

Grigory Petrov sat down with Yukihiro Matsumoto to hear from him first-hand about being a star, the philosophy behind Ruby’s design and evolution, and a little about Japanese life and culture.

We had the honor of interviewing Matz a few years back. The man is a wealth of knowledge. I especially appreciated reading his thoughts on type checking.

tapping_device lets you inspect your program’s behavior without adding any breakpoints or puts-ish methods. In this post, the gem’s author walks through using it to find the cause of a real-world Rails issue in less than an hour.

I like the why behind Matestack:

Implementing two separate systems (backend-api, frontend-app) is a pain: Two different code bases, two repositories to maintain, two different deployment schedules, two test environments, two everything… Being a small dev team, we decided not to adopt this modern web development complexity and decided to create… Matestack!

If you have 30 minutes and want an easy button to learn all about it, Jonas Jabari gave a talk on it at Ruby Unconf 2019.

Reports of Ruby’s death are greatly exaggerated.

I’m not a big fan of Intercom-style chat widgets, but with how many of them I see out there I might literally be the only person in that camp. That being said, if you’re on the market for (what looks like) a bare bones implementation of that functionality that you can keep 100% 1st party, maybe give Chatwoot a try.

Eileen Uchitelle shared the backstory of how they have GitHub running on Rails 6.0 just 1.5 weeks after its final release. 👏

As soon as we finished the Rails 5.2 upgrade last year, we started upgrading our application to Rails 6.0. Instead of waiting for the final release, we’d upgrade every week by pulling in the latest changes from Rails master and run all of our tests against that new version. This allowed us to find regressions quickly and early—often finding regressions in Rails master just hours after they were introduced. Upgrading weekly made it easy to find where these regressions were introduced since we were bisecting Rails with only a week’s worth of commits instead of more than a year of commits.

A Ruby gem that significantly improves the situation with terminal logging as part of TTY Toolkit. It allows streaming of log data to any IO device (socket, file, etc…) with a highly customizable and pretty output to make key information stand out. You can limit the depth of the displayed data and specify the maximum size in bytes.

Joel Ambass with some good thoughts (and a tiny gem) on monkey patching in Ruby

Applied correctly and with care, monkey patching becomes a powerful tool that every ruby programmer can benefit from.

I really dig his idea and implementation of a version guard as my main source of trepidation when monkey patching around a bug is not knowing if/when I can remove my patch.

This is a truly glorious hack. How do they do it?

Background-images loaded via pseudoselectors + a forever-loading index page (remember Comet?).

There’s a more detailed explanation of what’s going on here in the README. Hopefully doesn’t need to be said, but I’ll say it anyway just in case: don’t try this at $HOME

Discover the lesser-known parts of the next major framework upgrade, appealing to mature applications that have been around for a while. Instead of focusing on “greatest hits,” we will walk you through B-sides and rarities that make this new release enjoyable in subtler ways.

What B-sides and rarities are Vladimir speaking of?

While the most-advertised Rails 6 features like Action Mailbox and Action Text steal all the spotlight, it is unlikely that a real-life Rails application that has been around for a while will benefit from the ease of building WYSIWYG text editors right after the upgrade.

At the same time, less flashy features like multiple databases support or parallel testing can bring immediate gains to your productivity—and Rails 6 has enough of those to offer if you know where to look.

Some interesting new open source coming out of the team at Stripe. It appears they’ve stolen a few (good) tricks from TypeScript’s playbook:

Sorbet is 100% compatible with Ruby. It type checks normal method definitions, and introduces backwards-compatible syntax for method signatures.

Explicit method signatures make Sorbet useful for anyone reading the code too (not just the author). Type annotations serve as a tool for understanding long after they’re written.

Sorbet is designed to be useful, not burdensome. Explicit annotations are repaid with clear error messages, increased safety, and increased productivity.

There’s docs, a demo, and a talk from Strange Loop 2018, but you’ll have to wait to get your hands on the source. It’s advertised as Coming Summer 2019.

A nice tut on the nitty gritty of using Action Cable to build a chat app. See also the follow-up post in which Lazarus dockerizes it as well.

A web UI for managing your app’s cache, inspired by Sidekiq’s web UI.

David Chanin:

I know Rails isn’t universally beloved by developers, and I’m not suggesting that we give up React and es7 and go back to writing server-templated web-apps like it’s 2012 again.

There’s a false dichotomy here. You don’t have to give up React to write server-templated web-apps. That being said, I understand what he’s trying to say.

However, I do think that in the transition to the modern web stack (something like React / nodejs / graphql / etc), we’ve unsolved some of what tools like Rails made easy 10 years ago - and I don’t think it needs to be that way.

This post is less a love song to Rails as it is a pitch for the value of unified frameworks in web development.