This page is archived. Please visit https://countable-ops-manual.readthedocs.io/
TLDR, read this
We don't want to support every stack, so we chose the best for most cases and want to pass on the benefits of a superior stack to our clients, rather than them making an uninformed choice. Our stack selection is based on the following (descending importance):
- Popularity, growth, longevity and community support.
- Power, generality, flexiblity and interoperability.
- Open Source, inclusive community.
- Ease of use, readability, simplicity.
- Performance.
We've found the following back end stack to be very good on these metrics.
- Python - 3rd most loved language, and is the most wanted. [1]
- Node.js - 4 most loved language, 2nd most wanted. [1]
- Django / Flask / Express
- Unix (Ubuntu Linux for servers)
- PostgreSQL - 2nd most loved database [1]
- Redis - most loved database [1]
- Docker
Python in particular is a very strong general purpose stack choice. With "software eating the world", Python's been the condiment of choice, and is appearing in many niche industries. This lets us synergize with other of our clients' projects, staff and expertise within the same lingua franca.
| Technology | Current | Ideal |
|---|---|---|
| celery | not used | avoid, use django_rq |
TODO: add more to the above table
(Docker.)[./OPERATIONS.md]
Avoid language-specific environmental dependencies that can be met by built in functions or by Docker. ie, you don't need virtualenv, pyenv, grunt, gulp.
These are progressive principles for making your application predictable and scalable.
We have a lot less prescription on the front end, and choices are based on developer skill. However, we observe guidelines:
- Bias towards fewer dependencies. What's the simplest set of dependencies that will work?
- Bias towards small, specific purpose dependencies over frameworks. React, Preact and Riot is better than Angular in this way, for example.
- Ensure depedencies have healthy community support and/or are small enough to fork if support wavers. Ideally both.
These tables capture our current thoughts on the outlook for front end dependencies in our projects.
| Technology | Ideal |
|---|---|
| jQuery | avoid, slowly migrate to native dom |
| React | avoid, prefer preact or Vue |
| Angular | avoid, continue in existng usage |
| Riot | preferred for Django projects |
| Vue | preferred for SPA projects |
| Technology | Current | Ideal |
|---|---|---|
| postCSS | may use for complex css needs | |
| CSS vars / scopes | may use for simple projects | |
| SCSS | preferred | |
| other preprocessors (less/ stylus) | avoid, migrate away |
For front end builds, we always use Parcel.js and NPM scripts (no webpack, no gulp, no grunt)
We use mocha, native Node.js assert, and puppeteer for e2e tests. Superagent for API tests.