В целом статья хорошая, но вот этот сниппет явно из каких-то "Вредных советов":
match packet:
case [c1, c2, *data, footer] if ( # Деконструируем пакет на заголовок, данные и конец
(checksum := c1 + c2) == sum(data) and # Проверяем корректность контрольной суммы
len(data) == footer # Проверяем корректность размера данных
):
...
И, тем не менее, только что стартовавший контейнер будет "холодным", и ему потребуется время чтобы выйти на полную производительность.
Если приложение постоянно разрабатывается и депоится, можно предположить, что контролируемый перезапуск при деплое случается гораздо чаще, чем обрыв соединения с БД, поэтому тут в пределах погрешности.
Гораздо лучше если контейнер не будет падать по пустякам.
Тут зависит от того, что считать пустяком и насколько глубоко ты хочешь ковыряться. Если предполагается, что основная задача приложения - это работать с данными в удаленном хранилище, то и при недоступности этого хранилища упасть не грех.
Не хочешь каждый раз поднимать потом руками - настрой restart policy. Потом можешь сколько угодно ресерчить, как разрулить проблему с "морганием" сети на уровне приложения, ковырять сорцы фреймворка, читать платную документацию, но теперь уже без стресса.
Мы отправили наше приложение в докер. И я решил, что это неприлично, что проект на NestJS падает насмерть, когда происходит отсоединение Redis или базы данных.
А зачем что-то ковырять в кишках для решения проблемы, если можно задать restart policy у контейнера?
В целом статья хорошая, но вот этот сниппет явно из каких-то "Вредных советов":
Это еще ничего, кто-то ведь скачивает интернет в интернет https://www.notion.so/web-clipper
Поддерживаю, ничем другим на маке после OrbStack пользоваться просто невозможно.
Отдельно радует, что автор - простой студент (ладно, не очень простой, а студент Стенфорда), который просто любит писать хороший софт.
Да.
Если приложение постоянно разрабатывается и депоится, можно предположить, что контролируемый перезапуск при деплое случается гораздо чаще, чем обрыв соединения с БД, поэтому тут в пределах погрешности.
Тут зависит от того, что считать пустяком и насколько глубоко ты хочешь ковыряться. Если предполагается, что основная задача приложения - это работать с данными в удаленном хранилище, то и при недоступности этого хранилища упасть не грех.
Не хочешь каждый раз поднимать потом руками - настрой restart policy. Потом можешь сколько угодно ресерчить, как разрулить проблему с "морганием" сети на уровне приложения, ковырять сорцы фреймворка, читать платную документацию, но теперь уже без стресса.
Если речь о перезагрузке сервера "просто так", то это не то же самое, что автостарт контейнера/демона после падения.
А зачем что-то ковырять в кишках для решения проблемы, если можно задать restart policy у контейнера?
А что ЛОРы думают про наушники-затычки?
А что имеется ввиду под "держанием ушей в чистоте"? Ушная сера так-то не грязь.
вот этого мне очень не хотелось делать
дописал UPD
да, лучше заморочиться с двойным вызовом snprintf. это выходит за пределы скоупа текущей задачи, поэтому я решил по-простому.
gcc и clang.
мне кажется, и msvc должен проканать, я старался не завязываться на особенностях компиляторов. но если вдруг не проканает, напишите
чтобы прямо ровно такой код - не знаю, но я вдохновлялся исходниками CPython