Glukloader 1.0.4, I upgraded to
El Capitan (OS X 10.11) to find that
Glukloader wasn’t working anymore (not synching).
It seems that the behavior regarding an internal event changed in 10.11. I found an alternative and that’s what’s new in
Glukloader 1.0.5. I also reverted
a change from
1.0.4 to try and address instability issues when the receiver was plugged in on a Mac going idle. After some reading, I realized that this
is something that ORSSerialPort was supposed to be handling gracefully so I decided to upgrade to the latest
release (which has a few related fixes) and see where this would get me.
So, if you see this bug with
1.0.5, please contact me.
Grab the latest build here.
Here’s a bugfix release for something I hope I was the only one experiencing. I had noticed that my keyboard and mouse (and USB peripherals) on
iMac would sometime stop working after it going to sleep. At first, I suspected a hardware issue but I started noticing one day that I had my Dexcom receiver plugged in before my Mac went idle. And it happened a few more times when my receiver was plugged in again. So I cleaned up a little the management of the USB device and made sure it would be closed after a successful sync rather than keeping it open. After some testing, it looks like that might have been it.
Or maybe it was all a coincidence but either way,
Glukloader 1.0.4 is being a little more conservative in closing the resources and it’s for the best.
If you did have mysterious issues with your peripherals not responding after going idle, I apologize. Hopefully, this will solve that mystery.
Grab the latest build here.
I’m happy to announce that I finally decided to fully open-source Glukit, Glukloader and glukameleon (a little tool used in dev) under the MIT license. The main blocker was that I needed to find a solution to keeping client ids and client secrets outside of the repository and I found something I’m happy with now.
I was hesitant to open-source Glukit for a while because much of its value resides in the centralized service that enables you to be compared to other diabetics. It’s a bet but I’m hoping that Glukit going open-source won’t mean everyone starting their own instance. And even if that happens, that might not be the end of the world.
Here are where the repositories can be found:
safekeeper, a command-line tool to use with go:generate to keep secrets safe from the git history by generating code from environment variables, written in Go: https://github.com/alexandre-normand/safekeeper.
If you decide to grab the code and try hacking and find yourself lost, don’t hesitate to get in touch.
I’ve been wanting to open-source Glukit for a while but I had to find a way to keep the client ids/secrets safe and outside of git before I could do so.
Since Glukit runs on the Google App Engine, it can’t itself just read the sensitive information from environment variables. I read a post that suggested storing the secret keys in the datastore but I had quite a few and felt like this solution lacked good integration in the development flow.
After reading about go generate, I thought that this might be a good use for it. If I could get a way to use go generate and generate my app secrets into code that was going to be ommitted from the repository, I’d have something relatively simple and convenient.
Based on the go generate examples, I set myself out to create a command-line tool that would take a few inputs and generate a file to be git ignored containing all application secrets. You have to follow the instructions to get a nice integration but once it’s set up, developers can set their secrets in their environment and then they just have to run
go generate or
goapp generate to get them into the code to deploy or run.
I tried to include a detailed example of how it can be used effectively but let me know if you find anything missing.
I got a log file in my inbox earlier this evening. Sometimes, people write an accompanying email describing a problem but this time, I only had the log file. It didn’t take long to see the crash and stack trace in the logs. After a quick investigation, I found that there was a bug when the last sync had been done long enough ago that the last page synched didn’t exist anymore on the receiver. That was an easy fix and I just pushed the release with the bugfix.
Grab the latest build here.
Thanks to the anonymous bug report!
I just realized today that my a1c color wheel wasn’t rendering properly on Safari. It’s now fixed. If you were using Safari, now the a1c display should make a lot more sense. Firefox should also be covered if you’re using a recent version.
I also made a small tweak to the a1c calculation which should result in slightly higher values. I believe this should be more accurate but I don’t have enough samples to actually know for sure.
Again, I’d like to hear about your experience with this feature. Refer to my previous post for my suggested experiment.
Don’t hesitate to tell me what your experience is with this. Email me!
This will be a quick feature annoucement post because I think most of you will understand it without much need for detailed explanation.
As of this evening, Glukit will now display an estimate of your a1c based on your most recent data available.
A few notes:
- At least 3 months of data is required for a value to be shown.
- From the limited samples that I have, my a1c estimates seem to be lower than reality.
- The A1C color wheel might been a bit aggressive at first glance. I debated internally whether or not to tune it down but decided not to in the end. The standard presented in Glukit is more in line with Dr. Richard Bernstein’s recommendations than what you’d see from the American Diabetes Association. If you haven’t read The Diabetes Solution, I highly recommend it. It definitely was a major factor in me getting my A1C down to 4.4.
I’d like to hear about your experience with this feature. For people with the desire to do so, one interesting experiment to run would be to check you estimate the day that you get your a1c tested. Write it down. When you get your a1c result, it would be interesting to compare the estimate with the actual value.
If you feel like running such an experiment, I’d love it if you could email me your results. It would make it easier for me to improve the feature to provide more accurate estimates. And I promise that I won’t be judging.
Update: Added additional logic to seemlessly handle receiver being reset. Link updated below.
Dexcom released their new 505 firmware version earlier this week and I was happy to give it a try. I haven’t used the new version yet to confirm how better it is, but it’s looking promising. With that news also came the realization that Glukloader wasn’t quite ready for the case of receivers being reset. Thankfully, addressing it wasn’t very difficult.
I also got rid of the colors in the Glukloader menu bar icon. Glukloader should now fit more elegantly in the menu bar next to other black and white icons.
That’s it. You’ll find the new version here.
I’m currently the sole developer behind glukit but, like I mentionned in my intro post, I’m feeling a bit drained about the 17 months of uninterrupted work on it. Today, I’d like to call out to diabetic developers who would be interested in pushing glukit further.
As of today, the main feature of glukit is the comparison with a “steady sailor”. The steady sailor at the moment is the diabetic who has the best glukit score. And to make things more interesting, I’ve recently excluded myself from the pool of eligible users.
The next features I’d personally like to see in glukit are:
- a1c prediction
- ability to challenge a friend to be your steady sailor
Following that, I’d like to add more behavioral science nudges and potentially play with different ideas regarding the normative comparisons (aggregate comparisons with a “steady sailors” group and the average).
There’s also some ongoing efforts to enable 3rd party uploaders to push data to glukit and enable people that aren’t running on OS X to use it.
Glukloader, the Mac OS X uploader is written in Objective-C. Glukit itself was written in Go (and yes! Go is a lot of fun and it’s easy to learn) and runs on google app engine. glukit’s front-end uses the gumby framework. Both Glukloader and glukit’s code is hosted on github.
Get in Touch
If that sounds like something interesting to you, I think it could be a lot of fun. Glukit is a fully functional app but I have a nice backlog of exciting features that I think would be awesome for it. If you’d like to give this a try, talk to me. I’d love to hear from you.
Glukit had been built with multiple glucose units in mind but, to minimize the scope of the initial testing, the front-end had been made to support only mg/dL. I’m happy to say that this is now no longer the case. If your Dexcom is set to mmol/L, you’ll now be able to browse your data in the unit you’re used to.
Glukloader Required Upgrade
In the troubleshooting process with a friend from UK, I found a critical bug in my interpretation of the glucose values when the unit was mmol/L. If you’re a mmol user, you need to upgrade to the most recent build to get proper values: Glukloader 1.0-rc23. You should also drop me a line so we can reset your data uploaded with previous versions.
The build also includes a handy new feature: emailing glukit logs with a simple one-click action (in the “Advanced” menu).
The last week or so has been pretty interesting (see this reddit post for some details). The first few days showed how bad assumptions can quickly become blockers and then how other assumptions can manifest themselves in more subtle ways.
Time Resolution Bugs
I talked about the first blocker in the previous post but this is more about the latter. I had assumed that the Dexcom’s internal time was standard. That is, I assumed that two receivers would have different display times but the same system time at any given point in time. That proved to be a bad assumption to make. ChickenBeard again helped with this bug by testing my numerous builds and being patient with my varied attemps at finding a more robust solution.
I’m happy to say that it looks like my new approach is now working. The bad news is that previously uploaded data is bad and locally stored archives of your data (a copy that Glukloader keeps for you and for resending data in case of disasters) is also faulty (potentially). The result is bad times (it looks like bad timezone handling). It’s not necessarily dramatic but I’d like to sanitize the data at some point. More to come as I think about this and talk to a few more of you to understand the impact.
Since Glukloader has proven to be very important to the whole interaction with Glukit, I decided to follow edwhittle’s suggestion and add some user feedback with it.
Here’s the link to the new build with both of those: Glukloader 1.0-rc20.
Again, talk to me if there’s anything on your mind.
Today was a big milestone for Glukit: someone else besides me used it. Or rather, someone else besides me tried to.
Given the interesting and active discussions on /r/diabetes, I had the intuition that I might find people who met my pretty strict requirements: Type 1 diabetic Dexcom G4 user with a Mac.
While this didn’t go as smoothly as I would have hoped as people were giving it a spin, I was surprised to see this much activity on my post.
On the technical side, the biggest problem was due to a bad assumption (or oversight) I made a long time ago. Most people don’t enter user events (injections, carbs) on their receiver and the receiver returns an indicator to say there’s no data. Except I wasn’t expecting such a value. With the logs kindly provided by ChickenBeard, I was able to identify the bug and add tests to reproduce it. And fix it, too.
So, for my fellow redditors that were kind enough to give it a try but experienced Glukloader becoming unresponsive, this might be an update that you want to try: Glukloader 1.0-rc12.
Oh and there’s also a timezone related bug that I’m trying to isolate at the moment. Hopefully, it won’t be too long before I figure this one out.
Again, don’t hesitate to contact me.
People who know me can attest to this (I hope): once I commit myself to doing something, I do it. Even if it makes my life miserable. Even if no one is looking and the cost of giving up is nil.
I do it because I need to create something. I do it because I know that the result might be worth it. I do it because I know that working on something brings a great satisfaction only on successful completion of it.
I started working on glukit in March 2013. We’re in August 2014, 16 months later. After an initial functional app, I had a good idea of what the minimal set of features I wanted in the 1.0 preview release. And I wanted to get that first release out. So I committed myself to making 1 commit every day until I got all of it done.
This got me a streak of 200 days of commits on github. The funny thing is that I realized only after getting hooked that my streak would only ever be visible to me because my repositories are private. But that’s not why the feature is powerful. There might be a social aspect to it but, to me, this was another behavioral science trick to help me get to a desired outcome.
The Dark Side
Now what? I’ve gone through the making of successful creative projects like this one before. The hard part if always the life after. The truth is that I feel exhausted from having worked so hard without a pause for so long. That hard work and dedication got me to a significant milestone. But, now at that milestone, it’s hard to find the energy to commit to the next phase.
The first day of my 2 weeks family vacation was the day I made the commit that marked the 200th day. I knew I had to wrap-up before losing focus. I’m afraid that taking a break will get me to move away enough that I won’t want to get back to it. I might get drawn to something new like drawing or writing a book.
But glukit is also different. I did commit before I left that I would return from vacation to announce the preview release of glukit. If I was successful in creating a convincing presentation of my idea for a better, behavioral science powered diabetes application, maybe you’ll have something to tell me. Comments, suggestions, requests. I worked on glukit for so long that I can’t see clearly anymore if it’s any good or if it can be effective like I imagined it.
You’ll tell me.
If you think it might have potential, I’d be excited to hear it.
Your emails might be what fuels my next commit streak.