Felipe Moyano - English Blog

Integration Testing Remix Routes with Vitest

2023-09-26T01:32:39Z

In this article we'll go through the necessary steps to setup the tooling around your remix App so you can run integration tests for your Route components, loaders and actions.

Disclaimer: When I first started writing this post, the official Remix as a Vite plugin hadn't been released. I haven't tried it myself but I imagine most of this setup is still relevant.

Full Stack React

I've really been enjoying building Apps with Remix. Or rather, I've always enjoyed building apps with full stack frameworks, even though I've spent a significant amount of my development hours in React land for the past 4 years. Since I usually work on small to medium sized teams responsible for the whole stack, I've always found it a burden having to work on a separate layer when a frontend framework was necessary. That includes a handful of different setups, from monorepos, glue libraries (like react-rails), separate pipelines, and such.

With Remix I no longer feel the dread of having to maintain to different projects when it comes down to using React. Everything can live nicely under the same repository, share types, build pipeline, deploy to whatever cloud you want to, and access your database from a long running Nodejs server where you can bring in the whole ecosystem of libraries as needed.

Still, Remix is far from a full-stack framework nor is it trying to become one: they've clearly stated that they don't want to dictate the architecture of people's applications. That's a perfectly fine choice for the maintainers, they're already solving some really hard problems to bring us the magic experience of seamless frontend and backend integration, but it does mean that you're on your own when it comes to setting up certain core features that we've grown accustomed to in frameworks such as Rails, Laravel or Phoenix such as testing.

About Testing Remix Apps

It's worth mentioning that the common advice on the Remix community is to use e2e testing via Playwright or Cypress. I've uses both of these libraries and they work really well with Remix. After all, if you have full stack react you might as well test your whole app with e2e escenarios. However I needed to get test coverage reports for this project and since Playwright and Cypress both rely on Instanbul to setup instrumentation, which itself relies on babel plugins to work and those won't work since Remix uses Esbuild under the hood.

So, I had to drop down one level and do integration testing with Vitest

Setting up the Tools

First of all we want to install all our dependencies

npm install -D vitest vitest-dom vite-tsconfig-paths @vitejs/plugin-react @remix-run/testing

Then we add a few helper files to setup Vitest environment: huge shoutout to Kent C. Dodds' Epic Stack github repo, which has been a constant source of knowledge and inspiration for my Remix journey

// tests/setup-test-env.ts

import { beforeEach, expect, vi } from "vitest"
import { installGlobals } from "@remix-run/node"
import "dotenv/config"
import { truncateDB } from "./truncate-db.js"

import * as matchers from "vitest-dom/matchers"
expect.extend(matchers)

// console.log(matchers)
const ResizeObserverMock = vi.fn(() => ({
  observe: vi.fn(),
  unobserve: vi.fn(),
  disconnect: vi.fn(),
}))

// Stub the global ResizeObserver
vi.stubGlobal("ResizeObserver", ResizeObserverMock)

installGlobals()

beforeEach(async () => {
  await truncateDB()
})

Setting up a test database

This step is optional, but I prefer having a separate database to run tets against that can be fully setup and wipe out after each test run. This way you don't even have to mock your loaders and actions and can hit your stack all the way to the database (which is what I'm looking for since these are integration tests). If you want to setup a test database with docker, I'd recommend following the instructions in this article.

Since I'm using Drizzle instead of Postgres, there's a few things we need to do differently in our setup scripts:

// package.json
"scripts": {
    "db:migrate:dev": "ts-node ./drizzle/migrate.ts",
    "db:migrate:test": "dotenv -e .env.test -- npx drizzle-kit push:pg"
    "test": "run-s db:migrate:test test:unit",
    "test:unit": "dotenv -e .env.test -- vitest --no-threads"
}

Setting up Vitest with Istanbul for coverage reports

Now that everything is hooked up, we have to setup up a few additional configurations to get coverage reports. Start by installing the vitest/coverage-istanbul package from npm

npm install -D @vitest/coverage-istanbul

Then in our vitest.config.ts file we can add the following configurations:

    environment: "jsdom",
    setupFiles: ["./tests/setup/setup-test-env.ts"],
    coverage: {
      reporter: ["text", "lcov"],
      provider: "istanbul",
      include: ["app/**/*.{ts,tsx}"],
      exclude: ["app/entry.server.tsx", "app/root.tsx"],
      all: true,
    },

Don't forget to add the include and exclude according to your app and the files you'll wan't to see on the coverage report. You'll also need to tell vitest about any special aliases you might have setup in your project such as ~, @ or # as root for your app folder.

  resolve: {
    alias: {
      "~": path.resolve(__dirname, "app"),
    },
  },

Writing a test

Since this are integration tests we're going to be focusing on testing our Routes, Loaders and Actions.

The server part of Remix is not really special, since it's just a function running on a Nodejs server. We can test those directly by importing them in our test file and calling the route function directly assuming our app is running on localhost:3000.

For example, let's say we have a route that allows an authenticated user to see an Area and edit it at localhost:3000/areas/:areaId and we want to test the loader.

// area-loader.server.test.ts
describe("Edit area loader", () => {
  test("returns the area", async () => {
    // Get a signed cookie to clear authentication
    const { cookie } = await setupAdmin()
    // Some function that creates an area on the test db.
    const newArea = await AreaFactory.create()

    let url = "http://localhost:3000/areas/" + newArea.id.toString()

    // Create a request object and pass it the cookie
    const request = new Request(url, {
      method: "GET",
      headers: { cookie },
    })

    const response = await loader({
      request,
      params: { areaId: newArea.id.toString() },
      context: {},
    })
    expect(response.status).toBe(200)

    const data = await response.json()

    // We would expect the loader to return the area with the id we passed
    expect(data.area.id).toBe(newArea.id)
  })
})

That's all there is to it. You might want to check additional properties on the response data, but that's good enough for now.

What about Actions? We can test those in a similar way with the knowledge that on a successful request, the action will redirect to a new route.

// area-action.server.test.ts
describe("Edit area action", () => {
  test("returns success with valid parameters", async () => {
    const { cookie } = await setupAdmin()
    const newArea = await AreaFactory.create()

    // We use FormData to simulate a request
    const formData = new FormData()
    formData.set("name", "Test name")

    let url = `http://localhost:3000/areas/${newArea.id.toString()}`

    // Create a request object and pass it the authentication cookie and FormData

    const request = new Request(url, {
      method: "POST",
      headers: { cookie },
      body: formData,
    })

    // We call the action with the request
    const response = await action({
      request,
      params: { areaId: newArea.id.toString() },
      context: {},
    })
    //  We expect the response to be a redirect to the areas list
    expect(response.status).toBe(302)
    expect(response.headers.get("Location")).toBe("/areas")
  })
})

