Readonly models are a great way to signal that, well, you should only ever read them, not write them. Maybe you have some external system that connects to the database for writes, or maybe your Rails app connects to some data warehouse for some queries or reports. It's can be useful to have a safeguard to prevent accidental errant writes. It's actually really simple to make a model readonly, you just need to override the readonly? method:

class ReadOnlyPost < ApplicationRecord
  def readonly? = true
end

Now any attempt to create/save/update/delete a ReadOnlyPost will raise a friendly ActiveRecord::ReadOnlyRecord exception.

You might be able to see where this is going.

For any tests that can avoid saving this readonly model to the database, (i.e. using ReadOnlyPost.new or FactoryBot.build), then we're all good. But often tests need to persist some records to the test database. And if I try to create a ReadOnlyPost, I'm going to have a bad time.

RSpec.describe ReadOnlyPost, type: :model do
  let(:post) { ReadOnlyPost.create(title: "Title", body: "body") }

  it "can create a post" do
    expect(post).to be_a(ReadOnlyPost)
  end
end

% bundle exec rspec
F

Failures:

  1) ReadOnlyPost can create a post
     Failure/Error: let(:post) { ReadOnlyPost.create(title: "Title", body: "body") }

     ActiveRecord::ReadOnlyRecord:
       ReadOnlyPost is marked as readonly
     # ./spec/models/read_only_post_spec.rb:4:in `block (2 levels) in <top (required)>'
     # ./spec/models/read_only_post_spec.rb:7:in `block (2 levels) in <top (required)>'

This makes sense, the readonly property of the model doesn't go away in test - creating a record is creating a record is writing to the database, so it will fail.

What we want to do is override this constraint to temporarily allow us to persist data. Ideally, we do this very narrowly to not impact the system under test. If the model is writable during test execution, then the behavior in the test is different from production behavior and that can lead to bugs in production that we cannot capture in a test. So ideally we can override this during test setup only and revert back to readonly by the time the test executes.

Given those constraints, a nice API would look like this:

RSpec.describe ReadOnlyPost, type: :model do
  # In a let
  let(:post) { with_writable(ReadOnlyPost) { ReadOnlyPost.create(title: "Title", body: "body") } }

  # Or in a before block
  before do
    with_writable(ReadOnlyPost) do
      ReadOnlyPost.create(title: "Title", body: "body")
    end
  end

  it "can create a post" do
    # Even inline in a test
    with_writable(ReadOnlyPost) { ReadOnlyPost.create(title: "Title", body: "body") }

    expect(post).to be_a(ReadOnlyPost)
  end
end

The model would be writable only inside the block of with_writable, and outside the normal readonly value would hold true. Specifying the model that we want to override as the argument allows us to be intentional about which model we're overriding rather than blanket making everything writable (which could lead to some unexpected consequences).

Ruby's malleable nature allows us to make this override a reality with relative ease. We can open up the class to modification with class_eval and override readonly?, execute the block, and then revert readonly? back to it's original value.

# spec/support/readonly_helper.rb
def with_writable(klass)
  klass.class_eval do
    alias_method :_original_readonly?, :readonly?
    define_method(:readonly?) { false }
  end
  yield
ensure
  klass.class_eval do
    alias_method :readonly?, :_original_readonly?
    remove_method :_original_readonly?
  end
end

With this definition living in spec/support, it can be used in any test, but makes it inconvenient to accidentally use in app code (nothing is impossible in ruby - you could still require it in app code, but doing so would be a code smell and hopefully convince you that's not the way to go).

You could extend this helper to accept an array of classes and override readonly? for each if you had multiple readonly models for which you needed to create data.

I think the above solution provides the clearest intent and doesn't change the model's behavior during test execution. There are other ways to implement this but I think the drawbacks make them less desirable.

describe "example group", writable: ReadOnlyPost do
  # ...
end

You could make a writable helper to add to RSpec example groups or individual tests. This is arguably a cleaner interface than my preferred solution, but I couldn't find a way to make the override apply only during test setup, not during execution. That makes this a no go for me, since I lose confidence the test will behave the same way the application does in production - meaning I can't rely on this test.

RSpec.describe ReadOnlyPost, type: :model do
  before do
    ActiveRecord::Base.connection.execute("INSERT INTO read_only_posts VALUES ('Title', 'Body'")
  end

  it "can create a post" do
    expect(ReadOnlyPost.last).to be_a(ReadOnlyPost)
  end
end

You could write SQL statements directly to insert/update records. But this bypasses all of the ORM features of ActiveRecord and really feels like fighting Rails rather than extending it.

So there's a way to test readonly models effectively. Hope it's helpful, and let me know if you use this or a different solution yourself!

Photo by John Cardamone on Unsplash

For a long time, most of my side projects have been for the sole purpose of learning a new technology. When I wanted to start building mobile apps with React Native, I wrote a small to-do app that, once finished, I abandoned. The same thing happened when I wanted to try to use PostgreSQL's listen and notify feature to build a live updating chat app. So, when I was thinking about a new side project, I decided it was time to work on something that could be long lived and help me with one of my favorite hobbies: crocheting.

Recently, I've been making a lot of small projects that have started with a base shape that then gets built upon. Often, this shape is a circle. After running through several projects, I started to notice a pattern of increases and repetitions for each row. It occurred to me that if the shape followed a specific pattern, I could probably build a ruby class to generate that pattern. Thus began this side project!

To begin, we have to inspect the pattern. Crochet patterns follow a specific format, and use abbreviations for the types of stitches being used.

The example pattern uses the following abbreviations and rules:

With those abbreviations in mind, we can start parsing the pattern.

R1: 6sc in magic ring (6)
R2: [inc] x6 (12)
R3: [sc, inc] x6 (18)
R4: sc, inc, [2sc, inc] x5, sc (24)
R5: [3sc, inc] x6 (30)
R6: 2sc, inc, [4sc, inc] x5, 2sc (36)
R7: [5sc, inc] x6 (42)
R8: 3sc, inc, [6sc, inc] x5, 3sc (48)

Without knowing the details of how crochet patterns work, we can still get an idea of the format here. First, we can see that each line starts with R{n}:. This is the indicator of the round we are working on. We can see here that the pattern ends on R8, so we know that we're going to have exactly 8 rounds to the circle.

Second, we can see that each line ends with a number in parentheses. This number represents the final stitch count for the round. Here is where we may begin to see the beginnings of a pattern. Looking at the stitch counts, we see that we're starting with 6 stitches, and then increasing by 6 in each round. Given that behavior, the equation for determining the stitch count based on a given row would be 6 + 6(R - 1), where R is the row number.

In between the round number and stitch count are the actual directions for the round. In some cases, such as round 3, there are square brackets around a stitch or set of stitches, followed by x{n}. This is an indicator that the stitch or stitches within the brackets are going to be repeated n times. So in round 4, where the directions are sc, inc, [2sc, inc] x5, sc, what we're actually doing is:

sc, inc, sc, sc, inc, sc, sc, inc, sc, sc, inc, sc, sc, inc, sc, sc, inc, sc

Now that the stitch count equation has been determined, a small ruby class can start to be built up. The class will expect an input of how many rows, and output an array of strings in the correct format for each row. Also, given that we have an example pattern, an rspec test expecting the correct output can be written.

class CirclePatternGenerator
  attr_reader :row_number

  def self.generate(row_count:)
    (1..row_count).map do |row_number|
      new(row_number:).pattern
    end
  end

  def initialize(row_number:)
    @row_number = row_number
  end

  def pattern
    "#{row_title}: #{instructions} (#{stitch_count})"
  end

  private

  def row_title
    "R#{row_number}"
  end

  def stitch_count
    6 + 6 * (row_number - 1)
  end

  def instructions
  end
end

RSpec.describe CirclePatternGenerator do
  describe ".generate" do
    let(:expected_output) do
      [
        "R1: 6sc in magic ring (6)",
        "R2: [inc] x6 (12)",
        "R3: [sc, inc] x6 (18)",
        "R4: sc, inc, [2sc, inc] x5, sc (24)",
        "R5: [3sc, inc] x6 (30)",
        "R6: 2sc, inc, [4sc, inc] x5, 2sc (36)",
        "R7: [5sc, inc] x6 (42)",
        "R8: 3sc, inc, [6sc, inc] x5, 3sc (48)",
      ]
    end

    it "outputs the correct pattern" do
      expect(described_class.generate(row_count: 8)).to eq(expected_output)
    end
  end
end

Running the specs, we can confirm that the row titles and stitch counts are correct, and the instructions are the last thing to figure out.

$ rspec circle_pattern_generator.rb

Randomized with seed 47053
F

Failures:

  1) CirclePatternGenerator.generate outputs the correct pattern
     Failure/Error:
       expect(described_class.generate(row_count: 8)).to eq(expected_output)

       expected: ["R1: 6sc in magic ring (6)", "R2: [inc] x6 (12)", "R3: [sc, inc] x6 (18)", "R4: sc, inc, [2sc, inc] ...c, inc, [4sc, inc] x5, 2sc (36)", "R7: [5sc, inc] x6 (42)", "R8: 3sc, inc, [6sc, inc] x5, 3sc (48)"]
            got: ["R1:  (6)", "R2:  (12)", "R3:  (18)", "R4:  (24)", "R5:  (30)", "R6:  (36)", "R7:  (42)", "R8:  (48)"]

