🔔 Вот и лето прошло. Словно и не бывало.

Идеально, что сегодня, первого сентября, на календаре именно понедельник. Помню, что когда я учился в школе, то всегда хотел вести в своем дневнике первую учебную неделю с понедельника. Но такое совпадение было только в 1993 году.

Дневник - это первое о чем я думал 1 сентября в школьные годы. Ведь это единственное, что имело смысл брать с собой на первый урок. Как интересно, что этот инструмент учебного процесса изменил мое восприятие времени - прошли десятилетия, но каждый раз, когда я что-то планирую, то у меня перед глазами все тот же школьный дневник с понедельника по субботу. Поэтому на воскресенье я по привычке ничего не планирую 🤪

Учебники - это было второе, о чем приходилось думать 1 сентября. Нам в первый учебный день всегда выдавали гору книг из школьной библиотеки. Во второй половине 90х книг в библиотеке стало меньше и их раздавали по учебнику на 3-10 человек (да, некоторые книги были только по 3 на весь класс), но в эпоху моих средних классов их еще была буквально гора!

Однажды, примерно в 6 классе, мне всё выдавали и выдавали книги, а я их всё пихал и пихал в свой рюкзак (школьный портфель у меня был только в младших классах, а потом мне купили этот учебный рюкзак, с которым я проходил до выпуска). Сначала просто укладывал стопкой, потом впихивал вдоль стенок - в результате рюкзак невозможно было застегнуть. Но варианта оставить книги в школе не было - им бы сразу "приделали ноги". Во времена моей средней школы мы по сменам делили помещение с другими классами, а такое понятие как "школьные шкафчики" я мог видеть только по кабельному в американских фильмах...

И вот я тогда утрамбовал в свой рюкзак все полученные книги, но теперь нужно было его отнести домой. Помню, что это был очень тяжелый рюкзак. Какая-то книга стояла ребром и больно била меня в спину на каждом шаге. Вот так, груженный как ишак, я медленно брел домой под жаркими лучами солнышка. В тот день было так же жарко как и сегодня в Киеве ☀️

Примерно на половине дороги мне повстречался какой-то мужчина в возрасте:

- О! Поздравляю с днем знаний! Несешь учебники домой? У вас, поди, сейчас по тоненьким методичкам преподают. А вот я помню, что в своем детстве нам давали большие тяжелые книги - в них и знаний было больше.

Я что-то вежливо пробубнил в ответ и пошел дальше нести на спине свой груз будущего учебного года. И что я мог сказать? Ведь я всегда был воспитанным мальчиком и с уважением относился ко взрослым 🤓

Буквально на днях слушал подкаст преподавателя иностранных языков. И согласно его слов утверждать о свободном владении каким-либо языком можно только тогда, когда ты на нем начнешь видеть сны.

Всю ночь мне снилось, что я что-то писал - то в 1С:Конфигураторе, то в 1С:ЕДТ...

Выходит можно утверждать, что я свободно владею языком 🚗

⭐️ На днях я уже писал про MCP-серверов в 1С от Владимира Харина (@vladimir_kharin). Оказалось, что Владимир не просто сделал доброе дело в виде публичного репозитория на GitHub, но и записал видео, в котором подробно остановился на следующих вопросах:

🟡Что такое MCP и для чего оно полезно?
🟡Что могут MCP, получающие информацию из баз 1С?
🟡Почему технически невозможно подключить 1С напрямую к популярным ИИ-агентам?
🟡Как Владимир обошел ограничения?
🟡Как на практике встроить его расширение в базу 1С и подключить получившийся MCP в Cursor?

Кажется, что новости про ИИ противоречат одна другой.

Например, я сегодня прочитал о докладе компании Aprilo, которая специализируется на безопасности ПО и поиске уязвимостей. Они сделали анализ репозиториев, код которых написан с помощью различных ИИ-инструментов. Оказалось, что состоянием на июнь 2025 года количество проблем с безопасностью выросло десятикратно по сравнению с декабрем 2024 - т.е. выходит, что новые версии популярных ИИ пишуть менее безопасный код. Причем многие уязвимости уже давно хорошо известны и имеют многочисленные эксплойты.

Но так же я сегодня прочитал о достижении команды XBOW (белые хакеры), которые на августовской Black Hat 2025 поразили зрителей тем, что провели живую демонстрацию на реальных целях из HackerOne (ведущая платформа награждений за нахождение багов) и обнаружил десятки уязвимостей, для каждой из которых создал доказательство концепции эксплойта. В своем докладе они указали, что использование новой GPT-5 вместо предыдущих версий удвоило эффективность поиска и снизило количество ошибок.

Так ИИ делают написание программ уязвимыми или наоборот более защищенными?

Вы будете смеяться, но тут именно тот случай, когда важен не размер, а умением им пользоваться! 👆

И GPT, и Gemini, и Sonnet, и Grok и многие другие могут писать аккуратный код с минимальными проблемами с безопасностью - но только если этого явно потребовать в промпте и подключить MCP с реестрами известных проблем. А еще можно на этап кодревью подключить дополнительного ИИ-агента, который возможно не умеет рисовать, не умеет генерировать голос или писать стихи, но зато умеет искать потенциальные уязвимости на уровне опытных багбаунти охотников.

Тогда о чем же говорит факт, что все больше и больше появляется некачественного и уязвимого кода в публичных репозиториях (в том числе крупных опенсурс проектов)?