And that's all for the server part! There's obviously more escenarios we can test, including failed submissions, invalid requests, etc. But the important bit is that we can import our loaders and actions and call them directly passing them a Request object.

Testing the view layer

Since this is a React app a lot of the code we'll be writing is Components and we want to test those as well and include them in our coverage report.

For this we're using an special package called @remix-run/testing which provides a set of utilities to help us test Remix apps.
The idea is that we'll use a special createRemixStub function to create a RemixApp which will include the internal contexts and hooks so that we can render our routes by passing them as children in it.

We'll also use React Testing Library to render and interact with our route components.

// area-client.test.tsx
import { test, describe } from "vitest"
import AdminEditAreaRoute, { loader } from "./route"
import { render, screen, waitFor } from "@testing-library/react"
import { createRemixStub } from "@remix-run/testing"
import { AreaFactory } from "tests/factories/area"

describe("New template route", () => {
  test("it renders correctly", async () => {
    const area = await AreaFactory.create()

    const RemixStub = createRemixStub([
      {
        id: "root",
        path: "/",
        // We want to pass the cookie to check for authentication.
        loader: (args) => {
          args.request.headers.set("cookie", cookie)
          // This loader can actually just be a Mock or a fake
          return loader(args)
        },
        children: [
          {
            path: "/areas/:areaId",
            // Here we're passing the Route component as a child.
            Component: AdminEditAreaRoute,
            loader: async (args) => {
              args.request.headers.set("cookie", cookie)

              return loader(args)
            },
          },
        ],
      },
    ])

    // Initial entries we'll make it so that we don't have to navigate
    // to this route to test it.
    render(<RemixStub initialEntries={[`/admin/areas/${area.id}`]} />)

    // We test that the page is rendering correctly
    await waitFor(() =>
      screen.findByRole("heading", { name: `Edit area ${area.name}` })
    )
  })
})

This works fine for Route tests since they depend on Remix internals and contexts, for UI components I'd avoid this setup and just render them directly with React Testing Library.

Now that we have everything setup, we can run our test suite with the following command:

npm run testdotenv -e .env.test -- vitest --no-threads
# Or the shorthand defined in package.json
npm run test:unit

You might experiment with the --no-threads flag to see if it makes a difference in the speed of the test suite, but I've found it lead to flakyness and I'd rather wait a little bit longer than have false positives on my test runs.

Generating a coverage report

If everytyhing goes well, you we can run the following command to generate a coverage report:

"scripts": {
  "coverage": "dotenv -e .env.test -- vitest  run --coverage --no-threads"
}

This will run the test suite and generate a coverage report in the coverage folder.

As a bonus, since we also defined lcov as a reporter, we get a really nice html report that we can open in a browser to view an interactive version of the coverage report in our projets root folder.

Conclusion

In this article we covered how to setup integration tests for a Remix app using Vitest, React Testing Library and Istanbul for coverage reports. It took me a while to figure out how to go about this, specially rendering the Routes with createRemixStub. Now that Remix works as a Vite plugin I'd imagine that setting up Playwright or Cypress with coverage is going to be more straightforward, but I haven't tried it myself and I still think there's good value in focusing on integration tests rather than e2e for some apps.

Isla Sigma

2022-09-19T15:24:22Z

I'll probably write this translation some day. In the meantime, this article is only available in spanish.

From Tailwind to Vanilla Extract: the right CSS tool for the Design System job

2021-12-22T00:00:00Z

Intro

Recently I came into a new organization that is a good fit for developing it's own Design System. Although we're still early on the product development journey and we're just getting a couple of MVPs of the ground with a small team, we decided it would be worth to extract base components early on that would eventually become the foundation for a full featured Design System down the line.

The plan was to build the feature screens first and then extract common UI components as they revealed themselves. I've found this approach of "build then extract" to be a good balance of extracting base components while allowing the team to move forward with feature work. It does require some willingness to "let some things go", since there isn't always time to extract a component right then and there but the added benefit is that you can design the component's API that's, ideally, used in a couple different places.

Extracting Tailwind Components

For our tech stack we chose React and Nextjs with Tailwind as a styling solution. I'd found tailwind to work really well with component UI libraries since it creates a natural boundary for style reuse instead of going down the road of using @apply. However building components for a design system is quite a different story from building application components. The former tend to need more flexibility: they are often times themable and include lower level utilities for layouts and spacing based on design tokens. While we had some doubts about being able to pull out this transition we felt confident enough to keep using tailwind to get things of the ground and figure it out down the road. Some encouraging words from the Netlify team also reassured us that the idea wasn't too crazy after all.

However as we started extracting out some components we started bumping into some difficulties with the utility classes approach. As a disclaimer, I think tailwind is fine if you're extracting components inside your own app and are keeping the API of each component fairly restricted but since we were looking to extract a design system the constraints are a bit different. That said, let's dive into some of the problems we found.

It's awkward to map tailwind classes to props

The first decision that we bumped into is how we should expose styling props for some components. For example imagine a component that exposes background property that accepts a color from your palette. Do consumers of the component pass in the class that contains the style or a string with the color value?. The former feels a bit odd, since you'd be repeating yourself by using the class background="bg-blue-400". The latter would take in the value, such as blue-400 and the component would rebuild the appropriate class dynamically which brings it's own set of issues which we'll discuss later.

// This feels odd
function Card({ background = "bg-white", ...rest }) {
  return <div className={background} {...rest} />
}

// This needs more work for every property
function Card({ background = "white", ...rest }) {
  const backgroundClass = `bg-${background}` // No type safety

  return <div className={topSpace} {...rest} />
}

This is also the case for any other property that the component might expose and can get overwhelming pretty quickly.

You have to keep the Tailwind config in sync with component props

There's no real integration between React and Tailwind, meaning that they're not aware of each other, so every time you add or remove a value from Tailwind's config you have to remember to update or expose the corresponding props in your components. It's easy to forget this step and end up with out of date props and styles.

// tailwind.config.js
module.exports = {
  extend: {
    spacing: {
      // New values
      72: "18rem",
      84: "21rem",
    },
  },
}

// Must update types that map to the new values
type SpacingProps = {
  // New values
  72: number,
  84: number,
}

function Spacer({ top }: { top: SpacingProps }) {
  return <div className={topSpace} {...rest} />
}

Dynamically generating classNames don't get generated with JIT

