three word chantGetting Back into Ruby Solo Hackathon, day 6: Dockerhub is down 😭
OK I realised I could have been live-tooting this the whole time instead of spamming groupchats 😂
Solo #Ruby Hackathon: day 7.
Context is I've been working on upgrading Levelfly, an open-source Learning Management System https://github.com/neuronic-games/levelfly/
The codebase dates back to 2011, with #Rails 3.1.
In 2021, I upgraded it, getting as far as Rails 4 and #Ruby 2.4.
That same year, @autonomic colleage @roxxers and I containerised it to move it from Heroku to a Docker Swarm deployment (using @coopcloud ).
Since then, Levelfly has just had a couple of critical infrastructure fixes… meanwhile Rails 4 hasn't had security updates since 2017¹, and Ruby 2.4 hasn't had any since 2020².
This has involved learning/relearning a LOT of things 😅 Luckily that was the name of the game.
Most satisfying thing so far has probably been finally understanding RSpec enough to be useful – specifically getting my head further around the difference between fixtures, seeds, and factories.
(And then completely ripping out the fixtures lol)
Getting basic #RSpec coverage for the key endpoints going as soon as I'd upgraded to Rails 5 was a great move; those tests have already caught all kinds of issues with the new versions.
Part of me regrets not finding a way to test S3 sooner, because file uploads have always been a big source of bugs in Levelfly, and I built up a small version-hell nightmare for myself by not checking any of that until deep into #Rails 6.
But maybe this was an OK plan: by the time I got to it, I had a lot of practice with dealing with gem dependency issues, writing #RSpec, and writing tests that require other services – all of which turned out to be crucial to getting it going.
(For the curious, I ended up switching to the `kt-paperclip` fork, and using adobe/S3Mock in testing)
Brief aside, I tried to use the fake-s3 Rubygem but the original is deprecated and the last-active fork a) seems abandoned too and b) won't launch without a licence key, is this even allowed in Rubygems.org?! https://supso.org/projects/fake-s3/register
Current status: I borked tests by removing Pusher config from the test environment, thought that was handled automatically by pusher-fake, it is not, need to RTFM.
(Live-toot megathread inspired by @foone 🤘)
#Ruby dependency hell …. well, at least purgatory … once again – acts-as-taggable-on needs an upgrade to be compatible with activerecord > 6.2, but that seems to want a zeitwerk upgrade, and THAT seems to want Ruby 3.2. Good thing I got rbenv working! 😅
#Ruby 3.2 kinda works… but seemingly several gems in the bundle use the deprecated File.exists? method (hot take but was this alias really worth removing?).
Monkeypatching third-party gem to the rescue! https://idogawa.dev/p/2023/01/file-exists-ruby.html
While I wait for `bundle update rails` – probably the most dicey step was a #Rails upgrade that required completely deleting `Gemfile.lock`.
File under "very confused that this worked".
Current hackathon jam: https://soundcloud.com/afrohouseofc/john-summit-mayan-warrior
JOHN SUMMIT - Mayan Warrior - Burning Man 2025
JOHN SUMMIT - Mayan Warrior - Burning Man 2025 (SPOTIFY PLAYLIST IN DESCRIPTION) SPOTIFY PLAYLIST: https://open.spotify.com/playlist/0Uf13iNASSOszBjoo8icEw?si=fc74209d69e54c53
Now a real head-scratcher: "DEPRECATION WARNING: Passing instance variables to `render` is deprecated."
Not as many hits on th'internet as for other deprecation warnings I've run into.
I did find a blog post about it¹ but now I'm curious why I didn't see more warnings? (Could just be limited test coverage lol 🙈)
¹ https://andycroll.com/ruby/dont-use-instance-variables-in-partials/
Trying to rush through #Rails 7.1 upgrade before I have to go AFK for the day 🏃🌬️.
Rabbithole mental state update: I've started anthropomorphising the #Ruby gems (and feeling bad torturing them in probably very-unexpected version combinations!)
Back in the saddle!
#Rails 7.1 seems to be working fine – I had to upgrade rspec-rails, which seemingly changed the behaviour of the "as" parameter… but, plot twist, I didn't need to have ever added that in the first place! 😳
Solved this one in 13 minutes on the subway home, actually kinda great conditions for it surprisingly?
A non-screen break and a walk to let my subconscious mull the problem for a bit.
Then, a short time limit and unreliable internet meant I had to skip the usual steps of "searching the error message" and "reading the online documentation" and go straight to the source code – which by now is mostly making sense.
Ran `git reset --hard HEAD^` with uncommited unstaged changes 😭 (luckily not too many, and the key ones were in my vim history)
Making a mental note to add a wrapper script to git to make it bail in these conditions – I would never intentionally drop everything with `--hard`, I would use `checkout`.
Oh no, this is pretty late in the game to be finally paying attention to `new_framework_defaults` 😳
Wow and not only that, I'm not sure I remembered to run `rails app:update` after every Rails upgrade 🫠
Luckily merging the configs is going "OK" so far. Grr so frustrated to be learning yet more things 😾 (not really)
OK the universe didn't punish me too harshly for these mistakes 😇 #Rails 7.1 has the most configuration changes yet! And also some database migrations, exciting!
Wow so far only TWO config options which needed non-default values, all the way from #Rails 4.2, 5.0, 5.1, 5.2, 6.0, 6.1, 7.0, and 7.1 😲
Having the funniest issue where browser tests only run if I switch to a specific GNOME workspace, then away from it, then back to it again? Otherwise I get an HTTP timeout 🤡
If your application has a `--color` flag, be like #Rspec, also support `--colour` as an alias, absolute praxis imo
"If it upgrades, upgrade it. If it doesn't upgrade, release the version constraint" is the "If it moves, salute it, if it doesn't move, pick it up" of #Ruby
(Specifically of debugging third-party packages causing deprecation warnings, praise be to #Rspec's `--backtrace` option and ` config.active_support.deprecation = :raise`)
OK I was wrong earlier, my actual favourite part of this process was running into an extremely-handy-looking #Ruby gem… and it's made by my university (college) housemate 🤯
Just some final deployment configuration tidy-up, some manual testing, and then I'll be ready for the all-important "declare victory and run away" step 😌
➜ bundle-audit
No vulnerabilities found
No vulnerabilities found
Wow and `ruby-lsp` is working now, immense
Of course there's a completely haunted #Docker build issue, right on the home straight 🫠
Yep that was a real wild last problem to run into… "solved" with a new environment variable that probably summoned a demon.
And it's done! Docker image built, docs tidied… ready to set up a staging server and test this out 🤘
And, with some fresh inspiration, back to my solo hackathon, Day 8 👷
So, today, "what is left to do before this could maybe be deployed?"
Firstly: test coverage. We're currently at around 40% (it's varied up and down about 3% between #Rails / #Ruby versions, which has been interesting!)
I'm not shooting for 100% – I've made the mistake before of making tests too brittle with respect to changes, and at the end of the day 100% lines covered doesn't necessarily mean 100% of functionality covered anyway.
But some of the key models and controllers are very minimally tested, which feels worth improving given the scale of the changes.
First order of business is to see if #RSpec or #SimpleCov can tell me which methods (as opposed to lines) are covered – I'd be happy enough for now if each controller and model method is at least executed.
I'm also interested in setting up #Coveralls (maybe there are other similar services, but this is the only one that seems to have a Drone Plugin¹ for it already).
I'm not currently sure if if it makes sense to have coverage enforced by a CI step – but at least making this data more visible seems like a great start (and personally is helping the work I've done over the last week feel less abstract)