[1]: https://en.wikipedia.org/wiki/Metal%E2%80%93air_electrochemi...
183 karma · joined March 13, 2016
[1]: https://en.wikipedia.org/wiki/Metal%E2%80%93air_electrochemi...
https://secondlifestorage.com/index.php?threads/glubuxs-powe...
^ has a wild picture of full setup
- https://caltopo.com/map.html#ll=40.10094,-105.61557&z=15&b=m...
- Right click and select "Simulated View"
- Change to "WireImagery" in the upper right
I learned about Tay-Sachs in high school biology. I think we watched a short documentary on it, as an example of genetic inheritance, and the importance of enzyme function. I remember being so surprised that something so simple (absence of one protein) could be so horrible. A beyond-grim prognosis, and immeasurable/unavoidable suffering for everyone involved. Since then, it's been something that I can't reconcile with the existence of a higher benevolent being. I'm no expert, but it made a lasting impression on me.
I'm so uplifted that researchers have made progress on curing this senseless disease.
A query plan changed, on a frequently-run query (~1k/sec) on a large table (~2B rows) without warning. Went from sub-millisecond to multi-second.
The PG query planner is generally very good, but also very opaque. The statistics collected during an ANALYZE and used by the planner are subject to some significant caveats. Essentially, the planner would sometimes wildly mis-estimate costs due to under-sampling, and would choose a bad plan. We fixed it in two different ways: 1) lower the auto-ANALYZE threshold; 2) increase the number of rows sampled when collecting statistics for the relevant column.
Again, this was “user error”. That said, it will probably happen again on the same or another query, because it’s hard to know if/when a query plan is about to change, and pg_hint_plan and similar are very heavy-handed solutions.
- They don't actually need to estimate, because the task can very obviously be completed by the previously window
- They're simply trying to prioritize two different features, so the estimate doesn't need to account for who will be working on the project, known vacations, meetings, etc.
- The business is trying to use the estimate for strategic planning, so high-confidence, or multiple estimates (optimistic/normal/conservative) are actually needed.
It's similar to when someone comes to engineering and asks "Please build this button for me" - it's always crucial to ask "Why?" and understand the problem they're trying to solve, since often what they've asked for is not what they need.
My idea is a daily (or weekly/monthly/etc) notification that re-computes a "death day" for you, on that recurring basis. Each notification would include a day, and together, they'd form a distribution that faithfully represents the variance in days you're likely to die.
For example: me; 28-year-old male. I'd regularly get "death days" that are ~50 years out. Occasionally, maybe they'd be 25, or 55 years away. And very rarely, they'd be things like 10, or even 5 years away. A perfect reminder to play hooky, or call up a friend, or tick off a bucket list item every once in a while!
Anyone interested in this? I'm kind of fishing for an excuse to build it...
Twilio has this thing called "Twilio Studio" [1] that is essentially a UI that can be used to make these fairly easily. I've asked things like cuisine and alcohol preferences, what time is best for them, and even done more creative things like SMS a scammy link for them to send details in order to collect their "grand prize" (the date).
Also, for the same person, I built an online game for her to play with her students, tailored for speech-language pathology. She works in a public school and was having a really hard time adapting curriculum to an online format (due to COVID). She and her co-workers loved it, and since then, we've made a lading page, more games, and thinking about turning it into a business! [2]
https://gist.github.com/scott113341/56c03bc7f285eefbea0a6146...
FWIW, I ran into the same issue (Chrome): https://user-images.githubusercontent.com/1910118/81509549-a...
I saw this [2] Chess + video chat project the other day, and drew heavy inspiration from its approach [3].
[1]: https://github.com/scott113341/slp-memory
[1] https://caltopo.blogspot.com/2011/12/launching-caltopocom.ht...
Story of a failed pentest https://news.ycombinator.com/item?id=18475438
[1] https://www.2ndquadrant.com/en/blog/sequential-uuid-generato...
Very clear technical writing, mostly about web technologies.
I don't think they are asserting that the laser beam travels faster than the speed of light. I think they are referring to Proxima Centauri being about 4 light-years away from Earth [0].
Completely agree, but I've found this can be a non-technical "feature" too. Serial integer primary keys are much more susceptible to human error when doing any sort of direct database manipulation.
Make a typo on a integer PK? Wrong user gets deleted. UUID typo? Row not found (almost certainly).
Another source of error I've seen is when someone in sales asks "Hey, can you remove User #1234?", but they really meant Customer #1234." With UUIDs, there's no "collision" between the tables.
Clearly there are better process/tool-based ways to prevent these types of mistakes, but it's a useful side effect of UUIDs.
Its submission from 2 years ago: https://news.ycombinator.com/item?id=11517491