Debugging Rails in Visual Studio Code When Using Puma-dev

Collin Donnell — Sat, 21 May 2022 02:19:10 +0000

Coming from languages like Swift and Objective-C, using a proper debugger where I don’t have to edit my code to log something or pause execution is pretty critical for tracking down issues quickly. So — I thought — we’re using puma-dev to run our Rails app during development, that’s a common setup, and so there must be easy instructions for how to attach Visual Studio Code’s debugger to a running app. Well, not that I could find. I did manage to patch it together through a combination of reading Stack Overflow posts and experimentation.

So, here it is.

Set up debug port environment variable

First, we need to add an environment variable in a place that puma-dev will load from. I put mine in ~/.powconfig, because that’s the first thing that gets loaded and it’s in my home directory.

Edit ~/.powconfig to include this:

export RUBY_DEBUG_PORT=1234

Update Gemfile

Make sure you’ve got these under :development:

gem "ruby-debug-ide"
gem "debase" # or byebug

I’m sure there’s a way to make this work with the new debugger that comes packaged with Ruby 3.1+ (rdbg), but that’s going to be an exercise for another time.

Add Rails initializer to start `rdebug-ide`

Create a file in /config/initializers/ called start_debugger.rb (or whatever you want), and add this code:

if Rails.env.development? && ENV['RUBY_DEBUG_PORT']
  require "ruby-debug-ide"
  Debugger.start_server nil, ENV['RUBY_DEBUG_PORT'].to_i
end

Add Launch Target to project in Visual Studio Code

Add this configuration to <app root>/.vscode/launch.json:

{
  "configurations": [
    {
      "name": "Remote Debug",
      "type": "Ruby",
      "request": "attach",
      "remoteHost": "127.0.0.1",
      "remotePort": "1234",
      "remoteWorkspaceRoot": "${workspaceRoot}",
      "cwd": "${workspaceRoot}",
    }
  ]
}

Finally

Restart your app with touch tmp/restart.txt.

Test it out by running “Remote Debug”, setting a breakpoint in one of your controllers, and refreshing the page that will trigger the code. If everything is setup correctly, your app should pause at the breakpoint.

Congratulations! 🎉

The Brilliance of `nil` in Objective-C

Collin Donnell — Fri, 29 Apr 2022 20:10:03 +0000

I don’t code much in Objective-C these days¹ but one thing I miss about it compared to Swift is how nil works.

To be fair to Swift, the concept of “nothing” in Objective-C is kind of a mess, since there’s four different versions of it compared to two in Swift.

`nil`	An empty Objective-C object.
`Nil`	An empty Objective-C class.
`NULL`	Nothing in C.
`NSNull`	Mostly used to represent null in Objective-C collections.

The reason NSNull exists is that Objective-C collections (NSArray, NSDictionary) use nil in other ways. NSArray is nil terminated, so if you did this:

NSArray *array = @[@"a", @"b", nil, @"c"];
// array = [@"a", @"b"]

You'd only have the first two elements available. In NSDictionary, setting a key to nil removes it from the dictionary, so NSNull is used to say “this exists in the dictionary, and it is nothing.”

The main thing to remember is that if you have a pointer assigned to NSNull or NULL and you try to do something with them, your app will crash. nil on the other hand is kind of magic. nil evaluates to NO (false), and nil as an object always returns nil. That means that because whatever you sent to nil will return nil and that will evaluate to false instead of crashing your app that this:

if (dict != nil &amp;&amp; dict.containsObjectForKey[@"a"]) { ... }

Can become this:

if (dict.containsObjectForKey[@"a"]) { ... }

This is probably the least-Swift thing ever, but, if you're used to coding in this style, it's fantastic. In a lot (most?) cases where there's a possibility that dict could be nil, the thing you want is for nothing to happen. Way back when Swift was first released, and Brent said switching to Swift “feels like a Jedi who’s trying to switch from a lightsaber to a blaster,” this is what I thought of.

Originally posted on collindonnell.com

Although a lot more than none, and I still think it’s important to know if you’re writing software for Apple Platforms. ↩

DEV Community: Collin Donnell