Pull to refresh
51
0
Дмитрий @theRavel

Пользователь

Send message

Был такой мобильный провайдер, у которого посреди ночи могли "неожиданно отключиться" сервисы доставки СМС для определенных абонентов, у которых на СМС была завязана двухфакторная авторизация.

С встроенным MITM в браузер появляется риск небольших различий сертификатов для разных пользователей. Есть ли какая-то гарантия защиты от подобных технических сбоев в Яндекс браузере?

Вопрос риторический.

То есть при угрозе 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 (как оно сейчас то работает?).

Можно конечно пойти и поверить документации или чьим-то словам, но путь весьма рискованный.
Вопрос от solution architect to solution architect: как же вы рисуете диаграммы и выбираете технологии если вы не умеете код?
А как деплоятся модули? Это одно приложение или например каждый консьюмер можно отдельно задеплоить?

Во всем подходе немного настораживает наличие общих DTO… Они же создают сильную связанность между модулями (изменение в одном модуле ведет к изменению в другом) — хотя это возможно допустимо с точки зрения постановки задачи.
Рассматривали ли вы уже существующие способы реализовать scheduled delivery? Например:
Зашел посмотреть на новые идеи как сочетать E2E/Integration тестирование с Continuous Deployment отдельных микросервисов и т.п., но…
Ага, вот разница между Symfony & Laravel.

А как пройдут тесты в удаленном CI, если нет дефолтных значений и переменные явно не применили?
Дефолтные настройки хранятся в .env (коммитится в репозиторий), который собственно используется приложением. Локально переменные можно переопределить в .env.local (никогда не коммитится).

Что такое пресет со списком ключей, сохраняемых в репозиторий?

Так а зачем нужно иметь два файла .env и .env.example?

Чем мой комментарий нерелевантен на ваш взгляд?

В Symfony, например, .env.example давно не используется, переменные либо подставляются через реальные переменные окружения, либо используются зашифрованные секреты. Вы .env файл с секретами прямо в репозиторий пушите?
Есть то же самое на английском? Я бы много с кем хотел поделиться этой статьей.

Information

Rating
Does not participate
Location
Düsseldorf, Nordrhein-Westfalen, Германия
Registered
Activity