HN user

gorb314

91 karma
Posts0
Comments30
View on HN
No posts found.

If I were in your situation (which granted I am not) and mood swings related to blood sugar was a concern, I would pick up a simple finger-prick blood testing kit. It is fast, safe and most of all very accurate. That would then either put my mind at ease or convince me to see a doctor.

Again, having what might be very inaccurate measurements of blood sugar won't help in this case either, I fear.

Just my two cents, but as a type 1 diabetic: I either want very accurate blood sugar readings, or none at all. And from what I know about people who don't suffer from diabetes: there is almost no reason to try and find out what your blood sugar is doing, because your body regulates it so well.

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?

Not a feature, but an advantage: From what I can tell (I have only used PureRef so far) is that BeeRef has a open file format. For someone with their own image tagging system, it is hard for me to export an image query to PureRef. Having an open file format would make that easy.

My blog is about my hobbies: drawing, painting, sculpting and modeling.

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.

So I was thinking about the fediverse and blogging, and if we already have blogs then why not publish them using ActivityPub? As in, using your fediverse account to follow blogs instead of just other federated accounts.

I know there is an rss-activitypub server out there. Are there other projects/solutions like that? Something that'll work for static blogs?

I think this is an interesting research direction.

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.

We once went hiking in a newly opened area close to Mt. Kosciuszko, which had previously been decimated by fire. The new growth was so thick and high, it took us 6 hours to walk 5km (3mi), all the while hunting for the pink tags left by the rangers that showed the "path".

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...

Why don't you let the hobbyist decide what he or she thinks is safe to hack on.

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.

Boeing as a whole might not be "evil", the same way VW as a whole is not "evil". So going after the whole of Boeing may not be the right thing.

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?

I've got a related question: I'm looking for a (BASIC) programming book I loved as a kid. I can't quite remember the title, but it was something like "Programming for kids from 8 to 80".

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?

I agree, even as a young kid with no idea how make the speaker even go beep (I was young, ok?) hearing the music/speech coming from Mean Streets was amazing. Everything else up to that point was just beeping and blipping... IIRC the volume was very low though.

I am not a cryptologist, not a lawyer, and only a marginally capable software engineer.

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...

I like the basic script template that the author provides.

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.

Interesting: are you saying that people with Type 2 that progressively get "worse", will eventually become Type 1 diabetics for the exact same reason?

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...

Nice work...

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.

Constructive Solid Geometry using BSP trees.

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.

[0] https://github.com/evanw/csg.js/blob/master/csg.js

Poka-yoke 8 years ago

From my understanding, poka-yoke addresses the problem where "[...] the mistakes are allowed to reach the customer".

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.