я подумал, что использовать обычный публичный почтовый рф сервис - ошибка, пошел дальше и развернул на рф сервере свой chatmail инстанс для deltachat.
оно даже работает, но невероятно сложно добиться от родственников 60+ лет чтобы они зарегались именно по ссылке, а не просто на публичном сервере nine.testrun.org (который или уже заблочен, или пока еще не...).
кстати, они тестируют видео/аудио звонки даже, но у меня вне рф цензуры не завелось.
справкдливости ради, не вижу ркн причин не сломать и email, раз уж они так явно хотят все коммуникации порезать, тут тоже вполне нетрудно придумать как сломать всё
Подрядчик с офисом на 400 индусов не имеет принципиальных отличий для заказчика от подписки на ИИ агенты
всё-таки имеет
мой поинт:
контроль был за счет контроля требований менеджментом и контроля реализации разработкой. это делегируется иишке, над которой нужной степени контроля нет ни у кого
контролировать разработчиков трудно, но можно. контролировать блэкбокс иишку невозможно
а с обслуживанием и правками после у них проблемы.
в этом и пикантность ситуации.
менеджмент, приученный смотреть не дальше спринта, столкнется с последствиями: кодовая база стала неуправляемой, агенты не могут внести правку которая не ломает что-то еще, требования не понимает никто, что-то сломалось, деньги теряем сейчас.
и что делать?
систему характеризует не ошибка, а реакция на ошибку
Да, была иллюзия контроля за счёт гор планов и отчётов
нет так, контроль был за счет контроля требований менеджментом и контроля реализации разработкой. это делегируется иишке, над которой нужной степени контроля нет ни у кого.
я уверен что этап оптимистического промпт-гэмблинга в индустрии быстро закончится, на этапе накопления проектами тонн необслуживаемых никаким образом (включая ai) слопов.
идет естественный отбор бизнесов. видимо, каждый отдельно взятый бизнес сам хочет прийти в эту точку.
Jira создавалась чтобы трекать работу по этапам, которых больше нет.
собственно, бизнесы, которые заменяют Процессы на Гэмблинг, ожидает эта самая точка. как они из нее будут разворачиваться и будет определять выживут они или нет
атрибут никак не помогает понять что именно происходит (сигнатура атрибута Authorize `create, [someClass::class, "post"]`, там где мы ожидаем чтото типа "авторизовать действие X")
мидлвэр "subscribed" указывает что где то есть какой то реестр именованных мидлвэров (а мог бы указывать на конректный класс, например)
возможно, если бы аргументы указывали бы с ключами (`paramName: value`), то было бы легче.
однако именно плохой пример с позиционными аргументами явно и наглядно демонстрирует дерьмовый дизайн фреймворка
смотрю на этот контроллер, и мне плохо от количества магии в этих атрибутах
#[Authorize('create', [Comment::class, 'post'])]
public function store(Post $post)
так что с комментом происходит: create, post или store? а авторизовывается какое действие: create или post? почему контроллер CommentController работает с моделью Post, а не с Comment?
Middleware('subscribed')]
что за мидлвэр "сабскрайбед"? кто на что подписан? где его искать чтобы понять что оно делает?
ларавел - жуть, ощущение что меня хотят запутать, а не помочь
в реальном мире это означает что сообщение с неактуальной схемой осядет в outbox/inbox, и никогда оттуда не выйдет пока ты его не смигрируешь и после какой то retry механизм не заберет смигрированное сообщение и не отправит в синкованные ноды.
единственный разумный паттерн применения генерации кода с пом ии: контролировать архитектуру, контролировать требования, просить дописать реализацию.
собрал требования, продумал как это дизайнить (можно отдельно посоветоваться в чатике с ии если надо), создал интерфейсы, создал тестовые методы с названиями и комментами о том что именно тестируется, раскидал там комменты про неочевидные моменты, попросил ии реализовать.
"вот интерфейс, реализуй", "вот тест, допиши".
в этом случае ии скорее автокомплит, чем думающая единица, и тогда это действительно полезный ассистент, который экономит время. меньше профита по времени, чем если бы он делал все полностью, но меньше и негативных последствий.
этот подход позволяет держать слопы под контролем, изолировать последствия: наворотил он фигни в рамках интерфейса - в худшем случае допишешь его сам.
как только ии позволяют работать выше, чем уровень реализации уже "набросанных" стабов - начинаются проблемы.
хорошие тесты начинаются с верно выбранной абстракции.
пример с order/shipping кривой, потому что в реальности требование "расчитывать цену доставки нужно корретно по таким то правилам" должен реализовывать компонент вродеShippingFeeCalculator, с методом вроде calculateFee(***) который прекрасным образом покроется тривиальным юнит тестом и не будет ломаться на каждый чих.
если уж очень хочется получать цену доставки из Order, то этот калькулятор передается в метод как аргумент, а не в конструктор order. order тупо делегирует, что покрывать действительно нет особого смысла.
если появляется новая реализация расчета доставки (новая реализация интерфейса fee калькулятора) - пишется новая реализация и новый юнит тест для нее, тестировать делегирование не стоит.
если для расчета доставки появляются новые параметры во всех калькуляторах (было calcFee(order) стало `calcFee(order, moonPosition, managerMood, dollarRate...)` - от это защититься можно только страшно обобщив (типа calcFee(calcFeeParameters), то есть ценой сложности.
не весть какой рефакторинг, но делать так сразу - скорее всего не окупится, и дешевле будет с этим смириться.
ну ansible же, господи
я подумал, что использовать обычный публичный почтовый рф сервис - ошибка, пошел дальше и развернул на рф сервере свой chatmail инстанс для deltachat.
оно даже работает, но невероятно сложно добиться от родственников 60+ лет чтобы они зарегались именно по ссылке, а не просто на публичном сервере nine.testrun.org (который или уже заблочен, или пока еще не...).
кстати, они тестируют видео/аудио звонки даже, но у меня вне рф цензуры не завелось.
справкдливости ради, не вижу ркн причин не сломать и email, раз уж они так явно хотят все коммуникации порезать, тут тоже вполне нетрудно придумать как сломать всё
всё-таки имеет
мой поинт:
контролировать разработчиков трудно, но можно. контролировать блэкбокс иишку невозможно
я перестал понимать что вы хотите доказать.
если не надо код писать потому что от этого компания не зависит - то рассуждения на тему процессов написания кода, который не нужен, бессмысленны.
мы же говорим про компании в которых услуга, за которую компания получает деньги, все-таки зависит от кода, который работает.
если код нужен - есть ии и есть спецы, выбор за бизнесом. с людьми далеко, с ии быстро и с высокими рисками оказаться в точке невозврата
нагенерит, да.
в менеджменте эйфория, в разработке лэйоффы.
а с обслуживанием и правками после у них проблемы.
в этом и пикантность ситуации.
менеджмент, приученный смотреть не дальше спринта, столкнется с последствиями: кодовая база стала неуправляемой, агенты не могут внести правку которая не ломает что-то еще, требования не понимает никто, что-то сломалось, деньги теряем сейчас.
и что делать?
систему характеризует не ошибка, а реакция на ошибку
нет так, контроль был за счет контроля требований менеджментом и контроля реализации разработкой. это делегируется иишке, над которой нужной степени контроля нет ни у кого.
мы видим, менеджмент тоже.
им нужно дать время убедиться что это не вопрос кривых рук, не локальная история, а системная проблема подхода
я уверен что этап оптимистического промпт-гэмблинга в индустрии быстро закончится, на этапе накопления проектами тонн необслуживаемых никаким образом (включая ai) слопов.
идет естественный отбор бизнесов. видимо, каждый отдельно взятый бизнес сам хочет прийти в эту точку.
собственно, бизнесы, которые заменяют Процессы на Гэмблинг, ожидает эта самая точка. как они из нее будут разворачиваться и будет определять выживут они или нет
Решительно плевать на метрику покрытия, в петах использую чтобы из теста быстро проваливаться в реализацию и обратно (`@covers`/`covered-by`).
Аналогично с event/eventListener (`@uses`/`used-by`)
я может чего то не понимаю, но они вроде просто завернули api'шку llm'ок в php api.
причем здесь ai-native, и что это вообще значит?
и там и там на самом деле
атрибут никак не помогает понять что именно происходит (сигнатура атрибута Authorize `create, [someClass::class, "post"]`, там где мы ожидаем чтото типа "авторизовать действие X")
мидлвэр "subscribed" указывает что где то есть какой то реестр именованных мидлвэров (а мог бы указывать на конректный класс, например)
возможно, если бы аргументы указывали бы с ключами (`paramName: value`), то было бы легче.
однако именно плохой пример с позиционными аргументами явно и наглядно демонстрирует дерьмовый дизайн фреймворка
смотрю на этот контроллер, и мне плохо от количества магии в этих атрибутах
так что с комментом происходит: create, post или store? а авторизовывается какое действие: create или post? почему контроллер CommentController работает с моделью Post, а не с Comment?
что за мидлвэр "сабскрайбед"? кто на что подписан? где его искать чтобы понять что оно делает?
ларавел - жуть, ощущение что меня хотят запутать, а не помочь
завожу доску в трелло, в карточку с названием компании завожу контакты hr, в комментах делаю пометки что важного услышал.
календарь нафиг не нужен, напоминалку на телефон и ок
не то что бы это сильно помогает: ситуации что у тебя 10 офферов и ты сидишь такой выбираешь давно уже нет
в реальном мире это означает что сообщение с неактуальной схемой осядет в outbox/inbox, и никогда оттуда не выйдет пока ты его не смигрируешь и после какой то retry механизм не заберет смигрированное сообщение и не отправит в синкованные ноды.
принял, большое спасибо!
Я не понимаю концепт, можете объяснить?
Есть schema registry, при сериализации/десериализации мы сверяем схему с той что в реестре, и если нет соответствия - падаем. Окей.
Изменили тип поля с int на string, запушили в реестр. Сериализация/десериализация сообщений падают из за того что несовместимы со схемой.
Обновили producer чтобы сериализовывал в соответствии с актуальной схемой. Consumer продолжает падать.
Обновили consumer, чтобы десериализовывал в соотв с актуальной схемой. Падать перестало.
Упавшие сообщения остаются в dlq и никогда оттуда не вернутся сами по себе.
В целом, то же самое случилось бы с авро, или без него: пока consumer/producer не синхронизируются все будет лететь в dlq, с той или другой стороны.
Если оно не решает проблему миграций, то какую проблему тогда оно решает?
Та же схема могла бы спокойненько себе лежать где нить в confluence.
сидеть и перебирать промпты, пока не опишешь все необходимые компромиссы звучит грустно
единственный разумный паттерн применения генерации кода с пом ии: контролировать архитектуру, контролировать требования, просить дописать реализацию.
собрал требования, продумал как это дизайнить (можно отдельно посоветоваться в чатике с ии если надо), создал интерфейсы, создал тестовые методы с названиями и комментами о том что именно тестируется, раскидал там комменты про неочевидные моменты, попросил ии реализовать.
"вот интерфейс, реализуй", "вот тест, допиши".
в этом случае ии скорее автокомплит, чем думающая единица, и тогда это действительно полезный ассистент, который экономит время. меньше профита по времени, чем если бы он делал все полностью, но меньше и негативных последствий.
этот подход позволяет держать слопы под контролем, изолировать последствия: наворотил он фигни в рамках интерфейса - в худшем случае допишешь его сам.
как только ии позволяют работать выше, чем уровень реализации уже "набросанных" стабов - начинаются проблемы.
ну, в браузере то можно хоть с пом pgp шифровать (mailvelope или что то типа того)
и совершенно точно будет, но это прекрасно, потому что каждая реализация калькулятора будет иметь только свои зависимости нужные ей.
EmsFeeCalculator(emsBase, ...)
RussianPostFeeCalculator(russianPostBase, ...)
хорошие тесты начинаются с верно выбранной абстракции.
пример с order/shipping кривой, потому что в реальности требование "расчитывать цену доставки нужно корретно по таким то правилам" должен реализовывать компонент вроде
ShippingFeeCalculator, с методом вродеcalculateFee(***)который прекрасным образом покроется тривиальным юнит тестом и не будет ломаться на каждый чих.если уж очень хочется получать цену доставки из Order, то этот калькулятор передается в метод как аргумент, а не в конструктор order. order тупо делегирует, что покрывать действительно нет особого смысла.
если появляется новая реализация расчета доставки (новая реализация интерфейса fee калькулятора) - пишется новая реализация и новый юнит тест для нее, тестировать делегирование не стоит.
если для расчета доставки появляются новые параметры во всех калькуляторах (было
calcFee(order)стало `calcFee(order, moonPosition, managerMood, dollarRate...)` - от это защититься можно только страшно обобщив (типаcalcFee(calcFeeParameters), то есть ценой сложности.не весть какой рефакторинг, но делать так сразу - скорее всего не окупится, и дешевле будет с этим смириться.