DEV Community: Josh Smith

Configuring IRB autocomplete

Josh Smith — Tue, 20 Feb 2024 20:36:36 +0000

Since the release of Rails 7, the Rails console comes with a super cool autocomplete feature that provides suggestions to you as you type. This is much like the intellisense and snippets you get while writing code in an editor. But let's take a look at what this autocomplete looks like out of the box:

Yuck.

This might look okay for you depending on the color setup of your terminal, but for me the contrast is almost poor enough to render it unusable. Fortunately this can be changed! Let's explore how.

Time for a Facelift

Until recently there was no good way to configure IRB's autocomplete styling. But a few months ago, a Reline::Face class was added to IRB that offers a simple public API for configuring the colors of the autocomplete dialog.

Using this, I can get it looking much nicer:

To start with, you'll want to create a new file in your home directory called .irbrc. The contents of this file are executed before an IRB session starts, so you can use it to configure certain properties of your IRB sessions.



# to create the file
touch ~/.irbrc

# to edit the file
code ~/.irbrc # or `vim` or `subl` or whatever you use

In this file, I have the following code set to configure the autocompletion dialog:



# configure autocomplete dialog colors
if defined? Reline::Face
  Reline::Face.config(:completion_dialog) do |conf|
    conf.define(:default, foreground: "#cad3f5", background: "#363a4f")
    conf.define(:enhanced, foreground: "#cad3f5", background: "#5b6078")
    conf.define(:scrollbar, foreground: "#c6a0f6", background: "#181926")
  end
else
  IRB.conf[:USE_AUTOCOMPLETE] = false
end

To walk through this some, I first check defined? Reline::Face because I sometimes work on older projects that don't have these newer features available. When I'm unable to customize through Reline::Face, I prefer to just disable autocomplete entirely with IRB.conf[:USE_AUTOCOMPLETE] = false.

If Reline::Face does exist, I can define the colors used by :default, :enhanced, and :scrollbar. The enhanced option defines what the currently highlighted item in the autocomplete dialog looks like. The default option defines what every other item in the list looks like. And the scrollbar of course defines what the scrollbar looks like.

If your terminal doesn't support truecolor (a common example is the default Terminal app for MacOS), then you won't be able to use full RGB for these. See Reline's docs for other options.

More with IRB

There are several other cool things you can do to configure your experience with IRB. You can set aliases for commonly used methods, you can define methods for more complicated tasks that you find yourself frequently executing, you can write a custom prompt that tells you if you're in the production or development console, etc.

If you're interested in any of this, I definitely recommend reading the IRB docs. I like using some of the features around EVAL_HISTORY, which are disabled by default. Let me know in the comments if you'd like any more IRB-centered posts 😄

Connecting Debugger to Rails Applications

Josh Smith — Tue, 19 Dec 2023 18:52:08 +0000

In a previous post about debugging silent create action failures, I touched upon the practice of connecting the Rails web process to a debugger when facing challenging issues. A debugger allows you to methodically step through your code and examine the runtime values for every stage of a process.

Setting up the debugger can be a bit of a hurdle though, especially if your app is being driven by a Procfile. I wanted to make a dedicated post about the different ways you can get the debugger up and running in a Rails app. So let's get to it!

Note
This post assumes that you're on a Rails 7 app, which comes out of the box with the ruby debug gem. With earlier versions of Rails, the ruby debug gem wasn't included by default, and it was common to use the pry-byebug gem for debugging. So if that's the situation you're in, not everything I say in this post will work.

Without a Procfile

In the root of your Rails application, run ls Procfile* in your terminal. If nothing shows up, your application's processes aren't managed by a Procfile, and you likely just run rails server to start your app.

If this is the case, then connecting a debugger to your server is fairly straightforward. Let's take a #create action on a Post resource as an example for illustration:



class PostsController < ApplicationController
  def create
    # assuming `current_user` is an instance of the User model
    @post = current_user.posts.build(post_params)

    if @post.save
      redirect_to root_path
    else
      render :new, status: :unprocessable_entity
    end
  end
