Похоже оставшиеся сотрудники будут очень активно создавать видимость самой прорывной нейросети и лучшая работа поздно ночью - это отвечать на запросы клиентов в чатах.
Сравнивал в рамках своего проекта. CBOR в сыром виде конечно на порядок компактнее json'а, но очень слабо поддается сжатию (видимо хорошо продуман и минимизирован). На выходе сжатый json получался +/- того же размера что и сжатый cbor (разница примерно +/-5%)
Т.е. в сыром виде cjon конечно немного меньше, но сжатию обычный json поддается лучше, а если есть ограничение по передаче только текста, то пожатый json в base64 имеет намного меньший размер (меньше почти в два раза) чем сырой cjon.
Через 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 для записи метрик и трейсинга
Похоже оставшиеся сотрудники будут очень активно создавать видимость самой прорывной нейросети и лучшая работа поздно ночью - это отвечать на запросы клиентов в чатах.
Сравнивал в рамках своего проекта. CBOR в сыром виде конечно на порядок компактнее json'а, но очень слабо поддается сжатию (видимо хорошо продуман и минимизирован). На выходе сжатый json получался +/- того же размера что и сжатый cbor (разница примерно +/-5%)
Не поленился посмотреть как будет выглядеть размер данных в zstd сжатом виде на дефолтных настройках:
jsonLen: 2710cjonLen: 2519
Compressed json bytes: 1078
Compressed cjon bytes: 1133
Compressed json as base64 len: 1440
Т.е. в сыром виде cjon конечно немного меньше, но сжатию обычный json поддается лучше, а если есть ограничение по передаче только текста, то пожатый json в base64 имеет намного меньший размер (меньше почти в два раза) чем сырой cjon.
А зачем вообще в наше время нужен 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 токенами