itsjustme2
Joined 9 years ago
Joined 9 years ago
Don irritated the guy who invited him into a partnership and then that partnership was rescinded. Don himself prefaces the clip by saying his show wasn't cancelled by X. Seems pretty in line with what Elon said in the interview about how everyone's free to post, but that doesn't mean X will promote it. X decided not to promote Don Lemon's show.
It tells the time and tells me time elapsed, the light isn't obnoxiously bright at night, I'm not fiddling with the interface, I'm not getting pinged, my data isn't being collected, I'm not afraid of breaking it or soaking it, I'm not charging it.
It just works.
I personally thought it was well-written, and I find it relieving to hear someone admit the many flaws in the execution of the covid response.
I agree, it would be great to have a fresh, pragmatic take on this data, and I'll be reading more about that Built for Zero framework.
One Center of Care (CoC) I talked to talked about their old HMIS system from a private company who charged something like $70K/yr (iirc) to keep using their software. That seemed excessive to me, but they didn't seem to mind too much. Migrating off would have been extremely difficult anyway. Their bigger stated need was the ability to easily send data from their system to other CoC systems in the area as the people they were helping moved around or were transferred to more relevant services. Each time those people encountered another CoC, basically the intake process would have to be started over again at the new location, which was a drain on both the receivers and givers of services.
We tried a couple attempts at making a sort of hub for pulling and pushing data to the various systems, but only one entry system company was very supportive, while we had to tread carefully around some of the HMIS system makers who seemed very protective and unwilling to expose or share their APIs if they had any. One big challenge was finding a single unique identifier for each person across systems, which is why a local by-name list like the article mentions is very intriguing.
[0] https://files.hudexchange.info/resources/documents/FY-2022-H...
I just wanted to mention that a friend of mine made an app for user-reported trail conditions that might be worth taking a look at: https://trekko.app/
This looks like it's well-executed too. I like the minimal, elegant design. Good idea on the links as unobtrusive arrows that are still informative as to whether it's linked from/to.
- "The setup is noise and boilerplate heavy." Actually the signals example looks just as noisy and boilerplate heavy to me. And it introduces new boilerplate concepts which are hard for beginners to understand.
- "If the counter changes but parity does not (e.g. counter goes from 2 to 4), then we do unnecessary computation of the parity and unnecessary rendering." - Sounds like they want premature memoization.
- "What if another part of our UI just wants to render when the counter updates?" Then I agree the strawman example is probably not what you want. At that point you might want to handle the state using signals, event handling, central state store (e.g. redux-like tools), or some other method. I think this is also what they meant by "The counter state is tightly coupled to the rendering system."? Some of this document feels a little repetitive.
- "What if another part of our UI is dependent on isEven or parity alone?" Sure, you could change your entire approach because of this if that's a really central part of your app, but most often it's not. And "The render function, which is only dependent on parity must instead "know" that it actually needs to subscribe to counter." is often not an unreasonable obligation. I mean, that's one of the nice things about pure computed functions- it's easy to spot their inputs.