The core instructions for each row will be the most involved part of this pattern generator. Knowing that each row is made up of single crochets and increases, we can break down the instructions for the rows into the totals for each kind of stitch:

Looking at the table, we can see that the number of increases is 6 starting from the second row, and doesn't change as the rows progress. It's also apparent that the number of single crochets increases by 6 per row after starting from 0 on the second row. The first row, therefore, appears to be an outlier to the pattern evident from lines 2 - 8. The first row is also the only row that has special instructions ("in magic ring").

If we treat the first row like a special case, we can add a guard clause to the instructions method on the ruby class.

class CirclePatternGenerator
  # ...

  def instructions
    return first_row_instructions if first_row?
  end

  def first_row_instructions
    "6sc in magic ring"
  end

  def first_row?
    row_number == 1
  end
end

Running the specs again, we can see that the first row now matches the expected output.

$ rspec circle_pattern_generator.rb

Randomized with seed 47053
F

Failures:

  1) CirclePatternGenerator.generate outputs the correct pattern
     Failure/Error:
       expect(described_class.generate(row_count: 8)).to eq(expected_output)

       expected: ["R1: 6sc in magic ring (6)", "R2: [inc] x6 (12)", "R3: [sc, inc] x6 (18)", "R4: sc, inc, [2sc, inc] ...c, inc, [4sc, inc] x5, 2sc (36)", "R7: [5sc, inc] x6 (42)", "R8: 3sc, inc, [6sc, inc] x5, 3sc (48)"]
            got: ["R1: 6sc in magic ring (6)", "R2:  (12)", "R3:  (18)", "R4:  (24)", "R5:  (30)", "R6:  (36)", "R7:  (42)", "R8:  (48)"]

With the special case out of the way, it's time to look into the rows that adhere to the pattern of single crochets and increases.

The most noticeable thing in the row instructions is the number of single crochets that are used to space out the increases. In row 2, there are none, but from there, we can see that row 3 has 1 single crochet between increases, followed by 2 in row 4, 3 in row 5, and so on. We have ourselves another small equation -- the number of single crochets spacing out the increases is R - 2, where R is our row number. We can add that as a method to use for the instructions in the ruby class.

def sc_count
  row_number - 2
end

Returing to the pattern, it appears that the only difference in the way the instructions work is that in the odd numbered rows, we repeat the same thing 6 times, and in the even numbered rows, the repeat is only 5 times. The reason the repeat on the even rows is 5 times is because the single crochet spacing appears to be split between the beginning and end of the row. We again have a bit of an outlier with the second row, since it doesn't have any single crochets spacing out the increases.

# no sc
R2: [inc] x6 (12)

# sc in the beginning and end, totaling 2sc
R4: sc, inc, [2sc, inc] x5, sc (24)

# 2sc in the beginning and end, totaling 4sc
R6: 2sc, inc, [4sc, inc] x5, 2sc (36)

# 3sc in the beginning and end, totaling 6sc
R8: 3sc, inc, [6sc, inc] x5, 3sc (48)

Since we have another outlier, it seems easiest to add a second guard clause to the class.

class CirclePatternGenerator
  # ...

  def instructions
    return first_row_instructions if first_row?
    return second_row_instructions if second_row?
  end

  # ...

  def second_row_instructions
    "[inc] x6"
  end

  def second_row?
    row_number == 2
  end
end

Now, we can build out the logic for the even and odd rows, starting with the easier option: the odd rows.

Using the sc_count method determined earlier, the odd numbered rows should follow the pattern of "[#{sc_count}sc, inc] x6".

class CirclePatternGenerator
  # ...

  def instructions
    return first_row_instructions if first_row?
    return second_row_instructions if second_row?

    if row_number.odd?
      odd_row_instructions
    end
  end

  def odd_row_instructions
    "[#{sc_count}sc, inc] x6"
  end

  # ...
end

Running the tests again, we see that this almost looks right, except that there shouldn't be a 1 in front of the sc for row 3 ("R3: [1sc, inc] x6 (18)").

$ rspec circle_pattern_generator.rb

Randomized with seed 37350
F

Failures:

  1) CirclePatternGenerator.generate outputs the correct pattern
     Failure/Error: expect(described_class.generate(row_count: 8)).to eq(expected_output)

       expected: ["R1: 6sc in magic ring (6)", "R2: [inc] x6 (12)", "R3: [sc, inc] x6 (18)", "R4: sc, inc, [2sc, inc] ...c, inc, [4sc, inc] x5, 2sc (36)", "R7: [5sc, inc] x6 (42)", "R8: 3sc, inc, [6sc, inc] x5, 3sc (48)"]
            got: ["R1: 6sc in magic ring (6)", "R2: [inc] x6 (12)", "R3: [1sc, inc] x6 (18)", "R4:  (24)", "R5: [3sc, inc] x6 (30)", "R6:  (36)", "R7: [5sc, inc] x6 (42)", "R8:  (48)"]

While we can fix this for row 3, this isn't the only case where there's just one single crochet. Perhaps it would be worth creating a method to handle the display of the single crochets.

class CirclePatternGenerator
  # ...

  def odd_row_instructions
    "[#{sc_pattern(sc_count)}, inc] x6"
  end

  def sc_pattern(number)
    (number == 1) ? "sc" : "#{number}sc"
  end

  # ...
end

Rerunning the tests, we can see that this solves the issue for row 3.

