Они год в корп. сети находились, достаточно было получить доступ к БД в режиме чтения, найти хеш пароля админов и тупо брутфорсом перебрать. Если пароль слабый вполне за пару месяцев бы добыли.
Статья начинается с того что 90% разработчиков не верно трактуют DIP, а где итог? Как в двух словах объяснить DIP так, чтобы трактовка не звучала в корне не верной?
Статья хорошая. Помню как то на iphone 8 перестала работать кнопка home после попадания влаги, перезагрузил, iphone определил что действительно проблемы с кнопкой и предложил добавить виртуальную. Через пару недель кнопка сама собой заработала. В целом ничего особенного, но на тот момент меня удивило что был предусмотрен сценарий когда вышла из строя кнопка (без нее в принципе не возможно пользоваться телефоном) и был предложен альтернативный вариант.
"Самый частый негативный пример – генерация большого отчёта аккуратно заставляет все остальные функции сервиса «подождать», т. е. остальные запросы клиентов «подвисают»."
Смотря какая ситуация, зачастую это ошибка архитектуры, для решения проблем с блокировками БД существует паттерн Database per service.
А как поддерживать актуальность данных в Fulfilment без временной связности? Допустим развернули сервис пуляем первый запрос оказывается что в локальном хранилище нет инфы по запрошенному товару, что дальше? Идем на склад за инфой? Через брокер? Почему не сделать синхронный запрос ведь информация нужна здесь и сейчас. Я не помню как в предложенной реализации решить эту проблему. Предполагается делать БД в двух экземплярах для Fulfilment и для Warehouse, или как?
ммм... х*ета
Они год в корп. сети находились, достаточно было получить доступ к БД в режиме чтения, найти хеш пароля админов и тупо брутфорсом перебрать. Если пароль слабый вполне за пару месяцев бы добыли.
Зачем? Как теперь узнать из за чего срач начался
Забавная статья
Если html это язык вычислений, то как на нем вычислить 2*2?!
Статья начинается с того что 90% разработчиков не верно трактуют DIP, а где итог? Как в двух словах объяснить DIP так, чтобы трактовка не звучала в корне не верной?
Что насчёт поддержки micronaut?
Статья хорошая. Помню как то на iphone 8 перестала работать кнопка home после попадания влаги, перезагрузил, iphone определил что действительно проблемы с кнопкой и предложил добавить виртуальную. Через пару недель кнопка сама собой заработала. В целом ничего особенного, но на тот момент меня удивило что был предусмотрен сценарий когда вышла из строя кнопка (без нее в принципе не возможно пользоваться телефоном) и был предложен альтернативный вариант.
"Самый частый негативный пример – генерация большого отчёта аккуратно заставляет все остальные функции сервиса «подождать», т. е. остальные запросы клиентов «подвисают»."
Смотря какая ситуация, зачастую это ошибка архитектуры, для решения проблем с блокировками БД существует паттерн Database per service.
Мне показалось или статья написана чтобы прорекламировать курс?
не понимаю*
А как поддерживать актуальность данных в Fulfilment без временной связности? Допустим развернули сервис пуляем первый запрос оказывается что в локальном хранилище нет инфы по запрошенному товару, что дальше? Идем на склад за инфой? Через брокер? Почему не сделать синхронный запрос ведь информация нужна здесь и сейчас. Я не помню как в предложенной реализации решить эту проблему. Предполагается делать БД в двух экземплярах для Fulfilment и для Warehouse, или как?