Notes

this is not the real thing, just scraps of topics that should go into the real thing.

Project Development

• create feature branches for your work. It's ok to push feature branches to the main repo. But you can also make a fork to your own repo if you want.
• create a pull request as early as possible, even if you're not done yet. add a prefix to the title: "[WIP] my new feature". [W]ork [i]n [P]rogress: meaning don't merge yet!. This allows a nice overview of who is working on what and where merge conflicts might arise.

Deployment branches

At the beginning of the project there is just the 'develop' branch. It can be deployed to "dev" and "live" servers. After the first release, "master" should be used for "live" and "develop" for "dev". Using the git-flow-ish branch management.

Project deployment

• Always setup a sentry project
• if the project uses HTTPS, set up django-secure

Naming conventions

• created_at, created_on, modified_at, modified_on (past time form!)
• item_count (for amounts)

python: use single quotes everywhere.

templates:

• see https://github.com/divio/divio-boilerplate/blob/master/README.rst
• template readability counts: it does not matter if the resulting html has excess whitespace after indenting loops and ifs

required reading/watching

• Brandon Rhodes (RuPy): "THE NAMING OF DUCKS: WHERE DYNAMIC TYPES MEET SMART CONVENTIONS"

Database Fields

• ForeignKeys that can be blank, should also have on_delete=models.SET_NULL. This prevents cascade deletes of a lot of attached content that is usually not what you want.
• Filer fields are also ForeignKeys, so the rule above applies!

Tools to evaluate

• cookie cutter for aldryn app templates (and project templates?): https://github.com/audreyr/cookiecutter

Package publication

• TODO: check out http://www.jeffknupp.com/blog/2013/08/16/open-sourcing-a-python-project-the-right-way/ if it applies us

Aldryn Addon Rules

• always translate in English and German