Fractional Postgresql DBA, Ruby on Rails Developer, and Data Engineer.
As developers, we love pagination. It is a familiar UX pattern, it is simple to implement, and we have libraries that make it easy. Give users a few filters, show them how many pages of results there are, and you have an interface flexible enough for almost everyone.
As Rails developers, we’re taught that code is the expensive part and that the database will mostly take care of itself, as long as you throw enough RAM, CPU, and indexes at it. But that approach doesn’t lead to high performance.
A long time ago, I made a call I thought was smart and scalable: using UUIDv4 as the primary key for alerting data. It seemed forward-looking.
Some recent conversations touched on building a culture of reliability. This post explores one piece of that: practice.
Performance First Rails – Lessons From Production
So, HTTPScout’s JavaScript bundle is 1.9MB.
I love the presenter pattern. I use it in all my mailer views.
I use Docker. I used to manually prune Docker every few weeks to keep it from eating up all my disk. Annoyed I eventually put it in cron, but, have you used cron? It wasn’t fun, and I just can’t anymore with cron. I was complaining about it on Mastadon and the adam12 showed me a better way: use systemd timers to schedule the prune. Here’s how it works: first, two files—one for the service, one for…
Pre-pandemic DevOps was a strange place with stranger rules, rituals, and prayers. Here’s one I said regularly—something I thought would give me faster builds and smaller images.
When I was building HTTPScout, the goal was to keep things simple. Every extra service, integration, or dependency meant more things to break, more bugs to chase, more overhead. I’ve spent enough time cleaning up after “clever” setups to know that fewer moving parts is usually the better choice. These five gems helped me stay focused on building.