I tend to use my calendar and reminders to track a lot of what I want to do, but sometimes I want to manage the data externally and sync. For certain kinds of repeating tasks, I wanted to edit a list of tasks in a group, and it seemed like csv might work. While csv does not have a strong specification, many programming tools make it easy to work with. The initial format I thought about was something simple.

One advantage of having my own personal api is that I can put various useful scripts under a single repo and have them run. I have been using raindrop for several years, to collect bookmarks to read later. Often, while researching things, it would be useful to automatically group things into collections, so I wrote some celery tasks to help with this.

I have long been inspired by Aaron Pareki and his pk3 tool for his website. With some searching, one can find other kinds of personal management systems on GitHub or other developers writing about their own personal api with links to other examples. As a developer myself, I have my own personal API that I am able to add to as wanted.

In the interest of choosing boring technology my personal api is powered primarily by django and celery .

Django comes with support for MIDDLEWARE and provides several useful ones by default. I usually try to make my projects as useable as possible, and some debug middleware is only useful when development.

Example Middleware

Since the order and layering often matter, I’ll usually configure all my optional middleware in the correct spot like bellow, with a short comment.

MIDDLEWARE = [
    "debug_toolbar.middleware.DebugToolbarMiddleware",  # Only enabled for debug
    "django.middleware.security.SecurityMiddleware",
    "whitenoise.middleware.WhiteNoiseMiddleware",  # Used primarily for docker
    "django.middleware.locale.LocaleMiddleware",
    "django.contrib.sessions.middleware.SessionMiddleware",
    "django.middleware.common.CommonMiddleware",
    "django.middleware.csrf.CsrfViewMiddleware",
    "django.contrib.auth.middleware.AuthenticationMiddleware",
    "django.contrib.messages.middleware.MessageMiddleware",
    "django.middleware.clickjacking.XFrameOptionsMiddleware",
]

Then I’ll use other conditional checks to see if this list (or other variables) need to be modified.

Loosely inspired by xinetd , I wrote a simple dev proxy launcher.

Currently I’m using Ansible at work, but I would MUCH rather be using Salt . A discussion on the Salt mailing list reminded me of this again, so I thought I would write down a few notes regarding why I would rather be using Salt (and why I not-so-secretly use Salt for development)

Why have both roles and playbooks?

Roles and Playbooks are somewhat similar, and feel like they have some overlap in usage, so at times it can be quite frustrating to have things that are so similar but different.