One I'm familiar with (but don't know deeply about) is Iron-air batteries [1]. Form Energy [2], an interesting grid-storage startup uses them. They're not energy-dense whatsoever, but very cheap, which makes them economical for that application.
Neat project and approach! I got fed up with expensive registries and ended up self-hosting Zot [1], but this seems way easier for some use cases. Does anyone else wish there was an easy-to-configure, cheap & usage-based, private registry service?
You reminded me of this scene from Battlestar Galactica that has stuck with me since I watched it (spoiler alert). Conversely, the character laments the sensory limitations of the human body :)
I was actually thinking about Tay-Sachs this morning on a walk, after I passed by a church with a billboard out front that says "Christ died for all, even babies in the womb".
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.
I’m a huge fan of Postgres. This one is “user error”, but we still got bit pretty hard.
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.
One strategy I've found useful when asked for an estimate is to ask back: "What do you need the estimate for?" Often, this leads to a useful discussion, and we can discover things like:
- 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.
I've been loving my COROS. It's quite simple, and the battery life is astonishing. No music functionality though, if that's a dealbreaker for you. I got the APEX 42mm about 5 months ago.
I've been kicking around a related idea for a while. A static "death day" is great because you can internalize, and countdown towards it, but it loses the distribution behind life expectancy. A single day is probability's expected value, but there's a huge range of days that could be your last - even today!
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...
Robocalls are super annoying, but kind of an amazing way to ask someone out on a date (not first date - followups where you know they'll say "yes").
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]
Awesome idea, and nice work! Is this open source, and if so, would you mind sharing a link to it? I am beginning work on a slightly similar project [1] to help facilitate speech therapy (girlfriend is a speech-language pathologist) over video chat and would be interested to compare with your approach and tech stack.
I saw this [2] Chess + video chat project the other day, and drew heavy inspiration from its approach [3].
I got paged 50 minutes before AWS updated their status page. We are running on AWS's managed Kubernetes offering (EKS), and about one third of our nodes were running in the affected availability zone. We were then able to move all of or traffic out of that AZ, which solved our issues. The main symptom was HTTP requests made by our backend to 3rd party APIs failing, but only on requests originating from that AZ.
Not strictly related to this article or your question, but generating ordered UUIDs can sometimes bring some performance improvements (at least in Postgres) on index reads/writes [1].
[1]: https://en.wikipedia.org/wiki/Metal%E2%80%93air_electrochemi...
[2]: https://formenergy.com/technology/battery-technology/