$ rspec circle_pattern_generator.rb

Randomized with seed 45147
F

Failures:

  1) CirclePatternGenerator.generate outputs the correct pattern
     Failure/Error: expect(described_class.generate(row_count: 8)).to eq(expected_output)

       expected: ["R1: 6sc in magic ring (6)", "R2: [inc] x6 (12)", "R3: [sc, inc] x6 (18)", "R4: sc, inc, [2sc, inc] ...c, inc, [4sc, inc] x5, 2sc (36)", "R7: [5sc, inc] x6 (42)", "R8: 3sc, inc, [6sc, inc] x5, 3sc (48)"]
            got: ["R1: 6sc in magic ring (6)", "R2: [inc] x6 (12)", "R3: [sc, inc] x6 (18)", "R4:  (24)", "R5: [3sc, inc] x6 (30)", "R6:  (36)", "R7: [5sc, inc] x6 (42)", "R8:  (48)"]

Now we can address the even rows.

As noted before, the even rows repeat 5 times, and have the 6th repetition split across the beginning and end of the row.

class CirclePatternGenerator
  # ...

  def instructions
    return first_row_instructions if first_row?
    return second_row_instructions if second_row?

    row_number.odd? ? odd_row_instructions : even_row_instructions
  end

  def even_row_instructions
    split_pattern = sc_pattern(sc_count / 2)
    "#{split_pattern}, inc, [#{sc_pattern(sc_count)}, inc] x5, #{split_pattern}"
  end

  # ...
end

Running the test again, we have green! We have created a pattern generator for crochet circles based on a specified row count.

class CirclePatternGenerator
  attr_reader :row_number

  def self.generate(row_count:)
    (1..row_count).map do |row_number|
      new(row_number:).pattern
    end
  end

  def initialize(row_number:)
    @row_number = row_number
  end

  def pattern
    "#{row_title}: #{instructions} (#{stitch_count})"
  end

  private

  def row_title
    "R#{row_number}"
  end

  def stitch_count
    6 + 6 * (row_number - 1)
  end

  def instructions
    return first_row_instructions if first_row?
    return second_row_instructions if second_row?

    row_number.odd? ? odd_row_instructions : even_row_instructions
  end

  def odd_row_instructions
    "[#{sc_pattern(sc_count)}, inc] x6"
  end

  def even_row_instructions
    split_pattern = sc_pattern(sc_count / 2)
    "#{split_pattern}, inc, [#{sc_pattern(sc_count)}, inc] x5, #{split_pattern}"
  end

  def sc_pattern(number)
    (number == 1) ? "sc" : "#{number}sc"
  end

  def sc_count
    row_number - 2
  end

  def first_row_instructions
    "6sc in magic ring"
  end

  def first_row?
    row_number == 1
  end

  def second_row_instructions
    "[inc] x6"
  end

  def second_row?
    row_number == 2
  end
end

This was a fun little experiment, but not entirely useful on its own. However, what if 3D shapes in crochet also follow a similar pattern? Would I be able to generate spheres? Or cubes? Would a row count really be the ideal entry point for such shapes? It seems that more research and experimentation are needed!

Here's how the search input looks. It's a simple search form connected to a Stimulus controller. The input triggers the search function upon every input event. The debounce logic occurs in the Stimulus controller to make sure not too many requests are made to the server:

<%= form_with url: items_path, method: :get,
    data: { controller: "search", turbo_frame: "items_list" } do |f| %>
  <%= f.text_field :query,
      placeholder: "Search...",
      data: {
        search_target: "input",
        action: "input->search#search"
      } %>
  <button type="button"
      class="hidden"
      data-search-target="clearButton"
      data-action="click->search#clear">
    ×
  </button>
<% end %>

There's an additional feature here: a button which appears in the search field whenever the field has a value. The button has a data-action attribute pointing to the clear action. If the button is clicked, the input value is cleared out.

All we need to do here is submit the form with a debounce timer, handle the action for clicking the clear input button, and handle hiding the clear button if the input field has a value or not.

export default class extends Controller {
  static targets = ["input", "clearButton"]

  connect() {
    this.toggleClear()
  }

  search() {
    this.toggleClear()
    clearTimeout(this.timeout)

    this.timeout = setTimeout(() => {
      this.element.requestSubmit()
    }, 300)
  }

  clear() {
    this.inputTarget.value = ""
    this.toggleClear()
    this.element.requestSubmit()
  }

  toggleClear() {
    if (this.inputTarget.value.length > 0) {
      this.clearButtonTarget.classList.remove("hidden")
    } else {
      this.clearButtonTarget.classList.add("hidden")
    }
  }
}

You'll notice the form targets an items_list turbo frame, which contains your search results in the view. When the Stimulus controller submits the form, the content inside this frame gets replaced with the new search results. This is a pretty simple way to update the search results without full page reloads. I also wanted to avoid turbo streams for this implementation, because I find them a tad awkward sometimes.

<%= turbo_frame_tag "items_list" do %>
  <% @items.each do |item| %>
    <%= render item %>
  <% end %>
<% end %>

Standard index action with optional query filtering. Works with or without search params:

def index
  # you will probably paginate your results
  if params[:query].present?
    @items = Item.where("name LIKE ?", "%#{params[:query]}%")
  else
    @items = Item.all
  end
end

This is a nice simple starting point to build out some more complicated search features from. I'd recommend using a pagination gem like pagy to handle the search results while keep your view manageable.

As I said, right when I went to try out this cool "new" board game for the first time, the plastic ends of the Analyzer snapped. The analyzer is basically a plastic rod with 2 floating spinners on them. The spinners, when rotated, will either land with a red face or a green face. You then refer to the chart to see what action to take. I thought this was such a unique way to give a random effect in a game, without relying on dice. It essentially is just a random binary spinner that counts up to 4. Here is what it looks like for reference:

So, without any 4 sided die lying around, and not wanting to use a boring random number generator, my brain went right to what it knows best---Ruby on Rails.

So without further ado, here's what I did and how you can do something similar yourself.

Sure, Rails could be considered overkill for such a simple app. But my idea is to allow this project to scale into a whole library of board game helpers that can all live within the same app. So, to start off I ran the old trusty rails new command, with a couple preferences I like to pass in to make my life easier as a developer.

rails new board_game_library --css tailwind --database=postgresql

One of the main tools I leveraged for this project besides Rails was Tailwind. Tailwind makes styling so easy. Here at Hashrocket Tailwind is pretty standard for all of us, so if you're interested in any tips or tricks, we have plenty of blog posts and TILs worth checking out!

The app itself is very simple. Here is everything I needed to do:

• Create a view to host the Analyzer
• Create a stimulus controller to "scramble" the Analyzer
• Expose ngrok as a host in the config so I could access the Analyzer from my phone for free

The view is nothing revolutionary. I just wanted a simple interface that gave me all the capabilities of the Analyzer from the board game. So, I needed 2 "spinners", a way to spin them, and a chart that let you know what action to take.

Here is the html for the spinners. Simply 2 boxes side by side that have some data-analyzer-targets that are used by the stimulus controller. I also give them some default colors here to give the user an idea of what to expect when the app opens up.

<div class="flex space-x-4">
  <div class="bg-red-400 w-1/2 h-24" data-analyzer-target="left">
  </div>

  <div class="bg-green-400 w-1/2 h-24" data-analyzer-target="right">
  </div>
