Ozymandias on Rails. Cartography of a Ruin
When everything is on fire, nothing is on fire. Where do you start when every problem seems intractable? By drawing a map.
When everything is on fire, nothing is on fire. Where do you start when every problem seems intractable? By drawing a map.
Shelley wrote about a king whose monument outlived everything it was built on. I've spent 15 years inside Rails monoliths that did the same thing. This is the first post about what to do when you're standing in the ruins.
I don't like to bury ledes, so when people ask me about polymorphic relationships my answer is simply:
Don't.
What if, by trading 1% correctness, you could count billions of items all within kilobytes worth of space? Well that's HyperLogLog, and as a non-bit-enlightened Rubyist it was a trip figuring out how it worked and how to explain it.
The problem with optimizing indexes is if you don't control every query, and another team goes and writes an unoptimal variant in their code. Much like callbacks and commands there's a lot of value in owning your code paths and only exposing clear, named actions against it rather than trusting consumers to behave responsibly.
Eventually you hire folks who don't know Rails, might not read the guides, and that stuff compounds fast until outages start hitting. Soft rules are prayers at best, hard rules keep the line.
The sheer number of outages I can point to across now 5 Rails monoliths related to issues with callbacks has made it one of the first things I go after when in a new Rails app to see what's about to give me a nightmare.
Another one that took me a while to research and test, as I wanted to make sure I had a reasonable understanding of the subject matter, especially considering how often getting it wrong has given me a rather bad day.
Last one on this series for a bit, jumping back to some Rails and MySQL fun after this. The next parts of this series are venturing into probabilistic algorithms like HyperLogLog and boy howdy is that dense to get through.
This one is admittedly a sore spot considering how many interviews I've managed to fail over the years from not knowing a lot of this cold, so as is my penance I'm writing about this one too.
Honestly I never really understood how these were written and what the reasoning behind them was as much as I just reached for existing gems or frameworks, so as I tend to do I learn by teaching and writing.
After trying to explain some of the sharp parts around locks to someone I realized I didn't know as much as I'd like to be able to answer with confidence on what to watch out for, so I spent a week or two looking into locking to pull this together.
I was working on some content for algorithms and maths, but in doing so I think I found a more generic starting place on some things that I feel may be missing from Enumerable and the thought experiments around them. This one starts with two-pointers and windows as a concept.
Finally back to writing again, it's been a bit. Wanted to have a redesigned site first, and over the weekend I finally got that landed, so here we go.