I’m Still Doing It Wrong

Let’s talk about Docker.

So, naturally enough (not blaming you, Kurt), if you install the Ruby Language Server extension into VSCode (thanks, Microsoft, for giving me an electron IDE) then it works great — if you’re running VSCode on a computer that has Ruby and has Rails and has Docker installed and you’re working on a source folder that contains a rails project. Everything’s local, plus you have Docker, so you’re good. The extension launches a new container that maps the project directory into itself and can communicate back to VSCode, and we’re all happy, navigating code like the curious little monkeys we are.

However.

Let’s imagine for a second that:

• You’re a cranky old programmer who’s been upgrading (and migrating) his development laptop since 2002. It has, literally, two decades of cruft in there. Not just the home directory, but apparently there are still the skeletons of when, a decade or more ago, you were using MacPorts instead of Homebrew to install packages, and thus
• You’re stuck with either Ruby 2.7.2 which, somehow, rbenv managed to build and install in your $HOME/.rbenv/versions directory or else jRuby 9.3.4.0, which, by some miracle, managed to build (all other Rubies failed to build for reasons relating to the prior bullet point (probably) and specifically to do with either openssl or readline. jRuby works, which is cool, and further allows you to install rails (albeit version 6, which is down by 1 from current) but it takes multiple seconds to launch. Like, invoke `bin/rails server` and then go to the bathroom because it’s gonna take a while. Forget about creating new models.

Okay, so you (I) build an image that has Ruby (3.1.1) and Rails (7.0.2.3) and then map a local source directory into a container running that image. Now, you’re (I’m) gonna go try to run a container that is based on that image and maps your (my) local source directory into it so that changes made in the container persist after the container, inevitably, gets destroyed. Cool, that works. Now launch VSCode from your laptop. Attach to a container (the one you just launched) — and sweet! you  can edit the Ruby code and you can (from a terminal in the container) start the app and VSCode will helpfully offer to forward port 3000 from the container to localhost and you can interact with your stupid code. Noice!

Except:

That swell Ruby Language Server extension doesn’t work, because that’s just so meta that who would even do that? You’d need to have Docker installed on the container, and then it would need to be reachable from…Kurt’s brain hurts and can’t keep track. Don’t Do That.

So instead, what if you use jRuby and do all the development locally? It turns out that that works great! Except for the part where you buy a dartboard and some darts because in 1996 when you fired off a build of a C++ project for MacOS, Windows 3.11, and WindowsNT, you got used to long periods of waiting and now you feel like you’re part of the eternal return.

Wait, why are we doing this Ruby bullshit again? Because some loser in Provo, Utah says it’s the bomb? Utah? Isn’t that where the students who did the first skeleton build of this project built it with ASP? You know what? Fuck Microsoft. You’re retired. Tell these guys that, hey, you love ‘em, babe, and you’d be happy to do this in Swift or even in Flutter, but you’re a busy guy with tunes to learn. If they wanna do it in Ruby, they can find some other chump.