</div>

Next we have the call to action, the "spinner" button. This is simply a nicely styled button that will call the randomize method on the stimulus controller.

<div class="w-fit mx-auto mt-12">
  <button class="border border-black rounded-md shadow-lg p-2" data-action="click->analyzer#randomize" data-analyzer-target="analyzer">
    ANALYZE
  </button>
</div>

The actions chart is just simply a bunch of elements of text, styled with html, along with a visual representation of the matching result. I'll give an example of one, but to save screen space on this post, I won't post the whole thing. Remember, you can always check out the source code here.

<div class="mt-12">
  <div class="w-fit mx-auto border border-black rounded-lg p-4 space-y-4">
    <div class="flex space-x-6">
      <div class="flex space-x-1 my-auto">
        <div class="w-8 h-4 bg-red-400 border border-black"></div>
        <div class="w-8 h-4 bg-red-400 border border-black"></div>
      </div>

      <div>
        Take investment you are analyzing.
      </div>
    </div>

    <!-- Other divs for the other outcomes -->
</div>

For my stimulus controller I gave it the targets you saw in the examples above, as well as some functions to help us randomize. Here is a high-level view of a few of the methods. If you want to see the code for yourself, please check out the repo here:

• randomize() Called via the Analyze button. Kicks off the randomization, or *spinning*
• disableButton() Disables the Analyze button
• randomAnimation() Starts animating the left and right spinners on the page
• makeDecision() Determine via 50% chance for each spinner whether it will be red or green
• enableButton() Enable the Analyze button when everything is finished

For the final piece of the puzzle, I wanted a way to easily view this from my phone so I didn't need to bring a big laptop or something to the table. So, for a simple and easy way to host this "on the web" without actually paying for a domain and setting all that up, I used the free version of ngrok. Now, for this to work properly with your Rails app, you will need to add one line to your config/application.rb file.

#config/application.rb

# ...
config.hosts << ".ngrok-free.app"
# ...

This allows any hosts that end with .ngrok-free.app to have access to the application. This way you can start and stop ngrok as much as you wish, and you don't need to manually input the random host in every time.

Now simply start your rails server, start up ngrok, and access it from your phone or any other device and you should have something like this as your final product:

So, this ended up being a fun way to play the game with some friends. It worked exactly as expected and it was also really cool to be playing a 50 year old board game that had its own custom mobile integration, even if it was small and simple.

Don't want to go through all the work to make your own Rails app? Feel free to reach out to Hashrocket for your next project! Big or small, we'd love to hear about how we can help you make the app you want to get the results you need!

Cover Photo by Thomas Buchhol on Unsplash.

Analyzer image provided by Thomas Melinsky on BoardGameGeek.

I've been taking part in Advent of Code since 2019 (I've never completed a full year - and that's ok! You can participate for as long as it's fun and have the time) and have tried solving in multiple different languages - Advent is a great way to learn/skill up in a new language. But Ruby remains my favorite language in which to solve these puzzles.

Many of Ruby's strengths - its flexibility, robust standard library, and tooling make it the ideal language for Advent of Code.

Ruby doesn't enforce any one way of writing code. Want to solve a problem with a procedural script? Go for it! Want to leverage object-oriented programming and send messages between classes? Can do! Want to write in a functional style and map and zip a data structure in one long chain? You can do that too! And you can mix and match paradigms between problems - whatever models each problem best.

Ruby's data structures are super flexible as well. In many of the problems, Array and Hash allow you to very quickly model solutions. But if you find a hash isn't quite cutting it and you don't want to upgrade it to a full class, you can use the Data class to create value objects. This will lend you a bit more structure than a hash, and allow you to encapsulate some logic inside it without having to bring in the overhead of a Class.

Some of Ruby's flexibility - metaprogramming in particular - can be...unpopular... in larger production codebases. It's the "magic" that can lead to some nasty bugs. But Advent is a great place to play with those features. So go ahead, open up String and redefine some methods! Live life dangerously!

The Ruby standard library is well-suited for Advent of Code.

Array and Hash will probably be your best friends, and can get you pretty far in Advent. Because they both implement Enumerable, you can easily slice, dice, and transform these data structures with higher order functions like map, reduce, zip, and each. Convenience methods like sum and chunk mean you don't have to reinvent the wheel over and over again.

Set operations are built in - union (|), intersection (&), difference (-), and XOR (^). I've had to define these in other languages and while not difficult, it takes away from the actual solving of the puzzle.

The built in matrix gem can be a nicer way to represent grids than using arrays of arrays. It also includes some utilities to transpose, inverse and check if symmetric or upper or lower triangular.

The prime gem (included in Ruby) has utilities for listing prime numbers, determining if a number is prime, and decomposing integers into their prime factorization. It's up to you if you want to write this kind of thing yourself or skip ahead to the more exciting parts of the puzzle.

Ruby's tooling makes it very easy to run, debug, and test your Advent solutions. Drop into an irb session, load in your code and play around with it. Within the REPL you can run the whole solution, or poke around at different methods to see if they're behaving as expected. Use debug or pry to pause execution and check the current state of your variables. When you're exploring solutions and not quite sure where to go or what's going wrong, a REPL is a great way to think, try things out, and iterate.

You can also write tests for Advent of Code! (I do!) RSpec or Minitest are easy to add into a project. You can write unit tests for various helper methods. And you can write tests for each solution's output - great if you want to refactor or try out a performance optimization and ensure you still get the same solution.

Sure, other languages have some or all of these features. But I don't know of any other language that has them all and is as pleasant to use as in Ruby.

Ruby was designed for programmer happiness. So wouldn't that make it the best choice for a fun programming challenge? The two were made for each other.

Photo by Jocelyn Allen on Unsplash

The Model Context Protocol (MCP) is a way to allow LLM models to interact with development environments and external tools. The rails-mcp-server gem is a Ruby implementation that enables LLMs to interact directly with Rails projects through MCP; Once you have it set up with an agent like claude or copilot, the model will have way more context about your app's architecture and removes a lot of the nonsense and guesswork associated with AI driven development. Check out the repo here

I'll walk you through setting up the rails-mcp-server gem for your Rails projects.

Installing the rails-mcp-server gem is simple like any ruby gem. Open your terminal and run.

Don't install it to your project's directory or add it to a Rails gemfile, this gem is meant to be installed globally and configured to run with multiple projects.

gem install rails-mcp-server

Once you run the server for the first time, you can configure the gem to access your rails projects. The configuration location depends on your operating system:

• macOS: $XDG_CONFIG_HOME/rails-mcp or ~/.config/rails-mcp if XDG_CONFIG_HOME is not set
• Windows: %APPDATA%\rails-mcp

The first time the server runs, these directories will be created.

The server can be ran in two modes, but for the purposes of this article we will stick to http mode, if you want to find out about STDIO mode check out the docs here. Running the server will create the config directory.

HTTP mode runs as an HTTP server with JSON-RPC and Server-Sent Events (SSE) endpoints, perfect for web applications. Lets start it up.

# Start on the default port (6029)
rails-mcp-server --mode http

# Starting on a custom port
rails-mcp-server --mode http -p 8080

When running in HTTP mode, the server can be accessed at these endpoints:

• JSON-RPC endpoint: http://localhost:<port>/mcp/messages
• SSE endpoint: http://localhost:<port>/mcp/sse

