«

dia-log, a diabetes management system

Context

I have type 1 diabetes. It's not a big deal, there are much worse afflictions that can hang on a person. Diabetes just means the occasional pain in the arse (sometimes literally xo).

I am supposed to get up early, eat 3 steady solid meals, and exercise; as is the case with every university student, none of the above happens more than one day a week. I am also discouraged from excessive alcohol, but that is another scéal. Every once in a blue moon (between once a month and once every 18 months) I have to go to the hospital to see a nurse or doctor or dietitian, and look at the trends in my blood sugar.

The biggest hurdle with diabetes is tracking my blood sugars. I use a glucometer like this to measure my blood glucose level. This is a device with a pathetically small battery and a sufficient amount of internal memory, that stores a history of my blood sugar readings in mmol/L, next to a timestamp of when that reading was taken.

It is a closed system; I cannot access that data. I have dreamed of writing ML tools to predict a hypo, suggest that I should take more insulin at certain meals, or even just graph my sugars. It is fine (but against my libre ideals *sob*) that it is a closed system, I can get past that. But every time I visit the hospital, I am supposed to bring all of my blood sugar data from the previous weeks or months in written form, so the doctor does not have to squint at the tiny screen on the glucometer and scroll through readings one at a time. Ugggghhhh.

I have for years been planning to sit down and write a system to digitise the process of logging blood sugars in an open and friendly format, and this afternoon I finally did it.

Project

Presenting: dia-log (and its accompanying frontend);

Dia-log (diabetes logging, perhaps the most boring project name I have ever envisioned) is a small backend+frontend to allow a number of users (or a single one, as in my case) to upload their blood sugar data to the cloud (at least, a VPS in my case).

Right now, it is a lightweight system.

The backend is a JSON-based RESTful server implemented with Flask (my favourite framework of all time, it's so nice to use). So far there are only two endpoints; one to add a new blood sugar reading, and one to add a new user.

That's right, it's a multi-user system, with some small authentification of those users, based on a username and (bcrypt+salted) password.

The frontend is as yet a simple static form (with a nice date picker based on Pikaday and moment.js) that sends things to the back end, built with a python&jinja-based static site generation script. I hope to spice it up with some CSS (TACHYONS is very nice) at some stage, and add some d3-flavoured visualisations; but baby steps.

Design Decisions

I was asked why I separated the project into two separate repositories. It seemed to make more sense;

I have configured my nginx to make the frontend available at dialog.blurry.video, and the backend at dialog.blurry.video/api, with some rewrite-fu in the middle to make Flask think it is at a subdomain and not /api.

I wanted dia-log to be very configurable, and if you look at the config.json that comes with each repo, I think you'll see I succeeded reasonably well with that.

All of the blood sugar readings are put into plain old textfiles (of the path <configurable_dir>/<username>/<timestamp>), so a backup is as simple as a cp (or in my case, a git push). I have read lots of praise for plaintext data storage systems, and with how simple this data is, a database would likely be overkill.

I need to document, and add a few more features, configuration options (I ignore timezone woes, and there are other measurement systems than mmol/L, to name a couple) and tests, but who knows; maybe another sorrowful diabetic will find these tools useful someday?

Share Comment on Twitter