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 (новости релизов)

ansible

Есть, так называемое, "бухгалтерское" округление до суммы. Например, не буду брать процент, как поделить 100 рублей между тремя работниками: каждый получает 1/3 суммы, последний остаток (33.33 + 33.33 + 33.34).

Дополнительно: не путать с "бухгалтерским" (или "банковским") округлением до ближайшего четного (в процессоре есть специальный регистр для переключение округления с математического на бухгалтерское).

Загадки округления.

Никак.
Команда "Архаровцы" из Нижнего Кукуева имеет коэффициент прошлых побед 10.
Команда "Атлетико" из Мадрида имеет коэффициент прошлых побед 8.
Каковы шансы победы архаровцев?