Ей богу, некоторые даже не перевели термины. gpt никак не может быть ии , и никогда эта технология иишкой не станет. Маркетинг и реальность разные вещи.
В случае необходимости просмотра телефона не глазами, кабель вставят в хозяина, до полного понимания необходимости сотрудничества. Эти уловки работают пока ваша информация реально не понадобиться. А при стирании значительно ухудшит моральное и физическое состояние владельца, не более.
Больше достали деграданты(люди кто вроде что-то умел но ии помогло им деградировать в нейрослопера). Люди например начинают отдавать написание спек на ии. И продвигают это как экономию ресурсов. Некоторые на уровне мидла- начинают думать что вполне могут написать свой bpm движок. Паралельно решая что код ревью можно оставить на или тоже. При том что опыта в движках в принципе не имеют. сперва рофлил, но потом начали давать исправлять это "торжество разума". Причем претензии предъявляют не им, а мне что медленно и что предлагаю масштабные правки... И это уже не рофл :)
Чем ближе anthropic, к ipo, тем больше идиотизма мы будем наблюдать. Интересно посмотреть на этот продукт после года эксплуатации. Пока это маркетинговый хайп, не более
В 2026 году отметать все наработки и заявлять, что все не так и нужно делать все по-другому, потому что мне так кажется.. нуда нуда ведь все поменялось со времён Фаулера и Кента Бека, или ничего не поменялось и вы просто делаете ошибку в статье, на голубом глазу заявляя, что они просто устарели и все не так. Сослался я на книгу так как там вроде аксиомы рефакторинга прописаны, которым стоит следовать. 2*2 всегда 4, либо меняйте базовые аксиомы, чего в статье не сделано.
"UPD: про Unit тесты" тут вообще ад описан интересно где такое ) ни разу с таким трёшки не сталкивался)
https://martinfowler.com/articles/refactoring-2nd-ed.html крайне советую. Заодно solid. Штука в том что если вы пишите нормальный код, то юниты это просто подпорки на которые вы ориентируетесь. Фактически колличество тестов до и после должно быть примерно одинаковым. Там так вы код меняете а не использование его. Рефачить в потом писать тесты , странно...
Не ближе его роль в сре. В конкретно этой статье проблема в нт, имхо. Все кейсы про то что нт по сути нет или сделаны для галочки. Первый кейс: у вас либо нет теста, либо логин замокан(какой это тогда ни тест с моками). Очередь переполнилась: либо нет теста либо тест с моками систем с которыми взаимодействует. Моки отвечают быстро, а реальность другая.. 3 кейс тоже самое.Похоже вместо нт написаны бенчмарки. Плюсом вместо доработки и оттачивания стресс тестирования, вводится новая новая практика.
Вообщем просто не понимание процесса разработки.. юниты нужны не только для качества , но и для поддержки кода в будущем, рефакторинг например, да любые изменения в принципе не возможны без покрытия юнит тестами. Есть такой принцип написания текстов FIRST, F-FAST... Такие тесты и него удешевляют разработку, а не стоят дополнительные деньги. Главное в статье спутано покрытие кода и покрытия кейсов использования системы.
Опус о том что показываю сломанные юнит тест , а система работает, показывает просто бездну. Значит работает система не потому варианту , что в тесте, когда пишется код, код и тесты актуализируются. То есть если у вас есть блок мертвого кода, это не значит, что у вас плохие тесты, это значит у вас проблема с процессами разработки.
Опус о невозможности что-то тестить если это Букинг отелей... Тут со дна стучат уже. Ну возьмите вы практически стандарт индустрии: test containers. Или вот есть у вас рест: 400 ошибку. Хотя да.. юнит тесты нужны слабым программистам))
Обычно процесс выглядит как: maven central/github/any other source ->local installation: artifactory/nexus-> проверка лицензий проекта на этапе подключения(это базовый уровень разработчика что и почему он тянет нового)->юрист по лицензированию для перепроверки лицензий, перед выпусками версий где добавляется новое.
стек разработки обычно очень стабильный и что-то реально новое тянется редко, то есть реально заморачиваться придется только первый раз с юристом, дальше инкрементальные изменения ну раз в год максимум.
Это все понадобится как только вы реально захотите выйти на рынок.
Лично сидел юристом из Франции и помогал с проверкой лицензий, каждый год в течении недели. Колличество новых фич/фиксов за год сложно подсчитать, их были тысячи.
Валидация безопасности скорее миф. Проверить код всех зависимостей для rest hello world на spring boot java 21, конечно можно, но ресурсы нужны не подъемные, и переносится на комьюнити в целом + нужно следить и вовремя обновлять зависимости
Ей богу, некоторые даже не перевели термины. gpt никак не может быть ии , и никогда эта технология иишкой не станет. Маркетинг и реальность разные вещи.
В случае необходимости просмотра телефона не глазами, кабель вставят в хозяина, до полного понимания необходимости сотрудничества. Эти уловки работают пока ваша информация реально не понадобиться. А при стирании значительно ухудшит моральное и физическое состояние владельца, не более.
По ссылкам нейрослоп. Недавно видел презу в таком дизайне. Тоже чуваки вешали про ai. Это видать общее...
Реальные вещи я так понимаю не делали..
Больше достали деграданты(люди кто вроде что-то умел но ии помогло им деградировать в нейрослопера). Люди например начинают отдавать написание спек на ии. И продвигают это как экономию ресурсов. Некоторые на уровне мидла- начинают думать что вполне могут написать свой bpm движок. Паралельно решая что код ревью можно оставить на или тоже. При том что опыта в движках в принципе не имеют. сперва рофлил, но потом начали давать исправлять это "торжество разума". Причем претензии предъявляют не им, а мне что медленно и что предлагаю масштабные правки... И это уже не рофл :)
Очевидно ии участвовало в разработке, в качестве инструмента генерации научной статьи
Это в каком году статья писалась? Вроде +- java в этом плане выровнялись давно.
Как же это все далеко от реального прода, issues, да разработки в принципе.. когда этот ваш нейрослопа уже кончится
Визионер.
Чем ближе anthropic, к ipo, тем больше идиотизма мы будем наблюдать. Интересно посмотреть на этот продукт после года эксплуатации. Пока это маркетинговый хайп, не более
Нейрослоп реклама через гуглтранслейт )
В 2026 году отметать все наработки и заявлять, что все не так и нужно делать все по-другому, потому что мне так кажется.. нуда нуда ведь все поменялось со времён Фаулера и Кента Бека, или ничего не поменялось и вы просто делаете ошибку в статье, на голубом глазу заявляя, что они просто устарели и все не так. Сослался я на книгу так как там вроде аксиомы рефакторинга прописаны, которым стоит следовать. 2*2 всегда 4, либо меняйте базовые аксиомы, чего в статье не сделано.
"UPD: про Unit тесты" тут вообще ад описан интересно где такое ) ни разу с таким трёшки не сталкивался)
https://martinfowler.com/articles/refactoring-2nd-ed.html крайне советую. Заодно solid. Штука в том что если вы пишите нормальный код, то юниты это просто подпорки на которые вы ориентируетесь. Фактически колличество тестов до и после должно быть примерно одинаковым. Там так вы код меняете а не использование его. Рефачить в потом писать тесты , странно...
Вас запишут в луддиты, но благодаря таким , пока ещё, среди кучи аи-слопа, можно найти нормально написанные тексты. нормальные программы.
Не ближе его роль в сре. В конкретно этой статье проблема в нт, имхо. Все кейсы про то что нт по сути нет или сделаны для галочки. Первый кейс: у вас либо нет теста, либо логин замокан(какой это тогда ни тест с моками). Очередь переполнилась: либо нет теста либо тест с моками систем с которыми взаимодействует. Моки отвечают быстро, а реальность другая.. 3 кейс тоже самое.Похоже вместо нт написаны бенчмарки. Плюсом вместо доработки и оттачивания стресс тестирования, вводится новая новая практика.
Мало было январского обновления...
Вообщем просто не понимание процесса разработки.. юниты нужны не только для качества , но и для поддержки кода в будущем, рефакторинг например, да любые изменения в принципе не возможны без покрытия юнит тестами. Есть такой принцип написания текстов FIRST, F-FAST... Такие тесты и него удешевляют разработку, а не стоят дополнительные деньги. Главное в статье спутано покрытие кода и покрытия кейсов использования системы.
Опус о том что показываю сломанные юнит тест , а система работает, показывает просто бездну. Значит работает система не потому варианту , что в тесте, когда пишется код, код и тесты актуализируются. То есть если у вас есть блок мертвого кода, это не значит, что у вас плохие тесты, это значит у вас проблема с процессами разработки.
Опус о невозможности что-то тестить если это Букинг отелей... Тут со дна стучат уже. Ну возьмите вы практически стандарт индустрии: test containers. Или вот есть у вас рест: 400 ошибку. Хотя да.. юнит тесты нужны слабым программистам))
Зачем это на хабре? 100500 статей с оконулевой связью к разработке но про "ai"
0 информативности в или генерированной статье :(
Обычно процесс выглядит как: maven central/github/any other source ->local installation: artifactory/nexus-> проверка лицензий проекта на этапе подключения(это базовый уровень разработчика что и почему он тянет нового)->юрист по лицензированию для перепроверки лицензий, перед выпусками версий где добавляется новое.
стек разработки обычно очень стабильный и что-то реально новое тянется редко, то есть реально заморачиваться придется только первый раз с юристом, дальше инкрементальные изменения ну раз в год максимум.
Это все понадобится как только вы реально захотите выйти на рынок.
Лично сидел юристом из Франции и помогал с проверкой лицензий, каждый год в течении недели. Колличество новых фич/фиксов за год сложно подсчитать, их были тысячи.
Валидация безопасности скорее миф. Проверить код всех зависимостей для rest hello world на spring boot java 21, конечно можно, но ресурсы нужны не подъемные, и переносится на комьюнити в целом + нужно следить и вовремя обновлять зависимости
Очевидно, чтобы оставить часть платформ без обновлений гита. Ну и часть разработчиков выкинуть из проекта.