Это говорит о том, что все больше и больше в отрасль приходит "программистов", которые просто не знают об особенностях и рисках различных этапов жизненного цикла разработки ПО. Вайбкодинг дал им возможность сразу писать рабочий код, но он же позволил пропустить месяцы и годы набивания шишек и хождений по граблям, а следовательно не позволил накопить собственный опыт. Думаю, что скоро мы еще услышим множество историй в духе "зумеры внезапно узнали, что нужно было делать бэкапы".

Когда я начинал в IRP Team, то моей задачей на испытательный срок было создание инструмента для мокирования (имитации поведения) внешних веб-сервисов. Команде был нужен этот инструмент для покрытия автотестами операций с порталами электронных документов.

Поскольку задача мне ставилась для целей тестирования, то я не создавал совсем новый "велосипед" и функционал поместил в расширении для юнит-тестирования. Оглядываясь назад, это уже не кажется красивым решением, так как юниты запускаются отдельно и независимо от интеграционных тестов на базе Vanessa-Automation (для которых моки и создавались). Хотя возможно "Units" давно пора немного расширить и переименовать в "Testing"? Или даже забрать в ядро? 🤔

Сейчас у меня в работе задачка по доработке одного расширения для IRP, в котором работу с физическим фискальным аппаратом нужно заменить на интеграцию с одним веб-сервисом. Проблема в том, что разработку я делаю у себя, а тестирование можно делать только на специальном ноутбуке, который мне по запросу включают - только там есть доступ к веб-сервису. Усложняет задачу то, что тут помимо смены реализации API, из расширения нужно изменить также внешнее поведение системы - т.е. мне нужно раз за разом смотреть что вообще происходит и как изменяется поведение рабочего места кассира (расширения уж очень капризные), но каждый раз я попадал на таймауты к недоступному сервису.

Короче очень захотелось поднять заглушки, чтобы получать фейковые ответы... И тут я вспоминаю, что мокирование в продукте уже есть и что это же я сам его разработал для похожих целей 🤦‍♂️

Механизм моков после сегодняшнего явно ожидает еще одна итерация доработки, так как не ожидалось их ручное оформление. Была концепция, что у базы во время настройки есть доступ к нужному сервису и можно буквально "записывать" ответы, на базе которых будут созданы сценарии для тестов. К счастью, даже текущего функционала оказалось достаточно и не пришлось ничего дорабатывать.

Небольшая автоматизация и работа полетела!

#понедельник #тестирование #мокирование

Вчера я решил попробовать новый ИИ-инструмент Trae от ByteDance. По сути это клон Cursor (тоже на базе VS Code и похожая бизнес-модель), но с большим числом LLM, более высокими лимитами, более дешевыми планами (Pro за $10/мес против $20 у Cursor) и некоторыми своими ноухау. Они заявляют, что оптимизированы для командной работы над большими проектами со множеством файлов - стало интересно скормить ему какую-нибудь ERP...

📝 Но сегодня я хотел не рекламировать новый инструмент, а обратить внимание на то, с чего начинается установка каждой программы - на лицензионное соглашение. Китайцы выкатили огромный файл, который я естественно не стал читать и просто скормил ИИ для анализа рисков. Большинство пунктов стандартны: запрет на реверс-инжениринг, обучение конкурирующих решений, использование в странах под санкциями США... Но был и интересный момент - весь обрабатываемый контент включая логотипы может использоваться компанией ByteDance для коммерческого использования. Так что нужно держать во внимании, что своего "убийцу Фейсбука" тут лучше не создавать.

👀 Но разве среднестатистические пользователи ПО используют ИИ для анализа лицензионных соглашений? И разве фактически есть выбор отказаться? Это только в анекдотах кто-то читает 50 страниц соглашения и отказывается, потому-что не устроила формулировка...

⁉️ Что собой представляет стандартное соглашение? Огромная простынь написанная запутанным юридическим языком со множеством латинизмов и формализмов, где постулируется отказ от любой ответственности даже от явно причиненной владельцами сервиса, но при этом требуется предоставлять право на коммерческое использование собственной персональной информации.

🥷 По сути все эти пользовательские и лицензионные соглашения являются огромным мошенничеством, с которым не борется ни одна страна мира! Будучи фактическими монополистами многие сервисы и продукты (соцсети, мессенджеры, фото- и видео- редакторы) используют нереализованную потребность пользователей чтобы заставить их согласится на различные неочевидные сделки.

🔮 Вы знали, что когда генерируете картинки и видео в Midjourney, то они могут продать на них права в Wirestock, а сервисы генерации аудио Suno и Uncharted Labs продают работы своих пользователей в Sony Music и Warner Music? Понятно, что продаются права не на все подряд, а только на контент, который загружается на YouTube и стриминговые платформы, и который начинает приносить монетизацию - тут внезапно объявляются новые правообладатели и требуют лицензионные отчисления за использование "их собственности". И только в этот момент удивленные "креаторы" узнают, что же на самом деле они подписали не читая своим бездумным кликом "я согласен".

🦄 В идеальном мире соглашение должно быть из коротких и четких пунктов, которые дают ясное представление пользователю, к каким юридическим последствиям могут привести использованию нужного им сервиса. Эти пункты должны быть отключаемы, если пользователь согласен с ограничением функциональности и/или доплатой. А при внесении платежей за использование услуги сервис не должен иметь право развести руками - он должен покрывать убытки, к которым он же привел (в оффлайн бизнесе использование страхования является обычной и часто обязательной практикой).

🔔 Но мы живем не в идеальном мире. Поэтому проверяйте соглашения перед подписанием хотя бы с помощью ИИ.