You have a system backed by a Postgres database that uses UUIDs as primary keys for everything. This is nice:

• You can generate ids on clients before transmitting writes to servers if you wish.
• You don't have to worry about exhausting the integer size allocated to your auto-incrementing primary keys.[^1]
• You don't have to worry about enumeration attacks from auto-incrementing primary keys.
• You can identify and index on data that has no natural key, without the challenges of auto-incrementing primary keys.

In roughly chronological order:

• Actively contributed to language design discussions for over a decade
• Enhanced some stdlib functions early on in Elixir's development
• Contributed the expressive relative Ecto migration mix tasks
• Allowed ExUnit.Doctest to handle fenced code blocks
• Developed an experimental key-value store adapter library, Mnemonix
• Started volunteering my time to help run ElixirConf US, Lonestar Elixir, and Gig City Elixir conferences since 2016
• Implemented the defguard macro
• Building a [first-class match specif

Flask-SQLAlchemy has some nice built-ins (e.g. accessing query directly on classes). To continue leveraging these nicities while still inside of a Celery worker, we need to make sure we setup/teardown in a similar fashion to Flask-SQLAlchemy does on Flask.

Flask-SQLAlchemy uses create_scoped_session at startup which avoids any setup on a per-request basis.

https://github.com/mitsuhiko/flask-sqlalchemy/blob/2.0/flask_sqlalchemy/__init__.py#L668

This means Celery can piggyback off of this initialization.

git config --global alias.chunk 'add -p'

Usage: starts an interactive chunk-by-chunk staging session, similar to git rebase -i. Handy for picking apart a full index to make a nicer narrative of small commits.