This project is meant to log everything in one's life. The key goal is to let the user go back in time -- and into present too -- and have a better understanding of how things are turning out.
- SMS (partial)
- Twitter (partial)
- Call logs (including audio)
- E-mails
- Events from Google Calendar
- Activity on Facebook
- Activity on Google Plus
- Pictures taken at Google Photos
- Pictures taken at Instagram
- Conversations from Hangouts
- Conversations from Whatsapp
- Conversations from Telegram
- Conversations from Skype
- (please share your idea)
This is an open source project and you might prefer to run it on your own. So here are the basic how-to.
First, you might want to customize a few settings by setting environment
variables. Or just writing them to a .env
file. The available options are:
ALLOWED_HOSTS
: A comma-separated list of domains (FQDNs) that the application will be accessed from. Defaults to'*'
.DATABASE_URL
: The URL to your database in a special format. Defaults to'sqlite:///db.sqlite3'
.DEBUG
: Debug mode. Defaults to'True'
.LANGUAGE_CODE
: The language code to get the application translated to. Defaults to'en-us'
. Mind the language availability.REDIS_URL
: The URL to your Redis database in a special format. It's used to queue asynchronous tasks. Defaults to'redis://localhost:6379/0'
.SECRET_KEY
: A long, powerful and unique random mix of weird chars. It will be used to salt password hashes and other security-wise stuff. Please don't share it anywhere!STATIC_URL
: The URL on which static files will be available, with a trailing slash. Defaults to'/static/'
.TIME_ZONE
: The most adequate time zone for your application instance. Check available options. Defaults to'America/Sao_Paulo'
.
Note that none of these are required in order to run the application in a local development environment, though I highly recommend you to set them for production.
Then, assuming you have cloned this repository and got an active
virtualenv running Python 3.5, you must begin with our magical make
script:
(my_env)$ make setup
Note that you should run the command above whenever you update your local repository from the mainstream. This will keep any local dependencies up to date and run occasional required migration tasks.
This projects uses bower for managing third-party static files libraries.
Please make sure you have an up-to-date version of it installed and available
in your $PATH
:
$ bower --version
As for connecting to third-party API services, the following configuration keys are available:
TWITTER_CONSUMER_TOKEN
: The consumer token provided by Twitter.TWITTER_CONSUMER_TOKEN
: The consumer secret provided by Twitter.
Note that none of the above is required in order to quick-start the project, but obviously not every third-party related module will work. It is important to check
settings/security.py
for details on each service.
From now on you should be able to run a development server locally:
(my_env)$ make dev
Note that this command will run a couple commands simultaneously: 1. start a local Redis server with default parameters, 2. start the
rqworker
command to handle parallel job queues and 3. finally, bound to capturing keystrokes, our modified version of Django'srunserver
. You should not use thismake
command if you intend to develop using different configurations.
And that's it. Of course, for a production environment, you'll want to use a different stack of software and/or infrastructure to serve your application. Check out the Django documentation for details and be careful.
All the current tests are written in a very simple manner thanks to pytest. To check all the unit tests, just run it:
(my_env)$ py.test -vs
Note that the arguments
-vs
are meant to make the tests output more verbose and let any text come into the stdout normally.
There are some important design decisions made to better organize this project. Some of them bypass default Django recommended structure, but greatly improve the modularization of all applications on this specific project. The main point is to take advantage of the core features from Django while having our own structure, pure-Python like.
- Apps are not independent. While following the Don't Repeat Yourself
principle heavily, the "one big app" is split into several core apps
(
backend.*
). This breaks the default Django design recommendation, but gives us an advantage on organization of code and assets. - Front-end is separated from the core apps. While the core apps
(
backend.*
) will provide us base functionality, front-end code related to web views live in the/static
directory. Thebackend.webview
app will rely on it, leaving Django'sAppDirectoriesFinder
useless. Note that it can't be disabled in order to keep support for 3rd-party apps.
Oh and I need coffee to continue writing this. And money to buy me coffee. That's all folks.
This software is available under the GNU GPLv3 license. Please see the LICENSE file and/or read the full license.