Implementing the QS Data Spec on iOS

As part of implementing the Quantified Self Data Spec (look here for an introduction), I’ve started implementing it on iOS so that I’m living with it every day. The implementation I’m about to outline leverages the following technologies:


Launch Center Pro

Launch Center Pro is the perfect dashboard for testing (and even long-term running) of custom QS data collection efforts. You can set up multiple 1-touch actions to rapidly log many data points and have it integrate with other apps on your iOS device via URL-schemes if necessary. Notably, this process I’m using passes off to Drafts 4.

While it is possible to save files directly to Dropbox from Launch Center Pro, in order to fully support/implement the QS Data Spec I needed to be able to have a little more dynamic control over the JSON data before it was saved. You will see that my Launch Center Pro actions are missing the required uuid and timestamp  JSON parameters. These will be inserted with Drafts later in the process.

I am going to demonstrate two basic workflow types: single-step (one touch) and multi-step. I’ve set up a emotional logger as the multi-step example, and a bathroom logger as the single-step example. For the bathroom logger, there are actually multiple single-step actions that I’ve grouped in to a folder, to make it more organized. I’m using single-step actions for this since it happens multiple times a day and I wanted to ensure it was as efficient as possible.

Launch Center Pro

Single-step Action (Bathroom log)

This one is very simple. We need to pass a URL-encoded version of the base JSON object for this datatype to Drafts for further processing. Here’s what the QS Data Spec says the JSON object should look like (full schema):

(Note: while the spec is very medical, I labeled things a little more politely in Launch Center Pro. i.e. feces -> BM)

As I mentioned previously, we will add the uuid and timestamp values dynamically within Drafts, so our Launch Center Pro action simply looks like this:

This action is basically saying do the following steps:

  1. Launch Drafts 4
  2. Get ready to run an action
  3. Pass in the URL encoded text for the JSON object
  4. Run the ‘Log QuantifiedSelf Entry’ action
  5. On success, come back to Launch Center Pro

Multi-step Action (Emotional log)

Launch Center Pro - Emotional

The multi-step example follows the identical process as the single-step example except that it prompts the user for a few inputs before sending the JSON object over to Drafts. Here is what the QS Data Spec says the emotional object should look like (full schema):

Our Launch Center Pro action, complete with user prompts to select the values of the three inputs looks like this:


Bonus! Medical Log

You get the picture, right? So as a bonus we have the QS Data Spec example for medicine (full schema):

And the corresponding Launch Center Pro action, customized with entries for Ibuprofen and Ranitidine:

Drafts 4

Drafts Action Overview

The quickest way to get this custom action into Drafts is from the Drafts Action Directory. I’ve posted it here.

The Drafts action is pretty straightforward. To contain a JavaScript file and a save to Dropbox action. To keep the files more organized until I can process them at a later date, I’ve told drafts to save the files in a date-based file system hierarchy: Logs/[year]/[month]/[day]/[UUID].json

The JavaScript is fairly simple itself. It basically sets the timestamp and UUID, and then saves the file to Dropbox with the UUID as the filename. It ends up looking more complicated because I had to paste in support-methods for UUID and JSON.

Siri-controlled Blog Publishing

Hot on the heels of setting up my markdown-dropbox-blog workflow, I realized I needed a more reliable way to regenerate and rsync the rendered files. The workflow I had set up worked fine for new articles, but not for edits to already-published articles, it assumed I wanted to publish immediately, and didn’t offer any easy way to handle any sort of failure.

What I came up with seems like the digital equivalent of a Rube Goldberg machine but it works and affords flexibility for automating other tasks as well. Besides, Rube Goldberg machines are awesome.

tl;dr – Simply hit a button or say “Siri, add refresh blog to the automation list” and sit back while your Jekyll-based blog rebuilds and republishes itself.

Continue reading “Siri-controlled Blog Publishing”

Branching Out

Don’t be fooled. I still love Drupal.

However, a perfect storm hit me:

  • some recent discussions with folks about how the Drupal community can be rather insulated and myopic
  • my need for a new blog
  • a my desire to use Markdown and some iOS tools
  • was curious about static site generators
  • vacation time!

So I decided to branch out a bit and just play. What I’ve come up with so far is a combination of Byword, Dropbox, Hazel, Octopress, and rsync with SSH keys. It may be easiest to see the overview first …

*Update 2013-12-25: Of course this is already outdated, as I’ve switched to using Jekyll directly instead of the Octopress wrapper around it. It’s largely the same, though. I’m going to play a bit, come up with some more automations, and then post a followup at some point the future after the dust from my playing settles down.*

Continue reading “Branching Out”