> failing to load the one part of the map that I want to see.
Yep. My partner and I have this problem every time we use the app in our home city. It usually works better when we’re traveling. I’ve left them feedback and will keep hoping for better. Meantime, I’ve switched to a less frustrating app.
Same. The guy didn’t change any of my profile or recovery info, luckily, so I was able to get it back. And then he sent me a message from another account asking why I had taken his UIN. We ended up chatting for a while. It’s a fond memory.
I actually tried to delete that UIN a few years ago, but the support folks wanted me to provide a few UINs from my contact list to verify ownership. No chance I’m going to remember those.
My main use case is upgrading codebases that depend on ffmpeg. I work for a shop that does a lot of media encoding and analysis across several independent systems, and we can’t upgrade all of them at once when a new ffmpeg is released, which means that for a while we’re actively supporting versions N and N+1. With this plugin, each codebase can declare which version of ffmpeg it wants in .tool-versions, and I don’t have to remember to do the uninstall/reinstall dance.
Most people won’t need this, but a few might find it very helpful.
Congrats, Bob, and thanks for all of your time and effort. I enjoyed the illustration videos that you included in the earlier blog post [1] (under "Illustrating by Hand"). That post landed at a time when many of us were badly stressed, and I remember it being very soothing.
Agreed. Maybe it was just the April-2020 of it all, but "Writing is Suffering" really hit me in the feels. It's inspiring to see all your hard work reach this milestone, and I can't wait to hold it in my hands.
One advantage of CloudFront is support for uploading large files (5GB+) to the origin server. CDNs tend to enforce a low size limit for uploads. It’s probably an uncommon use case, but the reduced client-side latency is nice for customers who are far away from the origin.
A tool for visualizing log file volume over time in your terminal [1]. Useful for quickly getting a handle on traffic patterns during a production incident. This began as a scratch-the-itch project and was also the first useful thing I made in Rust. Two itches scratched :)
A tool for visualizing ping latency as a heatmap [2]. My Macbook's wifi had developed a severe latency stutter every ~500ms that was driving me nuts when using interactive tools like SSH. It was very satisfying to visualize it and see the pattern, and it helped to narrow the list of possible causes.
Last year I built a tool for visualizing log file volume (based on time) in your terminal [1]. Similar tools exist, but none were fast enough or easy to set up in a hurry, e.g. when you're investigating a production outage.
The year before that, a tool for visualizing ping latency as a heatmap [2]. My laptop's wifi had developed a severe latency stutter every ~500ms that was driving me nuts when using SSH and other interactive tools, not to mention killing my throughput. Once I could visualize it and saw the pattern, it was very clear that there was a system-level issue. Eventually traced it to a virtualization product's network driver.
It's definitely a pattern for me -- feel frustrated with diagnostic and data viz tools that are either too slow to handle or too complex to configure when I need them, and try to build simple tools that solve exactly the problems I keep bumping into. These smaller projects also provide good opportunities to practice with new languages or frameworks.
Yep. My partner and I have this problem every time we use the app in our home city. It usually works better when we’re traveling. I’ve left them feedback and will keep hoping for better. Meantime, I’ve switched to a less frustrating app.