кумулятивное обновление KB4566116. После установки этого патча пользователи ОС Windows 10 версии 1903 и версии 1909 могут установить вторую версию подсистемы Windows для Linux (WSL 2).
Вот только Docker Desktop всё равно требует наличия Hyper-V.
services.AddDbContext регистрирует контекст, как scoped. Transient сервис делать смысла особенного нет, потому что он зависит только от EFTodoDBContext, который scoped.
В Web-окружении вообще всё имеет смысл делать scoped.
Разница в lifetime у DbContext только в том, что при долгом времени жизни DbContext насобирает в себя очень много tracked-объектов и начнёт тормозить и жрать память.
Отключать нотфикации хорошо для конкретного работника, но очень плохо для команды, особенно если в ней есть новички. В случае командной удалённой работы нужно думать о других ещё больше, чем в офисе.
Желание отключать связь надо обязательно обговаривать при найме, потому что я работал в нескольких командах, где за это уволили бы.
Отвечать быстро нужно, чтобы не блокировать людей.
Если у вас в команде появляются блокированные задачи, то вы начинаете терять производительность. Особенно, если у вас в команде не все синьёр-юникорн-топерформеры.
Основной принцип удалёнки «spice must flow», если вы не отвечаете быстро, вы блокируете человека.
когда я задаю вопрос, не жду моментального ответа и двигаюсь дальше.
Если люди не получают быстрый правильный ответ, то они либо ничего не делают, либо начинают искать обходные пути, либо делают предположения, которые не всегда верны. Всё это портит производительность относительно ситуации, когда команда сидит в одной комнате.
Человек наиболее эффективен, когда работает над одной задачей в состоянии потока. Если вы не отвечаете быстро, то человек выходит из состояния потока, ждёт, потом переключается на другую задачу и теряет фокус. Переключение стоит сил и времени, обратно переключать контекст на прошлую задачу тоже займёт время.
Когда команды сильно разведены в часовых поясах и время ответа занимает сутки. В этом случае вы не сможете минимизировать число открытых задач и WOT (количество задач в work in progress) зашкаливает. Большой WOT ведёт к тому, что планирование становится очень сложным.
Работать в условиях с долгими ответами можно, там становится ещё более важно писать правильные вопросы и давать полные ответы. Но эффективность такой команды будет сильно ниже, чем если бы они все сидели рядом, особенно если у проекта сложная бизнес-логика.
Мы в итоге, к тому же и пришли. Только у нас не make migrate, а большой скрипт, который инициализирует окружение. Только вот для запуска этого скрипта надо локально установить кучу всего, например, чтобы сделать mongorestore нужно поставить mongo-tools, чтобы проиндексировать эластик, надо собрать соответствующий кусок приложухи, для сборки которого нужно поставить SDK. Так что да, вынести сервера бд в отдельные контейнеры можно, но SDK всё равно надо будет ставить и настраивать.
Невозможность работать офлайн или при плохом Интернете.
Хороший интернет в наше время must have. Без него вообще плохо.
Необходимость делить один и тот же ресурс с другими разработчиками и тестировщиками.
Почти никогда у нас это не проблема, но зависит от проекта, конечно.
Такой сервер достаточно хрупкий.
Да, он хрупкий (хотя перед выкладкой прогоняются тесты), но понять почему у фронта упало бекендерам сильно проще, потому что обший сервер пишет логи.
Есть более важная проблема при таком подходе: очень сложно иметь по серверу на фиче-ветку. Можно сделать front-ветку на каждого фронта и если фронту нужно переключиться на какую-то фиче ветку, то то эту ветку мерджат в front-ветку и CI/CD её строит. Однако это запарано, потому народ всё льёт в master.
Так для разработки и нужно, чтобы каждое добавление поля в базу бэкендером сразу же было доступно фронтам. Причём чем интенсивнее разработка, тем быстрее должно обновляться API и база.
Иметь образа с данными можно, но строить такие образы намного сложнее. По мне пока самый простой способ, это делать образ уже запущенного и модифицированного контейнера. Те я не знаю, как описать рестор данных в рамках Dockerfile.
Потом для автоматического построения всех этих образов нужна инфраструктура, причём она должна куда-то публиковать образа. А образа должны быть специфичны для веток в которых идёт разработка. Ведь в разных ветках могут быть разные поля в базе. Ну и операция переключения между ветками для фронта будет тоже не такой тривиальной.
В 1909 можно установить WSL2, но Docker Desktop не запустится, без фичи Hyper-V, и не даст использовать WSL2 (Галка Use WSL2 будет задизэйблена).
Вот только Docker Desktop всё равно требует наличия Hyper-V.
В Web-окружении вообще всё имеет смысл делать scoped.
Разница в lifetime у DbContext только в том, что при долгом времени жизни DbContext насобирает в себя очень много tracked-объектов и начнёт тормозить и жрать память.
Тут и ТК никакого не надо.
Желание отключать связь надо обязательно обговаривать при найме, потому что я работал в нескольких командах, где за это уволили бы.
Отвечать быстро нужно, чтобы не блокировать людей.
Если у вас в команде появляются блокированные задачи, то вы начинаете терять производительность. Особенно, если у вас в команде не все синьёр-юникорн-топерформеры.
Основной принцип удалёнки «spice must flow», если вы не отвечаете быстро, вы блокируете человека.
Если люди не получают быстрый правильный ответ, то они либо ничего не делают, либо начинают искать обходные пути, либо делают предположения, которые не всегда верны. Всё это портит производительность относительно ситуации, когда команда сидит в одной комнате.
Человек наиболее эффективен, когда работает над одной задачей в состоянии потока. Если вы не отвечаете быстро, то человек выходит из состояния потока, ждёт, потом переключается на другую задачу и теряет фокус. Переключение стоит сил и времени, обратно переключать контекст на прошлую задачу тоже займёт время.
Когда команды сильно разведены в часовых поясах и время ответа занимает сутки. В этом случае вы не сможете минимизировать число открытых задач и WOT (количество задач в work in progress) зашкаливает. Большой WOT ведёт к тому, что планирование становится очень сложным.
Работать в условиях с долгими ответами можно, там становится ещё более важно писать правильные вопросы и давать полные ответы. Но эффективность такой команды будет сильно ниже, чем если бы они все сидели рядом, особенно если у проекта сложная бизнес-логика.
Вроде Slack тоже умеет в видеоконференции.
Какой у вас размер индекса и какая конфигурация кластера (ноды/память/cpu)?
А как получить страховку на 40 летнюю яхту? Без страховки ни в одну марину не пустят.
Хороший интернет в наше время must have. Без него вообще плохо.
Почти никогда у нас это не проблема, но зависит от проекта, конечно.
Да, он хрупкий (хотя перед выкладкой прогоняются тесты), но понять почему у фронта упало бекендерам сильно проще, потому что обший сервер пишет логи.
Есть более важная проблема при таком подходе: очень сложно иметь по серверу на фиче-ветку. Можно сделать front-ветку на каждого фронта и если фронту нужно переключиться на какую-то фиче ветку, то то эту ветку мерджат в front-ветку и CI/CD её строит. Однако это запарано, потому народ всё льёт в master.
Иметь образа с данными можно, но строить такие образы намного сложнее. По мне пока самый простой способ, это делать образ уже запущенного и модифицированного контейнера. Те я не знаю, как описать рестор данных в рамках Dockerfile.
Потом для автоматического построения всех этих образов нужна инфраструктура, причём она должна куда-то публиковать образа. А образа должны быть специфичны для веток в которых идёт разработка. Ведь в разных ветках могут быть разные поля в базе. Ну и операция переключения между ветками для фронта будет тоже не такой тривиальной.