If you've built Rails applications, you've likely used the popular High Voltage gem to handle static pages. But what happens when your application outgrows the constraints of this gem, particularly when using modern view components like Phlex within a multi-tenant or namespaced application?
When rate limiting jobs, I use a simple redis rate limit lua script that I posted here: https://mhenrixon.com/articles/client-side-rate-limiter , and I also use a similar scheduler to spread the jobs out. This is how I do it
I never liked the built-in date picker; it looks different in every browser. I wanted a date picker that fits with the existing design without learning how to style a third-party library.
In an attempt to keep things stupidly simple, I had issues choosing tags for my array column tags. Every library I tried expects me to be more complex, so I "rolled my own™
MongoDB 2.x has few possibilities for data extraction, and I need to make some changes to be able to load it into PostgreSQL. Recursion was the last thing on my mind 🤷♂️
After 37signals posted how they sped up their test suite considerably by using cookies directly instead of signing a user in for every test, I wanted to do the same. Why spend more time than necessary on testing, am I right?
Unfortunately,
Sometimes you have to get ahead of things. Rate limits suck but are there for a reason, waiting until the API you are calling raises a rate limit error is bad, really bad. This is how you get ahead and prevent the external API from raising rate limit errors.
Ruby is more than a little memory hungry. This is a known fact, what isn't known by most of my clients is how to reduce memory consumption considerably. This is how you do it.
I wanted a custom font to use for my website. While loading fonts using google fonts is possible, I want to reduce the number of external dependencies as much as possible and this is how I did it.