Был такой мобильный провайдер, у которого посреди ночи могли "неожиданно отключиться" сервисы доставки СМС для определенных абонентов, у которых на СМС была завязана двухфакторная авторизация.
С встроенным MITM в браузер появляется риск небольших различий сертификатов для разных пользователей. Есть ли какая-то гарантия защиты от подобных технических сбоев в Яндекс браузере?
Я правильно понимаю, что посыл статьи - это заменить одно большое ТЗ на ТЗ, разбитое по фичам?
Если да, то исходная проблема никуда не делась, правильно?
Фичи по-прежнему хочется описывать в деталях, покрывая edge cases, etc. - просто куски описания стали меньше. Но, чтобы это делать, нужно время и квалификация.
ТЗ по-прежнему устаревает после очередной итерации. Нужно писать либо новое ТЗ на фичу, либо переписывать старое. Чтобы это делать, нужно время и квалификация.
Предполагаю, что у вас свои библиотеки/сервисы для взаимодействия с bus layer (отправка по завершению транзакции, tenant throttling, и т.п.) - не хотите что-то из этого в open-source выложить?
А другие сервисы (не монолит) живут в том же инстансе базы? Просто не очень понятен компромис с хранением ивентов в БД:
1) Если инстанс один и тот же, то консистентность и транзакционность гарантирована, да. Но получаем БД как single point of failure (ВСЕ сервисы падают несмотря на микросервисную архитектуру) и БД заодно является performance bottleneck.
2) Если инстансы разные, то получаем опять проблему distributed storage, и можно было бы с таким же успехом сообщения сразу писать в message bus.
Как человек который живет в Германии могу добавить что:
В Берлине много интересных компаний в IT — это правда;
5к — это вцелом нормально для Германии для не IT, но вообще это грустная сумма для IT;
Зачем собственно ехать в Берлин? Если мы говорим про современные компании и стартапы, то удаленка теперь вполне популярная модель. Можно на эти компании работать, но жить в Берлине или нет — это ваш выбор.
Несколько распространённых ошибок при использовании health probes:
Не учитывается состояние внешних сервисов в readiness probe (например, баз данных)
Несколько спорное утверждение. Возможно, в некоторых случаях перестать пускать трафик на сервис у которого умерла БД — допустимо. Но лучше, если этот сценарий обрабатывает само приложение, и например, показывает разумное сообщение об ошибке.
Чтобы например понять, как предполагаемая схема деплоймента впишется в уже существующие решения деплоймента (и как много усилий это может стоить), вероятно нужно пойти и почитать код, как собственно этот деплоймент уже работает?
То же самое применимо и к sequence & component (как оно сейчас то работает?).
Можно конечно пойти и поверить документации или чьим-то словам, но путь весьма рискованный.
А как деплоятся модули? Это одно приложение или например каждый консьюмер можно отдельно задеплоить?
Во всем подходе немного настораживает наличие общих DTO… Они же создают сильную связанность между модулями (изменение в одном модуле ведет к изменению в другом) — хотя это возможно допустимо с точки зрения постановки задачи.
Дефолтные настройки хранятся в .env (коммитится в репозиторий), который собственно используется приложением. Локально переменные можно переопределить в .env.local (никогда не коммитится).
Что такое пресет со списком ключей, сохраняемых в репозиторий?
В Symfony, например, .env.example давно не используется, переменные либо подставляются через реальные переменные окружения, либо используются зашифрованные секреты. Вы .env файл с секретами прямо в репозиторий пушите?
Был такой мобильный провайдер, у которого посреди ночи могли "неожиданно отключиться" сервисы доставки СМС для определенных абонентов, у которых на СМС была завязана двухфакторная авторизация.
С встроенным MITM в браузер появляется риск небольших различий сертификатов для разных пользователей. Есть ли какая-то гарантия защиты от подобных технических сбоев в Яндекс браузере?
Вопрос риторический.
То есть при угрозе MITM предлагается доверять компании Яндекс, которая бОльшую часть выручки получает в РФ?
Я правильно понимаю, что посыл статьи - это заменить одно большое ТЗ на ТЗ, разбитое по фичам?
Если да, то исходная проблема никуда не делась, правильно?
Фичи по-прежнему хочется описывать в деталях, покрывая edge cases, etc. - просто куски описания стали меньше. Но, чтобы это делать, нужно время и квалификация.
ТЗ по-прежнему устаревает после очередной итерации. Нужно писать либо новое ТЗ на фичу, либо переписывать старое. Чтобы это делать, нужно время и квалификация.
А как узнать, какое искусство настоящее? Вероятно люди с "хорошим вкусом" должны это определять?
... и мы получили доказательство теоремы через ее следствие, упс.
Спасибо, теперь понятнее.
Предполагаю, что у вас свои библиотеки/сервисы для взаимодействия с bus layer (отправка по завершению транзакции, tenant throttling, и т.п.) - не хотите что-то из этого в open-source выложить?
А другие сервисы (не монолит) живут в том же инстансе базы? Просто не очень понятен компромис с хранением ивентов в БД:
1) Если инстанс один и тот же, то консистентность и транзакционность гарантирована, да. Но получаем БД как single point of failure (ВСЕ сервисы падают несмотря на микросервисную архитектуру) и БД заодно является performance bottleneck.
2) Если инстансы разные, то получаем опять проблему distributed storage, и можно было бы с таким же успехом сообщения сразу писать в message bus.
То же самое применимо и к sequence & component (как оно сейчас то работает?).
Можно конечно пойти и поверить документации или чьим-то словам, но путь весьма рискованный.
Во всем подходе немного настораживает наличие общих DTO… Они же создают сильную связанность между модулями (изменение в одном модуле ведет к изменению в другом) — хотя это возможно допустимо с точки зрения постановки задачи.
А как пройдут тесты в удаленном CI, если нет дефолтных значений и переменные явно не применили?
Что такое пресет со списком ключей, сохраняемых в репозиторий?
Так а зачем нужно иметь два файла .env и .env.example?
Чем мой комментарий нерелевантен на ваш взгляд?