morganherlocker

Bummer, bootstrap still causes the same issue, which can be seen on twitter.com.

That is precisely who it was.

I have been dodging calls for the past 3 years from a company that makes Java profiling tools. I am not and have never been a Java dev.

You should use this tool, IMO. It creates images with your commit history graph :-)

https://github.com/gelstudios/gitfiti

They also tend to word much of their social outreach in ways that imply they are releasing it, not the community. I know they have some talented people who work hard on core, but their marketing is pretty slimy and purposely misleading in my opinion.

As someone who switched from python to node.js, I can give a few reasons.

1. npm is extremely easy to use and has a lot of traction. Language X is going to be a tough sell if it lacks good libraries.

2. node.js devs tend to be religiously adherent to the idea of small modules. While not everyone like this, and some would prefer large frameworks, it is definitely a more flexible model.

3. Speed. I happen to write mapping and geospatial analysis software. Most of the existing solutions are python based. I spent months optimizing one particular algorithm in python and was able to get processing time down to 70 seconds. This was not acceptable for a web app, so I wrote a new geostatistical engine from scratch in node.js. New operating time: 35ms. Sure, there were probably ways to optimize the python code further, but it was never going to touch the node implementation.

https://github.com/morganherlocker/turf

4. In data analysis type applications like this, async IO is a huge help. More connections with less servers means huge cost savings.

5. Syntax is just syntax. When I was a python dev I would look at javascript and cringe, now I find myself doing the reverse. I fully expect to look back at both and cringe when I am a few years into my next language. We all experience that feeling when we see something different than we are used to.

Elegant design, great job!

I would venture to say that most people use dropbox and similar services for image sync. Sure people use it for all sorts of things, but I would bet that the majority is images.

At the same time, developers need to ship using the tools that are currently available. I think a multi-pronged approach is inevitable. Of course, I say this as someone who avoids this sort of tool as a general rule, since it seems risky to use in production, so I definitely see what you are saying. On the other hand, this sort of thinking would probably have been an argument against jQuery several years ago, and despite the fact that it was a 'hack' over the awful js standard api, it became a de facto standard through brute force of popularity.

I agree with you 99%, but would like to make a couple clarifications:

> Type I is genetic. If you have the faulty genes, you get it. Regardless of lifestyle, health, country and whatnot.

It is not entirely genetic. It is an auto-immune disease that has a complex, and not fully understood trigger mechanism. That said, type I diabetics still do not have any control over it.

> Type I is binary: you have it or you don't.

Generally true, with the exception of the "Honeymoon Phase" in which new diabetics will still produce small amounts of insulin for a year or two after onset.

That said, I agree with the sentiment all the way.

For diabetics, you are usually injecting insulin, which should be rotated around parts of the body (any fatty area) to avoid scar tissue build up.

In this case, however, I was talking about glucagon, which is only given in emergencies (to messed up to ingest sugar). Glucagon needles are much larger than insulin needles, and can be shot straight into the leg through jeans. The arm would work too, but might be more likely to leave soreness. The main thing is to administer it as quickly as possible.

Correct, the performance of lodash definitely makes it the better choice. :)

Even this only applies to SF and NY, if at all.

This is insultingly inaccurate. Please read any of the literature before posting

How does this help type I diabetes? I see nothing about this diet that does anything beneficial over alternatives. Type II maybe, but please try to research a bit more before throwing in a dictate.

Reduced accuracy would be offset by frequency of feedback. The current model requires active input; you have to go and prick your finger. With a passive input, you could get a general idea all the time, which is especially important considering that a low blood sugar can sometimes affect your mental capacity.

The current solutions I am aware of are invasive (put a big needle into your gut and redo it again every few days), and do not allow for real time feedback. Useful in that you can analyze the data later, but hardly helps when you are currently experiencing an issue (which could be life threatening).

... and when they stop, we can swoon over the tech advances of the new player. The fact that Bell Labs no longer puts out tech hardly detracts from their contributions.

Thanks for the tip. I will buy this and try it out, open sourcing any scripts I can write that will assist in the extraction. Do you know of any existing tools?

If pro athletes are where the demand lies, I am fine with that. Unfortunately, most education around diabetes has conflated type I with type II, which has caused and overemphasis on high blood sugar control, rather than low blood sugar management. Pro athletes might have the same problem as type I diabetics, which could lead to a converging need.

Oh, Panic Room.

The movie in which a child has a severe low blood sugar, on the edge of death, and her mother administers here a large shot of... insulin! I could not believe it when I saw it. The treatment given in the movie would have killed her in no time.

