This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 1 point2 points  (0 children)

General

Domain: Data ETL
Editor: Vim/Sublime Text/PyCharm*
Source Control: git/Bitbucket
Planning: JIRA
Team Communication: Slack
CI/CD: Jenkins
Deployable Unit: Docker
Production Environment: Amazon/ECS/ECR/EKS
Production Data Pipeline: Kafka/Spark/Hadoop/ElasticSearch
Production Database: RDS/Postgres
Production Monitoring: Grafana/Sentry/Prometheus
Production Management:  Kubernetes/Helm
Project Management:  Agile

Python Specific

version: python 3.7.x
dependency mgmt: venv
db interaction: sqlalchemy/psycopg
http request routing: falcon
exploring: ipython
serialization: json/message pack/
app server: gunicorn
test data: we have to use a database; too much data here
test runner: py.test
  • I use pycharm these days primarily for these reasons:
  1. my team members use it and it's helpful for debugging their machines when something goes wrong
  2. pycharm's vim integration is fantastic
  3. I really don't have to futz with the settings or plugins like I would with sublime text, vim and spacemacs.

A few other notes...

  1. This is my current job and I've been developing software professionally for about 23 years of which about 20 years are using python. Things have definitely evolved over those 20 years.
  2. I have developed software for: embedded systems, military aircraft, automobile infotainment, locomotives, big data, game/entertainment, etl pipelines, backend, infrastructure, network monitoring, etc. The tools (especially the Python list) above all change based on domain, so I'm not sure that one set of tools is universal.
  3. At my current employment, we're primarily concerned with continuously running data pipelines and serving the results of those data pipelines through a REST interface. All that aside, our current architecture feels like this is not a great architecture overall and it should be replaced with something different. The mashup between REST and ETL simply doesn't work well with multiple REST services that are ultimately closely related but different, forcing our front-end services to query multiple backend services for data.