end

Let's say this post won't save and you want step through this code to analyze why. You can add a breakpoint to the beginning of the #create action:



def create
  # aliased as `binding.b` and `debugger`, you can use those too
  binding.break

  # the actual code ...
end

Now in your browser with localhost open, when you try to submit a form to create a new post, you'll see that the browser just hangs as if caught in an infinite loop. This is good thing! Your application is effectively paused at the breakpoint you set.

If you look in the terminal window that's running the server process, you'll see something like the image below:

Execution is paused at the breakpoint (which has a little arrow pointing at it). You can then enter commands to the rdbg prompt to control the debugger. For a list of the different commands you can use, visit the documentation for the debug gem.

With a Procfile

If you ran ls Procfile* and one or more Procfiles were listed, then your application is probably run through one. To start your app, you likely use a tool like foreman, heroku local, or some bin/dev script.

A Procfile tends to be used when there are multiple processes that need to be running for your app to function. This can include things like building CSS/JS, background worker, search engine, etc. A Procfile will specify the commands for each process that your app requires. Instead of opening new terminal windows for each process, tools like foreman and heroku local can streamline your app's setup by using the Procfile to run these processes from a single terminal instance. This is great for keeping your workspace clean and ensuring you have all the necessary processes running.

But this introduces some problems if you try to connect a debugger using the flow above. Aforementioned tools like foreman and heroku local won't know that they should be listening to and forwarding stdin (your inputs on the terminal) to your web process. So although you can set breakpoints and pause execution in your app, you'll be unable to actually control the debugger.

Solutions

There are a few ways connect a debugger when your app is managed by a Procfile:

1. Split out the server process

You can isolate the Rails server process from the rest of the commands in the Procfile. Navigate to your Procfile (or potentially Procfile.dev if you have a different one set to run locally), and remove the line that runs the web process. Now when you run the Procfile, all your processes will start up except the server. Then you can open a new terminal and run the server in isolation with bin/rails server. With the web process running separately, you'll be able to properly operate the debugger in the terminal that's running the server.

This is probably the most straightforward method, but it can be a bit inconvenient if you regularly have to do this. If it's your own project or one you control, you can remove the server process from your local Procfile.dev and always run the server separately. If you're working with others, the team may not be okay with committing this kind of change to the Procfile. So you'll have to manually set this up each time you want to debug and then remember to revert it back before committing any changes.

2. Use Overmind

Another solution is to use a different tool to drive the Procfile. The one I'm most familiar with is a tool called overmind. If you run your Procfile with overmind, you'll be able to open up a new terminal window and individually connect to any of the processes that are running. So if you want to connect to the web process to debug, you can open up a new window and run overmind connect web, and you'll have a window where you can work with the debugger's prompt.

The downside of overmind is that it requires tmux, which is a terminal multiplexer tool. If you don't already use tmux, I'd say it's probably not worth learning it just for the purposes of using overmind. But if you're like me and already know/use tmux, this can be a great solution to pursue.

3. Connect to debugger remotely

In the Procfile.dev that's currently generated by the cssbundling-rails and jsbundling-rails gems, we can see that they write the web process like:



web: env RUBY_DEBUG_OPEN=true bin/rails server

This RUBY_DEBUG_OPEN=true bit can allow us to remotely connect a debugger to the server instance the Procfile is running. When you run the Procfile, you'll see something like this in the server logs:



web.1  | DEBUGGER: Debugger can attach via UNIX domain socket (/run/user/1000/ruby-debug-josh-1396004)

Except probably with a different username than "josh" 🤣

But like the message said, a debugger can attach remotely via UDS. Don't worry, it sounds more intimidating than it is. You just need to open a new terminal window and run rdbg -An. The -A option means "attach", and it automatically connects the debugger to the open UNIX domain socket that was setup. If you have multiple sockets open for a debugger to connect to (ie. because you're running multiple Rails projects), you may be forced to specify which one it should use. The -n option means "nonstop." This prevents the program from stopping when you connect the debugger, which is usually what you're going to want when debugging a Rails app.