Previously we discussed the awkwardness of interpolating values into strings to generate tailwind classes. Another issue is that there's no way for the JIT to know if a certain class needs to be generated or not, so you might get production bundles that don't include the classes that you're expecting. This might be confusing at first but the easy way to get around it is to whitelist the classes you want to be included in the bundle.

function Spacer({ top = "16", ...rest }) {
  const topSpace = `mt-${top}` // mt-16 will be absent on the prod bundle since PurgeCSS couldn't find it
  return <div className={topSpace} {...rest} />
}

Deduping and CSS specificity issues

When it comes to overriding base styles for a component or ensuring that you don't apply 2 different classes that target the same CSS property you're on your own. Generally components in a Design System will have some default classes and allow expose some props to modify their appearance/behaviour. It's ultimately up to you to write the conditional logic that makes this work and it can get a bit hairy in some cases.

Sometimes you need to break out of tailwind

There's a good chance that you'll get to a point where you need to implement something outside of tailwind's utilities. The alternatives here are to use plain old CSS with @apply so you can keep using your tokens. This works fine but I've found that since className is already overloaded with utilities it's easy to miss when and where custom CSS was used which is something I'd rather see stand out in the code as an implementor.

Switching to Vanilla Extract

Given the previous points we felt that we needed to stop bending tailwind backwards and use a different underlying tool to power our growing component library. Ideally we'd go for something that allows the use of design tokens directly as props. Vanilla Extract provides just with it's Sprinkles addon plust it comes with good Typescript support.

The switch

We decided to do the switch progressively, converting one component at a time as we needed to add functionality. Setting up the library was somewhat easy but it was helpful to see a couple reference implementations from Shopify's Polaris and Seek's Braid given that you need to do some plumbing in order to expose your atomic classes as props.

The good things

First class Typescript support gives you autocomplete for consumers and type errors for authors. This added an extra layer of confidence for the team to continue growing the Design System while avoiding unintentionally breaking application components.

The mental model while working with Vanilla Extract is a bit different than Tailwind. While it provides atomic classes it doesn't expect you to write your whole application with it. Thus, it feels more naturally to drop down to css in ts and finish the job. You still get to mix and match regular CSS properties with your atomic classes and it all gets extracted to static CSS at buildtime.

Defining low level components proved relatively simple, which in turn could be composed into more complex ones. Dessert Box was a great starting point to map your theme variables to a Box component that could later be used as basis for components such as Flex, Center, Grid, Cards, Button and more.

These components could be used to develop new features or to reimplement existing ones extracted with Tailwind. Since Vanilla Extract has first class variant support we could simplify a lot of conditional code to apply classes according to props. If a component get's particularly convoluted 'css.ts' files provide an obvious place to write styling logic.

The not so good things

Previously I listed dealing PurgeCSS when creating classNames dynamically as a problem. That's not really fair in this comparison since Vanilla Extract doesn't do any purging at all. But Vanilla Extract doesn't want you to map as much of CSS to utilities, so while in theory you could end up with unused CSS it's unlikely this will become a problem in practice.

While one of the initial value propositions of Vanilla Extract is that CSS in TS is closer to CSS than other approaches it's early to tell if this will be the case. So far I find that css.ts files tend to feel more like typescript files than style sheets. This is fine for developers and you get to have the full power of typescript at your disposal, but ideally you'd want designers to share ownership of this files and they might feel a bit daunting at first:

// A sample css.ts file.
export const step = styleVariants({
  default: {},
  active: {
    color: "white",
    background: vars.colors["purple-500"],
  },
  disabled: {
    color: vars.colors["gray-400"],
    background: vars.colors["gray-50"],
  },
})

export const icon = style([
  style({
    transition: "transform 75ms ease-in",
  }),
  atoms({
    height: "6",
    width: "6",
  }),
])

export const openAnimation = style({
  transform: "rotate(180deg)",
})

You're restricted to one kind of variant per property. In tailwind you can get multiple kind's of variants for a single property. Think of how you can have hover:text-sm and md:text-lg at the same time. On Vanilla Extract + Sprinkles, as far as I can tell, you can only have one type of variant per property. This is fine 90% of the time and, as I mentioned before, since Vanilla Extract doesn't encourage to have every single style as an atomic property, it's best to pull out a css.ts if you're looking for multiple modifiers, but I do miss it some times.

Takeaways

This article isn't by any means meant to bash on Tailwind. While it was a very real possibility that it wasn't going to be the right fit to build a Component Library it was still a good way to get the ball rolling given the team's size and constraints . I think it's valuable to write about the experience of hitting some of the walls that you might encounter with these libraries in the context of building a production application since I find that most articles focus on shallow use cases that don't give you the full picture in order to understand some of the trade offs of a library.

On a personal note, I am very impressed by Vanilla Extract and I feel like I'll be reaching for it more often on projects that require a component based approach, while keeping tailwind as my preferred solution for server side templates. I'm particularly excited to see how Web Components continue to mature and I think Vanilla Extract, being statically extracted at build time, fits into that ecosystem.

Tailwind: more than a CSS library

2021-12-20T00:00:00Z

Intro

I've been a fan of Tailwind for a while now and it seems that it has recently exploded in popularity. It's a great framework and I'm happy to see it succeed given how much value I've gotten out of it. Plenty of articles have been written about the good parts (and downsides) of using Tailwind from the technical point of view, however, some of the reasons I hold Tailwind in such a high regard go beyond the technical aspect of it, I'd say they're even emotional and I'd like to share them in this article.

How it first came to me

On 2016 I started developing a new consumer product along with my partners at Savy. At the time I didn't really know how to make a site look nice, but I knew that Bootstrap was a good starting point for typography, colors and a few components. Naturally, I quickly bumped into use cases where I wanted to change break out a bit from the default styles, specially with components such as the navbar, cards, etc. To my delight, bootstrap included helper utilities that you could throw in the HTML like mb-5, px-4, bg-primary to personalize the default components. In fact, just with a few utilities for padding, positioning, display, and color I realized that 80% of what I needed to do was achievable with these utilities, right in my HTML.

I was hooked on utility classes from that point on, but 80% wasn't enough, I wanted to have more of them which eventually lead me to Tailwind v0.7(IIRC). Thus it began one of my longest lasting relationship's with a library. But there was something bigger in store for me behind that library, something that changed my career for the better, I just didn't know it at the time. It was also the beginning of my love for Web Design.

Beyond a CSS library

