Через 10 минут будете знать, как внедрить Zero Trust в продакшене
Нужно всего лишь нанять пару десятков безопасников. Выделить им ~50 миллионов и наблюдать как они вашу архитектуру превращают в кашу, в которой никто не сможет разобраться. Profit!
Рецепт может и рабочий, но для очень крупного бизнеса, который и без советов со стороны знает как организовать у себя безопасность.
Это лишь значит, что у вас три книжки с плохим переводом. Сомневаюсь, что вы хоть в одном словаре найдете определение термина "карты" в том смысле, в котором его используете.
Где ничего не сказано о том почему распределенные транзакции между двумя+ бд не работают. Есть ссылка на статью, в которой так же ничего особо не раскрывается. Написано только в том же ключе - "не работают!" и дальше идет разбор подходов, которые помогают как-то жить без транзакций.
Но это выглядит сложно.
Реализовать такое для платформы было не просто — это факт. Но прелесть в том, что это позволило использовать camunda в микросервисной архитектуре где бизнес‑данные управляются в одном микросервисе, а движок работает в контексте другого микросервиса. При этом разработчикам не нужно на каждом шаге думать об обработке целого вороха сценариев когда что‑то может пойти не по плану. И самое прекрасное — распределенные транзакции никоим образом не мешают использовать все те «безтранзакционные» подходы вроде саг, там где это уместно.
Громкое заявление. У нас распределенные транзакции работают замечательно в связке с камундой. Правда потребовалось свой транзакционный менеджер написать.
Мой аргумент в том, что методы - это не зло и привел пример где они очень органично вписываются. Автор же в свою очередь - лицемер. Даже в своем примере "правильного кода" он использует методы, против которых воюет.
// Функция.
const getDisplayName = (user: {firstName: string, lastName?: string, middleName?: string} | null | undefined) => {
if (!user) return undefined
return [user.firstName, user.middleName, user.lastName]
.filter(Boolean) // ой, а что это у нас такое?
.join(" ") // и здесь! безобразные методы!!!!!!
}
Вы вызываете стороннюю функцию чтобы добавить элемент в массив вроде addElementToArray(array, element) или все таки используете богомерзкий array.add(element) которому (о боже!) "массив передается неявно первым аргументом" и "его нельзя переиспользовать чтобы добавлять подливы в свой гуляш".
п.с. прошу заметить, что позиция "и тот и тот подходы имеют место быть" противоречит позиции автора, который явно тяготеет к темной стороне и возводит все в абсолют.
Автору нужно миску риса выдать за такой веселый накид на вентилятор. С огромной радостью бы посмотрел как автор применяет функциональный стиль при работе со строками или массивами. Или это другое?
Вот бы можно было придумать такой интерфейс, которому отправляешь текст и он может в ответ прислать текст. И таким образом слать сообщения туда-сюда на человеческом языке в рамках одного диалога, чтобы агенты общались друг с другом...
Был на 100% уверен, что это очередная фича для хабра-элиты как и все другое на этом ресурсе. Удивлен, что оказывается этим могли пользоваться все. Если бы знал, то может быть и пользовался иногда.
Уж больно неорганично они смотрелись в относительно строгом дизайне сайта. Они бы подошли для сайта детского сада или сайта с играми для маленьких детей.
Радостно видеть, что автор понимает, что SRP - это принцип про людей (не только изначально, но и сейчас). То что этот принцип коверкают - это не проблема принципа. Если у автора есть аргументы против оригинальной версии SRP, было бы интересно их услышать.
OCP
Согласен с тем, что фанатично этому принципу не стоит следовать, но и утверждать, что он всегда бесполезен тоже нельзя. В любом деле возведение в абсолют каких-то рекомендаций и принципов обычно до добра не доводит.
LSP
Вот тут очень плохой пример получился. API чтения файлов должно отдавать поток байтов и ему должно быть по барабану зашифрованы они или нет. Логика дешифрования пишется как обертка для потока байтов, которая на выходе тоже отдает поток байт. Это позволяет а) очень легко тестировать каждую часть по отдельности б) добавлять обертки для сжатия/разжатия данных и других манипуляций в) использовать в качестве исходного источника потока байт не только файлы.
ISP
То же что OCP - не следуем фанатично, но и совсем о нем забывать нельзя.
DIP
Грустно наблюдать, что этот принцип понимают как "всегда используйте интерфейсы". Этот принцип на мой взгяд очень плохо себя проявляет в рамках одного проекта т.к. обычно процесс сборки проекта означает выпуск нового билда, который должен так или иначе пройти все этапы тестирования. Другое дело - разные библиотеки. Если у нас есть библиотеки, которые образуют цепь зависимостей A->B->C->D->E->F, и что-то меняется в F, то нам придется проводить тестирование и пересобирать библиотеки E, D, C, B, A. Если же мы введем промежуточную API библиотеку G, то сможем разорвать цепь зависимостей: A->B->C-->G<--D->E->F
и изменения в F уже затронут только две библиотеки - E и D.
Вот некоторые примеры такой инверсии из мира java: slf4j-api - фасад для подсистемы логирования
opentelemetry-api - API для записи метрик и трейсинга
Принцип имеет смысл и на одном уровне. Что выше в вашей системе мер - БД или система логирования?
Модулю нижнего уровня важны детали высокого уровня? Если нет, то в чем смысл деления здесь?
Интерфейс в контексте DI (не только он конечно, но опустим этот момент) - это средство уменьшения связности модулей. Чем меньше связность модулей в программе, тем она стабильнее, проще тестируется и развивается (понятно все это в разумных пределах). Я не утверждаю, что разделение на уровни вообще не нужно. Бизнес сверху, инфраструктура снизу - это все правильно, но это все из других принципов и в контексте DI уровни не важны.
Высокоуровневые модули не должны зависеть от низкоуровневых
Нету в контексте это принципа понятий "высокий модуль" и "низкий модуль". Пример в статье для этого принципа с едой больше относится к OCP.
Принцип о том что не нужно делать большие цепочки зависимостей между модулями. Если не следовать принципу, то можно реализовать зависимые друг от друга модули A->B->C->D->E->F и при любом изменении в модуле F все остальные модули в нашей цепочке нужно перетестировать и пересобирать. Если же добавить тут один абстрактный модуль G, то можем разбить нашу цепь на три:
A->B->C->G
D->G
D->E->F
И изменения в F уже влияют не на 5 модулей, а на 2. Где именно и как часто ломать цепи зависимостей используя DI - это уже может варьироваться от проекта к проекту.
JSON с быстрым сжатием на lz4 покажет похожие цифры скорости и объема трафика. Плюс есть и бинарные форматы для сериализации json'а (но мои эксперименты с ними показали те же цифры что и обычный JSON с сжатием).
А зачем вообще в наше время нужен LibreOffice когда есть OnlyOffice? Прекрасно ставится на десктоп и имеет шикарную совместимость с docx/xlsx/pptx
В чем тогда смысл абзаца "Безопасность и контроль"? Получается MCP сервера никакой дополнительной безопасности не дают.
Как жалко, что для обычных серверов не придумали еще хранить токены доступа на прокси сервере. Это же очень удобно и безумно безопасно!
Нужно всего лишь нанять пару десятков безопасников. Выделить им ~50 миллионов и наблюдать как они вашу архитектуру превращают в кашу, в которой никто не сможет разобраться. Profit!
Рецепт может и рабочий, но для очень крупного бизнеса, который и без советов со стороны знает как организовать у себя безопасность.
Тогда извиняюсь. Я грешным делом подумал, что вы пишете статью для людей, а не для себя.
Это лишь значит, что у вас три книжки с плохим переводом. Сомневаюсь, что вы хоть в одном словаре найдете определение термина "карты" в том смысле, в котором его используете.
Спасибо, посмеялся. Рекомендую к ознакомлению:
https://habr.com/ru/articles/565158/
Где ничего не сказано о том почему распределенные транзакции между двумя+ бд не работают. Есть ссылка на статью, в которой так же ничего особо не раскрывается. Написано только в том же ключе - "не работают!" и дальше идет разбор подходов, которые помогают как-то жить без транзакций.
Реализовать такое для платформы было не просто — это факт. Но прелесть в том, что это позволило использовать camunda в микросервисной архитектуре где бизнес‑данные управляются в одном микросервисе, а движок работает в контексте другого микросервиса. При этом разработчикам не нужно на каждом шаге думать об обработке целого вороха сценариев когда что‑то может пойти не по плану. И самое прекрасное — распределенные транзакции никоим образом не мешают использовать все те «безтранзакционные» подходы вроде саг, там где это уместно.
Громкое заявление. У нас распределенные транзакции работают замечательно в связке с камундой. Правда потребовалось свой транзакционный менеджер написать.
Мой аргумент в том, что методы - это не зло и привел пример где они очень органично вписываются. Автор же в свою очередь - лицемер. Даже в своем примере "правильного кода" он использует методы, против которых воюет.
Вы вызываете стороннюю функцию чтобы добавить элемент в массив вроде addElementToArray(array, element) или все таки используете богомерзкий array.add(element) которому (о боже!) "массив передается неявно первым аргументом" и "его нельзя переиспользовать чтобы добавлять подливы в свой гуляш".
п.с. прошу заметить, что позиция "и тот и тот подходы имеют место быть" противоречит позиции автора, который явно тяготеет к темной стороне и возводит все в абсолют.
Автору нужно миску риса выдать за такой веселый накид на вентилятор. С огромной радостью бы посмотрел как автор применяет функциональный стиль при работе со строками или массивами. Или это другое?
Вот бы можно было придумать такой интерфейс, которому отправляешь текст и он может в ответ прислать текст. И таким образом слать сообщения туда-сюда на человеческом языке в рамках одного диалога, чтобы агенты общались друг с другом...
Никакой угадайки. Зачем базе в запросе с лимитом без сортировки загружать все строки?
Крепко пожал бы руку тому кто придумал этот мусор генерировать
Был на 100% уверен, что это очередная фича для хабра-элиты как и все другое на этом ресурсе. Удивлен, что оказывается этим могли пользоваться все. Если бы знал, то может быть и пользовался иногда.
Уж больно неорганично они смотрелись в относительно строгом дизайне сайта. Они бы подошли для сайта детского сада или сайта с играми для маленьких детей.
Радостно видеть, что автор понимает, что SRP - это принцип про людей (не только изначально, но и сейчас). То что этот принцип коверкают - это не проблема принципа. Если у автора есть аргументы против оригинальной версии SRP, было бы интересно их услышать.
Согласен с тем, что фанатично этому принципу не стоит следовать, но и утверждать, что он всегда бесполезен тоже нельзя. В любом деле возведение в абсолют каких-то рекомендаций и принципов обычно до добра не доводит.
Вот тут очень плохой пример получился. API чтения файлов должно отдавать поток байтов и ему должно быть по барабану зашифрованы они или нет. Логика дешифрования пишется как обертка для потока байтов, которая на выходе тоже отдает поток байт. Это позволяет а) очень легко тестировать каждую часть по отдельности б) добавлять обертки для сжатия/разжатия данных и других манипуляций в) использовать в качестве исходного источника потока байт не только файлы.
То же что OCP - не следуем фанатично, но и совсем о нем забывать нельзя.
Грустно наблюдать, что этот принцип понимают как "всегда используйте интерфейсы". Этот принцип на мой взгяд очень плохо себя проявляет в рамках одного проекта т.к. обычно процесс сборки проекта означает выпуск нового билда, который должен так или иначе пройти все этапы тестирования. Другое дело - разные библиотеки. Если у нас есть библиотеки, которые образуют цепь зависимостей A->B->C->D->E->F, и что-то меняется в F, то нам придется проводить тестирование и пересобирать библиотеки E, D, C, B, A. Если же мы введем промежуточную API библиотеку G, то сможем разорвать цепь зависимостей:
A->B->C-->G<--D->E->F
и изменения в F уже затронут только две библиотеки - E и D.
Вот некоторые примеры такой инверсии из мира java:
slf4j-api - фасад для подсистемы логирования
opentelemetry-api - API для записи метрик и трейсинга
jjwt-api - API для работы с jwt токенами
У вас база реализует бизнес логику?
Принцип имеет смысл и на одном уровне. Что выше в вашей системе мер - БД или система логирования?
Модулю нижнего уровня важны детали высокого уровня? Если нет, то в чем смысл деления здесь?
Интерфейс в контексте DI (не только он конечно, но опустим этот момент) - это средство уменьшения связности модулей. Чем меньше связность модулей в программе, тем она стабильнее, проще тестируется и развивается (понятно все это в разумных пределах). Я не утверждаю, что разделение на уровни вообще не нужно. Бизнес сверху, инфраструктура снизу - это все правильно, но это все из других принципов и в контексте DI уровни не важны.
Нету в контексте это принципа понятий "высокий модуль" и "низкий модуль". Пример в статье для этого принципа с едой больше относится к OCP.
Принцип о том что не нужно делать большие цепочки зависимостей между модулями. Если не следовать принципу, то можно реализовать зависимые друг от друга модули A->B->C->D->E->F и при любом изменении в модуле F все остальные модули в нашей цепочке нужно перетестировать и пересобирать. Если же добавить тут один абстрактный модуль G, то можем разбить нашу цепь на три:
A->B->C->G
D->G
D->E->F
И изменения в F уже влияют не на 5 модулей, а на 2. Где именно и как часто ломать цепи зависимостей используя DI - это уже может варьироваться от проекта к проекту.
JSON с быстрым сжатием на lz4 покажет похожие цифры скорости и объема трафика. Плюс есть и бинарные форматы для сериализации json'а (но мои эксперименты с ними показали те же цифры что и обычный JSON с сжатием).