Now when you hit a breakpoint, you'll be able to use the debugger in the terminal window where you remotely connected with rdbg -An. This is straightforward to use and the method I recommend for most people. If it's a project where the Procfile.dev doesn't provide that setup and you can't add it in, you can prefix the command to start your app with RUBY_DEBUG_OPEN=true to still enable the same effect.

Conclusion

Using the debugger to figure out tricky problems has saved me a ton of time when working on Rails apps. It's a great skill to learn and practice, but I also know that a lot of beginners avoid it because of how troublesome the setup can be. Hopefully this post has given you some ideas about the workflow you want to use for debugging 🐛

Debugging Silent Create Action Failures in Rails

Josh Smith — Thu, 09 Nov 2023 18:27:07 +0000

I often work with beginner Rails developers through The Odin Project and The Agency of Learning. One common pain point people may run into while learning is the dreaded "silent create action" failure. You've written your model, controller, and routes for a new resource, you've built the form view for creating this resource, but when you fill out the form and click the submit button, nothing happens. And the logs may not offer obvious clues to pinpoint the problem.

In this post, I'll discuss some techniques I find useful for getting to the bottom of this type of issue.

Isolating Layers

So let's say you have a typical #create action like this:

class PostsController < ApplicationController
  def create
    @post = Post.new(post_params)

    if @post.save
      redirect_to @post, notice: 'Post successfully saved'
    else
      render :new, status: :unprocessable_entity
    end
  end
end

You fill in the form for a new post, click submit, and then nothing happens. Where should you start? When you're filling in a form to create a resource, you're exercising every layer of the app to make that action happen: the view, the controller, and the model. It'd be a simpler problem if we could examine just one slice of the app. Narrowing down the focus makes it easier to spot bugs.

So I begin by ensuring the model layer works in isolation. Rails provides a super convenient way to check this: the Rails console. The Rails console is a powerful tool for interacting with your application's code and data. Open up a rails console by doing:

bin/rails console

