Entries tagged with thoughts
I thought I had arrived. One of my open-source projects started gaining a small following on GitHub. No more nagging self-doubt, the thousand or so star-gazers of my project provided all the validation I needed. Here was something I could conjure up in moments of doubt, reminding myself that I truly was all those things I wanted to believe about myself. I never stopped to think that the stars might not be for me.
* * *
All this got turned on it's head, though, by one of those very people who I set so much store by. I'm thinking in particular of one person who was using my project to manage the backend data-storage for his company's platform. It was a critical function, and as the CTO of his organization, he was responsible for ensuring it was technically sound. He was very invested, professionally, in the direction of my project. This was a sharp contrast to most people I'd talked to, who were using my project for side-projects and hobbies of their own.
The combination of his expectations of me, as a maintainer, and my beliefs about my own motivations for sharing my code led to a pretty unbelievable series of events.
When Kenneth Reitz created the
requests library, the Python community rushed to embrace the project, as it provided (finally) a clean, sane API for making HTTP requests. He subtitled his project "Python HTTP Requests for Humans", referring, I suppose, to the fact that his API provided developer-friendly APIs. If naming things "for humans" had stopped there, that would have been fine with me, but instead there's been a steady stream of new projects describing themselves as being "For Humans" and I have issues with that.
In the Limitations section of the
README, Salvatore has written:
Disque was designed a bit in astronaut mode, not triggered by an actual use case of mine, but more in response to what I was seeing people doing with Redis as a message queue and with other message queues.
This admission makes me wary of using Disque, even if it reaches a stable release, because of my own experience with similar projects I've created but never actually used. These projects are usually fun opportunities for learning, but when it comes to maintenance, my experience has shown me that they quickly become a burden. Usually the problem is masked by the fact that if I'm not using it usually nobody else is either, but in the rare case I do end up with users, then eventually those users are going to submit bug reports and feature requests.
For a problem as complex as a distribute message broker, I imagine that there are going to be a lot of bug reports, strange edge-cases, and feature requests to support exotic use-cases. I hope that, in addition to his work on Redis, Salvatore can find the time to support Disque!
The other reason I don't foresee using Disque is alluded to in the author's own comments. He observes that many people are using Redis as a message broker, and decides that maybe there is a need for a "Redis of messaging". I would say the opposite is true, and that instead of another message server, people want to use Redis!
Redis integrates very nicely into the stack for web-based projects. It can be used as a cache, for locking, as a primary data store, for write-heavy portions of the application, and yes, as a message broker.
Perhaps the reason people are using Redis as a message broker is because they don't want to use something else?
I am proud to live in Lawrence, KS, a college town of about 100,000 which has been my home for the majority of my life. Perhaps the most striking feature about my home is the amazing sky here -- nowhere else I've lived comes close:
Being in the tech industry, I'm often asked if I have plans to move away to a place with more jobs. I always answer simply and somewhat apologetically that I intend to stay in Kansas. Answering that way is so much less embarassing than explaining why I love Kansas. My home is very much a part of me, though, and I'd like to write just once about why I am so happy to live here.