Committed to Ruby on Rails

Milestones

There are many milestones in a software developer’s career. I’m not entirely sure what they all are but you know them once you achieve them. Big or small, it’s a feeling you get after conquering the coding battles (yes plural) with the swinging journey of emotions and you just know. There’s the achievements that you fumble upon in a default sort of fashion and there’s the ones you aspire for. It’s been a developer dream of mine to contribute to the framework I adore, Ruby on Rails.

First Time Moments

Let’s take it a step back, because it’s not like I just woke up one day, cloned the Rails repo and started digging around for lines of code to change for the sport of it. No one has time for that. There’s your first pull request to a private code repository, your first open source contribution and there’s your first open source contribution you actually want.

Opening my first pull request to a very active private repository for a high traffic application was one of the most nerve-racking experiences of my developer career. Something like 80 commits for maybe 4 lines of code, a mammoth pull request description of debugging notes and who knows what else. There was feedback from that first pull request that I still follow to this day 🫡. Let’s just say it was that memorable (for me at least). Just getting comfortable with code review and the processes of getting code deployed are very consuming. Open source contributions were not even a thought at this stage for me.

Then necessity and scrappiness kicks in…suddenly production starts breaking. Fork that public repo I didn’t know this codebase I work in everyday used, drop this one line code change, push and fix! After the storm calms, fixing the problem upstream makes sense. Incoming pull request to again this repo I know nothing about but I’m going to go for it anyway. The moment it gets approved and merged indeed feels pretty epic! Don’t get me wrong, I’ve certainly had denials and rejected pull requests. That’s just something to get comfortable with…and it’s what makes the wins feel that much better!

Then there are personal projects. Publishing an extension or two for something nifty and neat. No need to deal with code review or adhering to any guidelines, play and publish! I definitely get joy out of this from time to time (when I have the time) 🤓.

“Gitting” to the Dream

Now, for the dream, git my name in that code history for a widely used full stack framework, Ruby on Rails. Part of my approach in “keeping up to date with the latest technologies” is to build projects and run them with the main branch of major packages (such as Ruby on Rails) - and just keep updating it to see what commits come in. It's not so scary if you have good test coverage or if it's not a production application.

Rails 7 has a whole new flavor for the frontend experience. Anyone that knows me, knows I will go pretty far out of my way to avoid frontend related work. It’s simply not my strength and not something I particularly aspire to be better at. Rails also goes pretty far out of its way to avoid javaScript, so we get along. With that, I trust Rails for the new frontend experience, ruby style!

I should have known it would be something frontend related that would send me down an obscure path 🙄. JavaScript Import Maps (and browser support for it) is this new thing. The Rails setup for it is new. It’s all just new and requires some documentation and source code reading to understand. If there’s one thing I feel known for as a software developer, it’s versioning. As my career progresses, I spend more and more time reading CHANGELOGs, managing version upgrades, untangling version messes etc. The versioning with importmaps was not clear. There's no .lock file so how do I begin to decipher? There's this mix and match kind of approach depending on if you use a cdn, do a vendor checkin or if the checkin is secretly coming from a ruby gem. It's a bit hectic. To be clear, lack of clarity for javaScript related versioning is certainly not a new thing - I'm not sure if this will ever be solved.

What I learned, at least with the Rails setup for importmaps, is that for the most part, you have to manually mark the versions 🤨. It was conflicting reading the ActionText CHANGELOG that said “this is the version for trix.js” but upon further inspection, it was otherwise. I tried to do a vendor checkin and it would not take. That is because you can't use the same file name (trix.js) Rails uses - because in the end, Rails wins (and rightfully so). Sure, I was able to override by doing a vendor checkin or cdn pinned to a different file name - and that's good knowledge when I want to diverge. However, the latest changes should be fixed upstream and match what the CHANGELOGsays. There are enough distractions when upgrading applications, it's important to minimize these as much as possible.

Somehow, js and css found it's way to be the source of my ruby related dream...🙃

Fork it, let’s go! My first Rails PR opened and merged! 👩🏻‍💻 💃🏻

Committed to Ruby on Rails, in more ways than one 😉.