And then try to get a Post (or whatever resource you're working with) to save. Often you can spot problems with this related to how your data is set up, particularly when factoring in associations. In the above example, perhaps I've said that a Post belongs_to a User. But because I haven't thought to provide a user id for the new post, the database will reject it.

Most of the time, I take this step before even writing any route, controller, or view code at all. I like to make sure there are no problems with how I've set up associations and data migrations, and I like to have it fresh in my head exactly what data this model needs to save. But in the event that I didn't take this step when starting out, I make it the first thing I check when I run into trouble.

Checking on the Parameters

A quick next step I take is to look at what the parameters are on the request to the create action. You can find these by looking back through the server logs. They'll appear adjacent to where the logs start for the request like this:

| Started POST "/posts" for 127.0.0.1 at <timestamp>
| Processing by PostsController#create
|   Parameters: {"authenticity_token"=>"[FILTERED]", "post"=>{"title"=>"Title", "body"=>"Post's body"}, "commit"=>"Create Post"}

If you have trouble finding it among the other stuff happening in the server log, well, so do I! I recommend learning how to programmatically search through your terminal output. Providing a universal method for this is challenging because various tools and terminal emulators implement this functionality differently. Another option would be to use tools like grep or the_silver_searcher (a favorite of mine) to search the file where your dev logs are written to. This file is located at log/development.log in a Rails project.

After you've located the parameters, you can examine them for clues regarding the failure to create. You can see the exact data that your resource will be receiving, and you can consider if that data is what you expect. The parameters will also have a special annotation if any of them are "unpermitted". This happens when you haven't properly configured strong parameters for your resource.

Save with a Bang

If I still don't know what the problem is, my next step is to change how I'm saving the object. The standard construction of a save tends to look like:

if @post.save
  redirect_to :post, notice: 'Post successfully saved'
else
  render :new, status: :unprocessable_entity
end

In this code, if the model fails to persist to the database, the save call will return false. This will fire off our else condition. This is nice for elegantly handling issues with user inputs, but it's less nice for understanding any bug that is causing the save's failure. We need to get at what's going wrong rather than just silently rendering the new template for this resource.

To get more information about what exactly is causing the failure, I like to temporarily change my #save to a #save!. When you add a !, a failure no longer returns false. Instead, it will raise an error. Errors and their messages tend to provide crucial insights into the underlying cause of a problem.

The Big Guns

For a straightforward #create action, I usually find the steps above are sufficient for solving the problem. Sometimes there's more going on in the action though. If I still don't have a great understanding of the problem, I'll usually break out the ultimate tool: a debugger.

Debuggers are powerful tools that allow you to step through your code line-by-line, inspecting variables and understanding the flow of execution. Using debuggers is a whole topic unto itself, and getting into the weeds with that would balloon the scope of this post. If you want more information on using them, I recommend reading the README for rdbg. This is the debugging solution for modern Ruby/Rails development. It's in Ruby's stdlib as of v3.1, and Rails 7+ apps include it in the Gemfile by default. I also recommend this section of the Rails guides for exploring how to use the debug gem with Rails applications.

Developing a Process

Hopefully the steps I've outlined here can help demystify these silent create failures. I've found it helpful to develop a debugging process for the different types of common errors I run into, and I encourage other developers do the same. Remember, debugging isn't just about fixing errors; it's a skill that evolves with each challenge. Embrace the journey, uncover the intricacies of your code, build a debugging process. You'll understand your code better, and you'll solve errors faster.

Happy debugging 🐛

Emmet Snippets in Rails Views

Josh Smith — Thu, 07 Sep 2023 18:41:16 +0000

Emmet is a tool that helps you rapidly build sections of HTML by typing abbreviated snippets of what you want. If you're using VSCode, you can give it a quick test drive by opening a .html file and trying this:

<!-- type this and press `tab` in a `.html` file -->
div>ul>li.list-item*3

<!-- and you'll see it expand to: -->
<div>
  <ul>
    <li class="list-item"></li>
    <li class="list-item"></li>
    <li class="list-item"></li>
  </ul>
</div>

Support for this is built in for the current most popular editor: VSCode. But if you work with Rails a lot, you'll probably notice that it does not work in erb template files out of the box. Let's enable it!

To start, open your settings.json file in VSCode. You can take a shortcut there by opening the command palette (ctrl/cmd + shift + p) and typing "settings.json". Look for the item Open User Settings (JSON) and click it to open the file. Inside the curly braces of the JSON, you'll want to add this:

"emmet.includeLanguages": {
    "html.erb": "html"
},

This will tell Emmet to include its HTML snippets for files with the .html.erb extension. Save and close your settings.json, open up a view template in a Rails project, and you should now be able to use these snippets. Here is an awesome cheatsheet that shows some of the cool stuff you can do to generate HTML quickly.

Wrap with Abbreviation

The snippet stuff can be super useful, but I think one of the best Emmet tricks is something that isn't enabled by default in VSCode. Have you ever needed to wrap a section of HTML in a div for styling purposes? I'm terrible at estimating how many containers I need for styling, so I have to do this often. But I find the manual flow for this cumbersome. You have to type the opening tag, the closing tag on a completely different line while still matching the opening tag's indentation, and then you have to indent the section between the tags you've added. To help with this, we can use Emmet's wrap with abbreviation:

So you can highlight the section you want to wrap, hit a keybind, and then type the emmet snippet you want to wrap that section in. Emmet will handle inserting the tags and indenting the content in between automatically.

VSCode doesn't have this keybind set by default. To set it, you'll need to navigate to your keyboard shortcuts. Click the gear icon in the bottom left and you should see Keyboard Shortcuts in the submenu. Click on it and then search 'wrap with abbreviation'. You should see the Emmet command pop up, and you'll be able to set the keybind to something that's comfortable to use for you.

Other Considerations

What if you don't use VSCode? That's understandable, my preferred editor is Neovim. Emmet is still probably supported in some fashion by the editor you use. You'll just have to google to fill in some gaps. I wrote this for VSCode because it's what 95% of developers use these days.

You also might sometimes want these snippets in other places, like in .jsx files if you work with React. In that case, you can add .jsx to emmet.includeLanguages in your settings.json file like I showed with html.erb.

Debugging Flaky Tests in CI

Josh Smith — Thu, 13 Jul 2023 22:26:02 +0000

Flaky Tests

Debugging CI test failures can be frustrating. Sometimes it's impossible to recreate the failure conditions locally. We recently had an issue with some our tests flaking in CI at my job. The experience of debugging it made me want to write a small post on the process. I hope it can help others encountering these types of problems 💪

Background

At my job, we use Minitest as our testing framework for our Ruby on Rails application. We have simple GitHub actions for running continuous integration (CI). We noticed a few of the tests were occasionally failing in the CI run for Minitest. The frequency of the failures seemed to be roughly 2/3 pass to fail. Every failing test had a few things in common. They were all tests for our API controllers, they were all for a #create action, and they were all following this general pattern:

test "create new resource" do
  assert_difference('Resource.count') do
    post(
      'route',
      params: {
        resource: { **attrs },
        access_token: access_token
      },
      as: :json
    )
  end
end

The goal here is that when a user POSTs to that route with valid attributes and access token, a new resource is persisted to the test database. The assert_difference('Resource.count') checks this by looking for if the count increases by 1.

The failure message was a simple "Resource.count" didn't change by 1.

Process

The main thing I try to do when debugging is recreate the situation that produces the bug. If I can guarantee a situation that produces the bug consistently, I can cut out the noise and focus in on what's going wrong. Sometimes this is straightforward, but with problems in CI, that's often not the case.

Idea 1: Pull the seed number of the failing CI test

Testing frameworks usually offer a mechanism for running the tests in a random order, and Minitest is no exception. This is useful because it's important that tests are free of side effects. If TestA only passes when run after TestB -- this is a problem, and TestA isn't testing what it claims to be testing. The randomized runs help check for these types of situations. Alongside a randomized run, Minitest will output a "seed" identifier for that test run. This allows developers to run the tests in that specific order again if they want to.

Our first idea was to investigate the log output for the failing GitHub Action. These logs will show the seed value used in the test run. If we pass that seed identifier to Minitest locally, will the tests fail in our dev environment?

They continued to pass in development ... On to the next idea!

Idea 2: Force the GitHub action to run with a failing seed every time

So we've confirmed the bug only exists in the CI environment. My coworker had the idea to take a failing seed number and add it to the Minitest command in the workflow for our GitHub testing action:
run: bundle exec rails test --seed=${FAILING_SEED_NUMBER}
Then we could examine if the test fails in CI every time rather than only occasionally. After a few runs, we felt confident that the test was consistently failing in CI. It's inconvenient weren't able to recreate the problem locally. But at least we had a consistent environment for the failures. Now we can begin examining the failing cases.

Print Debugging

Unfortunately we can't hook up a debug session for the tests running in CI. So we had to return to our old friend: print debugging. We spammed a few p and puts statements in our failing test cases. What were the values of different local variables? What was 'Resource.count' returning? What were the instance variables configured in our setup method returning? And finally, what did response look like?

We quickly found out that this wasn't failing because of a mismatch in the output and assertion. Instead it was failing because of an error raised during the test:

ActiveRecord::RecordNotUnique (duplicate key value violates unique constraint). Key already exists.

After examining the code, we became suspicious of a FactoryBot method in our test's #setup:

def setup
  # access_token and user configuration
  @resource = create(:resource, attr1: "attr1", attr2: "attr2", id: '1')
end

An ID was explicitly assigned in the factory. This id was being used for assertions in a different test cases for the controller. After a little research, it wasn't too difficult to find examples of this kind of thing being a problem (see: here). By directly assigning an ID, the natural incrementing of primary keys can be thrown off. So we decided to remove that id argument and change the assertions that relied on the id to look for @resource.id instead. We made these changes for each test case that was using this pattern.

Then we pushed the code up with the CI test command still set to run the failing seed, and it passed! We then went back to running the GitHub action without a specified seed so it would return to running in a random order. After a several successful runs in a row, we felt confident that we'd fixed the problem!

Conclusion

I've run into these types of CI issues a few times now through my job and in open source projects. It can be a difficult when you can't recreate the failures in development. But a little patience and an organized debugging process can make quick work of the problem ✅

Terminal Colors Using Ruby

Josh Smith — Fri, 23 Sep 2022 02:55:29 +0000

I'm a web development student who's been learning through The Odin Project for the past year now (wow time flies). Students who join me in the Ruby on Rails course will encounter a number of projects where we build terminal applications using plain ol' Ruby. This is great for developing general programming skills and familiarity with the Ruby language, but since you're in the terminal, it can be a challenge to make your apps aesthetically pleasing. In this post, I'll explore some ways you can add visual flare to your ruby terminal apps through using colors.

Off-the-Shelf Solutions

So you want to add color to your terminal app? Since you're a programmer, the first thing you do is go straight to Google. This generally leads people to two ideas. One is the popular Colorize gem, which is an easy and super convenient way to get color functionality into your app. You just install the gem, require it into whatever file(s) you wish to use it in, and then you'll have several color utility functions added onto the String class. Other things people often run into are Stack Overflow posts like this one, which essentially peel back the curtain on how the Colorize gem works. When we want to add colors to a string, we wrap the string in an ANSI escape code that signals how your terminal emulator should style the text.

Both of these methods of injecting color into your app are great and easy to use. I would say they're ideal for if you're just wanting to color the log output for some server or process you're running. But if you're using them to add color to a terminal app or game, I find these and most other solutions out there underwhelming for one big reason: they offer an extremely limited color palette. The Colorize gem defines methods for 16 colors, and most other sources only show how to work with 8 or 16 colors. But most modern terminal emulators supports 24-bit "true color", meaning we actually have access to the RGB spectrum of 16,777,216 colors. Using this full spectrum can lend a lot more flavor and personality to a terminal app. So let's explore how to do it!

A Note about MacOS Terminal

The default MacOS Terminal app would be one of the modern terminals that does not support true color. If you're a Mac user and want to use the exact technique I show in this post, you'll have to use a different terminal emulator. iTerm2 is a popular choice on MacOS. It provides support for true color and a few other cool features not present in the default Terminal app.

Another option would be to use 256 color mode, which will work on the default Terminal app. For this mode, you can still reference the rest of the article except your ANSI color string will look like this:



# the 5 at the beginning puts this in 256 color mode
"\e[38;5;#{color_code}m#{string}\e[0m"

And you can find what colors map to what color code through this table on wikipedia

24-bit ANSI color code

So above I mentioned that ANSI codes are used to style the text in a terminal. They can also be used for many other things from moving the cursor around to deleting lines of text, but right now I'll just be focusing on the colors. We can see the form of the 24-bit ANSI code here. Translated into a Ruby string, it would look this:



"\e[38;2;#{r};#{g};#{b}m#{string}\e[0m"

Let's break down what's happening here. "\e[" is the "control sequence introducer" and is how we begin using one of these codes. This is followed by a list of semicolon-separated parameter values to communicate what exactly should happen. 38 signals that we're setting the foreground color (we'd use 48 for the background). The 2 signals that we're using the RGB format for the color. Then we list each RGB value for the color we want to use. The 'm' is a "final byte" to signal the end of the parameter list. This is followed by the string we want to apply the color to. The final piece is the "\e[0m" reset code. This returns the colors to their default state.

