Alex’s Blag

Migrate Your Asset Pipeline to Rails 7.x

2023-10-24T10:00:00-07:00

After another confusing migration of a Rails app’s asset stack into I finally found a stack that I’m happy with for Rails 7.x.

Before…

I had some Rails 6 and Rails 5 apps. One of them was using webpacker, sprockets 3, bootstrap-sass 3, react, typescript, jquery-ui and jquery-ujs. Two others were using sprockets 3 and bootstrap-sass 3.

The Concept

Use JS-based tools like node-sass and esbuild to compile CSS and JS files and output the compiled files to app/assets/builds
@import any CSS files required by your JS libraries (like date pickers or charts) in your CSS files instead of JS files
Make a list of those built files in app/config/manifest.js so sprockets-4 will let you reference them with javascript_include_tag etc…
Remove webpack

The Solution

1. `cssbundling-rails`

This gives you a nice bin/build-css command. It’s a bash script that compiles all your CSS/SCSS using node-sass, which you will install in your package.json.

You can configure multiple CSS entrypoints in here if you need. Mine looks something like this:

./node_modules/sass/sass.js \
  ./app/assets/stylesheets/application.sass.scss:./app/assets/builds/application.css \
  ./app/assets/stylesheets/admin/application.sass.scss:./app/assets/builds/admin/application.css --no-source-map \
  --load-path=node_modules \
  --load-path=vendor/assets/stylesheets \
  $@

The outputs will all be sent to app/assets/builds.

Some of the JS libraries we use come with CSS dependencies. Previously I was import-ing them in JS files (which always felt weird in a Rails app). Now I can import them into my SCSS files like this:

@import "../../../../node_modules/react-date-range/dist/styles";
@import "../../../../node_modules/@melloware/coloris/dist/coloris";
@import "../../../../vendor/assets/stylesheets/medium-editor";

Note: be sure to remove the .css extension when importing CSS from node_modules. That’s the only way the will import properly.

2. `jsbundling-rails` with `esbuild`

This will auto-create an esbuild.config.js where you can set your JS entrypoints. Mine looks something like this:

require("esbuild")
  .build({
    entryPoints: [
      "app/javascript/dashboard.js",
      "app/javascript/frontend.js",
      "app/javascript/onboarding.js",
    ],
    bundle: true,
    sourcemap: true,
    watch: process.argv.includes("--watch"),
    outdir: "app/assets/builds",
  })
  .catch(() => process.exit(1));

Like with CSS your outputs will all be sent to app/assets/builds.

3. `sprockets 4`

I’d avoided sprocket upgrades for years. Anytime I tried it just got messy and their warnings in the upgrade guide definitely didn’t inspire confidence.

In the end sprockets-4 was simple to get running. I created the sprockets app/config/manifest.js file like this:

//= link_tree ../builds
//= link_tree ../images
//= link_tree ../fonts

The first line references all those files we built in the previous steps. The next two let me use my image_url and font_url helpers as usual.

The sprockets manifest replaces any Rails.application.config.assets.precompile you had before. Get rid of that entirely.

4. Global jQuery

Old Bootstrap, jQuery UI and some old plugins require a global jQuery object. At first I put this at the top of each of my entrypoints:

import jquery from "jquery";
window.$ = window.jQuery = jquery;

…but that was not enough. I needed to move that to a separate file and then import that file. So like this:

// in app/javascript/jquery.js
import jquery from "jquery";
window.$ = window.jQuery = jquery;

// in your other JS files
import "./jquery";
import {} from "jquery-ui";
import {} from "jquery-ujs";
import {} from "bootstrap-sass";

5. Bonus Tips

Ensure your app/assets/builds exists by adding a .keep file or similar. Sprockets won’t work in production without it.

esbuild doesn’t minify by default. Here’s how you can conditionally minify your JS in production.

When importing your local JS files, make sure you import them without extensions so Sprockets can do its thing. So instead of

import "my/forms.js";

remove the extension…

import "my/forms";

Talking Sorbet on Ruby Rogues

2021-09-15T10:00:00-07:00

In August, 2021 I got to check off a Rubyist bucket list item and appear as a guest on the Ruby Rogues podcast.

I was talking about Sorbet and my experiences bringing it into our Rails app. The whole recording process was fun and enjoyable. And after listening for years I’m pleased to be part of that podcast’s illustrious back catalogue.

Take a listen: « Ruby Rogues episode 512 »

BC Vaccine Passport Data Format

2021-09-08T00:00:00-07:00

BC’s COVID-19 vaccine passport is being distributed primarily via QR code. I love QR codes and wanted to see what was encoded in there.

Regardless of the ethics of everything that is going on, from a technical point of view I was pleased to see that the data are narrowly scoped and that the whole system works without provided data back to a central authority.

BC COVID-19 Vaccine Passport Data Format

The QR code payload is encoded as a JSON web token following the SMART Health Card open spec. When you scan it you get a string starting with shc:/. (This is the same format used in Quebec.)

There is a handy JS project called obrassard/shc-extractor where you can decode that string and inspect it yourself. The code to decode the payload is pretty straightforward.

The payload is signed and can be decoded using the public keys provided by the passport issuer. In the case of BC it’s the Provincial Health Services Authority. You can get the keys from https://smarthealthcard.phsa.ca/v1/issuer/.well-known/jwks.json

The payload contains the person’s

first name
last name
birth date
date, location and type of COVID-19 vaccine

There isn’t any other data included in the payload.

Caching the public keys means you can verify vax passport QR codes entirely offline.

Vaccine codes

Each dose of administered vaccine has a specific code. You can inspect the http://snomed.info/sct coding key to see which type of vaccines were administered (source):

28581000087106 – PFIZER-BIONTECH COVID-19 messenger ribonucleic acid 30 micrograms per 0.3 milliliter suspension for dilution for injection Pfizer Canada ULC-BioNTech Manufacturing GmbH (real clinical drug)
28571000087109 – MODERNA COVID-19 messenger ribonucleic acid-1273 100 micrograms per 0.5 milliliter liquid for injection Moderna Therapeutics Inc. (real clinical drug)
28531000087107 – Vaccine product against disease caused by Severe acute respiratory syndrome coronavirus 2 (medicinal product)
1119349007 – Vaccine product containing only Severe acute respiratory syndrome coronavirus 2 messenger ribonucleic acid (medicinal product)

Sample BC Vaccine Passport Contents

