I use Pry as my REPL for all my Ruby projects. In fact, Pry is one of the reasons Ruby has “stuck” with me. I find the commands both intuitive and helpful. I have a text expansion that I constantly use in development: ;pry -> binding.pry if !@jsw_skip_pry The if clause is there to allow easy exits from loops - once I see what I need to see, I set the instance variable to true to avoid all subsequent breaks.

I have been using Pry for years and I have never messed with its configuration. Just this week I was debugging a pretty involved class. The instantiated class often has A LOT of instance variables (maybe that’s a code smell? That’s a topic for another day which may never come). I was getting an exception in this instantiated class unrelated to the instance variables. Pry’s default exception handler, which is one of the reason’s I love Pry, in this case was spitting out all of the instance variables which was taking up literally hundreds of lines in my terminal and I was having to scroll through all of these lines to see the actual exception that was being thrown. It got to be too much. I went in search of options to tame the exception output. Pry did not disapoint. I found a great resource for configuring Pry’s exception handler. Lot’s of options there. The big takeaways for me were that it’s fairly trivial to override its default handler and that you can do it in either the active session, or in a .pryrc file¹.

Here is my Pry exception handler from my .pryrc in my home directory:

Pry.config.exception_handler = proc do |output, exception, _|
  output.puts "#{exception.class.name}: #{exception.message}\n"
  exception.backtrace.each {|ebt| output.puts ebt if ebt.match?(/^(?!.*(__pry__|\/gems\/|<main>)).*$/)}
end

This handler omits the default handler’s object inspection, which is what causes all the instance variables to be displayed. I am also filtering the backtrace to exclude any lines referencing, pry, gems, and main because 99% of the time I am only interested in errors from my code and this dramtically reduces the backtrace. If I ever need the more verbose default exception, I can always comment out my code in my ~/.pryrc and start a new session, or, better yet, create a different handler in my current Pry session:

pry_instance.config.exception_handler = proc do |output, exception, _|
  output.puts "#{exception.class}: #{exception.message}"
  output.puts "from #{exception.backtrace.first}"
end

$ ssh -L 6380:localhost:6379 secure-remote-server.example.com -N &

6380: port where I can access the service on my local machine localhost:6380
6379: port that the server runs on on the remote machine
-L: local socket:host:port does the heavy lifting creating the and exposing the tunnel
-N: does not execute a command on the remote machine
&: runs this command in the background

Every time I need to do this, I have to search the web for instructions. Every time I search the web for instructions I end up slogging through a bunch of results that either don’t make sense to me, or are just different enough from what I am trying to do that I can’t accomplish my goal.

What I am almost always trying to do is expose a service running on some port on my server. My server is configured, for security reasons, to open as few ports as necessary to outside requests. This means I open 80 & 443 for web traffic, and 22 for SSH and almost nothing else. I do not open ports for the database, or for Redis, or just about any other service but I occasionally have a need to access these services from a remote machine. SSH Tunnel to the rescue!

An SHH tunnel creates a secure tunnel from one machine to another using SSH and it allows me to run a command on my local machine to access a port (via the tunnel) on the remote machine that is not otherwise open to remote requests. So if I want to view data from Redis on secure-remote-server.example.com on my local machine, and the remote server is running Redis and serving it to it’s localhost on port 6379 (localhost:6379), I would do the following on my local machine

$ ssh -L 6380:localhost:6379 secure-remote-server.example.com -N &

The above command assumes my username on the remote machine is the same as my username on my local machine. If not, I prepend the username plus @ in front of the remote server.

$ ssh -L 6380:localhost:6379 user@secure-remote-server.example.com -N &

How do they self select? They self select by following @WordleQuarant on Twitter.

How does one make sure only these self selected followers see their Wordle results? Start a new Tweet with the very first characters “@WordleQuarant “, no dots or spaces before the @, the space after coulld be a return or just a space, and then paste the copied Worsle results. Here is a recent example:

Why does this work? It goes back to the early days of Twitter. Tweets that start with an @mention, by default, are seen only by the mentioned party and those that follow both the author and the mentioned party. The tweets are public and visible in the author’s list of Tweets and in the mentioned party’s mentions, but others will not see them in their own default timeline unless they follow both accounts. This is why you see so many Tweets that begin with a period followed by an @mention (.@jswright61). This is an early convention whereby someone could direct a Tweet at a specific account and making it default visible to all of the author’s followers as well.

This is yet another attempt, after all previous attempts have failed, to carve out a place on the web for my thoughts and ramblings.

For those interested it’s hosted on Github pages using the standard Jekyll theme, minima.

I learned about Laura on Twitter. Due to the Covid-19 pandemic she had both time and a need for some extra $ as she found herself unemployed. She decided to take requests to perform songs on piano and viola. She gratefully accepts donations. You can make a request and see how to donate if you want here. I made a request for Thunder Road and was thrilled with the rendition she and her accompanist performed.

When Apple fails to take care of the little things, I get a little disappointed. Opportunity lost. I get it. There is a finite amount of time and every feature cannot make it into the final product. Even if it’s just a few lines of code to implement a feature it takes time and resources (way more than a developer typing a few lines into Xcode).

Nicknames. There, I said it. Apple could make iOS way better in a lot of areas by implementing nicknames. Two quick wins off the top of my head: WiFi networks and Bluetooth devices. Manufacturers usually do a good job of naming things, but not always, and even when they do, sometimes there’s still a good reason for nicknames, if I want to differentiate between two identical devices, for instance. But when the manufacturer swings and misses and names their device something generic, nicknames would be especially useful.

The image below shows my current Bluetooth devices. Some names are better than other. MY-CAR works for me, but my wife has the same MY-CAR in her Bluetooth devices and it’s not hers.

When I tap the i next to the first item above (Bluetooth - HORRIBLE name) I get the following screen. What if there was a nickname text box that allowed me to give this device a meaningful name (Porch Speakers in this case) and when saved, the above list would then display the nickname I just gave it instead of the stupid name the manufacturer used.

WiFi too. And especially here. How many 2Wrire, Linksys, or Netgear WiFi networks do you see? Maybe the device owner has no idea how to change the SSID, or maybe they don’t want to call attention to their network. Maybe you know the SSID and password for your neighbors WiFi - maybe they’re on AT&T and you’re on Comcast and you’ve shared credentials for when one network is down. Wouldn’t it be nice to have the network show up as “William’s WiFi” instead of 2WIRE7843?

It’s the little things. This feature, if implemented, would go unnoticed by an overwhelming majority of iOS users, but those that notice would have yet another datapoint on how Apple gets the little things right.