chupasaurus

1. Работа над личным брендом: Высокая репутация в профессиональных сообществах повышает привлекательность для нанимателей.
   
2. Улучшение существующих знаний: Хочешь что-то понять, объясни другому.
   
3. Приобретение новых знаний: Специализация замыкает в узком спектре задач и проблем, а Q&A-сервисы - это источник задач и проблем из самых разных областей и иногда под самыми неожиданными углами.
   
4. Альтруизм: Большинству из нас кто-то помогал в начале пути, пришло время возвращать долг и делать свой скромный вклад в рост кадров.
   

Ещё бывают поклонники какой-то технологии, которые делают вклад в её развитие, продвижение и популяризацию, помогая другим с ней разобраться. Но лично я за это пока не брался, хотя мысли есть.

Для чего просиживаете на тостере по 5-6 часов в день?

Я в среднем раз в полчаса-час заглядываю. Если находится интересный вопрос, могу потратить на него минут 10. Некоторые на перекуры больше времени тратят.

numbers = [n for n in range(1000, 10000)]

или

numbers = list(range(1000, 10000))

Почитайте уж что-нибудь типа "Асимметричная криптография для чайников".

Личный ключ не должен уходить к недоверенным лицам вообще. От слова совсем. Попадание ключа стороннему лицу - это возможность идентифицировать себя как тот обьект, который в сертификате (человек, оборудование, сервер).
В CSR же - общий ключ и данные, которые будут вписаны в сертификат (кстати, необязательно все - CA использует шаблоны, которые могут и игнорить часть данных).

если просто
listen [::]:80;
?

Программы подбираются под ситуацию. Общего универсального средства нет.
Можно использовать и штатные механизмы WIndows, работают отлично, хотя не всегда удобны.

Как правило делается образ системных дисков серверов - для быстрого развертывания.
Диски виртуальных машин как правило удобнее делать отдельно.
Такие вещи как БД лучше бэкапить штатными средствами в большинстве случаев.

Тут главное обращать внимание на несколько основных моментов -
1) У вас должен быть план развертывания. Вот представьте ситуацию, полетел сервер, есть бэкапы и нужно срочно развернуть - и что дальше? Какие ваши действия по пунктам?
Вот тут у большинства и начинаются проблемы - они настраивают бэкап, по принципу - будет проблема разберемся как восстановить, а при реальном сбое в условиях дефицита времени совершают ошибки, вплоть до случайного уничтожения бэкапа.
Поэтому забэкапили - создали план восстановления, и проверили его.

2)Работа механизма бэкапа должна обязательно контролироваться - чтобы в случае неуспеха и проблем приходили сообщения ответственным лицам. Иначе по факту зачастую оказывается бэкап есть, но за прошлый год.

3)Доступ к хранилищу бэкапов по сети должен быть только у пользователей которые создают бэкап, больше ни у кого, даже у администраторов не должно быть доступа. В идеале сам сервер бэкапа забирает бэкап.

4)Регулярно надо проводить плановые проверки и развертывания - инфраструктура меняется, и возможны ситуации что при настройке бэкапа эти изменения не учли.

5)Особо критичные данные должны хранится территориально удаленно.

Win 10 умеет запоминать позицию и монитор, на котором приложение запускается из коробки.
Насколько я помню, надо отресайзить окно, чтобы оно не было на весь экран, перетащить и расположить где надо приложение и закрыть его. При следующем запуске оно должно быть в той же позиции на том же мониторе где было.

Вы должны разрабатывать и деплоить приложение соответствующим образом. Так, чтобы старая версия приложения могла работать с новой версией схемы базы. Или наоборот, новая версия приложения могла работать со старой схемой базы.
То есть удаление таблички: сначала деплоите приложение, которое уже не работает с этой таблицей, потом удаляете таблицу
Новая табличка: сначала миграция, затем приложение
Новое поле в таблице с default значением: сначала поле, затем приложение
Новое поле без default: сначала новое поле с default null, затем релиз приложения которое обязано писать новое поле, но ещё не читать его (либо приводить null к нужному если это возможно на приложении), затем миграция с проставлением нужного значения (и, блин, не одним update по всей большой таблице), drop default, set not null, деплой приложения со всей логикой
И так далее. Во время разработки думаем, а как, когда и в сколько итераций это можно будет задеплоить.

Ну и, разумеется, DBA (или заменяющий его обязанности человек) думает над тем, как именно вносить нужную миграцию в базу

Предполагается, что "сервер" это не боевой сервер, где крутится приложение, а сервер сборки, например агент teamcity/jenkins/hudson.

Если же у вас на "боевом" сервере что-то пойдет не так, то это что? интернет пропадет, чтобы подкачать зависимости? Так а как юзеры будут тогда на нем работать?

Предполагается, что разработчиков много.

Предполагается наличие pull request-ов, которые требуют успешного билда для merge

Если ты работаешь сам, то делай как тебе удобно. Если работаешь не сам - есть best practice

После загрузки файлов на сервер, они пакуются в архив, шифруются

Вот тут ошибка!

Правильно, будет так:

Выбираются файлы для загрузки, заполняются поля и комментарии к загружаемым файлам. Они пакуются в архив, шифруются и, после загрузки файлов на сервер, становятся доступны для скачивания по ссылке с доступом по паролю, например.

Для шифрования (до отправки на сервер!) используйте файловый контейнер.
Например, VeraCrypt (новости релизов)