fearthetelomere
Joined 5 years ago
Karma
56
Submissions
38
Member since
Feb 11
Recent submissions
Comment · 1 year ago
Comment · 2 years ago
Survival analysis is often also called time-to-event analysis or failure analysis in engineering. In a general sense, it's used to model time until a "death" event, whether that could be divorce, machine part failure, or actually a person's death.
While methods like linear or polynomial regression can be used predict continuous variables like number of patient deaths over time, survival analysis gives us more context and allows us to make inferences about the survival of individuals and populations as a whole, in addition to forecasting illness.
It does this in a few ways, but firstly by giving us a more rich language to discuss survival data. This is where concepts like "censoring", etc. come into play. It should be noted that censoring here does not refer to the colloquial use of the word, but rather the statistical definition [1].
Survival analysis in practice includes training KM-curves, Cox-PH models, etc. by fitting them to the underlying survival data based on this censored data. It's very possible that new and more robust methods have come out since I last touched the subject around 2015. Modern NNs may blow these models out of the water in terms of pure predictive power, but from a population-modeling perspective survival analysis would likely still be very useful.
Comment · 2 years ago
Thanks, explains a lot. Wish the article did a better job explaining that instead of framing it as a version upgrade to V2.
Comment · 2 years ago
>Diving into the actual contents of one of those PASSIVE_UPDATE_V1 dispatches, we would send all of the channels, members, or members in voice, even if only a single element changed.
> the metrics that guided us during the [zstd experiment] revealed a surprising behavior
This feels so backwards. I'm glad that they addressed this low-hanging fruit, but I wonder why they didn't do this metrics analysis from the start, instead of during the zstd experiment.
I also wonder why they didn't just send deltas from the get-go. If PASSIVE_UPDATE_V1 was initially implemented "as a means to scale Discord servers to hundreds of thousands of users", why was this obvious optimization missed?
Comment · 2 years ago
I see, I didn't know that.
Why would one sell permanent ownership of a networked product? I've been seeing the rise of "lifetime" subscription levels (pay once) for SaaS products, but I'm curious as to what the actual long-term economics of it are.
If your cost of operations is not a one-time cost per user, I don't see how you can avoid a subscription model.
Comment · 2 years ago
Remember: it's local-first, not offline.
When users subscribe they should be purchasing a license that renews periodically. Local-first apps should validate the license (based on its expiry) by connecting to the internet to ensure users are subscribed. If they're not subscribed or they don't have internet access, they cannot use pay-walled features. You should offer a free, fair, and robust export tool for those not subscribed, though unfortunately not many companies do this.
What am I missing here? The drawback is of course when customers don't have internet access but are still valid subscribers, so they lose access to pay-walled features. One option would be to only offer annual licenses (infrequent license checking), another would be to offer a complementary 7 day license extension for the short-term until the user reconnects to the internet (grace period).
Stop giving away your value proposition for free. Get paid fairly.
Comment · 2 years ago
A bit of an aside, but CRDTs are not always the best approach to solving the local-first distributed consistency problem. For the specific given example of syncing files it might make sense, but I'm starting to see CRDTs used in places they don't need to be.
Where is your ground truth? How collaborative is a given resource? How are merge conflicts (or any overlapping interactions) handled? Depending on your answers, CRDTs might be the wrong tool.
Please don't forget about straightforward replicated state machines. They can be very easy to reason about and scale, although require bespoke implementations. A centralized server can validate and enforce business logic, solve merge conflicts, etc. Figma uses a centralized server because their ground truth may not be local.[1]
If you try a decentralized state machine approach the implementation is undoubtedly going to be more complex and difficult to maintain. However, depending on your data and interaction patterns, they still might be the better choice over CRDTs.
It could be argued that even for this example, two local-first clients editing the same file should not be automatically merged with a CRDT. One could make the case that the slower client should rename their file (fork it), merge any conflicts, or overwrite the file altogether. A centralized server could enforce these rules and further propagate state changes after resolution.
[1] https://www.figma.com/blog/how-figmas-multiplayer-technology...
Comment · 2 years ago
Adderall?
I'm only half-joking :)
Comment · 2 years ago
This looks super promising...
I very much relate to the dropdown example, and I've found that complicated UX patterns can be extremely awkward to implement and maintain in LV.
One example from my experience that was prickly to implement in LV was graying out a chat message you sent if it didn't get acked or persisted by the channel/server for any reason.
Can't wait to try this out in my next project!
Comment · 2 years ago
While still a marvel in its own right, I couldn't help but feel underwhelmed when I visited.
After witnessing the architecture of both ancient and (relatively) modern Eastern/Southeastern structures, I found the Sagrada Familia lacking. It came across somewhat soulless with its bleached cavernous interior and uninspired stained glass artwork.
That came across harsher than I truly feel, but I think it's garnered some undeserved hype especially after 100 years of construction. I wonder what structures inspired Gaudi that may be lost to time, and what feelings he wanted to evoke in me that I didn't experience during my visit.
Comment · 2 years ago
I often synthesize this as: to write, is to think.
It derives from David McCullough's quote, "Writing is thinking. To write well is to think clearly. That's why it's so hard."
In order to arrange the right words in the right sequence to convey the right message, you're required to organize your thinking, and also consider how it might be consumed.
To bring it back home, I suppose the same could be said of writing code.
---
As an aside, McCullough wrote my favorite biography, John Adams.
Comment · 2 years ago
If you do find the time, I'm sure that writeup would be very valuable!
Comment · 2 years ago
As I know nothing about TableGen, can someone explain when you would reach for this tool? Perhaps even links to simple examples?
Comment · 3 years ago
It may seem trivial, but I assure you it's valid criticism. FWIW, I've stopped using the Books app on my Ipad in favor of emailing my ebooks to my Kindle account and reading it through the Kindle app.
Why couldn't they have an option to keep the old animation? In 2022, it should be that simple, but of course...
It's not that I loved the old animation, but rather that I can't stand the current one. It's like I'm rotating a deck of cards, taking one off the top of the pile and putting it underneath. Not very pleasant to me, and also not an animation style I've seen used in any other book apps to my knowledge. I wonder why that is?
I've often wondered about this, so I'm curious to learn more. I agree in principle we should be more clever to ensure we have better memory use. However, half the implementations in the list you've linked use a growth factor of 2, so I'm confused about your point.
If it's not the best, what is? Do you know why these implementations opt for 2 if it's not the best choice?