For future reference, in case anyone comes across a diabetic experiencing a seizure. Do not give insulin in this case. This will lower blood sugar further. What they need is to consume anything with sugar, if conscious. If not, they need a glucagon injection. These typically come in a clunky red container, containing a large needle filled with saline and a vile containing a white powder. Shoot the saline into the vile, shake up the vile, extract the solution, then shoot the solution into the affected person's leg ASAP. Do not give anyone insulin under any circumstances. If you give someone glucagon with a high blood sugar, they will probably be ok. If you give someone insulin with a low blood sugar, they will likely be dead. /PSA

Almost all meters allow you to extract data over USB, but the data usually comes out in an obfuscated proprietary format. Do you know which format this exports to? Scott Hanselman had a blog post about this a few years ago (can't seem to find the link).

IMO, every meter should be required to export to CSV at a bare minimum. I will look into the one you linked, but for most users, they really need something that can be easily converted to an xls. The current state of things is that they only export to some supremely terrible proprietary program that is really only meant for an endocrinologist to use with the help of an IT team.

I should be able to easily view my health data and crunch it how I see fit. Decent analytics around my glucose data would be extremely valuable, but the current state of affairs is abysmal.

Expensive hardly matters to me. As long as it is less than ~$30k per 10 years, I would pay. Insulin pumps already cost $10k+, and do not provide as much value. This kind of tech is life extending for those of us who need it, so price kind of moot (up to a point). How much would you pay per year to get an extra decade of life?

Type I diabetic here. Assuming current tech stays where it is (not saying it will), this could easily tack 10 years on to my lifespan. For many who watch their diabetes less closely (something I cannot fault anyone for), this could add 20-30 years.

For anyone who does not know, type I diabetes is not something you can just follow a doctor's direction on and be ok. Even if you follow your doctor perfectly, there can still be serious complications, and type I diabetics with the best control are actually more likely to die from severe low blood sugars.

The reason for this is that the optimum blood glucose level is around 100. <70 and you start to be severely mentally impaired, making it difficult at times to seek treatment (finding and eating sugar, in a nutshell). On the flip side, if you are lax on insulin, your blood sugar might hover around 250 for months, and you will feel close to normal. Having a blood glucose this high on a long term basis will have long term effects that are what kill most diabetics in the long run. A low blood sugar, however, can be fatal within minutes to hours.

Either way, a continuous feedback mechanism would help tight control diabetics, and diabetics who do the minimum. Tight controllers could get faster feedback about when they are going into the serious danger zone without having to initiate any action (checking blood sugar), and lax diabetics would get a constant reminder of how they are letting there life slip away (which they normally would rarely see, since they hardly ever check their blood sugar anyway).

I have to say though, I am still a bit skeptical for a few reasons:

- One, I have been told about this sort of miracle technology ever since I was diagnosed 15 years ago.

- Two, the medical complex locks down their tech and extracts the maximum value out. There is not a single glucose device on the market that lets you extract the data out of your glucose monitor and crunch the data how you want. I have worked on hacking these devices to extract data and the legal verbiage around these activities has strongly discouraged me from releasing anything. Previous continuous glucose monitoring systems. These companies would prefer you rot in the dark, than to lose one bit of profit.

- Three, if one of these devices is not 100% perfect, it gets shot down and banned from the market. This is probably a combination of profit-motivated industry and caution-motivated government. A great example of this is a continuous glucose monitoring, non-invasive watch that came out ~ a decade ago. It was on the market for several years, before being banned. I, like just about every person in the thread I linked, would pay $10k+ for one of these, despite the reduced accuracy over traditional devices. Entrepreneurs in the health industry take note.

[1] [http://www.diabetesdaily.com/forum/testing-blood-sugar/61908...]

Does Google Now not do this? (not an Android user)

Maps works well for me and I can think of few times when I have found it lacking. Siri, on the other hand, gives me a timeout ~15% of the time.

Node core has fs.watch, and I know that grunt has a -w flag. I assume gulp does as well, so this is pretty easy to get with any of the solutions.

> You might prefer to write your builds in Node because you write your app in Node as well. Your team might not know bash.

This is a good point. In the example I linked to, I am actually planning on switching it over to node specifically for windows users. The reason I have not yet is that I handle all the builds so it has not really come up.

90% of the time I see one of these build systems in place, all they are doing is running browserify, then minifying the results. Maybe they have a stylus compilation or a couple things thrown in on top. Either way, most of these tasks would be much less complex in simple bash or node. Does a build script like this really need to be abstracted away?:

https://github.com/morganherlocker/turf/blob/master/build

And yet there are still requests on this project to switch over to grunt or gulp. I just do not get it in most cases. Big tools when not required create a sort of open source equivalent to "vendor lock in".

Love this idea. For small apps, I often just do a git push, ssh to server, git pull, restart app. It sounds like this might make this flow even more simple.