The server will also create a projects.yml file in your config directory when you run it; to include your Rails projects, just provide a project name and a path to the directory:

# ~/.config/rails-mcp/projects.yml
test_app: "~/projects/test_app"

Add the following to your claude/config.json:

{
  "mcpServers": {
    "railsMcpServer": {
      "command": "ruby",
      "args": ["/full/path/to/rails-mcp-server/exe/rails-mcp-server"]
    }
  }
}

To find the full path to your rails-mcp-server executable:

which rails-mcp-server

Restart the claude code session to refresh the new config.

With a new claude code session started, use the command /mcp to see that the session has access to the rails-mcp-server.

Add the following to your .vscode/mcp.json:

{
  "servers": {
    "railsMcpServer": {
      "command": "ruby",
      "args": ["/full/path/to/rails-mcp-server/exe/rails-mcp-server"]
    }
  }
}

To find the full path to your rails-mcp-server executable:

which rails-mcp-server

Once configured, your AI assistant can interact with your Rails projects using the provided tools, check out the docs too see the provided tools.

A helpful thing to note is that you dont need to use the tools names specifically in LLM chats. You can simply refrence them in plain english.

load the Turbo guides and then show me how to refactor my blog feed with turbo streams

Before you can use the MCP tools on your project, you will have to tell the mcp to switch to your project. it will have to be a project name that is included in projects.yml

Here's some of the tools can use in your LLM chats and how you might use them in a prompt:

project_info

=> break down each of the 3rd party integrations used in the project

get_routes

=> which routes are being used for the messaging endpoints?

analyze_models

=> how is the user model associated with the blogpost model?

See how the prompt above says load the turbo guides, the LLM is smart enough to know that it will use the load_guide tool to respond to the prompt.

While the MCP server gives your AI assistants access to your code structure, providing more context about what you're working on helps generate better suggestions. Be sure to mention:

• The specific files you want to work with
• A clear description of the feature or bug you're addressing
• Any architectural or logistical constraints (obviously)

The rails-mcp-server gem fills in the context gap between AI and your Rails development workflow.

Whether you're working on a single application or switching between multiple Rails projects, the MCP server provides a way for AI, and hopefully you, to understand your codebase better.

• GitHub Repository
• MCP Specification

Reach out to Hashrocket if you need help modernizing your Rails Project! 🚀

A very simple way to put it is that Model Context Protocol is an "API" that your AI tooling can use to get external data or perform actions by interacting with your application. If it's just an API, that seems very easy to implement. Let's think about our use case then.

The project is the TIL https://til.hashrocket.com/ website where we developers usually write about our own learning experiences throughout small TIL posts. So our idea with the MCP server was to provide a way to simply create a TIL post from inside our AI tooling, and then maybe go to the TIL site and refine that idea.

These days we spend a lot of time inside our AI tools asking the most variety of questions, and we end up learning something from those interactions. Eventually, if we learn from an AI chat interaction, we'd like to just grab that content and maybe scaffold it into a new TIL post.

This was the starting point of the project, and with that we started to take a look into libraries to achieve that. We found out that there were 2 libraries that were both forks of each other:

• Hermes MCP
• Anubis MCP

We played around a bit with Hermes but we ended up using Anubis in the end. I have to say it was a bit of a bumpy road. The documentation for both was not the best - we had some situations where the documentation was outdated or just simply not working - so follow our steps here if you want to setup an MCP server yourself.

The first component to write is an MCP server, which is very simple. For now it's just:

defmodule Tilex.MCP.Server do
  use Anubis.Server, name: "TIL", version: "1.0.0", capabilities: [:tools]

  component(Tilex.MCP.NewPost)
end

So the first tool we made was to create a TIL Post:

defmodule Tilex.MCP.NewPost do
  @moduledoc """
  Create a new TIL ("Today I Learned") post.

  TIL is a place for sharing something you've learned today with others.
  """

  use Anubis.Server.Component, type: :tool

  schema do
    field :title, :string,
      required: true,
      description: "Max 50 chars."

    field :body, :string,
      required: true,
      description: "Max 200 words in a Markdown format."

    field :channel, :string,
      required: true,
      description: "Post channel."
  end

  @impl true
  def execute(%{title: title, body: body, channel: channel}, frame) do
    ...
  end
end

The first bit of learning from here is that we need to be very generous in the description of what the tool does. In this case, we do that by adding a proper @moduledoc, and also by describing each field that we are accepting - which type they are, what validation applies, and more description. The idea with all these description fields is to give more information so if your AI tool decides to call this tool, it can break down those args properly.

With that in place, I expect to say something like:

write me a TIL about the new React 19.2 Activity component

and I want my AI tooling to find out that I mean to use our new MCP server tool to perform that operation. And after that, I want that same AI tooling to break down the information into the proper schema fields that we are expecting as our input for that tool. So far it seems a bit like magic, so let's keep going.

So title and body I guess the AI could infer from my prompt or from the chat history. But the channel I think should be inferred from that too. The only issue is that we have a finite set of channels we could pick from. So can we expose which channels AI could use in order to create a new TIL post? The response was to provide a new tool for that. In this case, as we are just providing data to the AI, we decided to use a resource instead of a tool per se. So we changed our Server to:

defmodule Tilex.MCP.Server do
  use Anubis.Server, name: "TIL", version: "1.0.0", capabilities: [:resources, :tools]

  component(Tilex.MCP.ListChannels)
  component(Tilex.MCP.NewPost)
end

And we created our new resource as:

defmodule Tilex.MCP.ListChannels do
  @moduledoc """
  List channels of TIL posts.

  Channels are used to group posts by the same topic.
  """

  use Anubis.Server.Component, type: :resource, uri: "til:///channels", name: "list_channels", mime_type: "application/json"

  alias Anubis.Server.Response

  @impl true
  def read(_input, frame) do
    channels = list_channels()
    resp = Response.json(Response.resource(), channels)
    {:reply, resp, frame}
  end

  defp list_channels() do
    ...
  end
end

The implementation of the list_channels function is just an Ecto Repo query, nothing more than that. The trick here is to tell the AI how to relate that resource with the input to be used in the other tool. This way we changed our schema definition in the NewPost to:

defmodule Tilex.MCP.NewPost do
  @moduledoc """
  Create a new TIL ("Today I Learned") post.

  TIL is a place for sharing something you've learned today with others.
  """

  use Anubis.Server.Component, type: :tool

  schema do
    field :title, :string,
      required: true,
      description: "Max 50 chars."

    field :body, :string,
      required: true,
      description: "Max 200 words in a Markdown format."

    field :channel, :string,
      required: true,
      description: "Channel is given by the list_channels MCP resource from this same server."
  end

  @impl true
  def execute(%{title: title, body: body, channel: channel}, frame) do
    ...
  end
end

As you can see, this is pretty much what we had before, but we are telling the AI to look for channels in the list_channels MCP resource. That's it, that simple.

This was the topic we had the most difficulty with (if any...) in this whole process, and this is because the docs were not great - at least they were not at the time we were doing this research. We followed the Authentication Recipe from the library we are using, and that did not work well.

The main issue we had was that the Server instance was shared across all users. This way, if 2 users connect to their own AI tools configured with that MCP at the same time, then all posts coming from those users would be assigned to one of these users. The last one to connects takes the credits. That's not good. So we realized that we should not assign the authenticated user in the Server module, but get the current user from the authentication header directly in the tools/resources executions. So now we have:

defmodule Tilex.MCP.NewPost do
  @moduledoc """
  Create a new TIL ("Today I Learned") post.

  TIL is a place for sharing something you've learned today with others.
  """

  use Anubis.Server.Component, type: :tool

  import Ecto.Query, only: [from: 2]

  alias Anubis.Server.Response
  alias Tilex.Blog.User
  alias Tilex.Blog.Post

  schema do
    field :title, :string,
      required: true,
      description: "Max 50 chars."

    field :body, :string,
      required: true,
      description: "Max 200 words in a Markdown format."

    field :channel, :string,
      required: true,
      description: "Channel is given by the list_channels MCP resource from this same server."
  end

  @impl true
  def execute(input, frame) do
    resp = Response.tool()

    resp =
      with {:ok, current_user} <- get_current_user(frame),
           {:ok, channel} <- get_channel(input),
           {:ok, %Post{} = post} <- create_til_post(current_user, channel, input) do

        Response.resource_link(resp, ~p"/post/#{post}", "til-post",
          description: "Open this link in order to review the TIL and publish it!"
        )
      else
        {:error, reason} ->
          Response.error(resp, "ERROR => #{reason}")
      end

    {:reply, resp, frame}
  end

  defp get_current_user(frame) do
    headers = Enum.into(frame.transport.req_headers, %{})
    signed_token = headers["x-api-key"]

    with "" <> _ <- signed_token,
         {:ok, mcp_api_key} <- User.verify_mcp_api_key(signed_token) do
      Tilex.Repo.one(from d in User, where: d.mcp_api_key == ^mcp_api_key)
    else
      _ -> nil
    end
    |> case do
      nil -> {:error, "User is not authenticated to create TILs"}
      %User{} = user -> {:ok, user}
    end
  end

  defp get_channel(%{channel: channel}) do
    ...
  end

  defp create_til_post(%User{} = current_user, channel, %{title: title, body: body}) do
    ...
  end
end

To be honest, this is the gist of it. Again the implementation of get_channel and create_til_post are just Ecto Repo queries and Ecto Changeset insert.

We ended up adding into our own User profile page a new feature to generate a new MCP token:

This way, when we click to generate a new token, we also get:

Right now, among all devs we are using 2 main AI tools: Cursor and Claude Code, so we ended up adapting that page to give the devs final instructions to setup that MCP on their preferred tool.

Another point to note here is that we used Phoenix.Token to sign and verify tokens for the authentication header. That's out of the scope of this post but again very nice that the this feature is available already to be used.

So now I can open my claude code and input this type of prompt:

write me a TIL about the most common bug in JS

And this is the output that I got:

⏺ I'll help you write a TIL post about the most common bug in JavaScript. Let me first check if there's already a draft file, then I'll create the post using the TIL system.

⏺ Read(til_most_common_js_bug.md)
  ⎿  Read 1 line