{
    "header": {
        "alg": "ES256",
        "zip": "DEF",
        "kid": "XCqxdhhS7SWlPqihaUXovM_FjU65WeoBFGc_ppent0Q"
    },
    "payload": {
        "iss": "https://smarthealthcard.phsa.ca/v1/issuer",
        "nbf": 1630885634,
        "vc": {
            "type": [
                "https://smarthealth.cards#covid19",
                "https://smarthealth.cards#immunization",
                "https://smarthealth.cards#health-card"
            ],
            "credentialSubject": {
                "fhirVersion": "4.0.1",
                "fhirBundle": {
                    "resourceType": "Bundle",
                    "type": "collection",
                    "entry": [
                        {
                            "fullUrl": "resource:0",
                            "resource": {
                                "resourceType": "Patient",
                                "name": [
                                    {
                                        "family": "LASTNAME",
                                        "given": [
                                            "FIRSTNAME"
                                        ]
                                    }
                                ],
                                "birthDate": "1980-01-01"
                            }
                        },
                        {
                            "fullUrl": "resource:1",
                            "resource": {
                                "resourceType": "Immunization",
                                "status": "completed",
                                "vaccineCode": {
                                    "coding": [
                                        {
                                            "system": "http://hl7.org/fhir/sid/cvx",
                                            "code": "208"
                                        },
                                        {
                                            "system": "http://snomed.info/sct",
                                            "code": "28581000087106"
                                        }
                                    ]
                                },
                                "patient": {
                                    "reference": "resource:0"
                                },
                                "occurrenceDateTime": "2021-05-21",
                                "lotNumber": "EW0199",
                                "performer": [
                                    {
                                        "actor": {
                                            "display": "Drop-in Vaccine Clinic"
                                        }
                                    }
                                ]
                            }
                        },
                        {
                            "fullUrl": "resource:2",
                            "resource": {
                                "resourceType": "Immunization",
                                "status": "completed",
                                "vaccineCode": {
                                    "coding": [
                                        {
                                            "system": "http://hl7.org/fhir/sid/cvx",
                                            "code": "208"
                                        },
                                        {
                                            "system": "http://snomed.info/sct",
                                            "code": "28581000087106"
                                        }
                                    ]
                                },
                                "patient": {
                                    "reference": "resource:0"
                                },
                                "occurrenceDateTime": "2021-07-25",
                                "lotNumber": "FD7206",
                                "performer": [
                                    {
                                        "actor": {
                                            "display": "UBC Vax Van"
                                        }
                                    }
                                ]
                            }
                        }
                    ]
                }
            }
        }
    },
    "verifications": {
        "trustable": true,
        "verifiedBy": "XCqxdhhS7SWlPqihaUXovM_FjU65WeoBFGc_ppent0Q",
        "origin": "https://smarthealthcard.phsa.ca/v1/issuer"
    }
}

You can also download the sample vaccine passport via a gist.

I'd love to hear any feedback you might have about this post. Tweet me up at @mrmrbug or email me at code@dunae.ca.

You can also grab a little bit of RSS or check out the rest of the blog.

Using Database Triggers for Caching Counts

2021-06-19T00:00:00-07:00

This is a story
all about how
my counts got flipped
turned rightside down

Today’s post looks at ways to improve an application by leaning more heavily on the database to manage data. Specifically we look at using database triggers for derived inventory counts, simplifying the application code and solving a deadlock along the way.

Moving Data Integrity into the Database

Some of the most satisfying code cleanups I’ve done recently have involved reinforcing data integrity checks from the application down into the database. Modern MySQL (and old Postgres) have plenty of options for add data constraints ranging from a simple NOT NULL to more complex constraints and they are generally rock solid.

Database-level constraints like these are useful because they run no matter what, even if your application validation is bypassed.

they run if you’re doing bulk INSERT INTO target (something) SELECT else FROM external_data from the command line
they run if you’re writing things like UPDATE target SET something = (SELECT else),
they run even if you’re manually editing rows like a maniac 👺

Most times I’ll keep the application-level constraints as well.

Here’s an example using MySQL 8 check constraints as well as application-level validation (in Rails in this case). Both types of constraint help ensure items.quantity_available never goes below 0:

diff --git a/app/models/item.rb b/app/models/item.rb
+  validates :quantity_available, numericality: { only_integer: true, greater_than_or_equal_to: 0 }

diff --git a/db/migrate/20210101000000_add_inventory_check_constraints.rb b/db/migrate/20210101000000_add_inventory_check_constraints.
+class AddInventoryCheckConstraints < ActiveRecord::Migration[6.1]
+  def change
+    add_check_constraint :items, "quantity_available >= 0", name: "chk_items_minimum_quantity_available"
+  end
+end


