dia-log, a diabetes management system
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.
Presenting: dia-log (and its accompanying frontend);
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.
I was asked why I separated the project into two separate repositories. It seemed to make more sense;
- The two parts are, from a programming point of view, completely separate. They communicate over a RESTful API but share no code.
- I would like to create alternate clients at some stage (eg. a mobile app), or at least leave the option open for it.
- The server is a dynamic app but the frontend is a static site better served with nginx or apache than Flask for performance and configuration reasons. Putting them in the same repo would conflate and confuse this.
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
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?