So let's quickly test this is working using the color green (r: 0, g: 128, b: 0).



green_rgb = "0;128;0"

puts "\e[38;2;#{green_rgb}mhello\e[0m world"

And you should see this text when you run the above code:

This is good. We have our green "hello", and "world", which was placed after the reset code, is back to normal.

So what's a good way to go about building this into our app? You can probably already see a method that can arise from the above code. Perhaps something like:



def fg_color(string, rgb_values)
  "\e[38;2;#{rgb_values}m#{string}\e[0m"
end

puts fg_color("hello world", "0;128;0")

But I think it'd be nice for the caller to not have to know or remember these RGB values, and if we extend the String class like the other solutions above do, we can get really clean, chainable methods. So let's explore that.

Building a Color Module

So I'm going to build a module that gives the String class some color utilities, but first I want to mention the pitfalls of "monkey patching" (or extending the base classes of the language). Ruby makes this very simple to do. We can just reopen any of the base classes anytime we like.



class String
  def shout
    "#{self}!!!"
  end
end

puts "hello world".shout
#-> "hello world!!!"

But despite the ease of doing this, it's often considered a code smell. One of the reasons is that this kind of code will be globally available -- because String itself is of course globally available. You may think that this kind of thing could work



module StringExtensions
  def shout
    "#{self}!!!"
  end
