Again, having what might be very inaccurate measurements of blood sugar won't help in this case either, I fear.
91 karma · joined February 2, 2017
Again, having what might be very inaccurate measurements of blood sugar won't help in this case either, I fear.
So I just don't see the point of this. Non-invasive glucose monitoring just doesn't seem feasible, the accuracy doesn't help diabetics and it certainly doesn't help non-diabetics.
I'm a naysayer on this, but I do hate having to continuously test my sugar and buy expensive CGM gear. Please prove me wrong?
A good example of a project page would be [2]. It shows the complete scratch build of a model tank, and is one of the more detailed step by steps.
[1] https://www.vigilantesculpting.com
[2] https://www.vigilantesculpting.com/projects/2021-08-19-storm...
As I blog about my projects and their progress, my static site generator will aggregate posts tagged with the same project name, so that the project's page will show a chronological build progress, as opposed to the typical reverse chronological listing on the blog's front page.
I think it's kinda neat and I haven't seen many other blogs that do this.
I know there is an rss-activitypub server out there. Are there other projects/solutions like that? Something that'll work for static blogs?
"Need more power? Use OpenGL."
we will be able to "Need more power? Write a shader."
?From my perspective though, being a T1, what I want is an even faster acting insulin than we already have, with a shorter "on" time.
To explain: the shortest acting insulins we have right now take effect about 30 minutes after injection. Then the dose stays active for about 4 hours. So for me to react to a high blood sugar, and until I can be certain that I did not inject too much (nor too little), can take up to 4 hours.
That is almost unbearably long, especially when my blood sugar climbs through the roof, and I am not sure whether it is because my pump line was blocked. Overloading on insulin (called "stacking") to compensate for a crazy high blood sugar can be very dangerous - plus I can't think straight when my sugar is that high. Nothing sucks more than having to sit and wait for a high blood sugar to come down...
Contrast that lagged response time to eating food, especially high GI sugars such as a soft drink, orange juice, or even bread. This can spike my insulin in a matter of minutes.
All this makes matching sugar spikes with insulin response curves very hard; it is a one-side-overdamped-and-other-side-underdamped dynamic system. Any diabetic will tell you how crazy a "roller coaster ride" can be, which is what happens when you overcompensate on either end.
To get back to the topic of the 'smart' insulin: if this research can lead to an insulin that can always be in my bloodstream, ready to act when my blood sugar rises, and stop when my blood sugar falls, and if it can do this quick enough, then that would be a game changer.
It is certainly not that far-fetched to see how the plant life Down Under has evolved to live with and take advantage of wild fires...
As a T1D myself, having to spend about 50% of my waking life second-guessing what my endocrine system is up to (with the same system screwing with my cognitive ability to successfully do so), I want to Close The Loop as quickly as possible, barring an actual cure.
Yes, it is dangerous "hacking" these systems. But just as dangerous is every one of the daily decisions I have to keep making myself, over and over again.
At the same time, some high-up people in VW are paying for the emissions-cheating scandal, which arguably could endanger human beings and the environment.
When are people in Boeing going to pay for actually contributing to the deaths caused by this scandal?
Googling for it doesn't help, all I get are references to the 80s, or the TRS 80, or some such.
Does anyone remember this book, or where I can find it?
But I think we've had the option to send personally encrypted end-to-end messages for a while now. (Open)PGP anyone?
So instead of using Signal, or Whatsapp, or whatever and depending on their client-side-encryption (and possible server-side-decryption) of private messages, how about plain email using standalone user-encryption.
Two things may come of this: Google will stop "interpreting" my email messages, and laws like these stop mattering very much.
Of course, 5th amendment (and its siblings in other countries) still apply...
However, when I start development of new code I always use a script that starts off with traceback and pdb, something like this:
#!/usr/bin/env python
import traceback
import pdb
import sys
def main():
# some WIP code that maybe raises an exception
raise BaseException("oh no, exception!")
return 0
if __name__ == "__main__":
try:
ret = main()
except:
traceback.print_exc()
pdb.post_mortem()
sys.exit(ret)
This means that whenever an uncaught exception gets raised, I immediately get told what happened (full backtrace) plus I get dumped into the debugger, from where I can inspect why this happened. I liberally sprinkle assert()s through my code, so this gives me a good edit-run-debug cycle to work with.Forgive my asking again. I am a Type 1 diabetic, since age 7. I know that it is an autoimmune disorder. I find that (as seems to be the case with the original article), people tend to blur T1 and T2, and the causes/effects/treatments for each, and it can be mildly infuriating...
I've ported this algorithm to Python, but mine is nowhere as succinct as yours (or the original). For my needs, I require the meshes to remain watertight (if the inputs are watertight), and this specific implementation doesn't preserve it. But I still love the algorithm due to its conceptual simplicity.
There is a javascript implementation [0] which is where I saw it the first time, it is about 500 lines of fully commented code. The algorithm is so simple, I absolutely love it.
Basically, when performing a union on two meshes, we determine the 3d BSP trees from both meshes, then simply clip each mesh using the other's tree. The output is the union of the two leftover meshes.
And since both intersection and difference can be written as a combination of inversion and union, they are simply composed from those.
I can't find a good paper on the algorithm though, not sure where exactly it originated.
In software, we know that the later a bug is caught, the more expensive (in terms of time / resources) it is to fix. So we want to catch bugs / mistakes earlier.
The "simple" idea that Poka-yoke introduces is to make it harder to make the mistake in the first place. If a physical component can be mounted more than one way, but there is only one correct way, then design it such that it is impossible to mount it incorrectly. This can be done by making the mounting holes for the part asymmetrical, for example.
IMO, in software a similar concept would be to fail early and fail hard.
[1] http://libb64.sourceforge.net
[2] http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html