⏺ listMcpResources(List MCP resources from server "til")
  ⎿  [
       {
         "name": "list_channels",
     … +7 lines (ctrl+o to expand)

⏺ readMcpResource(Read resource "til:///channels" from server "til")
  ⎿  {
       "contents": [
         {
     … +6 lines (ctrl+o to expand)

⏺ Now I'll create a TIL post about one of the most common bugs in JavaScript - the closure in loops issue:

⏺ til - new_post (MCP)(title: "The Classic Closure-in-Loop Bug", body: "One of the most common bugs in JavaScript is the closure-in-loop problem. Here's the classic example:\n\n```javascript\nfor (var i = 0; i < 5; i++) {\n  setTimeout(() => console.log(i), 100);\n}\n// Prints: 5, 5, 5, 5, 5\n```\n\nWhy? Because `var` is function-scoped, not block-scoped. All
                       callbacks share the same `i` reference, which equals 5 after the loop completes.\n\n**Solutions:**\n\n1. Use `let` (block-scoped):\n```javascript\nfor (let i = 0; i < 5; i++) {\n  setTimeout(() => console.log(i), 100);\n}\n// Prints: 0, 1, 2, 3, 4\n```\n\n2. Use an IIFE to capture the value:\n```javascript\nfor (var i = 0; i < 5; i++)
                      {\n  (function(j) {\n    setTimeout(() => console.log(j), 100);\n  })(i);\n}\n```\n\nThis bug stems from misunderstanding how closures capture variables by reference, not by value. Modern JavaScript developers should prefer `let` and `const` to avoid this entirely.", channel: "javascript")
  ⎿  [Resource link: til-post] http://til.hashrocket.com/posts/e4pehjsbkt-the-classic-closure-in-loop-bug/edit (Open this link in order to review the TIL and publish it!)

⏺ Done! I've created a TIL post about the classic closure-in-loop bug in JavaScript - one of the most common bugs that trips up developers.

  The post covers:
  - Why the bug happens (function-scoped var vs block-scoped let)
  - A clear example showing the problem
  - Two solutions: using let (modern approach) and IIFE (legacy approach)

  You can review and publish it here: http://til.hashrocket.com/posts/e4pehjsbkt-the-classic-closure-in-loop-bug/edit

We can see that uppon my prompt Claude decided to call list_channels to it's gathering of content and finally call the new_post tool. In our happy path the server return a Response.resource_link with the newly created TIL and in the text we are suggesting the developer to go to that link, review the whole content and if that's ok to publish it.

TIL started over 10 years ago as a Ruby on Rails project, and a few years ago that project was converted to be an Elixir Phoenix project. At that time, the developers that converted it wanted to experiment more with Elixir, so they migrated the project with the basic features. So there was 1 feature in particular that was left behind that I think we had to bring it back due to the use of this MCP server. It was the ability to create a TIL post as a draft. When we did this work, we wanted that feature back so badly.

The main issue is that no matter how we tell AI tooling to do their tasks the execution itself is always unpredictable. With the interactions we had so far to test all these new post MCP server we noticed that sometimes the TIL content created by the AI is ok but it's not the way we'd write, it does not expose the element of learning a particular thing in the post. Sometimes the examples are too complex and take the focus off. So we end up having to adjust the content in 100% of times. This was the main driver for us to put that draft posts feature back.

Some other times the post created are completely hallucinated trash. When it happens it's usually that our prompt was not adequate enough for AI to understand, so we'd like to prompt again, give more info and try to create again. We could create a new MCP server to update the last TIL or so, but we end up implementing a feature to delete a TIL. So when the user opens the TIL post page to check the content, now they can delete that post and go back to their AI and try again with a new post.

So in the end, implementing that MCP server was very easy. The power of scaffolding an idea into a new TIL is very helpful. But as the data now comes from an unpredictable source you may need to consider the implication of this new MCP servers. Adding a moderation to this process is quite important now.

At Hashrocket, we have deep expertise in Elixir, Phoenix, and integrating modern AI capabilities into production applications. Whether you're looking to build custom MCP servers, modernize your existing applications with Elixir, or explore how AI can enhance your development workflow, we'd love to help. Our team has decades of combined experience building robust, scalable web applications and we're always excited to tackle interesting technical challenges. Get in touch with us to discuss how we can help with your next project.

N+1s occur in rails when you have associated ActiveRecord models, and iterate over one model while accessing fields on the associated records. This might be easier to explain with an example.

Let's say you have the following ActiveRecord models:

class Author < ApplicationRecord
  has_many :posts
end

class Post < ApplicationRecord
  belongs_to :author
  has_many :tags
end

class Tag < ApplicationRecord
  belongs_to :post
end

An author has many posts, and each post can have many tags. If we want to list each author and their blog posts like below, then we'll make 1 query to the database for the authors, and then another query for each author's blog posts. For N authors, that's 1 + N queries to the database.

Author.take(3).each do |author|
  puts author.name
  author.posts.each do |post|
    puts post.title
  end
end

We can see all the queries in the logs - 1 query for authors, then 3 queries for each author's blog posts:

Author Load (31.4ms)  SELECT "authors".* FROM "authors"
Post Load (2.4ms)  SELECT "posts".* FROM "posts" WHERE "posts"."author_id" = 163
Post Load (0.4ms)  SELECT "posts".* FROM "posts" WHERE "posts"."author_id" = 164
Post Load (0.1ms)  SELECT "posts".* FROM "posts" WHERE "posts"."author_id" = 165

In small doses this isn't a big deal - these are small, quick queries. However, as soon as the data gets larger, the queries more complex, or the cardinality of these queries grow, then things can really slow down.

Let's look at a case study, where we start with an unoptimized query with 2 layers of N+1s, and see how much faster we can make it.

Let's take the example above, and add another layer to it. On our authors index page, we want to list each author, then each of their blog posts, including their associated tags. With a totally unoptimized query, our controller action and view will look like this:

class AuthorsController < ApplicationController
  def index
    @authors = Author.all.order(:name)
  end
end

# app/views/authors/index.html.erb
<h1>Authors</h1>

<% @authors.each do |author| %>
  <h2><%= author.name %></h2>
  <ul>
    <% author.posts.each do |post| %>
      <li><%= post.title %> - <%= post.tags.map(&:name).join(", ") %></li>
    <% end %>
  </ul>
<% end %>

As we can see in the logs, there's an explosion of queries - for 3 authors with 3 blog posts each with 3 tags, that's 13 queries!

Author Load (1.1ms)  SELECT "authors".* FROM "authors" ORDER BY "authors"."name" ASC
Post Load (0.9ms)  SELECT "posts".* FROM "posts" WHERE "posts"."author_id" = 163 
Tag Load (1.1ms)  SELECT "tags".* FROM "tags" WHERE "tags"."post_id" = 631 
Tag Load (0.2ms)  SELECT "tags".* FROM "tags" WHERE "tags"."post_id" = 632 
Tag Load (0.2ms)  SELECT "tags".* FROM "tags" WHERE "tags"."post_id" = 633 
Post Load (0.3ms)  SELECT "posts".* FROM "posts" WHERE "posts"."author_id" = 172 
Tag Load (0.2ms)  SELECT "tags".* FROM "tags" WHERE "tags"."post_id" = 716 
Tag Load (0.3ms)  SELECT "tags".* FROM "tags" WHERE "tags"."post_id" = 717 
Tag Load (0.2ms)  SELECT "tags".* FROM "tags" WHERE "tags"."post_id" = 718 
Post Load (0.2ms)  SELECT "posts".* FROM "posts" WHERE "posts"."author_id" = 262 
Tag Load (0.2ms)  SELECT "tags".* FROM "tags" WHERE "tags"."post_id" = 1521 
Tag Load (0.2ms)  SELECT "tags".* FROM "tags" WHERE "tags"."post_id" = 1522 
Tag Load (0.2ms)  SELECT "tags".* FROM "tags" WHERE "tags"."post_id" = 1523 
...

13 small queries isn't going to make that much of an impact. But what if there are 100 authors, each with 10 blog posts each, each post having 5 tags? That's 1,101 queries! On my well-specced computer, that page takes 1.007s to load.

That's a noticeable delay in page load. We can do better.

N+1s are a common occurrence in a Rails app, and fortunately Rails has a great tool for dealing with them. We can use the .includes method to eagerly load the associated records in the original query. By including posts in the query, we're performing the posts query up front in bulk as a single query for all associated posts. Here's the updated controller action (the view won't change throughout this exercise).

class AuthorsController < ApplicationController
  def index
    @authors = Author.all.includes(:posts).order(:name)
  end
end

We can see in the logs that we've cut down the number of queries - 1 for authors, 1 for posts, but still a tags query for each blog post. That totals 1,002 queries, down from 1,101. And page load time dropped from 1.007s -> 0.678s - that's a 32% improvement. Not bad! But, we can do better.

Author Load (23.1ms)  SELECT "authors".* FROM "authors" ORDER BY "authors"."name" ASC 
Post Load (1.2ms)  SELECT "posts".* FROM "posts" WHERE "posts"."author_id" IN (513, 522, 612, ...) 
Tag Load (0.8ms)  SELECT "tags".* FROM "tags" WHERE "tags"."post_id" = 4030 
Tag Load (0.2ms)  SELECT "tags".* FROM "tags" WHERE "tags"."post_id" = 4031 
Tag Load (0.2ms)  SELECT "tags".* FROM "tags" WHERE "tags"."post_id" = 4032 
Tag Load (0.2ms)  SELECT "tags".* FROM "tags" WHERE "tags"."post_id" = 4033 
Tag Load (0.2ms)  SELECT "tags".* FROM "tags" WHERE "tags"."post_id" = 4034 
...

You'll notice in the partially optimized query, we included the posts, but there remained an N+1 for the tags. .includes allows you to include further related records using a hash to denote the connections between records:

class AuthorsController < ApplicationController
  def index
    @authors = Author.all.includes(posts: [:tags]).order(:name)
  end
end

This allows us to include all the authors' posts, and all the posts' associated tags. We'll see in the logs that we're down to 3 queries now - one to bulk select the authors, one to bulk select the blog posts, and one to bulk select the tags. Page load dropped down to 0.126s - a 81% improvement over the partially optimized query, and an 87% improvement over the original!

Author Load (16.3ms)  SELECT "authors".* FROM "authors" ORDER BY "authors"."name" ASC
Post Load (1.0ms)  SELECT "posts".* FROM "posts" WHERE "posts"."author_id" IN (513, 522, 612, ...)
Tag Load (1.0ms)  SELECT "tags".* FROM "tags" WHERE "tags"."post_id" IN (4030, 4031, 4032, 4033, 4034, 4035, 4036, ...)

With a single line change, we can make a massive improvement in performance. You can argue in isolation that this is a small win. But with multiple unoptimized queries on a single page, or with N+1s persistent across an app, users will feel the sluggishness. Why normalize slow performance when instead we can have fast apps?

At Hashrocket, we specialize in building robust, performant applications using modern technologies. If you're modernizing or speeding up your Ruby on Rails app, get in touch to discuss how our team of expert developers can help.

Photo by Vitaly Gariev on Unsplash

To me, the main selling point for Claude Code is its ability to read through your entire codebase; a big shortcoming of many AI workflows is the model only partially understanding an issue due to it not having enough of the project's context and convention to be effective. Claude Code has the ability to access all of the files in the directory where you initiated the session, and can even ask for permission to search through extraneous directories. While potentially helpful, this is also a little sketchy when considering that everything Claude is processing is getting sent over the wire to Anthropic's servers; according to their privacy policy, the data sent over for processing will not be used for LLM training unless the user specifically opts in or the content has been flagged for a Trust & Safety Review. It's also important to be aware that Claude's data retention policy has changed in recent months and will likely continue to change.

When you start a Claude Code session and give it a task to complete, it will usually try to break down the task into steps to complete. Upon starting a 'step', Claude will show you what it wants to do, and ask you for permission to do it. In my experience, I always had three options when presented with Claude's suggestion: accept the suggested action, always accept the suggested action, or do not accept and tell Claude to do something different. I would urge any developer to stick to the first and last option. Take the time to look at Claude's suggestion critically and decide if it seems like the right way to go. Claude is usually logical, but also susceptable to hallucinations. A big advantage of Claude Code living in the terminal, is that it has the ability to run bash commands and verify its own work in lots of ways. This means it can actually run tests to see if the code it wrote compiles, if tests pass, or if a server spun up correctly. This was surprisingly useful when trying it out for my own projects and I found that Claude presented lot of concerns that I also held when working through a problem, and also highlighted potential mistakes and optimizations I had yet to consider. Claude is certainly not foolproof and sometimes it tries to confidently to run a command that makes no sense, or try to write some code that is off track.

Claude Code isn't cheap and charges you based on token usage. Each session burns through API tokens at a rate that can add up fast if you're using it regularly. If Claude is going through one of its episodes, it can end up repeating itself in logical thought loops that burn tokens quickly. For hobbyists or developers at smaller companies, this could create a weird calculus where you'd constantly ask if the task you're about to delegate is worth it or not. This friction fundamentally changes how you interact with the tool instead of treating it as a seamless assistant, you're rationing its use (Which is probably a smart thing to do with AI anyways😬).

Claude Code is pretty impressive when working on well defined problems in codebases with obvious patterns and structure (Like a nice Ruby on Rails app). Need to refactor some logic in a Rails model or service object? Want to add some error handling across several files? Need to write some specs for new features? These are tasks where I found Claude Code to have the most success. It typically understands the scope, stays consistent, and navigates the files without losing its train of thought.

But it struggles with ambiguity. Vague requests like "make this faster" or "fix the bugs" often lead to Claude making assumptions that don't align with what you actually meant. It also tends to be overly conservative sometimes and overly aggressive other times there's no middle ground. It might refuse to modify a file because it's "not sure" what you want, or it might rewrite an entire module when you just wanted a small tweak.

Claude Code is a pretty cool tool that improves certain workflows, but it's not a perfect advance in an AI revolution. It's expensive, it requires diligent supervision, and can make some pretty baffling mistakes. For the right tasks, particularly refactoring, boilerplate generation, or getting you out of being stumped by a bug, it can save a significant amount of time. Don't expect to be able to hand Claude Code your project directory and walk away. Claude Code is a tool that is more of a supplement to your workflow than it is a replacement. And for me, that's probably how it should be. The day we can fully trust AI to write production code unsupervised is not here yet and maybe further in the future than the hype suggests.

Use Claude Code with your eyes open. Review everything. Don't hit "always accept." And maybe check your API bill more often than you'd like to.

If you're anything like me, after working on a few web projects with Tailwind, it can feel like a drag to return to stacks that use other styling libraries. Tailwind has become, for myself, and many other developers, a standard styling paradigm. When starting my most recent React Native project, I was relieved to find out that NativeWind exists. NativeWind is exactly what is sounds like: Tailwind Classes in React Native. I can attest to the breeziness of writing an entire native app without a single call to StyleSheet.create.

Nativewind takes the familiar classes of Tailwind CSS directly to your React Native components. Virtually every* class from Tailwind CSS can be used the exact same way on your mobile app (and the web), and the development results end up being faster iteration, less translating, and components that feel more readable and maintainable.

Let’s look at how to set it up

NativeWind translates Tailwind class names into React Native styles at runtime or compile-time, if you use the Babel plugin. You end up with the the same composable mindset of Tailwind, but the output is just React Native styles.

The setup is simple enough, for my latest project we used expo:

npx expo install nativewind react-native-reanimated@~3.17.4 react-native-safe-area-context@5.4.0
npx expo install --dev tailwindcss@^3.4.17 prettier-plugin-tailwindcss@^0.5.11

Now to generate a tailwind config, run:

npx tailwindcss init

Be sure to include the path to your components in the generated tailwind.config.js file

/** @type {import('tailwindcss').Config} */
module.exports = {
  content: ["./App.tsx", "./components/**/*.{js,jsx,ts,tsx}"],
  presets: [require("nativewind/preset")],
  theme: {
    extend: {},
  },
  plugins: [],
}

Next create your global.css file with tailwind's directives

@tailwind base;
@tailwind components;
@tailwind utilities;

Then, enable the Babel plugin in babel.config.js:

module.exports = function (api) {
  api.cache(true);
  return {
    presets: [
      ["babel-preset-expo", { jsxImportSource: "nativewind" }],
      "nativewind/babel",
    ],
  };
};

Now you’re ready to use all the classes Nativewind provides in your components:

import { View, Text, Pressable } from 'react-native'

export default function MyComponent() {
  return (
    <View className="flex-1 items-center justify-center bg-gray-100">
      <Text className="text-2xl font-semibold text-gray-900 mb-4">
        Hello world, this component is using NativeWind!
      </Text>
      <Pressable className="bg-blue-400 px-4 py-2 rounded-lg active:bg-blue-600">
        <Text className="text-white font-medium">Press me</Text>
      </Pressable>
    </View>
  )
}

You will probably want to create some custom tailwind colors/classes, which you can include into the existing theme.

//tailwind.config.js

import { colors } from "./theme/colors"
module.exports = {
  theme: {
    extend: {
      colors: colors
      },
    },
  },
}

For more information on installing Nativewind, be sure to check out the documentation

Defining style objects in React Native can spiral, and to be fair, so can inline tailwind classes at times. The separation of style sheets can look neat at first, but over time, it can become another layer to maintain, a long list of key names that rarely get reused across files when not carefully organized.

Let's compare StyleSheets with Nativewind

const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: '#f9fafb',
    justifyContent: 'center',
    alignItems: 'center',
  },
})

Now compare that to this:

<View className="flex-1 bg-gray-50 justify-center items-center" />

The result is the same, and I'd argue the tailwind is more readable.

I prefer never having to context switch between the code I'm writing and the styles it uses. Navigating to the bottom of the file just to tweak a component's padding can be tedious.

As a developer that uses Tailwind on the web, Nativewind makes me feel right at home. It also means that If you plan on distributing your native app to the web, it's simple to use Tailwind breakpoints to alter the design of your components for larger screens.

Nativewind also plays well with other libraries. Since the generated output is just standard React Native styles, you can still use other animation and navigation libraries. Essentially, if it takes a className prop, you can throw Nativewind styles at it.

import { MotiView } from 'moti'

<MotiView
  from={{ opacity: 0, translateY: 8 }}
  animate={{ opacity: 1, translateY: 0 }}
  className="p-4 bg-brand-500 rounded-xl"
/>

Another great feature is that the basic animation classes included with Tailwind work with Nativewind. At the time of writing this the support is considered experimental, however in my experience all of the animate- classes work as expected on IOS and Android.

The familiar Tailwind class syntax and easily achieved responsiveness make Nativewind an effective library for speeding up react native development.

If you’re tired of jumping back and forth from component renders and StyleSheets, I highly recommend seeing if Nativewind can improve your workflow on your next React Native Project.

Need help with your next React Native project? Don't hesitate to reach out with any questions.