Chronicle allows you to form reliable memories. It keeps track of a tree of memories that are, ultimately, linked to the factual records recorded at the very moment they happened.
STATUS OF PROJECT: Chronicle is no longer active and has been superseded by neuron, which is based on Zettelkasten. The README below is left as is for historical reasons.
Humans are adept at denialism. The author therefore presumes that only a data-centric approach can be effective at improving human well-being and productivity.
The basic idea is to keep track of a tree of memories. Accumulation of data occurs at the level of leaf nodes (individual moments), from which we "fold" the memories up to summarize at the ancestries. Specifically, we fold all moments of the day to summarize for that day, and then fold all days to summarize for that week, then month, year and so on.
All level of summarizations are ultimately linked to the specific moments (thus forming a tree) that can be consulted at any time. We thus create reliable "memories" that are recorded at individual moments (the very moment they happened) without the bias of faulty recall.
There is also the notion of "story" (yet to be implemented) which some moments can belong to. A story is thus linked to the individual moments, and can be consulted when "telling" (to oneself or others) the story later on, and with little bias.
Chronicle stores all of its data in PostgreSQL. There are 4 concepts (tables):
This is what the user records (nothing else); it represents how things were going at that very moment (only) involving no recall or reverie.
This, as the word indicates, is a string of moments forming a "story" to be recalled (or re-told) later. Examples:
Each moment can belong to at most one story. Some stories, like "India trip 2015", are smart stories in that they are specified using time ranges (thus moments can't explicitly belong to them).
These are analogous to the colored shapes in my blackboard (cf. Seinfeld productivity hack). The idea is to have basic (SVG?) shapes defined somewhere – in Elm, or database — and let the user specify a list of them to be rendered ultimately in the calendar view. Fields:
Each day, week, month, year are summarized as folds. Stories may have their own folds (eg: work fold). Fields:
The calendar view of folds will be showing these marks (usually just the default one), thus emulating what we have in the blackboard. The user can define custom marks in the Marks table and refer to them in the folds.
Fold can also enable habit tracking (eg: contemplate XYZ every day; with value=0 or 1, accumulating over week/month/etc).
Please note that chronicle is not yet ready for public use.
As the first step, prepare a local postgresql database:
echo "CREATE database chronicle;" | psql psql -d chronicle < schema.sql # Optionally load production dump from Heroku (see below) as: pg_restore -d chronicle -a -t moments latest.dump
make run # requires spas cloned and compiled in parent repo make compile # rebuild Elm sources whenever they change
Full schema available in schema.sql. Use
\d+ 1.moments to inspect the view.
ALTER ROLE <username> SET timezone = 'America/Vancouver'; to set database timezone. This however doesn't automatically change the day end marker from 12am to something custom (like 3am).
To retrieve schema from Heroku Postgres:
heroku pg:backups capture curl -o latest.dump `heroku pg:backups public-url -a <appname>` pg_restore --verbose --clean --no-acl --no-owner -h localhost -U srid -d chronicle latest.dump rm latest.dump pg_dump -s chronicle > schema.sql vim schema.sql # remove odd looking definitions
Some new packages I can create by extracing code from this repo:
23 secs ago)
heroku pg:psql --app $APPNAME < schema.sql
heroku config | grep SPAS)