diff --git a/db/structure.sql b/db/structure.sql
CREATE TABLE `items` (
+  CONSTRAINT `chk_items_minimum_quantity_available` CHECK (`quantity_available` >= 0)

In this example we mirror the constraint (greater than or equal to zero) in both application code and in the database. This redundancy gives us a few nice things:

From the application-level constraint we get:

nice error messages to display to the user (database constraint errors are usually pretty ugly)
easy-to-find validation rules for other developers when they’re browsing the application code (they don’t need to check the database schema)

From the database-level constraint we get:

a guarantee that any manual changes, data imports or database-level calculations will never create invalid data
rules that will be enforced if any other applications start working with our database

This is all pretty straightforward. The rest of this post is going to look at using the database to actually create and mange valid data within the database itself.

`UPDATE constraints SET volume = 11`

The saddest entries I see in my bug tracker are: Mysql2::Error: Deadlock found when trying to get lock; try restarting transaction. They mean that there’s a database deadlock and I know we’re in for some tedious and delicate Heisenbug hunting to trace down the exact set of conditions that caused the database to lock. Yuck.

In one case case – issue #1330 from August 1, 2017 in the bug tracker - it became clear the deadlock was caused by our inventory updating code.

Trigger warning...

The application generates tickets for live events, with a limited number of each ticket type available. In order to have a 100% accurate inventory count we queried the inventory immediately before adding any items to an order.

This sort of code would run many times per second:

START TRANSACTION;

-- get quantity immediately before adding items to an order to ensure 100% accuracy
SELECT SUM(quantity) FROM line_items WHERE item_id = 'item1';

-- insert if available
INSERT INTO line_items (order_id, item_id, quantity) VALUES ('order1', 'item1', 2);

COMMIT;

Here’s the problem: SELECT SUM... would lock the line_items table at the same time as another purchaser was trying to INSERT line_items, creating deadlocks.

We needed a solution that would not run SELECT SUM... in the middle of the critical path of our application.

Cache it?

The first fix we tried to get rid of SELECT SUM... involved caching the inventory counts in Redis. This had potential but our implementation was never solid (a story for another day). We eventually moved on to our current solution: cache the inventory counts directly in the database using triggers.

Trigger happy

A database trigger is…

…a special stored procedure that is run when specific actions occur within a database. Most triggers are defined to run when changes are made to a table’s data …

You can write triggers that automatically run after INSERT, UPDATE or DELETE actions. Like constraints, they’re guaranteed to run no matter how you interact with your database (even manual editing like a maniac 👺). The trigger gets the value of the rows before and after your change, and you can use both old and new values to write some more SQL of your choosing.

Importantly, if a trigger fails it rolls back the entire operation so we don’t need to worry about data getting out of sync.

The new design

The system we landed on to keep our inventory counts in sync worked like this:

listen for any change to the line_items table
when a change is triggered, increment or decrement the related items.quantity_sold field by the amount in line_items.quantity

This meant no more SELECT SUM.... Just simple + and -.

Step: Add an inventory count column to `items` table and model

This column is read-only to the application and will only be updated by the triggers.

diff --git a/app/models/item.rb b/app/models/item.rb
class Item < ApplicationRecord
+  attr_readonly :quantity_sold
end

diff --git a/db/migrate/20210101000000_add_quantity_sold.rb b/db/migrate/20210101000000_add_quantity_sold.
+class AddQuantitySold < ActiveRecord::Migration[6.1]
+  # add counter column to the Items table - this will only be edited by the trigger
+  def change
+    add_columns :items, :quantity_sold, :integer, default: 0, null: false
+  end
+end

diff --git a/db/structure.sql b/db/structure.sql
CREATE TABLE `items` (
+ `quantity_sold` int NOT NULL DEFAULT '0',

Step: Create database triggers for each operation

-- the "AFTER INSERT" trigger
-- simply increments the value of quantity_sold (or decrements if the NEW.quantity is negative)
-- we always update timestamps, too, but you may not need to

CREATE TRIGGER `line_items_after_insert_row_tr` AFTER INSERT ON `line_items`
FOR EACH ROW
BEGIN
    UPDATE items
    SET quantity_sold = (quantity_sold + COALESCE(NEW.quantity, 0)),
        updated_at = UTC_TIMESTAMP(6)
    WHERE id = NEW.item_id;
END

--- the "BEFORE DELETE" trigger

CREATE TRIGGER `line_items_before_delete_row_tr` BEFORE DELETE ON `line_items`
FOR EACH ROW
BEGIN
  UPDATE items
  SET quantity_sold = (quantity_sold - OLD.quantity),
      updated_at = UTC_TIMESTAMP(6)
  WHERE id = OLD.item_id;
END

--- the "BEFORE UPDATE" trigger
--- this is a special guard to forbid changing a line item's ITEM_ID once it has been set
--- adding that restriction dramatically simplified our trigger code and fits logically with
--- how our system works.  If you find your triggers getting crazy feel free to set your own guards
--- to limit the possible states your data can be in.
---
--- For MySQL the easiest way to signal an error is with SIGNAL SQLSTATE
--- https://dev.mysql.com/doc/refman/8.0/en/signal.html

CREATE TRIGGER `line_items_before_update_row_tr` BEFORE UPDATE ON `line_items`
FOR EACH ROW
BEGIN
IF NEW.item_id <> OLD.item_id OR (NEW.item_id IS NULL) <> (OLD.item_id IS NULL) THEN
  SIGNAL SQLSTATE '45000' SET message_text = 'Changes to LineItem#item_id are forbidden';
END IF;
END

-- the "AFTER UPDATE" trigger
-- in order to reduce un-necessary update calls this trigger only runs
-- if an update actually changes the quantity
-- it also uses COALESCE to ensure our NEW.value is non-null

CREATE TRIGGER `line_items_after_update_row_tr` AFTER UPDATE ON `line_items`
FOR EACH ROW
BEGIN
IF NEW.quantity <> OLD.quantity THEN
  SET @delta_quantity_sold = (COALESCE(NEW.quantity, 0) - COALESCE(OLD.quantity, 0));
  UPDATE items
  SET quantity_sold = (quantity_sold + COALESCE(@delta_quantity_sold, 0)),
      updated_at = UTC_TIMESTAMP(6)
  WHERE id = NEW.item_id;
  END IF;
END

Step: Add tests

It’s important to be able to run your tests against the same version of database that you run in production. That’s a good practice anyways, and thankfully Rails and modern CI systems make that super easy.

Because this code was going to be largely out-of-sight, we added a decent number of unit tests to ensure every edge case results in proper counts.

Did it work? Ya!

This system has been running without issue for several years now and is rock solid. There are no more deadlocks since we no longer run SELECT SUM... and so are putting way less presure on the line_items table.

Moving such crucial code out of the application layer was nerve-wracking. This post began by talking about how great it was to have constraints at both the application and database levels. Well, this change moved the responsibility for data integrity entirely out of the application and into the database.

We knew the database would do a good job but we were worried about the developer experience. Would the triggers be hard to work with? Would they fail and be hard to debug? Would the math be wrong and we wouldn’t know why? Would we forget how they worked?

It also just seemed too simple. We were used to always running SUM on the entire data set. This just did puny little + and - operations on a single row at a time, relying on the atomicity of the database engine.

Happily, our worries have not come true. Triggers have been great. I think the reason triggers worked so well is that we chose a stable, rarely-changing and narrowly-scoped slice of our application. I wouldn’t want triggers in a chunk of code that changed frequently.

A few Rails specifics

This strategy works for any tech stack. We use Rails, which give us a few niceties. The main one is that Rails stores the database migrations directly beside application code, keeping things in sync. We don’t have dedicated DBAs, so the same people write SQL and Ruby, allowing for super close coordination.

The other is that Rails makes it easy to spin up and destroy test databases using the same database engine we use in production. This is key for getting good test coverage of our triggers.

We manually write the trigger modifying code in our Rails migrations. We looked at using the hair_trigger gem but I don’t think it played well with MySQL way back then. It might now. In any case, this code changes so rarely it’s not a big deal.

The End

Thanks to Corey Maas, Nico teWinkel and Yosuke Hasumi for reading drafts of this post.

And thank you for reading it!

I'd love to hear any feedback you might have about this post. Tweet me up at @mrmrbug or email me at code@dunae.ca.

You can also grab a little bit of RSS or check out the rest of the blog.

Sorbet Journey, Part 4: Sorbet Stability

2021-05-25T14:00:00-07:00

Sorbet Journey

This is an ongoing series about adding Sorbet to a mature Rails code base. Follow me on Twitter to find out when updates are posted.

It’s been six months since we started using Sorbet in earnest, so it seems like a fitting time for reflection.

TL;DR

Sorbet is great and I’m glad we added it. There is an occassional bit of awkwardness, but the benefits remain well worth it. I much prefer Rails with Sorbet on top.

Where Are We At?

Our original goal was to be able to refactor and develop with confidence on our “mature” Rails codebase. It had reached a size where it was hard to hold all the pieces in your head, and subsystems were stable enough that they wouldn’t need any dev time for months on end.

We hoped that adding types would…

surface existing subtle bugs,
prevent collateral damage when refactoring, and
allow us to move thoughtfully and not break things.

We added types incrementally, usually whenever we started working in a new area of the codebase.

We started with models, then moved on to service classes, internal libraries and background workers. We typed a handful of view helpers (which were surprisingly buggy) and mailers.

We still have not typed any controllers yet.

Sorbet Strictness	% of files
ignore	3%
false	35%
true	39%
strict	16%
strong	7%

Thinking in Types: Bug Squashing

Sorbet has changed the way we start to investigate bugs. Now, we start by looking to see if the code involved is strictly typed yet. If not, we’ll start by adding types to the code. The act of adding types is a great warm up for getting familiar with a section of code. It gives us a chance to reacquaint ourselves with our assumptions and the data types involved.

The process of adding types will often reveal the bug, somewhere around half the time.

If the bug isn’t revealed, learning that the types are ok lets us exclude a whole class of bugs from our bug hunt and sharpen our focus.

Thinking in Types: `nil`

A subtle but far-reaching change in my own thinking has been how nil now stands out as a wild and infectious value. The explicitness that Sorbet requires with nils (T.let and T.must) has made me think very carefully about what should be nullable. Since anything that is nullable now feels like it’s going to be more work (because it is), we avoid nullable values unless they actually make sense.

This null-avoidance has even spread to the schema database, where we’ve tightened up some sloppily defined column types.

There will always be plenty of nils in the code; we’re just more aware of them now.

(I’ve also gotten pretty enamoured with the concept of Maybe types, but that’s a story for a different day.)

Thinking in Types: Hashes => Structs

Passing around complex values like hashes is another area where Sorbet’s influence is felt. Defining the shapes of hashes in Sorbet isn’t amazing, so we’ve converted a good number to T::Structs to take advantage of all the type goodness.

So data structures like:

{ payment: ..., application_fee: ..., amount_to_refund_cents: 123_45 }

become the much more lovely…

class RefundResult < T::Struct
    const :payment, Payment
    const :application_fee, Stripe::ApplicationFee
    const :amount_to_refund_cents, Integer
end

We did some of this before Sorbet, but Sorbet just made it more compelling.

Thinking in Types: Arrays vs CollectionProxy

Before Sorbet, we’d treat arrays of ActiveRecord objects and ActiveRecord::Associations::CollectionProxy collections identically. In some ways this was really nice; after all one of the joys of Ruby and Rails is duck-typing and just iterating without a care in the world.

Sorbet makes us aware of the differences, and it’s sometimes being useful to be more explicit about these. Methods like #sum work pretty differently on Enumerable compared to CollectionProxy so its nice to know what we’re working with.

This change isn’t a pure net positive since it adds a level of strictness we don’t always need. I’d call this one more 50/50.

Tooling

The Sorbet tooling remains pretty good. Or rather, we’ve stuck with the tooling back from when we started and haven’t needed to move on.

Our stack is still just sorbet-rails, a little bit of sorbet-typed and the Sublime LSP plugin. We had always intended to move to tapioca since it seemed like The Right Way to do things, but sorbet-rails has given us everything that we need.

We don’t have any strict process for re-generating Sorbet’s hidden definitions. We update gem dependencies all the time (via Dependabot) and only rarely need to make any further updates. Sorbet continues to work just fine.

A few updates to sorbet-runtime have caused issues, but they’ve all been resolved by just waiting for the next weekly release.

Onward

We <3 Sorbet. It’s great, and it’s made working on old code feel much more secure.

The stock tooling has been enough for us to get plenty of benefits with minimal fuss and we’ll stick with it for the time being.

I expected to have to get more into the guts of things (and did a little bit) but Sorbet has been pleasantly, wonderfully boring.

I'd love to hear any feedback you might have about this post. Tweet me up at @mrmrbug or email me at code@dunae.ca.

You can also grab a little bit of RSS or check out the rest of the blog.

Workshop Notes: Intro to React and Typescript

2021-03-10T09:00:00-08:00

In February, 2021 I led a fun little workshop introducing React and Typescript via the Interactive Media and Design program at North Island College. The target audience was pretty broad: students, faculty looking to do some continuing education and members of the community.

I’ve always enjoyed presenting but haven’t done much lately essentially due to time restrictions. I’m hoping to do more. These are some notes to myself for the future.

Ingenuity on the Edge React with Alex Dunae - Compressed from NIC School of Fine Art + Design on Vimeo.

Notes on Presenting

Regular commits to source control during the presentation worked great, so people did not need to stay up to date with live coding.
Live-ish coding worked suprisingly well. I had the entire app written in steps and could cut and paste large chunks from my second monitor, but typing and talk was the most natural since it showed the true development flow. This was especially true when talking about Typescript and autocomplete.
Having intro slides was vital. I had planned to talk for about 20 minutes in the beginning about high-level concepts but didn’t plan on having slides until a few days before. I quickly made some up and they were really beneficial. Part of that benefit was that creating the slides was an additional editing step, forcing me to be even more concise and organized.
carbon.now.sh is amazing for creating minimal code screenshots
Talking slowly was well received. I left huge gaps at the end of “paragraphs”, spoke slowly and repeated my concluding sentences. I thought that this would be annoying, but it seemed to work well with the diverse audience.
I left a few areas that could be cut out entirely (e.g. adding Sparklines) if time got tight. It was helpful to have escape hatches since we ended up running long.
The college recorded the workshop and managed Q&A, which let me just focus on the workshop.

The workshop was virtual due to Covid, and I was pretty concerned about not getting any visual feedback. In the end it was fine, but next time I would like to find a way to get a little bit more interaction with the attendees.

Source Control as Handout Material

I created a bare source repository that participants could clone as their starting point and posted the live project on Netlify. While I live coded I pushed all the changes to their own branch, keeping the original bare repo clean.

Links

Blank starting repo

Commits during the workshop

Keynote slides

Video recording of the workshop

Sorbet Journey, Part 3: A Typical Day Adding Sorbet to a Rails App

2020-12-28T14:27:05-08:00

Sorbet Journey

This is an ongoing series about adding Sorbet to a mature Rails code base. Follow me on Twitter to find out when updates are posted.

In This Episode of Sorbet Journey…

We’re a few weeks in working with Sorbet in our Rails mainline app and we’ve found there’s a natural kind of rhythm to the process. The task at hand is a refactor of the way a purchase’s line items are handled. This requires some big, wide-reaching changes so we’re taking some dev cycles to do some deep cleaning and tech-debt paydown.

(These big changes are what made Sorbet so appealing – it’s giving us more confidence around making big, wide-reaching changes.)

But First: Make Sure You Have Tests

Having a comprehensive test suite has been super important as part of adding Sorbet to our Rails application. T.must and friends raise exceptions on invalid data.

Many times we’ve gotten everything passing the srb tc typechecker beautifully only to have CI explode with hundreds of failures because T.must got a nil or some typed method got passed something from an untyped part of the code base.

This is a good thing, since Sorbet is catching undefined behaviour and forcing explicit code. But without comprehensive tests we would be having a bad time.

The Usual Steps

So, these are the steps happen pretty much every time we start adding Sorbet to a part of the app.

Step: Increase Strictness, Check for Breakage

We chose an area, set typed: true if it wasn’t already and then add one or two sig {} declarations in key locations. We’ll often start by typing the attr_readers and initializers since they affect most of the file.

class ParamsParser
+  extend T::Sig
+
+  sig { returns(T.any(LineItem::RelationType, T::Array[LineItem])) }
   attr_reader :line_items
+
+  sig { params(line_items: T.any(LineItem::RelationType, T::Array[LineItem])).void }
   def initialize(line_items)
     @line_items = line_items
   end
end

Step: Run `sorbet-rails` on Affected Models

We’re using sorbet-rails to get Rails and Sorbet playing nicely together. sorbet-rails lets you generate RBI files for models, controllers and other Rails files. In order to make our migration to Sorbet as low-impact as possible, we didn’t run sorbet-rails on many files to start. Just enough to get a feel for things.

Because Sorbet needs to know something about those files, it created basic stubs for all our models in the hidden-definitions RBI file. The auto-generated hidden-definitions are pretty good, but sorbet-rails has Rails-specific knowledge that make enums and relations work properly.

So, we’ll run sorbet-rails on specific models as we come across them as part of our daily work. This will generate a proper RBI file (e.g. sorbet/rails-rbi/models/your_model.rbi) for each model with enum types, relation types and knowledge of some of our model mixins like money-rails (more on that in a future post).

Step: Rewrite Callbacks

Our single most frequent change is with ActiveRecord callbacks. Sorbet doesn’t like Rails callbacks using procs (you can’t use instance methods in proc callbacks) so we rewrite them with actual methods.

class RedemptionCode < ApplicationRecord
-  before_save do
-    self.code = code.to_s.downcase
-  end
+  before_save :normalize_before_save
+
+  private
+
+  def normalize_before_save
+    self.code = code.to_s.downcase
+  end
end

Easy enough.

Step: Add Nil Guards

When we first tried Sorbet about a year ago our code ended up littered with T.must everywhere (you wrap T.must around code to promise Sorbet that it is not null). This time around I spent a bit of time learning about what Sorbet can know about code, specifically about what might be nil. Funny how learning the rules makes things easier…

# Here's an example...
class MyModel
  def ticket_count
    # we know this will _probably_ return the same value each time, but Sorbet doesn't
    get_from_database(ticket_count)
  end
end

record = MyModel.new

# This won't work with Sorbet nil checking since
# Sorbet calls `record.ticket_count` two times and
# doesn't do a nil check the second time
if record.ticket_count && record.ticket_count > 100
    # ...
end

# Assigning a variable and doing a T.must assertion is the
# way to Sorbet happiness
ticket_count = T.must(record.ticket_count)
if ticket_count > 100
# ...
end

Some code like this is still inevitable:

def not_started?
-    starts_at? && starts_at > Time.now
+    starts_at? && T.must(starts_at) > Time.now
end

But for many cases a well-placed variable assignment can limit the T.must clutter.

-  result = quantity_per_item[item_id]&.seat_ids.take(quantity)
+
+  seat_ids = T.must(quantity_per_item[item_id].seat_ids) if quantity_per_item[item_id]&.seat_ids
+  result = item.seat_ids.take(quantity)

Interesting Code Changes

Refactoring Hashes to a Proper Data Structure

One of the core refactors we have been tackling is taking a Hash of user input (modifying the Items in an Order) and turning it into a strictly defined data structure. We could have done this without Sorbet, but having Sorbet typecheck during development and throw errors as part of our test runs made this refactor much easier.

The data structure we ended up with was like this:

# typed: strict

# A container for parsed and sanitized "modify cart" requests.
# Usually created via ParseCartQuantityParams.
class CartItemParams < T::Struct
  extend T::Sig
  prop :quantity, Integer
  prop :seat_ids, T::Array[Integer], default: []
  # various other props and methods
end

Which were then created like this:

+ sig { params(item_id: Integer, param: T::Hash[Symbol, T.untyped]).returns(CartItemParams) }
  def parse_quantity_param(item_id, param)
+    # all the parsing and sanitizing rules for CartItemParams in one place
  end

And in dozens of files, we can now made changes like this:

module Seats
  class UpdateForOrderByQuantity
+   sig { params(item_quantity: CartItemParams).void }
    def update(item_quantity)
-      # lots of unconfident code like...
-      quantity = item_quantity.fetch(:quantity, nil)&.to_i
-      seat_ids = Array(item_quantity.fetch(:seat_ids, []]).compact.map(&:to_i).uniq
+
+      # and instead we can have our nice object
+      item_quantities.quantity
+      item_quantities.seat_ids.empty?
  end
end

Just to re-iterate, all of the above is possible without Sorbet. Sorbet just made it easier and gave us much more confidence that it actually worked.

View Helpers (Yuck)

Rails’ view helpers have always been a bit of a nasty part of our code base. That continues. At least now they’re nasty with types.

The problem is that our view helpers are unstructured. Our ApplicationHelper has code that deals with routing, timezones, currency formatting, date formatting and meta tags. I’m not sure what’s in BaseHelper, CoreHelper or StoreHelper. Maybe spiders?

Many of our helpers also call global controller helper methods, like current_user and current_store.

Adding typed: true to the top of most view helpers caused dozens of errors that we weren’t ready to tackle yet. Instead we did a bit of reorganizing. We moved the methods we were ready to add types to new, narrowly defined helper modules left the other ones as typed: false for now.

--- /dev/null
+++ b/app/helpers/currency_helper.rb
+module CurrencyHelper
+   sig { params(amount: T.nilable(Money), precision: Integer).returns(String) }
+   def currency(amount, precision: 2)
+     amount ||= Money.zero
+     number_to_currency(amount.round, precision: precision) || ''
+   end
+end

Unfortunately we currently use some of these methods in non-view parts of code. For example, that currency formatting method is called in some models’ to_json methods. So for now we have code like this:

class SomeModel
+  include CurrencyHelper
end

sorbet-rails creates a module with all of your helpers in it but we weren’t able to get it working. We’ll dig deeper when we start working on more code that uses helpers.

This whole area is a work in progress. It feels like Sorbet just surfaced a bunch of unpleasant code that already existed, so we don’t blame Sorbet for all this, but the best way forward isn’t immediately clear.

Converting Request Params to Hashes

Right near the end of this refactor we finally touched the boundary where some user input comes in: a JSON API endpoint. Our internal code had all been operating happily on a Hash with Symbol keys (i.e. T::Hash[Symbol, T.untyped]). but our API endpoint had ActionController::Parameters.

My first instinct was to update our signatures to accept parameters:

- sig { params(params: T::Hash[Symbol, T.untyped]) }
+ sig { params(params: T.any(T::Hash[Symbol, T.untyped], ActionController::Parameters)) }

But then I remembered HashWithIndifferentAccess and hashes with string keys and remebered all the subtle issues that come up with dealing hash types (e.g. to_unsafe_h, deep_symbolize_keys, etc…).

So instead we took the opportunity to lock down the hashes we accept. We left the Sorbet signature unchanged and turned ActionController::Parameters into a hash earlier:

- purchase_params = ActionController::Parameters.new(params).permit(*PURCHASE_PARAM_KEYS)
+ purchase_params = ActionController::Parameters.new(params).permit(*PURCHASE_PARAM_KEYS).to_h

We haven’t added Sorbet to any controllers yet, so this may change. And we may change the place where to_h gets called. But at least we have this defined somewhere for once. Eliminating vague behaviour is exactly what we wanted to get from Sorbet.

Relations, Arrays and `RelationType`

Throughout our app we had many places where arrays or ActiveRecord relations could be passed, often calling to_a just to be safe when we didn’t know what we actually add. Sorbet has forced us to be explicit about those. It seems like an improvement in this early days, but it takes away a bit of the Rails magic of just iterating on whatever objects you find.

Be sure to use the RelationType alias from sorbet-rails when dealing with relations so you don’t end up with long T.any(...) signatures for your relation types.

RelationType combined with ActiveRecord#none for empty results is that way to happiness.

Summing Up

Things are going well. We’ve got about 25% of our models that have been specifically typed. We’ve found some bugs and gotten a bit of refactoring done with increased confidence.

sorbet-rails has been solid. We haven’t run tapioca yet but expect that’s coming soon. In a future post we’ll talk about adding types for an ActiveRecord plugin (money-rails).

I'd love to hear any feedback you might have about this post. Tweet me up at @mrmrbug or email me at code@dunae.ca.

You can also grab a little bit of RSS or check out the rest of the blog.

Sorbet Journey, Part 2: Adding Sorbet to an Existing Ruby Gem

2020-12-09T14:27:05-08:00

Sorbet Journey

This is an ongoing series about adding Sorbet to a mature Rails code base. Follow me on Twitter to find out when updates are posted.

What’s Happening

We chose a super simple gem to use to get a feel for Sorbet in the real world: tickit-best-seats. This gem contains our seat selection algorithm for chosing the “best available” seats when you buy tickets for an event, following all sorts of business rules. We chose it because it is largely self-contained, it only uses the Ruby standard library and it works on simple, well-defined data structures.

TL;DR

Overall, adding Sorbet was an overwhelmingly positive experience. We caught some subtle bugs, tightened up some sloppy data structures and added a lot of safety guarantees. Some of Sorbet’s current limitations (e.g. lack of splat support) forced a little bit of awkward rewriting. All in all, the upsides – for this small library – far outweighed the downsides.

The Steps

Here are a few notes about the process of getting Sorbet wired up.

Step: Cleaning Up Dependencies

Since Sorbet is going to need to create RBI files for any dependencies I wanted to keep things as clean as possible. Our gem hadn’t had any active development for about two years, so it was good to get freshened up anyways.

Almost all the dependencies for this gem are development only. It uses juwelier for gem packaging, which unfortunately brings in a lot of other sub-dependencies which ended up causing some issues.

Our final gemspec…

s.add_runtime_dependency('sorbet-runtime-stub')
s.add_development_dependency('amazing_print')
s.add_development_dependency('benchmark-ips')
s.add_development_dependency('bundler')
s.add_development_dependency('juwelier')
s.add_development_dependency('minitest')
s.add_development_dependency('parlour')
s.add_development_dependency('rubocop')
s.add_development_dependency('rubocop-performance')
s.add_development_dependency('rubocop-sorbet')
s.add_development_dependency('ruby-prof')
s.add_development_dependency('sorbet')
s.add_development_dependency('sorbet-runtime')
s.add_development_dependency('tapioca')

This modest gemspec resulted in 52 RBI files being brought in, including nokogiri, pry, hashie and a bunch of other things we don’t use directly. It’s understandable that they’re needed, but all the dependent RBIs add visual and mental clutter in git and our editors.

In these early days it was helpful to be able to grep these files. In future it might be possible to exclude them from our editor config, but they’ll always be in our repositories.

Step: Add `rubocop-sorbet` and sigils

Shopify’s rubocop-sorbet gem was helpful to catch a few things before actually bringing in Sorbet. Our gem is so simple that it didn’t catch much. The main change was to add all the # typed: false sigils to each file.

Adding the sigils creates a big messy commit. It wasn’t until later that I discovered the default-strictness option that was added to Sorbet. It lets you run srb init without having to touch every single Ruby file. Needing to touch every single Ruby file to get started with Sorbet is a definite turn off. Promoting using default-strictness might be a good way to make the first-run experience better.

Step: Wire up Sorbet

After seeing Shopify’s talk we were convinced to use tapioca instead of srb rbi for gem RBIs and it worked pretty well. The basic steps were:

Comment-out a glitchy gem (see below)
bundle exec srb init
rm -rf sorbet/rbi/sorbet-typed/ and rm -rf sorbet/rbi/gems/ (since we’re going to use tapioca)
bundle exec tapioca generate (create all the actual gem RBIs that we will use)
bundle exec srb rbi hidden-definitions (since these will have changed after running tapioca)

There was one rough edge with srb init. The juwelier gem is old and has some problematic dependencies. We spent the better part of a day trying to chase down answers before realizing it was easier to just comment it out before running srb init.

There were two errors we saw.

The first appears to be because of psych being loaded as a gem:

sorbet/rbi/gems/psych@3.2.0.rbi:223: Method Psych::Nodes::Node#to_ruby redefined without matching argument count. Expected: 0, got: 2 https://srb.help/4010
     223 |  def to_ruby(symbolize_names: T.unsafe(nil), freeze: T.unsafe(nil)); end
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    https://github.com/sorbet/sorbet/tree/3a01f6f45b1760e255239166e76db90c33690bfb/rbi/stdlib/psych.rbi#L875: Previous definition
     875 |  def to_ruby(); end

psych is in the Ruby standard library, but srb init attempted to create separate gem definitions, causing these Previous definition errors.

The second was about a namespace already being defined (which we never bothered to diagnose further):

.../gems/github_api-0.19.0/lib/github_api/api.rb:328:in `namespace': namespace 'say' is already defined (ArgumentError)

Commenting out the gem was thankfully easy in this case. If it hadn’t been we would likely have either forked our glitchy dependencies or chosen new ones.

Step: Configure `sorbet-runtime-stub`

We only wanted Sorbet to strictly enforce types during development while we’re still evaluating the toolchain. Shopify’s sorbet-runtime-stub library let’s that happen. It stubs out all of the sorbet-runtime T methods as no-ops, so T.cast and T.must, for example, don’t have any effect.

We only want it to run these stubs in the released “production” gem so we add this to the top of our main library code:

require 'sorbet-runtime-stub' unless defined?(T)

In order to still get the sorbet-runtime checks in development you can require 'sorbet-runtime' in your Rakefile and test_helper.rb.

(After going down this route we discovered T::Sig::WithoutRuntime which looks like another useful tool for avoiding runtime checks in dependencies.)

Code Changes

Here are some of the bits of code that actually changed as a result of adding Sorbet.

Data Structure Improvements

The seat search results are passed around as an array like [SearchScore, [SeatObject, SeatObject, SeatObject]]. The score could be false, nil, Integer or Float depending on the context.

This was never ideal, but defining Sorbet’s types made it plain just how silly it was. No one wants to write T.nilable(T.any(T::Boolean, Integer, Float)) all the time. Instead we used a non-nullable float, using the much more elegant -Float::INFINITY for “no results”. Our data structures got tighter and we got to remove some conditionals at the same time.

-  NO_RESULTS = [false, []].freeze
+  NO_RESULTS = [-Float::INFINITY, []].freeze

More Explicit Constructors

While it wasn’t strictly necessary, we ended up being much more explicit with all of our initializers, even when added typed: true strictness where typed initializers are not actually required.

Adding these types added a bunch of ceremony to the top of each class, but the benefits of explicit types everywhere seemed to be worth it.

Before (Quick Class Initialization)

class Seat
    attr_reader :seat_id, :parent

    def initialize(seat_id, parent)
        @seat_id = seat_id
        parent = parent
    end
end

After (More Explicit Class Initialization)

class Seat
    sig { returns(String) }
    attr_reader :seat_id

    sig { returns(T.nilable(SeatContainer)) }
    attr_reader :parent

    sig do
       params(
         seat_id: String,
         parent:  T.nilable(SeatContainer)
       ).void
     end
    def initialize(seat_id, parent)
        @seat_id = seat_id
        parent = parent
    end
end

Polymorphism Is Not As Fun

Our seat maps are made of SeatContainer objects with contain either more SeatContainer objects, or actual Seats. In Sorbet that looks like:

class SeatContainer
    sig { returns(T::Array[T.any(SeatContainer, Seat)) }
    attr_reader :children
end

Before Sorbet that served us really well. Duck-typing made things work nicely and we recursed by checking parent? and children? methods quite elegantly.

After our first pass with Sorbet this wasn’t working well; Sorbet really wanted to know if it was either a SeatContainer or a Seat. The fastest way forward (remembering this is still our proof-of-concept) was to add lookup methods that filtered and cast the child elements before returning the results, e.g.

class SeatContainer
    sig { returns(T.nilable(Seat)) }
    def seat_children(child_index)
        return unless is_seat_container?
        T.cast(children[child_index], Seat)
    end
end

Pretty clunky. I’m sure that Sorbet’s abstract types would help us out, but we didn’t get that far during our first experiments.

Splats with Uknown Array Sizes

This might be a super specific limitation to our codebase, but I think illustrates the pitfalls of using a still-in-development toolchain. We used to call values_at(*some_indexes) but Sorbet does not support splats with variable numbers of arguments. So we had to do some rewriting:

-    seats = children.values_at(*chunk.indexes)
+    seats = seats_at_indexes(chunk.indexes)
+
+    sig { params(indexes: T::Array[Integer]).returns(T::Array[Seat]) }
+    def seats_at_indexes(indexes)
+      indexes.map do |index|
+        children[index]
+      end.compact
+    end

Creating our Gem’s RBI File with Parlour

Since we are already doing all the type definition work it seemed our final step should be to generate our own RBI files to ship with the gem. Otherwise, when we use our gem we’d be relying on tapioca or hidden-definitions when we really shouldn’t need to.

parlour seemed to be the tool we needed. I was hesitant to add more dependencies and it wasn’t clear what its role is in the Sorbet ecosystem. parlour is used heavily by tapioca and sorbet-rails and has received PRs from Shopify so it’s sort-of blessed. Blessed enough for us, at least.

It was super easy to run: we created a .parlour file and ran bundle exec parlour and it was done.

Including RBI files with gems is pretty lightly documented and still feels like a work in progress. We ran into a few issues once we started using the gem in the Rails app, but we’ll save those for the next post.

Wrapping Up

Starting our Sorbet journey with an isolated gem was a useful excercise. It got us comfortable with Sorbet syntax and concepts (e.g. T.must for nil checks) without needing to wrangle an entire Rails meta-programmed monolith. It also let us experiment with different parts of the toolchain (e.g. srb rbi vs tapioca).

Sorbet checks are now a required step in this gem’s CI test suite and the Sorbet-ified version of our gem is now live. We’ve already started applying the lessons learned here to our main app. Stay tuned for that post.

I'd love to hear any feedback you might have about this post. Tweet me up at @mrmrbug or email me at code@dunae.ca.

You can also grab a little bit of RSS or check out the rest of the blog.

Sorbet Journey, Part 1: Why Add Types to a Rails App

2020-12-01T14:27:05-08:00

Sorbet Journey

This is an ongoing series about adding Sorbet to a mature Rails code base. Follow me on Twitter to find out when updates are posted.

TL;DR

Working on a big code base without types is hard. We’ve been interested in Sorbet for a while but were waiting for the “right time.” As of late 2020 we’re going to give it a real try.

What’s the Problem

I oversee a ten-year-old “majestic monolith” Rails application. The app is Tickit, an event ticket sales system (a competitor to Eventbrite and Brown Paper Tickets). It deals with money in various currencies, events in various timezones, sales over various channels, and generates tickets according to various rules.

The app is around 100k lines of code and it is decently factored given its age. There are lots of high quality tests. Even so, it’s been getting harder and harder to change the app with confidence. A typical change to any business logic involves re-building a mental map of the data flowing from storefront to the backend, often wrapped up in hashes like this:

{
  12356 => { quantity: 2, freeform_base_price: '125.50', delivery: 'digital' },
  44123 => { quantity: 5, delivery: 'digital' }
}

And then they get decorated with payment requirements…

cart.grand_total # => Money.new(123_45, 'USD')
cart.display_fees # => Money.zero('USD')

Which are sometimes modified as cents…

cart.gratuity_cents = 10_00

And payment methods…

{
  payment_source: { name: '', payment_type: 'apple_pay' }
}

And seat selection…

{
  seat_selection_mode: 'manual',
  seat_qids: %w[e1-a e1-b]
}

Every request involves building up data structures from request payloads, passing them down through the business logic and back to the user, transforming them as we go. At every step we need to be sure that all the transforms that have happened are typesafe and appropriate. Pretty standard stuff, but time consuming nonetheless.

Our automated tests were extensive and gave us confidence, but a full CI run can take ten minutes and that feedback loop is too long. We want to be warned immediately if we try to put a Money object where an Integer is meant to be.

We Got a Taste of Typescript

We started converting our vanilla JS and CoffeeScript over to TypeScript about a year ago and it has been a fantastic win. Other than some tooling issues, day-to-day development using TypeScript has added a huge layer of confidence and increased code quality.

An unexpected bonus was IDE integration: after years of being a Sublime Text minimalist, moving to VS Code and getting auto-complete when writing TypeScript has been amazing.

Anytime we’ve had to write JS instead of TypeScript it has felt like a big step backwards. Writing Ruby without types was starting to feel the same, too.

Just Add Types

We experimented with Sorbet when it first came out, but found too many rough edges when adding it to our code base. There was a lot we were excited about, but we didn’t have the resources to pursue it then. We filed it away for future exploration.

This November, Shopify published a blog post about adopting Sorbet and hosted a webinar focusing on their Tapioca library. If Shopify can run Rails master and Sorbet, we figured, maybe it was ready for us to try with our more, uh, modest resources.

Rather than starting with our main app, we decided to start with a single private gem of ours to get a feel for Sorbet at its various strictness levels. If that went well, we could look at adding Sorbet to the main Rails app. So that’s where we began.

I'd love to hear any feedback you might have about this post. Tweet me up at @mrmrbug or email me at code@dunae.ca.

You can also grab a little bit of RSS or check out the rest of the blog.

Alex’s Blag

Migrate Your Asset Pipeline to Rails 7.x

Before…

The Concept

The Solution

1. cssbundling-rails

2. jsbundling-rails with esbuild

3. sprockets 4

4. Global jQuery

5. Bonus Tips

Talking Sorbet on Ruby Rogues

BC Vaccine Passport Data Format

BC COVID-19 Vaccine Passport Data Format

Vaccine codes

Sample BC Vaccine Passport Contents

Using Database Triggers for Caching Counts

Moving Data Integrity into the Database

UPDATE constraints SET volume = 11

Cache it?

Trigger happy

The new design

Step: Add an inventory count column to items table and model

Step: Create database triggers for each operation

Step: Add tests

Did it work? Ya!

A few Rails specifics

Further Reading

The End

Sorbet Journey, Part 4: Sorbet Stability

Sorbet Journey

TL;DR

Where Are We At?

Thinking in Types: Bug Squashing

Thinking in Types: nil

Thinking in Types: Hashes => Structs

Thinking in Types: Arrays vs CollectionProxy

Tooling

Onward

Workshop Notes: Intro to React and Typescript

Notes on Presenting

Source Control as Handout Material

Links

Sorbet Journey, Part 3: A Typical Day Adding Sorbet to a Rails App

Sorbet Journey

In This Episode of Sorbet Journey…

But First: Make Sure You Have Tests

The Usual Steps

Step: Increase Strictness, Check for Breakage

Step: Run sorbet-rails on Affected Models

Step: Rewrite Callbacks

Step: Add Nil Guards

Interesting Code Changes

Refactoring Hashes to a Proper Data Structure

View Helpers (Yuck)

Converting Request Params to Hashes

Relations, Arrays and RelationType

Summing Up

Sorbet Journey, Part 2: Adding Sorbet to an Existing Ruby Gem

Sorbet Journey

What’s Happening

TL;DR

The Steps

Step: Cleaning Up Dependencies

Step: Add rubocop-sorbet and sigils

Step: Wire up Sorbet

Step: Configure sorbet-runtime-stub

Code Changes

Data Structure Improvements

More Explicit Constructors

Before (Quick Class Initialization)

After (More Explicit Class Initialization)

Polymorphism Is Not As Fun

Splats with Uknown Array Sizes

Creating our Gem’s RBI File with Parlour

Wrapping Up

Sorbet Journey, Part 1: Why Add Types to a Rails App

Sorbet Journey

TL;DR

What’s the Problem

We Got a Taste of Typescript

1. `cssbundling-rails`

2. `jsbundling-rails` with `esbuild`

3. `sprockets 4`

`UPDATE constraints SET volume = 11`

Step: Add an inventory count column to `items` table and model

Thinking in Types: `nil`

Step: Run `sorbet-rails` on Affected Models

Relations, Arrays and `RelationType`

Step: Add `rubocop-sorbet` and sigils

Step: Configure `sorbet-runtime-stub`