Угу. Сейчас тратят миллиарды на обучение моделей на кодовом наследии прошлых десятилетий, А потом будут обучать на нейрослопе и тратить миллиарды на то что бы модели не превращались в тыкву от того что они "накодили" за последние годы.
Первым делом я подумал о JSON Schema, однако из-за её многословности я решил отказаться от неё, на мой взгляд, она недостаточно человекочитаема.
Интересный проект. Однако я год назад подумывал создать свой DSL, и проблема таких кастомных решений - это сложность их последующего расширения если вдруг понадобится использовать его для более широких целей, и такие языки к сожалению, становятся заложниками узких кейсов применения. Что касается JSON Schema то она и не призвана быть малословной, а скорее наоборот, многословность обусловлена высоким охватом практически любого кейса. И я не знаю какой кейс JSON Schema неспособна покрыть при должном знании спецификации. Разве что GraphQL и gRPC (но это отдельная история). Для удобства чтения - есть Swagger UI который идеально подходит для чтения.
Во-первых: как уже писали выше - Trae существует намного дольше чем Z Code, и сделан в Китае.
Во-вторых: Z Code не использует в качестве базы VS Code и даже Electron, а построен как графический клиент для консольных агентов и использует фреймворк Tauri
В третьих: Поддержка любых версий glm там есть, в том числе glm-5, потому что, это фактически графическая обёртка над тремя (на данный момент) CLI-агентами - Claude Code, Genmini CLI и Codex и соответственно, имеет поддержку тех моделей, которые эти агенты поддерживают.
Что-то похожее сейчас делают разработчики OpenCode.
Изучайте материал перед тем как писать пост и не вводите людей в заблуждение. Желаю успехов!
В Composer 2 давно применяется многопроцессная обработка пакетов. Ну и судя по исходному коду, данное творение целиком и полностью написано нейронкой, и это ни хорошо ни плохо. Скорее плохо, так как вероятность что проект будет заброшен или в нём не будут исправляться найденные ошибки (ввиду того что автор свой код сам не писал) очень велика. Но попытка интересная.
Ничего удивительного. Господа из PVS Studio всегда считают себя "самыми умными" и делают такого рода финты. Им плевать на пользователей, пиар превыше всего. Потому и тащат на свой сайт. И если вы перейдёте по ссылке, то увидите, что статься там ни о чём.
Финт конечно интересный, но тогда лучше вынести 1 в константу, так как если в проекте используется анализатор, например SonarQube как у нас, то такой код quality gate не пройдёт, ибо magic number
Интересное решение. Но хотелось бы понять, в чём преимущество перед готовыми решениями? Например, ONLYOFFICE DocSpace Community разворачивается в докере в пару кликов, и при этом OpenSource.
Ну и хотелось бы немного высказать своё ИМХО по вашей статье. Как мне кажется, подход ResultTransformer более применим в контексте паттерна Query Object, т. е. когда нам действительно не нужно получать из БД сущности, а нужны некие DTO. То что репозиторий возвращает что-то отличное от сущностей, как мне кажется не есть хорошо.
Не совсем понятно, а причём тут собственно GraphQL? По сути, для статьи достаточно было описать SmsService, всё остальное детали для конкретного проекта. Полагаю что GraphQL притянут за уши, что бы статья совсем уж не выглядела голой рекламой вашего сервиса (впрочем это не помогло).
Ну и конечно же, не могу не отметить "качество" представленного кода, например:
То OpenAI в гос органы ходит жаловаться, теперь эти. Интересные они ребята, хотят что бы конкурировали честно, но не они.
Угу. Сейчас тратят миллиарды на обучение моделей на кодовом наследии прошлых десятилетий, А потом будут обучать на нейрослопе и тратить миллиарды на то что бы модели не превращались в тыкву от того что они "накодили" за последние годы.
Ну всё, теперь венде точно капец!
Интересный проект. Однако я год назад подумывал создать свой DSL, и проблема таких кастомных решений - это сложность их последующего расширения если вдруг понадобится использовать его для более широких целей, и такие языки к сожалению, становятся заложниками узких кейсов применения. Что касается JSON Schema то она и не призвана быть малословной, а скорее наоборот, многословность обусловлена высоким охватом практически любого кейса. И я не знаю какой кейс JSON Schema неспособна покрыть при должном знании спецификации. Разве что GraphQL и gRPC (но это отдельная история). Для удобства чтения - есть Swagger UI который идеально подходит для чтения.
Но, тем не менее, желаю успехов!
Весь пост - сплошная профанация!
Во-первых: как уже писали выше - Trae существует намного дольше чем Z Code, и сделан в Китае.
Во-вторых: Z Code не использует в качестве базы VS Code и даже Electron, а построен как графический клиент для консольных агентов и использует фреймворк Tauri
В третьих: Поддержка любых версий glm там есть, в том числе glm-5, потому что, это фактически графическая обёртка над тремя (на данный момент) CLI-агентами - Claude Code, Genmini CLI и Codex и соответственно, имеет поддержку тех моделей, которые эти агенты поддерживают.
Что-то похожее сейчас делают разработчики OpenCode.
Изучайте материал перед тем как писать пост и не вводите людей в заблуждение. Желаю успехов!
Полагаю имелось ввиду GLM-4.7?
Поделил на ноль
Очень похоже, что исследование не такое уж и независимое. И кому могло быть выгодно такое исследование? Да не, показалось...
Вы бы хоть в статье потрудились написать что такое этот ваш Veai
В Composer 2 давно применяется многопроцессная обработка пакетов. Ну и судя по исходному коду, данное творение целиком и полностью написано нейронкой, и это ни хорошо ни плохо. Скорее плохо, так как вероятность что проект будет заброшен или в нём не будут исправляться найденные ошибки (ввиду того что автор свой код сам не писал) очень велика. Но попытка интересная.
Ничего удивительного. Господа из PVS Studio всегда считают себя "самыми умными" и делают такого рода финты. Им плевать на пользователей, пиар превыше всего. Потому и тащат на свой сайт. И если вы перейдёте по ссылке, то увидите, что статься там ни о чём.
Хмм, я бы взял такую, несмотря на хейт выше. А если они сделают возможность открывать разные документы на разных экранах - то тем более.
Финт конечно интересный, но тогда лучше вынести 1 в константу, так как если в проекте используется анализатор, например SonarQube как у нас, то такой код quality gate не пройдёт, ибо magic number
А что конкретно не понравилось, если не секрет?
Интересное решение. Но хотелось бы понять, в чём преимущество перед готовыми решениями? Например, ONLYOFFICE DocSpace Community разворачивается в докере в пару кликов, и при этом OpenSource.
Здравствуйте! К сожалению, актуальных сравнительных тестов нет, думаю они появятся в следующих статьях.
Коммерческое внедрение есть. Используется как обработчик сообщений из RabbitMQ а так же на более ранней версии реализован телеграм бот.
К сожалению, над проектом работаю один, с конца 2018 года.
Поставил лайк за редактор блок-схем. Очень годная вещь получилась.
Сделайте, пожалуйста, подсветку синтаксиса кода.
Ну и хотелось бы немного высказать своё ИМХО по вашей статье. Как мне кажется, подход ResultTransformer более применим в контексте паттерна Query Object, т. е. когда нам действительно не нужно получать из БД сущности, а нужны некие DTO. То что репозиторий возвращает что-то отличное от сущностей, как мне кажется не есть хорошо.
За статью спасибо.
Не совсем понятно, а причём тут собственно GraphQL? По сути, для статьи достаточно было описать SmsService, всё остальное детали для конкретного проекта. Полагаю что GraphQL притянут за уши, что бы статья совсем уж не выглядела голой рекламой вашего сервиса (впрочем это не помогло).
Ну и конечно же, не могу не отметить "качество" представленного кода, например:
return $invite ? true : false;
Обновился вчера на SE 2022, полёт нормальный, никаких косяков не заметил. Батарея держится как обычно. Повезло.