end

class Display
  String.include StringExtensions
  # these methods are only available in this class, right?

  def yell_at_user
    puts "Don't do that".shout
  end
end

"hello world".shout
#-> "hello world!!!"
# the #shout method is available anywhere

We'd rather these methods only be available where they can/should be used. Enter the refine and using methods, which are builtin methods on the Module class. With refine, we can define some extensions on a base class, and then with using, we can be selective with where these refinements are available in our code. Check it out:



module StringExtensions
  refine String do
    def shout
      "#{self}!!!"
    end
  end
end

class Display
  using StringExtensions

  def yell_at_user
    puts "Don't do that".shout
  end
end

Display.new.yell_at_user
#-> "Don't do that!!!"

puts "hello world".shout
#-> NoMethodError

Using these methods, we can better control where the extensions to a base class are available. With this in mind, let's build a small color module. I'll use a few colors from the scheme of my favorite editor theme: dracula



module ColorableString
  RGB_COLOR_MAP = {
    cyan: "139;233;253",
    green: "80;250;123",
    red: "255;85;85"
  }.freeze

  refine String do
    def fg_color(color_name)
      rgb_val = RGB_COLOR_MAP[color_name]
      "\e[38;2;#{rgb_val}m#{self}\e[0m"
    end
  end
end

class Display
  using ColorableString

  def welcome_user
    puts "Welcome to my App".fg_color(:green)
  end

  def user_choice
    puts "Please choose an option".fg_color(:cyan)
  end

  def yell_at_user
    puts "Don't do that".fg_color(:red)
  end
end

display = Display.new

display.welcome_user
display.user_choice
display.yell_at_user

And now we have color! And it's in a format that's easy to reuse and extend. If you need background colors, just create a bg_color method with the 38 replaced by a 48. You can also create the color methods through metaprogramming if you feel so inclined, but I felt it best to keep it simple. Happy colorful coding!

DEV Community: Josh Smith

Configuring IRB autocomplete

Time for a Facelift

More with IRB

Connecting Debugger to Rails Applications

Without a Procfile

With a Procfile

Solutions

1. Split out the server process

2. Use Overmind

3. Connect to debugger remotely

Conclusion

Debugging Silent Create Action Failures in Rails

Isolating Layers

Checking on the Parameters

Save with a Bang

The Big Guns

Developing a Process

Emmet Snippets in Rails Views

Wrap with Abbreviation

Other Considerations

Debugging Flaky Tests in CI

Flaky Tests

Background

Process

Idea 1: Pull the seed number of the failing CI test

Idea 2: Force the GitHub action to run with a failing seed every time

Print Debugging

Conclusion

Further reading:

Terminal Colors Using Ruby

Off-the-Shelf Solutions

A Note about MacOS Terminal

24-bit ANSI color code

Building a Color Module