Похоже оставшиеся сотрудники будут очень активно создавать видимость самой прорывной нейросети и лучшая работа поздно ночью - это отвечать на запросы клиентов в чатах.
Сравнивал в рамках своего проекта. 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% уверен, что это очередная фича для хабра-элиты как и все другое на этом ресурсе. Удивлен, что оказывается этим могли пользоваться все. Если бы знал, то может быть и пользовался иногда.
Уж больно неорганично они смотрелись в относительно строгом дизайне сайта. Они бы подошли для сайта детского сада или сайта с играми для маленьких детей.
А как graphql помогает решать подобную задачу с произвольными фильтрами? Насколько помню в стандарте не было ничего об универсальном языке запросов.
Похоже оставшиеся сотрудники будут очень активно создавать видимость самой прорывной нейросети и лучшая работа поздно ночью - это отвечать на запросы клиентов в чатах.
Сравнивал в рамках своего проекта. 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% уверен, что это очередная фича для хабра-элиты как и все другое на этом ресурсе. Удивлен, что оказывается этим могли пользоваться все. Если бы знал, то может быть и пользовался иногда.
Уж больно неорганично они смотрелись в относительно строгом дизайне сайта. Они бы подошли для сайта детского сада или сайта с играми для маленьких детей.