I’ve virtually never regretted erring on the side of being more explicit about my expectations and my intents.
I like to distinguish between “distributed” and “remote”.
Being distributed is an intrinsic property - a team can be distributed, with no real central locus like an office.
Being remote is an extrinsic property - you’re remote from something, like a remote team in another country.
Your code lives in version control, with easy branching, reviewed changes, and tests, right?
Does your documentation?
By writing code in a non-standard fashion, we took on overhead that we would have not had to worry about had we stayed with the widely used platform defaults
Don’t underestimate the costs of doing your own thing.
Do you know what your full dependency graph looks like?
I built Emporium to get a better idea.
Emporium looks at libraries on the Python Packaging Index (PyPI), and analyses their dependencies.
For some libraries, that’s quite a small set - many have no dependencies at all, or a tiny handful at most.
Most of my Raspberry Pis run headless, with no screen. So the image I keep around is Raspbian Lite. It’s half the size of the “full” Raspbian-with-Desktop image, it has everything I usually want, and very little that I don’t.
But sometimes I find I want a GUI.
I don’t want to have to keep the full image around and re-image my Pi. Nor do I want to have to manually install the various components of a desktop environment.
I do want a single command that just “gives me a GUI”.
I really like Django. Django is fast, featureful, secure, scalable, and versatile. It works well with a variety of workflows, approaches, tools, platforms, and libraries.
But sometimes you can have too much choice.
I’ve spent a lot of time working with Django, and supporting other users via IRC in #django on Freenode. In that time I’ve seen a lot of the same questions come up again and again.
Django doesn’t provide official answers to many of these questions, and I don’t think it should - its versatility is one of its strengths. Here are my answers though - all of which are broad and given without knowing exactly what you’re doing - they’re not universally correct, but in the absence of knowing better, if you’re facing an unclear choice, then they should provide some clarity.
Moving from a “blog service” to a static site generator has been great:
- Hosting static content is pretty easy
- It’s backed by git, so I get all the benefits that brings: history, branches, diffs, etc.
- Security-wise, the attack surface is much smaller - the production site is just static HTML/CSS/JS, so there are entire classes of vulnerabilities and threats that I don’t have to worry about
However, it’s possibly come with a little complacency - I looked back recently to find I’d not actually updated the framework itself since my very first commit ~6 years ago. Slightly embarrassing (as someone who regularly talks about the benefits and importance of regular incremental updates) but not exactly surprising: “the cobbler’s children have the worst shoes” after all…