I commonly get asked questions around testing and test driven development in Python. Here’s some collated tips I’ve been doing for a while. If anyone has any specific questions or additions to these, please give me a tweet (@charwarz).
An integral part of our Kubernetes infrastructure at work is container image registry mirroring. It ensures if anything happens to the outside network connection to our clusters then the services in that data center can carry on running, or if the image somehow disappears from that source then it’s cached and avoids problems like the leftpad NPM issue. It also locks down access in and out of the cluster to that mirror, rather than haphazard pulling from registries in the cloud.
A while back I wrote about updating my mapping application to use Django for the backend and React for the frontend, having previously used pure JS on the front and well..having no real backend.
A repeated complaint of mine since joining a new company, one which heavily relies on a task board, is that we have a lot of tasks. Some of them are old, most of them are ill-defined, and a lot of them are just notes of what people have felt they should be doing and more dangerously, notes people felt they would be doing not anyone else in the team.
Recently my team established a first and second line support mechanism at work. Essentially, the idea is to address the need to train newer or lesser experienced people on the team for being on call on their own. During work there will be one person on first line who should take any tickets or requests to the team for support and do their best to answer the need. If there’s anything that person cannot handle they should either throw it over the fence to the second line support person, or ask them for help/links to documentation. Here’s some of the things that my week of first line support highlighted, and as work continues hopefully I’ll update this post with tips for avoiding it or fixing it.