> A) If being useful were enough to make a product successful, we'd still have Google Reader
Yeah bad example, Google Reader was extremely successful, so much so that it’s demise was enough for _many_ companies to be very financially successful by taking Reader’s customers.
I don't know much about CT requirements, but can't they prune data out of their logs after some time? Since the certs only last 6 days, the growth of the logs can be capped at some point right? If not now, provisions for such operations could surely be implemented, I imagine.
> I don't know much about CT requirements, but can't they prune data out of their logs after some time? Since the certs only last 6 days, the growth of the logs can be capped at some point right?
That's what happens - logs are "expired" after a few years. But if you want to have an exhaustive monitor, you probably don't want to discard the records of expired certificates.
Hmm, I wonder if it's possible to do dedicated intermediate certificates that promise to only sign short-lived certificates for a single site? That way the CT-log could be taught to only keep the intermediate?
That follows your system setting for the back gesture (mouse clicks immediately go back). If you use "Swipe Left or Right with Two Fingers" for the "Swipe between pages" setting, there is no animation. If you don't use a Magic Mouse or Magic Trackpad I don't think you'd see it at all.
From my experience, Rust programs are consistently high quality, just work, and deploy easily. I've rarely seen any well-known Rust projects that are garbage. Since Rust is still emerging in the corporate world, those proficient in it tend to be passionate engineers who take pride in writing solid code.
Rust’s steep learning curve is a pretty good filter too :)
Webhooks are a classic example of premature optimization masquerading as "best practice". The irony in this blog post is palpable - they advocate for webhooks while simultaneously describing their fundamental weakness. A webhook system requires you to implement the exact polling mechanism you were trying to avoid in the first place, just with added layers of complexity.
The recommendation for "exponential backoff spanning several days" is particularly telling. What happens when your service faces extended downtime beyond their arbitrary retry window? Your "real-time" system suddenly develops permanent blind spots. Meanwhile, a simple polling implementation would seamlessly catch up by simply processing the backlog.
For mission-critical integrations like payment processing, I've found that polling Stripe's events API at regular intervals is not just more reliable - it's significantly easier to reason about and debug. When issues arise, you can simply reset your local state and replay events, rather than attempting to recreate the exact conditions that triggered a webhook failure.
The purported benefit? Saving a few seconds of latency in a business process where users are already accustomed to asynchronous workflows. It's architectural complexity theater that solves a non-problem while introducing very real failure modes.
Well, in addition to near-real time, polling sucks at sparse workloads. Waking up to do work can be pretty wasteful with spiky or infrequently used but still important actions, and are arguably easier to set up, despite the hemming and hawing of this article, across system boundaries. But I do agree that webhooks are not the thing I really want to reach for with mission critical, high load integrations unless I feel like torturing my future self.
reply