There's a lot of work that was put behind Tailwind as a library but there's just as much, if not more, work put around it's ecosystem and development. I'm talking about the awesome docs, the streams implementing UIs with the library, the design tips, the book on design for developers, and more. All of these added up to an ecosystem that made it easy to not only succeed with the library but also learn Web Design as a whole at the same time.

It taught me CSS basics

I'd been using CSS for years but I don't think I'd ever truly understood it up to that point. Seriously, I have to thank the Tailwind docs for finally making flexbox click in my brain (and I don't think I'm alone here). The pictures along with the code samples were so helpful in understanding the different properties at play in a flex container. It wasn't an overnight process, but the way tailwind forces you to think in primitives made it so that I had to learn the properties in order to implement a layout.

This was a turning point for me. I could see a design and decompose in my mind the individual properties that would need to be implemented. Suddenly a whole new world of creative exploration was available to me.

It helped me take ownership of application styles

I used to feel very insecure when editing the stylesheets of an existing application. It wasn't just lack of knowledge but also that the way styles were written changing a property could lead to very unexpected results. So I'd generally feel like I was guessing and then hoping things wouldn't break. With Tailwind, even though elements with lots of classes might be difficult to parse specially at first, you know that it's all scoped to that single element. You're free to change everything up without fear of breaking other parts of the layout.

It made me more productive

I greatly value how the Tailwind workflow enables you to implement designs without having to jump between files. The quick feedback loop is great for iteration, if you're experimenting, or for implementing an existing design from a tool like figma. It also removes the step of having to come up with names for every HTML element and lets you focus just on the styling. While the markup may get pretty crowded and might be difficult to navigate you're encouraged to extract components or partials which let you focus on one piece of your design at a time.

It taught me (web) design fundamentals

This is part of Tailwind's ecosystem rather than the library itself, but following Steve's design tips on twitter helped me understand design basics for building UIs. On top of that Adam's screencasts on youtube were a terrific walk-through on how to implement a designer's vision with CSS. By making design fundamentals more approachable a new world was opened up to me, which ended up playing a big role in my career as a web developer and eventually as an entrepreneur.

It showed me the value of a design system

Okay kind of, this one is a bit of a stretch. A Design System goes beyond tokens and the way the framework has grown since the 0.7 days when you could call the limiting set of utilities an advantage to enforce consistency. Yet, Tailwind does point you in the right direction: tokenizing spacing scales, colors, borders, shadows and typography set you up for success specially with the great defaults given by the library itself. I don't consider Tailwind to be a Design System by itself (and it's not one of the libraries objectives) but it is a stepping stone for creating one.

The future

I'll probably keep using Tailwind on my personal projects. It keeps pushing it's own boundaries and it's been an interesting journey to discover what's possible beyond the idea of utility classes and atomic CSS. But this space is in constant flux, and new paradigms emerge everyday as the web evolves. CSS variables have already unlocked some new approaches such as Vanilla Extract and Stitches which I'm excited to explore for building Design Systems. It is, after all, still an exciting time for being a web developer.

UUIDs with Action Text and Active Storage

2021-04-11T00:00:00Z

In this article we'll learn how to use UUIDs as default primary key for a new Rails application using Postgres, Active Storage and Action Text.

Some time ago Rails shook the web development world by showing us the power of relying on convention over configuration. One of these conventions was that every table would have an ID column as primary key, and it would be an auto incremental integer. At the time, it was a very welcomed change. We no longer had to spend time thinking about what to name our primary key columns, if our tables should be named in singular or plural form or if we should use natural or surrogate keys on our tables.

At the time, Rails chose the default to give a surrogate key to every model and make it an incremental ID. Back then, this was mostly taken as a good practice by the community and it's still probably a good enough default for new apps, but nowadays you could make an argument for UUIDs as a better default given:

They don't expose information about your system
Accidentally accessing the wrong model by passing it another model's ID
Frontend independence to create new IDs without a database roundtrip

It's also worth noting the things that we'd be giving up by going all in on UUIDs:

Convenience to access a particular model in production
Logic for handling special cases (which you probably shouldn't be doing in your apps but it does happen often enough)
A very small (but not negligible) chance of key clashes.

Taking into account the previous considerations, I think it's worth it for me to go with UUIDs as default for my future Rails applications. I'm currently working on a job board app and I'd like to allow users to edit job listings by clicking on a magic link sent to their E-mail instead of having to create an account and login. Using the default edit action with a sequential ID was out of the question since it could be guessed easily. With a UUID, I'd practically get this feature for free without having to write any extra code.

Making UUIDs the new default

There's already a great article covering the steps to setup your models with UUIDs on a Rails 6 app and PostgreSQL. I recommend checking it out if you want to know in depth what's going on to make this work, or if you're trying to migrate an existing table with data. For completeness, I'll add the steps here to get us going before moving onto the ActionText and ActiveStorage bits.

Let's start by enabling the pgcrypto extension on Postgres. Create a new migration with

bin/rails g migration enable_pgcrypto

class EnablePgcypto < ActiveRecord::Migration[6.0]
  def change
    enable_extension 'pgcrypto'
  end
end

Next, we configure the rails generators to use UUIDs by default.

Rails.application.config.generators do |g|
  g.orm :active_record, primary_key_type: :uuid
end

From Rails 6 a new configuration option was introduced to control the default ordering column in ActiveRecord. Normally it uses IDs for ordering which would be inconsistent with random UUIDs and could break methods like last and first. Given that we want to make all tables use UUIDs by default, we can add the following to ApplicationRecord to make the change global.

class ApplicationRecord < ActiveRecord::Base
  self.abstract_class = true
  self.implicit_order_column = "created_at"
  ...
end

If everything is wired up correctly, your generators should now pickup the new default. For example, after running the following command to create a new Listing model for my Jobs:

bin/rails generate model Listing job:references published:boolean

The resulting migration should look like this (notice the :uuid tags on the table and the reference)

class CreateListings < ActiveRecord::Migration[6.1]
  def change
    create_table :listings, id: :uuid do |t|
      t.references :job, null: false, foreign_key: true, type: :uuid
      t.boolean :published
      t.timestamps
    end
  end
end

As you can see, the migration adapters need to explicitly define that they'll be using uuid as primary key. It's easy to forget to add the extra arguments if you're doing migrations manually, so I generally try to always run the generators to avoid these kind of manual errors.

Installing Active Storage

Now that we've changed our defaults, we can move on to installing Active Storage. If you want to read the full details of the setup, I recommend checking out the official rails guides here.

The first step is to run the following command:

bin/rails active_storage:install

This will generate a couple of migration tables. We now need to adjust the ActiveStorage migrations to look like the one on our listing model, making sure we adjust the table's id type and the references as well:

class CreateActiveStorageTables < ActiveRecord::Migration[5.2]
  def change
    create_table :active_storage_blobs, id: :uuid do |t|
      t.string   :key,        null: false
      t.string   :filename,   null: false
      t.string   :content_type
      t.text     :metadata
      t.bigint   :byte_size,  null: false
      t.string   :checksum,   null: false
      t.datetime :created_at, null: false

      t.index [ :key ], unique: true
    end

    create_table :active_storage_attachments, id: :uuid do |t|
      t.string     :name,     null: false
      t.references :record,   null: false, polymorphic: true, index: false, type: :uuid
      t.references :blob,     null: false, type: :uuid

      t.datetime :created_at, null: false

      t.index [ :record_type, :record_id, :name, :blob_id ], name: "index_active_storage_attachments_uniqueness", unique: true
      t.foreign_key :active_storage_blobs, column: :blob_id
    end
  end
end

Installing Action Text

Same story for Action Text. Let's run the installation script and modify the corresponding migration.

bin/rails action_text:install

class CreateActionTextTables < ActiveRecord::Migration[6.0]
  def change
    create_table :action_text_rich_texts, id: :uuid do |t|
      t.string     :name, null: false
      t.text       :body, size: :long
      t.references :record, null: false, polymorphic: true, index: false, type: :uuid

      t.timestamps

      t.index [ :record_type, :record_id, :name ], name: "index_action_text_rich_texts_uniqueness", unique: true
    end
  end
end

Don't forget to follow the rest of the installation steps for Action Text here

Closing thoughts

I hope this will help you get up and running on your new Rails app with UUIDs, Action Text and Active Storage. It's never been a better time to spin off new Rails apps and I've never felt more productive using the framework. It might have some opinions you don't agree with, but they're fairly easy to overwrite and replace with your own. As always, let me know if you try this out and how it went for you on (twitter)[https://twitter.com/gafemoyano] or writing to felipe@gafemoyano.com.

Not Every Bug is Worth Fixing

2021-02-27T00:00:00Z

On the early days of Savy, as we were building up the technology team and I did most of the coding, I took a very aggressive stance against fixing bugs: whenever someone asked me if I could fix it, my default answer would be no. This came as a shock to my co-founders'.

The conversation would go something like this:

What do you mean you're not going to fix it? SOMEBODY just sent me a screenshot of an error, it mu st be fixed! We can't let this happen again!
Why? I would respond, it's just that one person. Let's wait and see if it happens again to a couple more people then we can see if it's worth fixing.

I'd say that 90% of the time it wasn't. The bug did exist, but it probably wasn't on a hot path on the application. It just wasn't that bad. Maybe it would come up later and get fixed down the line if it, but I certainly didn't need to look at it right away.

As a founder, it was easy for me to say no to bugs and challenge the status quo. But as the team grew, I wanted them to have the same benefit. Sure, we established a process around it, but as a general rule no bug was urgent. I believe this allowed us to focus on bigger, more ambitious projects even if it meant that bugs had to wait a bit more to get fixed, or maybe didn't get fixed at all.

In my experience, people tend to treat all bugs as emergencies. But really, few of them are and even fewer require an immediate response. I believe there's two arguments to support that claim. The first one is that fixing bugs is expensive for you and your team, probably much more than you realize. The second one, is that it's probably not that big of a deal.

A general misunderstanding of bugs

When you're developing a digital product there's going to be bugs. It's just a fact about software. But somehow, we've set unreal expectations to software quality. We act like if every bug is outrageous, and that it should be fixed as soon as possible if not sooner.

But what is a bug anyways? I think the definition is not so straight forward and to make matters worse, it might depend on your position. The same definition might not apply if you're a developer, a QA engineer or a Product Manager. I believe this general misunderstanding comes from the current industry trend to create specialized silos of expertise, instead of having multidisciplinary groups responsible for a part of the product or feature. This lack of a general definition makes it hard to agree on the severeness of a bug and the corresponding tradeoffs every role views them differently and measuring a different metric as KPI. Even worse, sometimes that metric has nothing to do with the scope of the project.

If you're building a new product then you're likely putting out new features to complete your vision, or trying out different ideas while your company finds market fit. This means you're writing more code which means you're introducing more bugs. And that's okay! it's part of the process, there's no point in achieving a perfectly correct piece of engineering if you haven't validated your product's market. What matters is that you're making progress on solving your user's needs and providing them value. But no one on the team should be losing sleep over an ever growing backlog of bugs.

There will come times, when a particularly bad bug breaks an important part of the application and it will be a real emergency that calls for a code red all hands on type of response. But this emergencies are rare. You can't go into panic response every time a piece of javascript code crashes a user's application.

In short not all bugs are equal. Some of them occur on very specific circumstances or to a very small set of users. Other's live in poorly frequented workflows or low impact features. So instead of panicking, wait. Check your dashboards, review your data. Chances are most of your users are getting by with their day just fine.

The real cost of fixing a bug

In general, people tend to underestimate the cost of interruption and context switching. This is true for meetings, calls, instant messaging, and incidentally bug tickets. Reflect on how much it takes you to build up context and concentration when you're working on a task that requires deep focus. Writing a sensitive email, coding, designing a user interface. For most people, I'd say it takes at least 30 minutes to build up context on your task and pick up on where you left off, and at least another 30 minutes to get into your flow and start making progress. If by the time you manage to start being productive someone pokes you on the shoulder or over slack to go pay attention to something else, then that concentration build up didn't amount to much. Next time, you'll have to do it again. Imagine this happens a couple of times per week, if not more. If this is the case, then it wouldn't seem very surprising that you or your team are constantly behind schedule.

Why should bugs cut the line? If you spend time carefully considering on what next big project comes next, prioritizing work and setting ambitious objectives, why throw it all out of the window because of bugs? What makes them more important than the other work you've lined up? Bugs are work that need to be done by someone. As such, they should be weighted in with other tasks instead of cutting the queue by default.

Bugs can lead down to rabbit holes. A lot of times it's not obvious to pin point the root cause of the problem let alone a way to fix it. There might not even be a quick fix available once you manage to track down the problem. Keep this in mind next time you have an urge to go down the whole and chace a bug down. At the very least, I'd recommend setting strong time boundaries for diagnostics work.

It's about company culture

When it comes to having good team dynamics and organizationonal culture, there's no silver bullet. In my opinion, teams should experiment with different methodologies and practices and find what works best. Consequently, most of the learning in this article are derived from my own experience on start up product companies so that's the environment where they're likely to make most sense. However, I would dare to say these applies to broader engineering teams. If we want teams to be productive and deliver on time, they must be able to execute without being constantly distracted. A team that is working on challenging problems and making progress towards solving them is likely to stay a motivated team.

Having a company culture where every bug or ticket has a timer on it and must be solved ASAP ultimately drive's down a team's productivity and is detrimental to an organization. Let's explore some of the reasons why.

It sets the unrealistic expectations for engineering teams. At the beginning, it'll seem pretty harmless to deal with bugs right away. When the code base still fits in one person's head, it's a reasonable thing to do without getting lost in the weeds. But it won't stay that way for long and you've now set a precedent of responding immediately. As the code grows in size and complexity and new dependencies are introduced tasks that used to take a couple of minutes now take a couple of hours. Yet the expectation of immediate response will still be there and the team will constantly feel like it's treading water. The best way to prevent this scenario, is to kindly but firmly say no to this kind of work that's labeled as urgent. You'll soon realize, most of the time it wasn't that urgent after all.

It encourages poor communication. Just like there's a trend for bugs to cut in line on the priority queue they also tend to cut through the proper channels of communication. As a team lead, I've encountered more than one time a member of my team working on a bug fix just cause someone from another team asked him to. Founders are particularly guilty of this. Or maybe a person from support asked nicely via direct message to check on something out quickly. I'm not one to advocates for processes over good communication and common sense, but I've seen these practices add up to the point were they become a problem, like someone getting abused because they're too nice and never say no. I'm not saying that bugs shouldn't be reported, on the contrary I'd encourage everyone at a company to report bugs and take the time to do it properly. But let's get rid of the expectation that reporting it means assigning it to someone and putting a deadline on it. They'll be dealt with at the right time, which is, as I've repeated a few times already, not now.

It's demoralizing for the team. Let's consider for a secound the anxiety caused by constantly getting notifications for every error in a production environment. In this moderne age we've already started to see the psicological effects of consantly having reminders from our inboxes or direct messaging applications. This can lead to feelings of guilt and maybe even depression. I've seen organizations where it gets so overwhelming that people have to ignore it in order to keep their focus. Too little signal to noise ratio. Even if your team is able to handle the stream of incoming tickets while getting their schedule tasks done, it's probably slowing them down tremendously. And even if it isn't, for how long will they be able to keep it up? It's not a sustainable strategy on the mid term. There's a strong correlation between a team's morale and it's capacity to deliver. If the equation breaks down at some point, you'll end up with an unhappy, unmotivated team.

What about quality?

By now, I hope I was able to convince you that handling bugs as an emergency that should be addressed ASAP is a bad idea. Saying no to bugs will give you and your team the freedom to focus on delivering value and solving challenges during a product cycle, but they still need to be dealt with at some point. This is not an excuse to ignore them, however, I do believe there's a smarter way to deal with them. So let's go through a couple of techniques that are effective when it come's to bugs. I'd split them into two groups. Technical safeguards and tactical organizational practices.

Technical Safeguards

These recommendations are mainly concerned with making sure that most of the things are fine for most of the users. This will give you the confidence to say no, when dealing with a bug that doesn't trip any alarms and peace of mind to keep doing what you're doing.

Implement end to end tests for your most valuable user flows. If I could mention one investment of time that pays itself over tenfold, it would be this one. End to end tests are, generally, not easy to setup nor to maintain. But being able to deploy confidently is worth it and it will become your team's last line of defense to prevent an error from getting to production in the first place. It may seem obvious, but preventing bugs from getting through in the first place is the cheapest way to deal with them.
Use monitoring tools on your production environment. There's multiple kinds of monitoring tools and dashboards that give you a sense of how things are running. From exception trackers, performance metrics, user reports, among others. These are all useful on their own way so it's up to each team to decide which ones to adopt. The important part here is not to obsess over every metric or crash report, but rather to look at the big picture and know how your application behaves during normal conditions so you can quickly identify when something is amiss . Furthermore, you'll have historical data to make decisions. Exception tracking tools, for example, will also keep records of how many users or times each error is being hit, which is very valuable when deciding if action must be taken immediately or it can wait a few days.
Set automatic alarms for when things go really wrong. This will get you on your feet when an emergency does happen. Having dealt with emergencies successfully will give you and your team the confidence to not panic when they arrive, and to handle future incidents calmly and promptly. Their also quite easy to set up, so that's a lot of value for little effort.
Set automatic alarms for when things go really wrong. They generally require little effort to set up and they serve a dual purpose. For one, they might prevent an issue from escalating into an emergency such as a server going down due to extreme load. If not, they'll make sure that your team can react on a timely manner and be the first ones to know when an emergency arises. This will create trust amongst business areas and give the team the space it'll need in order to deal with the situation without added preassure.

Organizational Practices and Processes

The following practices are not about technology but rather about processes and how work is organized and expectations set internally as a company. They intend to create a sustainable environment for product teams and establishing clear communication lines.

Define what an emergency is and it's response. As I said before, 95% of the time a bug shouldn't make you drop what you're doing. But then there's the remaining 5%. What does this percentage mean for your product? If you're upfront about the things that are critical and will be treated as a code red in case they fail you'll get reduce a lot of uncertainty for everyone at the company. Tech teams won't be troubled by non-emergencies, and management can have the ensurance to know that, when things go wrong, there's a plan for it.
Let the dust settle after releasing new features. Honestly, I blame the adoption of Scrum and two week cycles for this. They're so short that you barely get anything and then there's the promise to have a release by the end of it. And right away, another cycle starts on the third week with a new batch of tickets. I think a healthier approach is to have longer and more ambicious cycles, say 4-6 weeks and then leave one or two weeks of unscheduled work. This is a good time to schedule a release, address immediate feedback and settle down. Let the team catch their breath and the new features to settle in.
Have bug cycles to clean up technical debt. I've seen this one catching on popularity and it's quite effective in my experience. After two or three intense cycles working on new features, teams generally welcome the chance to work on bugs or maybe pending tasks that they wouldn't get to do otherwise. This way you can change up the pace and avoid monotony and it's a good way to trim the backlogs every now and then.
Promote bugs to scheduled work. This is a continuation of the idea that bugs aren't really special or different from other kinds of work. Some bugs have root causes that are a symptom of a bigger issue like a bad architectural choice a while back, or an external service that's not quite working as expected. This is usually not a fix for one person to take in the form of a bug ticket, and should rather be scheduled as a project in it's own right and be put on the table against other ideas for the decision makers to consider the trade-offs and opportunity costs of working on it.

Closing thoughts

I hope these post will make you consider your view on what a bug is and the best way to deal with them. In the end, it's all about making great products that our users love and solving real problems for them. So if you feel like you're already fulfilling that mission, awesome! keep doing what's working for you. But if you're feeling like your product is not moving forward, please consider some of the ideas and practices written here. Maybe the way you're dealing with bugs is slowing you down. So next time you get a bug report, instead of saying give me 15 minutes you could reply, let's wait a few hours or until next week. Let's make sure that this bug is worth fixing.

Acknowledgements

I'd like to thank my great friend Felipe for always being my first reader and critic and my brother David for his timely and accurate feedback. Without them I would hardly be able to organize my ramblings into a coherent article.

DRY Input Errors in Rails

2021-01-31T00:00:00Z

Spinning up a new Rails app has always been a joy to me. You can quickly scaffold your screens, setup your initial models and go straight to creating value and business logic. However, there's always a part where I feel like the framework doesn't quite do the entire job: form validation and error handling. There's one thing that I find specially difficult, and that is showing validation errors.

If you run Rails scaffold generator (which is great way to get going fast but not really intended for production code), the form partial includes this snippet of code:

<div id="error_explanation">
  <h2><%= pluralize(model.errors.count, "error") %> prohibited this model from being saved:</h2>

  <ul>
    <% model.errors.each do |error| %>
      <li><%= error.full_message %></li>
    <% end %>
  </ul>
</div>

What it does is render an alert on top of the form wich contains the field name followed by the error message. Furthermore, since this bit of logic is fairly generic we could consider extracting it into it's own partial:

This technique is fine if your forms contain two or three inputs, but more than that it transfers the burden of mapping each error message to it's corresponding field to the user.

It would be clearer to show each error next to the input that produced it. To achieve this we'd have to delete this block of code generated by the scaffold with something else:

<%= form.label :email %>
<%= form.text_field :email %>

<!-- Show Email validation errors -->
<%= tag.p user.errors["email"].join(", ") if user.errors["email"].any? %>

While this seems good enough for start, it quickly becomes a very repetitive task to add the error fields to every input. Furthermore, if you've ever used something like Simple Form or Formtastic it feels like we're writing so much more code compared to:

<%= simple_form_for @user do |f| %>
  <%= f.input :email, label: 'Your email please', error: 'Email is mandatory, please specify one' %>
<% end %>

This snippet is doing a lot behind the scenes. It creates a label for our input, correctly infers the input type , conditionally renders errors below the input an even wraps it all up inside a dive so that your CSS can target the whole group.

However I did not want to bring in Simple Form into this project for two reasons.

The first one is that Simple Form plays better with a full fledged css framework like Bootstrap or Bulma and I'm using tailwind in this project. Since I'm using tailwind here I don't think utility css plays well with passing options through keyword_args. It makes it harder to understand the output HTML and I have't been able to make the intellisense + autocomplete work in my editor:

<%= simple_form_for @user do |f| %>
  <%= f.input :email,
   label: 'Your email please',
   error: 'Email is mandatory, please specify one',
   wrapper_html:  { class: "mt-2" },
   label_html:  { class: "font-semibold text-gray-800" },
   input_html:  { class: "border border-gray-800 rounded" },
   %>
<% end %>

<!-- vs -->

<%= form_for @user do |f| %>
  <div class="mt-2">
    <label for="user_email" class="font-semibold text-gray-800">Email</label>
    <%= f.input :email, class: "border border-gray-800 rounded" %>
  </div>
<% end %>

The second reason is a self-imposed rule to avoid bringing in gems if I only need a small part of it's functionality and I could write it myself in a reasonable amount of time.

DRYing up error rendering with a hook

Even if I didn't want all of Simple Form's functionality, conditionally rendering the model's validation errors seemed pretty useful to me so we could try to bring just that bit into our apps. Some googling around lead me to this great blog post by Jorge Manrubia. From there, we could modify his initializer to render errors next to each field instead of at the top of the form.

# Place this code in a initializer. E.g: config/initializers/field_error.rb

ActionView::Base.field_error_proc = Proc.new do |html_tag, instance_tag|
  fragment = Nokogiri::HTML.fragment(html_tag)
  field = fragment.at('input,select,textarea')

  html = if field
           error_message = instance_tag.error_message.join(', ')
           field['class'] = "#{field['class']} border-red-600 border focus:outline-none"
           html = <<-HTML
              #{fragment.to_s}
              <p class="mt-1 text-sm text-red-600">#{error_message.upcase_first}</p>
           HTML
           html
         else
           html_tag
         end

  html.html_safe
end

I'll walk through this code to see what's going on. While Rails is rendering the form elements it will call a Proc every time it detects the model has an error. You can hook into that and replace the default behaviour (which wraps the input in a div with a field_error css class) with something else.

Since The Proc gets called with all sort of elements, the first step is to check if we're dealing with an input element, and if that's the case append a <p /> tag with our error and styling on it. Thanks to the error_message) method on instance_tag we can get the corresponding errors on that field. For all other elements we return their html unchanged.

Closing thoughts

And there you go! Now we have a way to show validation errors on all of our forms without having to write conditional checks againts every field on our views. I got to admit it felt a bit hacky at first, but so far I haven't encountered any issues with this technique it works great with ActiveModel validations and Form Objects server side validations. So what do you think? Is this a great or terrible idea? Let me know via email if you experiment with it and find any issues.

My happy place

2020-12-08T00:00:00Z

A few days ago I was reflecting about the sentence "Go to your happy place". It's supposed to be some place you go to in your imagination when you close your eyes to the rest of the world, just when you don't want to take a little bit more of it, and instead of losing your mind you close your eyes and go somewhere else.

Or at least that's how I think that's supposed to work, since I haven't really felt the need to take a mind trip over there in a while.

It's been long overdue for me to write some closing thoughts about my previous entrepreneurship at Savy, after all, it was over so quickly and unceremoniously that there never was a good time for it. Then life happened, COVID kept going strong and... I just never got around to it. Until a timely apple algorithm decided, last week, to show me the cover picture on this post.

The thing that hit me the most about it, is how blissfully happy everyone looks in it. I know, it's a picture. You are supposed to smile. But there's something genuine about it that captured the joy of that particular moment, present in the air and on everyone's face when the picture was taken.

Because, in spite of all the challenges we faced, for the most part I believe that's the environment we lived in.

And that's what finally motivated me to write this piece: For nearly three years, I had the privilege of living in my happy place. That's what it always felt like, no matter how difficult things where, if a project was out of track, if the numbers weren't meeting our expectations, or even when I felt I had to let someone go from the team (which fucking sucks), I didn't feel like closing my eyes and going somewhere else. Not. Even. Once.

Entrepreneurship is funny like that, you get to experience so many feelings: joy and sadness, success and failure, clarity and despair, pride and shame and so much more. That you get to experience all of this is, in my eyes, reason enough to do it.

Unfortunately, everything must come to an end and 2020 was quite ruthless at ending things abruptly. Going back to the picture that prompted this post, I cannot predict the future but I do hope, sincerely, that everyone from the picture (and from our team) finds themselves, once again, in kind of environment. That once again, we get to experience this electric feeling of being surrounded by a team that's so much more than the sum of it's parts and that we're able to hold on to it for a bit longer than we were able to.

I'm incredibly lucky for having had that opportunity and I'm even more thankful to all the people that took part in those feelings and experiences. I loved being part of that team and having a small part in creating something that brought joy and happiness to the world and lives of many people.

To everyone in that picture (and the ones that aren't, you know who you are), for having shared this experience with me.

To my cofounders, for putting up with me during all these years.

Thank you for being part of my happy place.

And to my family, friends and girlfriend who dealt with my absence during the longest hours I've ever worked.

Felipe.

P.S. Some other memories

Allow me, for posterity, to share some other moments that come to memory from looking at this picture:

Playing ping pong matches on the afternoon and how Chris' competitive nature drove him to become the best at it
The after lunch Mario Kart game, to decide who would do the dishes.
Being perpetually late to every meeting we had, to the annoyance of my very punctual and very french co-founders.
The moment we released our first app to the app store, and the positive reviews started flowing in.
Watching Camilo arrive to the office every day with a huge smile on his face.
How sad everyone was when Sebastián left the team.
Luis' unconcious habit of singing when he was deeply focused.
Nathalia, Juanita and Abraham squished on top of each other working together on the office's iMac.
Mathias 🐕.
Camila teaching me how to dance properly, she did not succeed.
Ruby Conf, where Luis and I drank half the beer at the hostal.
My occasional gossip session with Sandra.
Las charlas con el jefe de jefes
The co founder late night meetings, regretting our choice of food for the evening 9 out of 10 times.
That fancy dinner we had after closing our first investment round.
Going out to party and having 1 bottle of guaro for every two people in the group.
The tejo, the parties, the after work beers, the cocktail evenings, the speeches and so many more.
Telling Gaetan he was right about the gamification project.
Crashing Chris's bike for running out late. My hand still hurts.
Practicing the Shark Tank pitch over and over with the team.
Our first YC application video that took 3 hours to record.
Our last YC application video that took 3 minutes.

So many more... I'm sorry if I missed some important ones, I might keep adding to the list just for the sake of memory.

A Simple Strategy for Translated Routes in Rails

2020-11-02T00:00:00Z

Recently I've been working on a new project, a job board focused on remote offerings. Admittedly this is not a novel idea, however I haven't seen anything like this targeted to the local job market in Colombia. My guess is that remote offerings are not that popular here (yet) and that most of the existing boards out there are not in spanish so I decided to give it a try.

I decided to go with Rails for the stack since it would allow me to leverage ActiveStorage for file uploads and ActionText for rich text editing, both of which I was going to need at some point for this.

My hypothesis is that current remote job boards haven't caught on due to them being on a foreign language, so I want this app to be completely in spanish. Rails comes with built in i18n, however it is targetted at content and does not cover one piece of the app, the URL. Also, I'm not really looking to internationalize this app I just want the public routes not to be in english.

Also, I'm not really looking to support multiple languages or internationalize this app, I just want the public facing routes not to be in english.

In the past, I've dealt with this in the following ways:

Create your domain models in the target language Since Rails is convention based, you can just create your models in spanish and by convention the routes themselves will be in spanish too. The downside, is that you'd have to start adding exceptions to Rails' inflector so that it pluralizes your models correctly and even if you do there are still edge cases where it doesn't work as expected. Also, the rest of Rails is still in english, so you end up reading code with words mixed up in two languages. I'd rather keep all the code in english.
Bring in an external gem. There's some great gems out there for handling route translations. Most notable of them is route_translator which can handle multiple use cases for multilingual sites. This would allow me to set spanish as the default locale and wrap all my routes in a localized block. This seems like a good option, but it also feels like this gem does way more than what I actually need. I'd like a simpler solution, if possible.
Ignore the URLs and let them be in english This is what I've done most of the time. Despite common SEO advice I haven't seen much impact on having two routes be in english and user's don't really notice the URL or what language it's in.

None of this options seemed very satisfying to me. There must be a simpler way to achieve this. After all, Rails is known for being a modular and flexible framework, although some people might argue with this statement.

Turns out there is a simpler way and it had been in front of me all along. I just needed to take a closer look into how rails routing works. When you define a resource or route in rails, it can take some keyword arguments. One of them is path, which according to the docs it allows you to change the path prefix of the resource. So we could do something like:

resources :jobs, path: 'trabajos'
# Generates the following routes:
# jobs	   GET    /trabajos(.:format)
#		   POST   /trabajos(.:format)
# new_job  GET    /trabajos/new(.:format)
# edit_job GET    /trabajos/:id/edit(.:format)
# job 	   GET    /trabajos/:id(.:format)
#	       PATCH  /trabajos/:id(.:format)
#          PUT    /trabajos/:id(.:format)
#	       DELETE /trabajos/:id(.:format)

That's great, on the one hand we have now have our user facing routes (mostly) in Spanish and on the other hand we get to keep our code consistent by referring to the models in English in our route helpers.

What about new and edit? Well it turns out that Rails also has an option to override those with the path_names keyword:

resources :jobs, path: 'trabajos', path_names: {new: "nuevo", edit: "editar"}

Furthermore, we could avoid having to pass path_names to every resource by defining a scope at the top of our routes:

scope(:path_names => { :new => 'nuevo', :edit => 'editar' }) do
    resources :jobs, path: 'trabajos'
    resources :tags, path: 'etiquetas'
  end
# new_job  GET    /trabajos/nuevo(.:format)
# edit_job GET    /trabajos/:id/editar(.:format)

And there you go! now every part of the URL should be in your language of choice, withouot having to include complex external dependencies or sacrificing hypothetical SEO points.

I hope this simple example is useful enough to illustrate that sometimes a simple solution might be enough and you sometimes have to look into the framework and the options it provides, instead of outside for dependencies that often include broader use cases.