Про то, что шрифт случайно окажется в кэше, уже можно забыть из-за такой штуки как cache partitioning. Чтобы избежать трекинга через ресурсы, теперь для каждого сайта в браузере свой кэш. По-моему, эта фича уже везде включена по умолчанию.
Вы себе даже не представляете, какого труда мне стоило прочитать ваш комментарий. Мой мозг постоянно спотыкался о неправильные окончания, склонения, знаки препинания. Такой уж у меня мозг. Мне пришлось сделать над собой усилие, чтобы сосредоточиться на содержании, а не на форме. Я ни в коем случае не обвиняю, просто вот так по-дурацки работает мой мозг.
То же самое относится к код-ревью. Если код написан без соблюдения стилей и нэйминга и у меня есть возможность поручить ревью кому-то другому, то я именно так и сделаю. В противном случае я потрачу на ревью в 3 раза больше времени, чем надо. Просто потому что, если мой мозг замечает дерьмо в коде, то ни на что другое переключить внимание он уже не может.
Так что если вас волнуют когнитивные усилия читателей, пишите красиво. Если не волнуют, пишите, как хотите.
На мой взгляд, основная проблема UML, как и любого другого языка, - на нём должны сносно разговаривать все участники процесса. Если вы знаете, что обозначают разные виды стреловек, а ваш визави нет, то коммуникация не состоится.
Может мне так "везло" с проектами, но последний человек, который нормально владел UML, это был мой препод в ВУЗе.
Поэтому, чтобы избежать проблем в коммуникации, я всегда добаляю к диаграммам легенду. Будь это что-то из UML или моё собственное творчество.
Использовать готовый образ может быть опасно. Почему вы должны доверять автору?
Я обычно беру официальный образ Python и сам установливаю в него Node.js пакетным менеждером ОС. Или наоборот, в официальный образ с Node.js устанавливаю Python.
На мой взгляд, стоило ещё упомянуть про DOCKER_BUILDKIT=1, который не везде включён по умолчанию. Он позволяет выполнять некоторые шаги сборки параллельно.
И ещё я бы добавил про монтирование папок по время сборки. Это относительно новая фича, не всё про неё знают. Полезно, например, чтобы локально закэшировать внешние зависимости и пошарить этот кэш между несколькими образами. Или при многостадийной сборке, можно какой-то пакет собрать на одном этапе, а установить на втором без копирования архива в образ.
Ну и много слоёв - это не всегда плохо. Если слои не генерируют никаких файлов, то их вклад в размер образа - сущие копейки. Таких слоёв можно делать много, если это поможет эффективнее использовать кэш. А удалять временные файлы нужно именно в том слое, где они созданы, иначе они всё равно останутся в финальном образе.
Красота - это такие вещи как лаконичность, семантический сахар. Они делают код эстетически более приятным, но не сильно влияют на читаемость или эффективность.
Если он не работает, то его правка может быть равносильна полному переписыванию с нуля, как в первом примере.
Представьте ситуацию, когда новую фичу начал имплементировать крутой разработчик, но в середине работы его чем-то отвлекли. Например, его навыки понадобились, чтобы срочно пофиксить баг, или его сбил автобус. Если код хорошо структурирован, то его может подхватить и дописать менее квалифицированный разработчик. А если крутой разраб будет писать в стиле "смотри как я умею" (привет однострочникам в 400 символов), то именно в этом случае придётся или потратить много времени, чтобы во всём разобраться, или потратить много времени, чтобы переписать с нуля.
Я считаю, что лучше сделать часть работы, которую потом можно доделать, чем всю работу, которую потом придётся переделывать. Именно моэтому функциональность не в приоритете.
А если разработчик может писать так, чтобы сразу было и читаемо, и работало, то это просто прекрасно.
Красота - это такие вещи как лаконичность, семантический сахар. Они делают код эстетически более приятным, но не сильно влияют на читаемость или эффективность.
Если он не работает, то его правка может быть равносильна полному переписыванию с нуля, как в первом примере.
Представьте ситуацию, когда новую фичу начал имплементировать крутой разработчик, но в середине работы его чем-то отвлекли. Например, его навыки понадобились, чтобы срочно пофиксить баг, или его сбил автобус. Если код хорошо структурирован, то его может подхватить и дописать менее квалифицированный разработчик. А если крутой разраб будет писать в стиле "смотри как я умею" (привет однострочникам в 400 символов), то именно в этом случае придётся или потратить много времени, чтобы во всём разобраться, или потратить много времени, чтобы переписать с нуля.
Я считаю, что лучше сделать часть работы, которую потом можно доделать, чем всю работу, которую потом придётся переделывать. Именно моэтому функциональность не в приоритете.
А если разработчик может писать так, чтобы сразу было и читаемо, и работало, то это просто прекрасно.
Я много раз видел код, который "просто работает". К сожалению, чаще всего это его единственное достоинство. И в тот момент, когда такой код нужно "немного подправить", оказывается, что быстрее будет написать с нуля, чем разобраться.
А если бы код был не рабочим, но хорошо структурированным и читаемым, то подправить его мог бы любой разработчик за разумное время.
А вы не рассматривали альтернативы для RESTful API, которые изначально разрабатывались с учётом проблемы обратной совместимости? Например, GraphQL или gRPC.
Если я правильно помню, метрика, которая меня интересует называется "Time to Production" или может быть "Time to Deliver". Ради уменьшения её до считанных минут требуется автоматизация всего и вся. И вот я не могу понять, как определить, что автоматизированные тесты, особенно, если они написаны разработчиком, достаточны для полностью автоматического деплоя.
Каюсь, до конца не дочитал, потому что в голове засел вопрос, который всегда там возникает при разговорах о CD.
А как определить, что фича в достаточной степени покрыта тестами и готова к тому, чтобы её автоматически без участия человека можно было зарелизить? Если QA Lead даёт добро на релиз, то я спокоен, потому что он человек опытный. А как я могу доверять джунам или мидлам, которые пилят и фичи, и тесты для них?
Тут скорее питон не пропустит сообщение, а не отправит в RabbitMQ вовремя heartbeat. В результате, RabbitMQ посчитает его мёртвым и перезапустит сообщение.
Не всё так плохо. Раздача контента с сервера, который георафически ближе к клиенту, всё ещё работает.
Про то, что шрифт случайно окажется в кэше, уже можно забыть из-за такой штуки как cache partitioning. Чтобы избежать трекинга через ресурсы, теперь для каждого сайта в браузере свой кэш. По-моему, эта фича уже везде включена по умолчанию.
Вы себе даже не представляете, какого труда мне стоило прочитать ваш комментарий. Мой мозг постоянно спотыкался о неправильные окончания, склонения, знаки препинания. Такой уж у меня мозг. Мне пришлось сделать над собой усилие, чтобы сосредоточиться на содержании, а не на форме. Я ни в коем случае не обвиняю, просто вот так по-дурацки работает мой мозг.
То же самое относится к код-ревью. Если код написан без соблюдения стилей и нэйминга и у меня есть возможность поручить ревью кому-то другому, то я именно так и сделаю. В противном случае я потрачу на ревью в 3 раза больше времени, чем надо. Просто потому что, если мой мозг замечает дерьмо в коде, то ни на что другое переключить внимание он уже не может.
Так что если вас волнуют когнитивные усилия читателей, пишите красиво. Если не волнуют, пишите, как хотите.
На мой взгляд, основная проблема UML, как и любого другого языка, - на нём должны сносно разговаривать все участники процесса. Если вы знаете, что обозначают разные виды стреловек, а ваш визави нет, то коммуникация не состоится.
Может мне так "везло" с проектами, но последний человек, который нормально владел UML, это был мой препод в ВУЗе.
Поэтому, чтобы избежать проблем в коммуникации, я всегда добаляю к диаграммам легенду. Будь это что-то из UML или моё собственное творчество.
Использовать готовый образ может быть опасно. Почему вы должны доверять автору?
Я обычно беру официальный образ Python и сам установливаю в него Node.js пакетным менеждером ОС. Или наоборот, в официальный образ с Node.js устанавливаю Python.
Хорошая статья, спасибо!
На мой взгляд, стоило ещё упомянуть про DOCKER_BUILDKIT=1, который не везде включён по умолчанию. Он позволяет выполнять некоторые шаги сборки параллельно.
И ещё я бы добавил про монтирование папок по время сборки. Это относительно новая фича, не всё про неё знают. Полезно, например, чтобы локально закэшировать внешние зависимости и пошарить этот кэш между несколькими образами. Или при многостадийной сборке, можно какой-то пакет собрать на одном этапе, а установить на втором без копирования архива в образ.
Ну и много слоёв - это не всегда плохо. Если слои не генерируют никаких файлов, то их вклад в размер образа - сущие копейки. Таких слоёв можно делать много, если это поможет эффективнее использовать кэш. А удалять временные файлы нужно именно в том слое, где они созданы, иначе они всё равно останутся в финальном образе.
Вроде бы Poetry уже поддерживает любое количество групп, а не только dev: https://python-poetry.org/docs/master/managing-dependencies/#dependency-groups
По моему опыту просто переносить готовый venv опасно: могут потеряться бинарные зависимости или поехать пути.
Для меня лучше работает такая схема:
в базовом образе с помощью Poetry генерируем requirements.txt;
там же из requirements.txt собираем wheel-пакеты;
монтируем requirements.txt и wheel-пакеты в финальный образ (понадобится DOCKER_BUILDKIT);
устанавливаем зависимости из wheel-пакетов обычным pip;
PROFIT.
Таким образом в финальном образе получим правильно установленные пакеты, но самих wheel-файлов и даже Poetry там не будет.
Красота - это такие вещи как лаконичность, семантический сахар. Они делают код эстетически более приятным, но не сильно влияют на читаемость или эффективность.
Представьте ситуацию, когда новую фичу начал имплементировать крутой разработчик, но в середине работы его чем-то отвлекли. Например, его навыки понадобились, чтобы срочно пофиксить баг, или его сбил автобус. Если код хорошо структурирован, то его может подхватить и дописать менее квалифицированный разработчик. А если крутой разраб будет писать в стиле "смотри как я умею" (привет однострочникам в 400 символов), то именно в этом случае придётся или потратить много времени, чтобы во всём разобраться, или потратить много времени, чтобы переписать с нуля.
Я считаю, что лучше сделать часть работы, которую потом можно доделать, чем всю работу, которую потом придётся переделывать. Именно моэтому функциональность не в приоритете.
А если разработчик может писать так, чтобы сразу было и читаемо, и работало, то это просто прекрасно.
Красота - это такие вещи как лаконичность, семантический сахар. Они делают код эстетически более приятным, но не сильно влияют на читаемость или эффективность.
Представьте ситуацию, когда новую фичу начал имплементировать крутой разработчик, но в середине работы его чем-то отвлекли. Например, его навыки понадобились, чтобы срочно пофиксить баг, или его сбил автобус. Если код хорошо структурирован, то его может подхватить и дописать менее квалифицированный разработчик. А если крутой разраб будет писать в стиле "смотри как я умею" (привет однострочникам в 400 символов), то именно в этом случае придётся или потратить много времени, чтобы во всём разобраться, или потратить много времени, чтобы переписать с нуля.
Я считаю, что лучше сделать часть работы, которую потом можно доделать, чем всю работу, которую потом придётся переделывать. Именно моэтому функциональность не в приоритете.
А если разработчик может писать так, чтобы сразу было и читаемо, и работало, то это просто прекрасно.
А может, если джун Вася всё понял в плохом коде, то код не так уж и плох?
Код из статьи я за разумное время не понял.
Я много раз видел код, который "просто работает". К сожалению, чаще всего это его единственное достоинство. И в тот момент, когда такой код нужно "немного подправить", оказывается, что быстрее будет написать с нуля, чем разобраться.
А если бы код был не рабочим, но хорошо структурированным и читаемым, то подправить его мог бы любой разработчик за разумное время.
Поэтому мои приоритеты такие:
Читаемость.
Эффективность.
Красота.
На PHP всё так же принято перемежать PHP-код вставками на HTML? Шаблонизаторы так и не прижились?
P.S. Серьёзно писал на PHP лет 10 назад.
А вы не рассматривали альтернативы для RESTful API, которые изначально разрабатывались с учётом проблемы обратной совместимости? Например, GraphQL или gRPC.
Спасибо за ваши ответы.
Если я правильно помню, метрика, которая меня интересует называется "Time to Production" или может быть "Time to Deliver". Ради уменьшения её до считанных минут требуется автоматизация всего и вся. И вот я не могу понять, как определить, что автоматизированные тесты, особенно, если они написаны разработчиком, достаточны для полностью автоматического деплоя.
Каюсь, до конца не дочитал, потому что в голове засел вопрос, который всегда там возникает при разговорах о CD.
А как определить, что фича в достаточной степени покрыта тестами и готова к тому, чтобы её автоматически без участия человека можно было зарелизить? Если QA Lead даёт добро на релиз, то я спокоен, потому что он человек опытный. А как я могу доверять джунам или мидлам, которые пилят и фичи, и тесты для них?
У poetry есть то же самое:
poetry export -o requirements.txt. Я это использую в Docker-образах, чтобы не тащить туда лишние зависимости.Чем это лучше или хуже pip-tools, я не знаю. Мне удобно.
Тут скорее питон не пропустит сообщение, а не отправит в RabbitMQ вовремя heartbeat. В результате, RabbitMQ посчитает его мёртвым и перезапустит сообщение.
Поэтому простой синхронный питон без потоков подходит только для таких же простых случаев. Для остальных есть официальный пример: https://github.com/pika/pika/blob/master/examples/basic_consumer_threaded.py
Кроме dev-зависимостей, новая версия Poetry будет поддерживать ещё и произвольные группы: https://python-poetry.org/docs/master/managing-dependencies/#dependency-groups
pyproject.toml - это часть стандарта PEP 517 и PEP 518. Насколько я понимаю, pip-tools использует свой собственный подход не основанный на PEP.