edit: apparently a thing -- https://single-spa.js.org/
347 karma · joined August 30, 2013
- am a principal software engineer at PointCard! - worked at Square for 7.5 years. - studied enough applied mathematics to earn a PhD.
More about me: http://traviscj.com/ My blog: http://traviscj.com/blog Get in touch: traviscj@traviscj.com or https://twitter.com/traviscj
[ my public key: https://keybase.io/traviscj; my proof: https://keybase.io/traviscj/sigs/JevjENzfsY9OoqMKH7gl9y_hQu6o2Mji-ERRb18kXpE ]
edit: apparently a thing -- https://single-spa.js.org/
Definitely agree that Lyft/Uber aren’t really ride sharing in that sense though — the driver’s goal is to earn a fare on a trip he wasn’t going to take otherwise, while the original ride shares were a cost-reduction on a trip the driver was going to make anyway.
> become your own advocate
Really resonates with me. Almost every time I go home and hang out with my parents, they share a new horror story about some close call with their medical treatments. (They've both had--and beat--cancer.) Last trip they were telling me about one of the days my Dad was getting chemotherapy; they needed to get a blood draw before the chemo was administered, and the cancer doc had instructed _them_ to make sure the phlebotomist installed a catheter for the initial blood draw, because (if I understood correctly) the extra needle hole in the vein from the blood draw can cause the chemo meds to leak & stagnate near the hand (which risks _the hand_...) But the phlebotomist didn't ask/confirm/want to, apparently because of some damn billing difficulty since the labwork division was different than the oncology division.
My conclusion is that there's a huge opportunity for more patient advocacy to really improve people's lives. Your "data for informed consent" angle sounds like a way more scalable path toward something like that!
- mess cleanup (paper towels, wipes, windex)
- small tool kit (leatherman, couple wrenches, battery post brush, duct tape)
I think there’s more but that’s off the top of my head.
I do a pretty similar version of this with command-| in textmate, but I've wished for/thought about building a command like this to speed up the process!
The textmate approach does have the advantage (or perhaps disadvantage, for large enough inputs!) of emitting immutable "views" of the data at each step, rather than (presumably?) re-evaluating the pipeline each time, which is nice if the steps of the pipeline are the slow part, or to go back 2 steps and start a new pipeline. Maybe a potential future flag? :-)
Automatically emitting an `up<N>.sh` script is super clever too!
My read of your quoted text is "This has the same average time complexity as WAVL/red-black trees, but is a simpler algorithm", which puts the search/insert/delete time complexity at O(log(n)). Being top-down means log(n) time complexity since that's the lower bound on the height of the tree.
In my mind, this alleviates a lot of the “would have to change jobs this year” concerns, because the people making changes would ALREADY be making bigger changes (starting to take their kids to school), and the most extreme schedule changes would be deferred until the children on the existing schedule had aged out of that grade’s current schedule.
(Done enough optimization modeling to know this isn’t an easy path... but seems like it has some potential.)
Similarly, (maybe this was just the article dumbing down reality a bit, but it sounded like the transit expenditure vs parent happiness units were somewhat fungible. Any possibility of offsetting a bit of upfront expenditure with future savings of the more efficient (say from year N/2 onward) future state?
Jk. Money talks, and outrage sells better than dry facts.
What about a process so painful nobody has even thought of it?
1. (most pertinent in this discussion) The logging framework can redact fields before emitting log entries. 2. Endpoints can redact the data unless the client explicitly requests (and is allowed to receive) unredacted data. 3. Serialization mechanisms (e.g. Gson) can be configured to redact data before serializing. (Again, probably can't always do this, but can make that the default for safety.)
It's also very straightforward to hook up as a Java annotation that does the same things.