Если сильно хочется иметь порядок в ветке и при мердже хотите все коммиты аккуратно вливать в мейн/мастер, то используйте коммит с --fixup, для веток с более чем 1 коммитом упрощает исправления (позволяет применять правки к конкретному коммиту в середине истории, а не только к последнему как амменд).
Для тех кто часто ребейзит или перестраивает историю коммиты вместо обычного git push --force, лучше --force-with-lease
Разумеется, важно так же помнить и понимать кто пользуется проектом/моделью и для кого готовятся правила. Частые инциденты/ошибки - хороший кандидат на покрытие или введение правил где поясняется что важно соблюсти их корректность на конечном этапе валидации. Из простого примера - я забанил имена файлов вида types.go или utils.go, ллм знает про эти правила, иногда нарушает но на финальном этапе валидации находит это и исправляет согласно начальной конвенции. Чуть больше токенов но меньше потом исправлять
Поигравшись (скорее всего проиграв) с Kiro (тот же курсор, но со своими нюансами) могу сказать что пользование происходит по нескольким сценариям. Самый простой - понятная задача из джиры/гитхаба/ноушена/другого трекера, где скармливаю описание, пожелания, ссылаюсь на инструкции и после нескольких итераций делаю коммит результата. Важно, что всегда тикет стартует в своем контексте (новый чат) и закрывается по окончании.
Вариант сложнее - где происходит исследование и задача от простого пожелания или абстрактного представления формируется и выливается в конкретный код. На этом шаге легко начать творить дичь без должного контроля и легко начать творить бардак. Опытные промптеры/инженеры легко наводят порядок и направляют модели давая подсказки/подсвечивая правильные пути. Набирая критическую массу таких подсказок инженер скорее всего заводит инструкцию, (steering в контексте Kiro или agent.md) где описаны подробнее что за технологии используются, как решать частые ситуации(начиная от библиотек и заканчивая какие конкретно команды вызывать и на каком этапе) + правила вроде именования, структуры проекта, как и где обновлять документацию и так далее. Очевидно (хотя скорее нет чем да) что модель может часть инструкций игнорировать ввиду обстоятельств (в том числе из-за перегрузки контекста), поэтому важно ловить баланс между начальным инпутом (то бишь стартом нового контекста) и решением проблематики. Рабочий вариант, который позволяет двигать проект вперёд с большим количеством людей - автоматизация рутины (рабочие тесты, линтеры, адекватное покрытие) и оговоренные правила игры на проекте (набор правил к которым вы пришли). С этими правилами ведите модель к конечной точке, улучшая правила/инструкции и контролируемо расширяйте кодобазу.
Ну и я бы всегда держал в голове что ллм пытается выдать код, который на 90% универсален и в общем случае дженерик, так что проявлять изобретательность она без вашего участия вообще не планирует, это на вашей ответственности:)
Инструмент хороший, особенно при правильной готовке. Если проект содержит несколько сервисов или сервис с библиотеками (привет монолиты) то неплохо бы делать группу и обновлять несколько папок в одном пул реквесте (уменьшить шум и количество раннов). Так же разделить на логические обновления, скажем не разрешать прыжки через мажорные версии, делать обновление по паттерну только внутренних библиотек и отдельно секурити патчи. Таким образом можно получить довольно гибкую систему обновлений, видеть и главное быстро фиксить уязвимости.
Здравствуйте, интересный подход. Было бы интересно посмотреть на прокси до реального регистри (начиная от докерхаба и заканчивая клауд провайдерами (вроде ECR)).
Я тоже бьюсь вокруг librkafka и с одной стороны почти все библиотеки вокруг нее и конфлюент выглядят съедобными, но если есть необходимость в качестве стратегии (например при необходимости реализовать распределение по зонам/az) скормить что-то своё, то это мрак и непреодолимый ужас.
Здравствуйте, очень глубокий материал, большое спасибо:) Из хороший новостей - большинство описанной работы не нужно кодить самостоятельно, благо большое количество библиотек, фреймворков уже написано/портировано на практически любой язык. И вот отсюда вопрос, какой фреймворк/язык наиболее комфортный и какой посоветуете?
Спасибо за статью, познавательно. Мне показалось что зря не покрыли ещё опцию Using при создании индекса. Пусть он и не участвует в описанных случаях, но тоже полезная инфа по работе с индексами.
Наверное тут сложно однозначно ответить, так как зависит от кучи факторов: Мощностей брокера, количества активных партиций, как быстро происходит обработка сообщений, как быстро новые поды ackают запросы на вхождение в группу, сам алгоритм партишн асаймента. На практике скажу что в более менее активном топики это происходит достаточно быстро, в пределах 10 секунд. Думаю точное число можно узнать только эмпирически :)
Тут стандарт упоминает сущность SpanKind, которая как раз поможет определить, был ли вызов как цепочка (Аля РПЦ или АПИ запрос) или задачи были заспавнены отложенно (вида Producer/Consumer). Касательно батча, зависит что хотите увидеть, я бы каждую задачу в батче помечал.
Спасибо за статью, предлагаю рассмотреть как альтернативу https://github.com/zillow/zkafka . Крайне приятный интерфейс, очень удобно пользоваться и построено поверх конфлюент-го.
Хм, у меня в целом были похожие мысли, хотелось чтобы кто-то подтвердил :)
Помню как-то в доках для sqs находил примеры на джаве, где создавали эфемерную (временную очередь) в соседний сервис, отправляли имя как один из параметров в основную очередь и ждали ответа с таймаутом. Выглядит конечно необычно, но сознание расширяет
Если сильно хочется иметь порядок в ветке и при мердже хотите все коммиты аккуратно вливать в мейн/мастер, то используйте коммит с --fixup, для веток с более чем 1 коммитом упрощает исправления (позволяет применять правки к конкретному коммиту в середине истории, а не только к последнему как амменд).
Для тех кто часто ребейзит или перестраивает историю коммиты вместо обычного git push --force, лучше --force-with-lease
Разумеется, важно так же помнить и понимать кто пользуется проектом/моделью и для кого готовятся правила. Частые инциденты/ошибки - хороший кандидат на покрытие или введение правил где поясняется что важно соблюсти их корректность на конечном этапе валидации. Из простого примера - я забанил имена файлов вида types.go или utils.go, ллм знает про эти правила, иногда нарушает но на финальном этапе валидации находит это и исправляет согласно начальной конвенции. Чуть больше токенов но меньше потом исправлять
Поигравшись (скорее всего проиграв) с Kiro (тот же курсор, но со своими нюансами) могу сказать что пользование происходит по нескольким сценариям. Самый простой - понятная задача из джиры/гитхаба/ноушена/другого трекера, где скармливаю описание, пожелания, ссылаюсь на инструкции и после нескольких итераций делаю коммит результата. Важно, что всегда тикет стартует в своем контексте (новый чат) и закрывается по окончании.
Вариант сложнее - где происходит исследование и задача от простого пожелания или абстрактного представления формируется и выливается в конкретный код. На этом шаге легко начать творить дичь без должного контроля и легко начать творить бардак. Опытные промптеры/инженеры легко наводят порядок и направляют модели давая подсказки/подсвечивая правильные пути. Набирая критическую массу таких подсказок инженер скорее всего заводит инструкцию, (steering в контексте Kiro или agent.md) где описаны подробнее что за технологии используются, как решать частые ситуации(начиная от библиотек и заканчивая какие конкретно команды вызывать и на каком этапе) + правила вроде именования, структуры проекта, как и где обновлять документацию и так далее. Очевидно (хотя скорее нет чем да) что модель может часть инструкций игнорировать ввиду обстоятельств (в том числе из-за перегрузки контекста), поэтому важно ловить баланс между начальным инпутом (то бишь стартом нового контекста) и решением проблематики. Рабочий вариант, который позволяет двигать проект вперёд с большим количеством людей - автоматизация рутины (рабочие тесты, линтеры, адекватное покрытие) и оговоренные правила игры на проекте (набор правил к которым вы пришли). С этими правилами ведите модель к конечной точке, улучшая правила/инструкции и контролируемо расширяйте кодобазу.
Ну и я бы всегда держал в голове что ллм пытается выдать код, который на 90% универсален и в общем случае дженерик, так что проявлять изобретательность она без вашего участия вообще не планирует, это на вашей ответственности:)
Кто
Давно киро пробовали? Они сильно упростили биллинг и расчетов токенов, многократно снизив стоимость, рекомендую дать ещё шанс.
В целом это можно, к примеру построить sbom и сравнивать с текущими именами сервисов/библиотек
Спасибо, останусь на redpanda + redpanda-console
Инструмент хороший, особенно при правильной готовке. Если проект содержит несколько сервисов или сервис с библиотеками (привет монолиты) то неплохо бы делать группу и обновлять несколько папок в одном пул реквесте (уменьшить шум и количество раннов). Так же разделить на логические обновления, скажем не разрешать прыжки через мажорные версии, делать обновление по паттерну только внутренних библиотек и отдельно секурити патчи. Таким образом можно получить довольно гибкую систему обновлений, видеть и главное быстро фиксить уязвимости.
Здравствуйте, интересный подход. Было бы интересно посмотреть на прокси до реального регистри (начиная от докерхаба и заканчивая клауд провайдерами (вроде ECR)).
Я тоже бьюсь вокруг librkafka и с одной стороны почти все библиотеки вокруг нее и конфлюент выглядят съедобными, но если есть необходимость в качестве стратегии (например при необходимости реализовать распределение по зонам/az) скормить что-то своё, то это мрак и непреодолимый ужас.
Здравствуйте, очень глубокий материал, большое спасибо:) Из хороший новостей - большинство описанной работы не нужно кодить самостоятельно, благо большое количество библиотек, фреймворков уже написано/портировано на практически любой язык. И вот отсюда вопрос, какой фреймворк/язык наиболее комфортный и какой посоветуете?
Спасибо за статью, познавательно. Мне показалось что зря не покрыли ещё опцию
Usingпри создании индекса. Пусть он и не участвует в описанных случаях, но тоже полезная инфа по работе с индексами.Наверное тут сложно однозначно ответить, так как зависит от кучи факторов: Мощностей брокера, количества активных партиций, как быстро происходит обработка сообщений, как быстро новые поды ackают запросы на вхождение в группу, сам алгоритм партишн асаймента. На практике скажу что в более менее активном топики это происходит достаточно быстро, в пределах 10 секунд. Думаю точное число можно узнать только эмпирически :)
Окей, к фастапи вопросов нет :)
Рассматривали ли faust-streaming?
Здравствуйте, спасибо за статью. Просматривал листинги и пытался сам себе ответить на вопрос, "а зачем тут фастапи то"?
Идея в целом понятна, но в таком случае может лучше взять faust-streaming?
Ага, обманочка для глаз steam -> stream
В крайнем случае можно описать валидацию в жсон схеме
Тут стандарт упоминает сущность SpanKind, которая как раз поможет определить, был ли вызов как цепочка (Аля РПЦ или АПИ запрос) или задачи были заспавнены отложенно (вида Producer/Consumer). Касательно батча, зависит что хотите увидеть, я бы каждую задачу в батче помечал.
Хм, а можете просвятить почему такое отношение к CGO? Кроме времени билда я не успел заметить каких-то проблем.
Спасибо за статью, предлагаю рассмотреть как альтернативу https://github.com/zillow/zkafka . Крайне приятный интерфейс, очень удобно пользоваться и построено поверх конфлюент-го.
Хм, у меня в целом были похожие мысли, хотелось чтобы кто-то подтвердил :)
Помню как-то в доках для sqs находил примеры на джаве, где создавали эфемерную (временную очередь) в соседний сервис, отправляли имя как один из параметров в основную очередь и ждали ответа с таймаутом. Выглядит конечно необычно, но сознание расширяет