Возьму на себя смелость предположить, что уже сейчас формируется огромный пласт софта, заточенного исключительно под агентов. Появилась потребность, которая буквально звучит как «Я хочу чтобы в первую очередь это мог использовать агент».
Пользовательский интерфейс в таком случае вторичен, красивые контракты со всем этим REST и остальной чепухой тоже вторичны. Документация в привычном нам смысле — туда же. Постепенно понятие «ai‑first» становится всё шире. Шаг за шагом начинает менять наш взгляд и на привычное проектирование любого софта. Новый флоу работы буквально сминает старые правила. А мы и не сильно против, пока что.
Все вы наверное слышали разговоры про отдельный язык программирования под ИИ. Мол меньше кода, больше дела, агенты разберутся. Тут кажется снова та же логика. Нам теперь не так важно, как будет выглядеть сам язык. Нам важно, чтобы его можно было эффективно использовать агентам, которых мы отправляем работать.
Интересно станет ли в конечном счёте понимание привычного нам «высокоуровневого» кода таким же вторичным, каким однажды стало понимание ассемблера? Если даже сейчас многие проблемы начинают решаться через «Клод, чувак, давай там разберись, отпишешься как разберешься».
Для бизнеса интеллект всегда вреден. Например, рассказывать по email гражданам Соединенных Штатов Америки почему так необходимо купить в 60 лет именно эту виагру для поддержания теплой обстановки супружеской жизни это прибыльный бизнес.
Любой интеллект принял бы решение аннигилироваться, так как рефлексия о содержимом голов деда с бабкой на старость лет уничтожает веру в светлое будущее человечества.
WEB-прокси Telegram помогает клиенту, но не инфраструктуре бота
В Telegram Desktop 7.1.0 появился новый тип подключения — WEB proxy. Его уже успели описать как способ, с помощью которого Telegram может выглядеть для сети как обычный HTTPS-сайт.
Клиент сохраняет обычный MTProxy framing и шифрование.
Соединения проходят через скрытый WebView внутри приложения.
WebView передаёт несколько логических потоков через один или несколько HTTPS- либо WebSocket-соединений с тем же доменом.
Серверный relay разделяет потоки и передаёт каждый локально запущенной официальной реализации MTProxy.
При этом relay видит только непрозрачный поток данных: он не расшифровывает содержимое и не выбирает Telegram-сервер назначения.
Указанный домен продолжает работать как обычный HTTPS-сайт. Если запрос не содержит корректного capability, вычисленного из домена и секрета WEB-прокси, посетитель получает публичную страницу. Bridge открывается только клиенту с правильными параметрами подключения.
Сейчас готовая реализация работает в Telegram Desktop. Для Android существует экспериментальный клиент, а поддержка iOS пока описана только в планах проекта.
Что это меняет для разработчика бота
Сам WEB-прокси обслуживает соединение Telegram-клиента с инфраструктурой мессенджера. Он не становится общим туннелем для всех компонентов продукта.
Mini App → домен, на котором размещено веб-приложение.
Если сервер бота потеряет доступ к api.telegram.org, результат будет зависеть от способа получения обновлений.
При long polling бот перестанет и получать обновления, и вызывать методы Bot API.
При webhook входящие обновления ещё могут приходить, если endpoint доступен извне. Однако обычные исходящие обращения к Bot API работать не будут. Есть редкое исключение: Telegram разрешает передать один метод Bot API прямо в HTTP-ответе на webhook. Но узнать результат выполнения такого метода бот уже не сможет.
WEB-прокси также не восстановит недоступный webhook и не поможет загрузить Mini App, если проблема возникла с доменом самого веб-приложения.
Это не недостаток новой технологии. Просто WEB-прокси решает задачу доступности клиента, а не отказоустойчивости сторонней инфраструктуры.
Что по-прежнему остаётся на стороне разработчика
Для long polling нужно отдельно контролировать доступность Bot API и задержку получения обновлений.
Для webhook полезно отслеживать через getWebhookInfo как минимум:
pending_update_count;
last_error_date;
last_error_message.
Обработку обновлений лучше делать идемпотентной: если webhook отвечает кодом вне диапазона 2xx, Telegram повторяет доставку. А слепой повтор исходящих методов вроде sendMessage, наоборот, способен создать дубли.
Получается, фраза «Telegram у пользователя открылся» ещё не означает, что бот, webhook и Mini App тоже работают.
Подскажите, держите ли для Bot API резервный egress или HTTPS-прокси? И состояние webhook вы контролируете через getWebhookInfo или ограничиваетесь метриками самого приложения?
Биржа Инфостарта: новые задачи по 1С за 20-26 августа
На Бирже заказов Инфостарта опубликованы новые проекты для разработчиков и консультантов 1С. В подборке за 20–26 августа - интеграции, перенос данных, доработка отчетов, складские решения и работа со старыми конфигурациями.
☕ JDBC и Spring JDBC — основы работы с БД без абстракций. ☕ JPA и Hibernate — что такое ORM, persistence context и как это работает внутри. ☕ Spring Data JPA vs Spring Data JDBC — различия репозиториев и критерии выбора. ☕ MyBatis и jOOQ — почему выбирают SQL-центричные фреймворки ради полного контроля. ☕ Альтернативные реализации JPA — что кроме Hibernate. ☕ Reactive Data Access — когда нужен R2DBC, а когда достаточно JDBC. ☕ Как выбрать фреймворк — сценарии, компромиссы и рекомендации.
📆 Когда: 31 августа в 16:00 (Мск)
🙍♂ Спикер: Александр Краснянский, эксперт в Java/Kotlin и архитектуре ПО
Что подтянуть бэкендеру для продакшена: 12 практических открытых уроков
Когда приложение выходит за пределы локальной машины, появляются задачи, которые редко помещаются в документацию одного фреймворка: блокировки, очереди, конкурентность, производительность и отказоустойчивость.
В подборке — бесплатные занятия, где эти проблемы разбирают через реальные инструменты и сценарии, с которыми бэкендер сталкивается в работе.
Очереди и надёжная доставка
26 августа, 20:00. «Работа с Kafka через библиотеку Kafka Clients». Записаться
17 сентября, 20:00. «RabbitMQ в Production: Transactional Outbox, идемпотентность и DLQ в ASP.NET Core». Записаться
Базы данных и конкурентный доступ
1 сентября, 20:00. «PostgreSQL 18: асинхронный I/O и io_uring на практике». Записаться
8 сентября, 20:00. «Борьба с блокировками в PostgreSQL: как достичь высокой параллельности при большой нагрузке». Записаться
16 сентября, 20:00. «Темпоральные данные в PostgreSQL 18: история и версии без триггеров». Записаться
Нагрузка и производительность
3 сентября, 20:00. «ASP.NET Core API под нагрузкой: как сделать сервис устойчивым к сбоям и росту трафика». Записаться
9 сентября, 20:00. «Go‑профилирование: как найти и исправить „тормоза“ в продакшене». Записаться
22 сентября, 20:00. «Горутины и каналы: под капотом (under the hood) и нюансы в продакшене». Записаться
HTTP и серверная разработка
21 сентября, 20:00. «HTTP‑сервер на чистой Java за 30 минут». Записаться
20 октября, 19:00. «Балансировка HTTP и L4 сервисов в Angie». Записаться
Продакшен и наблюдаемость
23 сентября, 20:00. «eBPF: рентгеновское зрение для production». Записаться
23 сентября, 20:00. «Узнайте, как использовать Patroni для управления высокодоступными кластерами PostgreSQL». Записаться
ЧТО ПОЧИТАТЬ БЭКЕНД‑РАЗРАБОТЧИКУ
Если удобнее разбираться в теме в своём темпе, собрали несколько практических материалов: про серверы, обновление стека, обработку ошибок и тонкости C++.
Type-driven development в Rust, часть 2/5: как доверить компилятору проверку контрактов между компонентами
Продолжаем серию о type-driven development в Rust — подходе, при котором правила предметной области выражаются в типах, а код, нарушающий эти правила, не компилируется. Рассказывает Никита Тимофеенко, разработчик команды MXDR компании F6.
В первой части типы отвечали за данные: какие значения возможны, какие комбинации допустимы, в каком порядке идут переходы. Но кроме данных в программе есть компоненты, которые общаются между собой, и у каждой такой границы есть контракт. Вторая часть посвящена тому, как записать эти контракты в типах, чтобы их нарушение не компилировалось.
После неё вы сможете найти в своём коде enum с match на каждом вызове, который на самом деле изображает открытый набор реализаций, и заменить его трейтом; отличить в контракте вход от выхода и перестать делать параметром трейта то, что должна выбирать реализация; поднять в тип размеры, которые известны ещё до запуска.
Во второй статье представлены три механизма, каждый разобран по той же схеме «проблема -> решение -> хорошие практики -> как это используют известные крейты или std библиотека»:
traits — контракт вместо конкретной реализации: код-потребитель требует поведение, а не тип, и работает с любым, кто его реализовал; новая реализация — это новый impl, а не правка общего кода;
associated types — типы, которые выбирает реализация, а не вызывающий: у каждой реализации свои типы результата и ошибки, и в один общий тип они не сводятся. Разница между параметром трейта и ассоциированным типом — это разница между входом и выходом;
const generics — значение как параметр типа: размер известен компилятору, а не хранится в рантайме, и структуры разного размера — разные типы. Что можно и чего нельзя в const-параметрах на стабильном Rust.
Отдельно рассмотрим CGP (Context-Generic Programming): что делать, когда одному типу нужно несколько реализаций одного трейта, а правило когерентности разрешает одну — и как одна и та же логика собирается под разные контексты без dyn и без match.
Примеры — из биржевой торговли, как и во всей серии, но приёмы работают в любом домене со сложными состояниями и правилами их изменения. Словарь типов продолжает часть 1.
Вторая статья «Type-driven development в Rust. Часть 2/5: задаём контракты между компонентами»уже на GitHub. Там же — компилируемые примеры ко всем приёмам, включая compile_fail-тесты на каждое «это не скомпилируется» из текста.
Как выстроить аварийное восстановление в гибриде и мультиоблаке. Вебинар Хайстекс
Привет, Хабр! Гибридная инфраструктура дает гибкость в штатном режиме, но превращается в хаос при серьезном сбое. Когда в едином контуре связаны локальные серверы, облака и унаследованный сегмент, обычный бэкап перестает гарантировать понятные сроки восстановления.
26 августа в 11:00 (МСК) команда Хайстекс проведет вебинар. Эксперты разберут, почему в гибридной инфраструктуре недостаточно просто настроить бэкап, и покажут на практике, как в Хайстекс Акура выстраивать сценарии восстановления для разрозненных платформ и площадок.
Что обсудим:
где чаще всего ломаются бэкап и репликация – сеть, окна копирования, ручные операции, ограничения площадок;
когда достаточно резервной копии, а когда уже нужен полноценный DR-сценарий;
почему заявленные RTO/RPO без тестовых восстановлений мало что значат;
как организовать восстановление между разными площадками и платформами.
После основной части спикеры проведут Q&A-сессию: можно принести архитектуру своего контура в чат и получить разбор от инженеров Хайстекс.
Как не отставать от технологий, не изучая всё подряд: 14 открытых уроков на этой неделе
Когда в работе появляется новая задача, часто выясняется, что привычных инструментов или знаний уже недостаточно. Но разбираться во всём подряд долго — важнее быстро найти нужный подход, проверить его на практике и понять, как применить в своём проекте.
На этой неделе на открытых уроках OTUS разбираем задачи из разработки, инфраструктуры, AI и ML, аналитики, тестирования и других направлений — чтобы увереннее решать рабочие задачи и двигаться дальше в профессии.
Все занятия бесплатные, а проводят их преподаватели‑практики, которые работают с этими технологиями и задачами каждый день. Чтобы присоединиться, достаточно выбрать интересную тему и зарегистрироваться.
Больше открытых вебинаров и практических занятий — в дайджесте.
Зачем ускорять разработку? Просто через раз вижу этот вопрос, во всех постах про агентов и новую эру автоматического кодинга. Переубедить конечно никого не получится, но написать надо, чтобы получилось структурировано. Погнали.
Нет такого количества задач
Если вы поговорите не с менеджерами, а владельцами бизнесов, то окажется, что количество идей у них такое, что за всю жизнь не сделать. То что из этого не всегда доходит до низов, проблема размера и процессов, которые тоже пытаются решать, поэтому так много разговоров про sdd и аналогичные истории.
Если разработка стала в два раза дешевле/быстрее, становятся экономически оправданными задачи, которые раньше вообще не попадали в backlog.
Это никому не нужно
В конкурентном мире невозможно сделать продукт до конца и сидеть сложа руки. А конкуренция приводит еще к тому, что кто первый встал, того и тапки. Сегодня вы на высоте, завтра ваш бизнес угрохали потому что вы не успели адаптироваться.
Ну если вы работаете у монополиста/госа/стратегического игрока, то можете игнорировать этот пункт :)
Фичи не принесут деньги
Может принесут, а может и нет, это невозможно обобщать не зная конкретных обстоятельства конкретных ситуаций. Например мы годами не могли сделать b2b кабинет таким как хотели наши клиенты, потому что у нас никогда не хватало ресурсов на эту часть. С помощью агентов мы это сделали и смогли получить хорошие контракты, которые от нас раньше уплывали.
Ускорение разработки меняет не только скорость выполнения уже выбранных задач, но и сам набор задач, которые становится рационально делать.
Покажите как это сократило фот?
По правде говоря у многих сократило. Но последовательность другая. Последние годы у многих были сокращения по экономическим причинам, а потом заморозка найма при одновременном росте производительности за счет ИИ. Поэтому ии больше повлиял не на сокращение как таковое, а на отсутствие найма
Покажите как это увеличило прибыль?
В экономике есть только два способа растить маржинальность: рост производительности и повышение цены. Когда то массовое внедрение компьютеров и экселя привело к такому же эффекту.
Итого
Ускорение разработки само по себе не цель. Реальная цель это снизить стоимость изменения продукта, поэтому помимо разработки одновременно ускоряется еще много всего, но об том просто говорят в других местах, куда разработчики не ходят, поэтому у них часто складывается такое одностороннее представление о происходящем
Если вы пользуетесь ИИ-агентами для написания кода, ты наверняка замечали: они генерируют код быстро, но не всегда следуя единному стилю или лучшим практикам.
Недавно я познакомился с безумно хорошим инструментом для улучшения качества вашего питоновского кода - wemake-python-styleguide
Изначально проект позиционировался как простой плагин для flake8, но с куда большим количеством правил, он стал настолько большой что его нужно воспринимать как полноценный линтер. Кстати, он полностью совместим со ВСЕМИ правилами от ruff. И что важно, его развивает core-разработчик CPython — Никита Соболев.
Я считаю, что каждую ошибку, который он подсвечивает, это не чья-то прихоть, а реальный опыт поддержки самого языка. При этом линтер не перегибает палку: нарушения объясняются. Например, если ваш агент написал if x > 42 линтер выдаст ошибку WPS432 («magic number used»). Достаточно вызвать wps explain WPS432 (или отправить MCP-запрос), и вы получите развёрнутое пояснение, почему магические числа это плохо, и как их заменить на константу, кстати именно в новой версии появилась эта функциональность, теперь объяснения приходят прямо в контекст агента, плюс появились скиллы. Вообщем сделано так, чтобы улучшать код и не раздражать разработчика :)
На площадке Nexign был максимально инженерный день. Ни грамма AI, только бэкенд, цифры и оптимизация. Слушали два доклада про экономику кода и производительность, а потом разбирали реальные кейсы на живом круглом столе.
Смотри влог, чтобы погрузиться с головой в этот вечер.
P.S. В нашем TG-канал рассказываем о технических мероприятиях и конференциях, делимся выступлениями экспертов, обсуждаем подборки на технические и ИБ темы.
3 неочевидных open source инструмента для разработки в облаке
Собрали инструменты, о которых не так часто говорят, но они закрывают конкретные боли dev-команд в облаке.
🖥️ Cреды разработки
Coder. Спасает, когда нужно, чтобы вся команда работала в идентичных окружениях, новые воркспейсы не требовали длительных настроек, а код при этом не покидал контур компании.
➕ Управляющий слой открыт целиком, воркспейс описывается как код на Terraform, есть аудит-логи и поддержка ИИ-агентов в изолированных рабочих окружениях.
➖ Docker Hub закрыт для российских IP — образы нужно тянуть через собственное зеркало на Harbor/Nexus или GHCR-прокси.
Альтернативы:
DevPod. Если маленькая команда или нужна гибкость по вендору. Инструмент работает как чистый CLI вообще без сервера, единообразие окружений обеспечивается через конфиг devcontainer.json, но централизованного управления нет.
Eclipse Che.Если у команды уже есть Kubernetes-кластер и нужна полноценная K8s-native среда. Также подходит тем, кто работает в экосистеме Red Hat / OpenShift.
🔑 Хранение секретов и разграничение доступов
OpenBao. Есть смысл внедрять, когда секреты уже расползлись по переменным, .env-файлам и табличкам в общем доступе, и теперь это добро трудно найти аудировать, легко потерять и невозможно безопасно ротировать. Инструмент позволяет собрать управление в одном контуре и применять единые политики доступа.
➕ Полностью открытая лицензия (MPL 2.0), можно не только использовать, но и перепродавать в составе других коммерческих продуктов; поддерживает и статические, и динамические секреты, есть PKI для выпуска X.509-сертификатов.
➖ Развертывание и обновления требуют дисциплины, нужны внутренние зеркала container images, helm-чартов и исходников, чтобы поставка не зависела от доступности внешних registry и Git-hosting.
Альтернативы/дополнения:
Infisical. Хороший выбор, если в приоритете удобство для разработчиков и более широкий продуктовый контур вокруг секретов. Еще он удобнее всего для работы с учетными данными ИИ-агентов.
External Secrets Operator. Не замена OpenBao, а Kubernetes-слой для доставки секретов. Он забирает значения из внешнего хранилища: OpenBao, Infisical, AWS Secrets Manager или любого другого бэкенда — и синхронизирует их в нативные Kubernetes Secrets внутри кластера. Стоит выбирать, когда приложения уже живут в Kubernetes и нужен GitOps-подход, когда в Git хранятся только ссылки на секреты и политики доступа, а сами значения остаются в защищенном хранилище (HashiCorp Vault, OpenBao) и никогда не попадают в репозиторий.
🚩 Флаги фич
GO Feature Flag. Выручает, когда нужно безопасно выкатывать фичи без передеплоя. Ну, или мгновенно вернуть как было, не трогая инфраструктуру.
➕ Легкая библиотека флагов на базе стандарта OpenFeature, работает встроенно в приложении или как промежуточный прокси-сервис. Конфиг может хранится в YAML-файле, в Git (даже self-hosted без привязки к GitHub), также можно держать в S3 или Redis. MIT-лицензия, минимум внешней инфраструктуры. ➖ Маленькое коммьюнити, мало готовых интеграций, а поддержка держится на GitHub Issues, доступность которых в РФ нестабильна.
Альтернативы:
Unleash. Если флаги больше нужны инженерам для безопасных раскаток и управления циклом изменений.
Flagsmith. Если кроме включения/выключения функций нужны продуктовые сценарии, например, сегментация пользователей или A/B-тесты.
Не будем скромничать, у нас тоже есть свое open source решение: фильтр для доступа к внешним нейросетям, которое, во-первых, позволяет использовать LLM (в том числе для кодинга), не сливая туда чувствительную инфу, а во-вторых, не ломает при этом вызов функций. Как мы этого добились, рассказывали в статье. Забирайте в свой контур, открывайте pull request’ы, оставляйте issuе — мы открыты к обратной связи.
AI-аналитик, MCP-сервер и GenAI-трейсы: что появилось в Proto Observability Platform 203
Главной темой релиза Proto Observability Platform 203 стало расширение инструментов для анализа телеметрии и наблюдаемости LLM-приложений: к существующим ИИ-расследованиям добавились AI-аналитик для работы с телеметрией на обычном языке, MCP-сервер для подключения ИИ-агентов и представление GenAI-трейсов для анализа работы внешних LLM-приложений.
AI-аналитикработает с метриками, логами, трейсами, инцидентами и ресурсно-сервисной моделью. В ответе он показывает затронутые сервисы, возможные причины проблемы и ссылки на найденные объекты платформы. Для анализа данных в платформе теперь не требуется знание PromQL, LogsQL или топологии приложений - все это теперь можно запрашивать в режиме чата на обычном языке.
Встроенный MCP-серверпредоставляет ИИ-агентам инструменты для работы с данными платформы по стандарту Model Context Protocol. Через него доступны метрики, логи, события, ресурсы, трейсы, сервисы, алерты и инциденты.
Новое представление GenAI-трейсов показывает выполнение LLM-приложения как последовательность действий. На одном экране видны сообщения по ролям, обращения к модели и инструментам, ошибки вызовов и длительность отдельных шагов.
Полное описание этих и других новых возможностей платформы доступно в заметках к релизу.
Собрали курс «Современный Gradle для Java-разработчика». Если Gradle для вас до сих пор воспринимается магической коробкой, которая путём магических конфигураций собирает проект, а что-то новое в неё вносится только через Claude Code или Codex, это для вас.
Курс рассчитан на тех, кто уже пишет на Java/Kotlin или каком-то другом JVM-языке и хочет перестать бояться строгать сборку лишний раз. Разбираем мультимодульные проекты с нуля, копаемся по compile classpath и смотрим на современные подходы к конфигурации.
Каждый урок начинаем с небольшой теории, а потом развлекаемся на лайвкодинге.
Биржа Инфостарта: новые задачи по 1С за 12-18 августа
На Бирже заказов Инфостарта появиись новые задачи для специалистов по 1С, опубликованные с 12 по 18 августа. В этот раз заказчики ищут помощь с обновлением конфигураций, обменами, отчетами и обработками, ЭТрН, складским оборудованием и нестандартными сценариями учета.
На этой неделе особенно заметны задачи для тех, кто работает с торговыми и бухгалтерскими конфигурациями, поддерживает обмены и интеграции, умеет разбираться в нетиповых решениях и подключается к небольшим точечным доработкам. Для исполнителей такая подборка — быстрый способ найти подходящую задачу без долгого поиска. Для заказчиков — ориентир по тому, какие специалисты уже работают на Бирже и на какие задачи можно найти исполнителя.
На Бирже заказов Инфостарта можно напрямую общаться с исполнителями, сравнивать отклики, рейтинг и опыт. Комиссии за работу нет, а при необходимости можно использовать безопасную сделку.
AI-аналитик, MCP-сервер и GenAI-трейсы: что появилось в Proto Observability Platform 203
Главной темой релиза Proto Observability Platform 203 стало расширение инструментов для машинного анализа телеметрии и наблюдаемости LLM-приложений: к существующим ИИ-расследованиям добавились AI-аналитик для работы с данными телеметрии на обычном языке, MCP-сервер для подключения ИИ-агентов и представление GenAI-трейсов для анализа работы внешних LLM-приложений.
AI-аналитикработает с метриками, логами, трейсами, инцидентами и объектами ресурсно-сервисной модели. В ответе на запросы оператора он показывает затронутые сервисы, возможные причины проблем и ссылки на найденные объекты платформы, сам проводит анализ ключевых данных производительности приложений и инфраструктуры. Для анализа данных в платформе теперь не требуется знание PromQL, LogsQL или топологии приложений - все это теперь можно запрашивать в режиме чата на обычном языке.
Встроенный MCP-серверпредоставляет ИИ-агентам инструменты для работы с данными платформы по стандарту Model Context Protocol. Через него доступны метрики, логи, события, ресурсы, трейсы, сервисы, алерты и инциденты, ошибки и другие ключевые данные платформы.
Новое представление GenAI-трейсов показывает выполнение LLM-приложения как последовательность действий. На одном экране видны сообщения по ролям, обращения к модели и инструментам, ошибки вызовов и длительность отдельных шагов.
Полное описание этих и других новых возможностей платформы доступно в заметках к релизу.
Можно ли быстро актуализировать старые PHPUnit-тесты под новые версии пакета?
Краткий ответ: да, но есть нюансы.
На Хабре незаслуженно мало статей про инструмент Rector, и даже в них совсем вскользь упоминается, что у инструмента есть отдельный функционал для актуализации PHPUnit-тестов, написанных под разные версии пакета. Причем если раньше, этот функционал был в виде отдельного пакета rector-phpunit, то на сегодня (для версии 2.6.3) этот функционал уже входит в состав основного пакета.
Итак, у нас были тесты написанные в разное время разными разработчиками под версию PHPUnit, которая была установлена при создании проекта. Вопрос о её обновлении поднимался регулярно, но оценка стоимости актуализации нескольких сотен файлов с несколькими тысячами тестов была довольно большой, пока не появилась возможность сделать это автоматически.
Как шло обновление: - установили пакет rector/rector - обновили пакет phpunit - сделали файл конфига rector.php в котором прописали наборы правил - запустили сначала в режиме vendor/bin/rector process --dry-run. Увидели, что аннотации @dataProvider не мигрировали в атрибуты #[DataProvider], а сами методы, на которые указывают dataProvider не стали статическими (требования PHPUint 10+). Добавили необходимые правила в конфиг rector.php и в при первом приближении всё сработало как нужно:
<?php
declare(strict_types=1);
use Rector\Config\RectorConfig;
return RectorConfig::configure()
// Путь к директории с тестами
->withPaths([
__DIR__ . '/tests',
])
// Включаем синтаксис PHP 8.4
->withPhpSets(php84: true)
// Правила берем для версии phpunit из composer.json
->withComposerBased(
phpunit: true
)
// Общие наборы правил для улучшения качества тестов
->withPreparedSets(
phpunitCodeQuality: true
)
// Явно запускаем встроенное правило миграции аннотаций PHPUnit в атрибуты
->withAttributesSets(
phpunit: true
);
Но и после этих инструкций не все методы dataProvider стали статическими. Основные причины были в следующем: - использование $this в методах dataProvider - коллизии из-за последовательности выполнения правил рефакторинга в Rector
Что помогло исправить ситуацию: 1. повторный запуск vendor/bin/rector process позволил правилам повторно пройтись по уже исправленным файлам и доделать изменения 2. использование ссылки на текущий объект в методах dataProvider плохая практика, от неё отказались
Немного философии Rust, возможно кому то интересно обсудить
Уже почти 3 месяца пишу проект на Rust. Сейчас разработка стала другой, ручная работа стала роскошью, реальные задачи бизнеса быстрее решить LLM-ками. Естественно познание языка в таком режиме замедляется, хочется как-то компенсировать, хотя бы поговорить об этом.
Вот какой аспект. В Rust уровень владения/заимствования объектом - часть контракта. По большому счету можно составить примерно такую таблицу (на самом деле это дерево должно быть, но для упрощения привожу плоскую таблицу):
Просто владею объектом → T
Временно читаю чужой объект → &T
Временно изменяю чужой объект → &mut T
Один владелец, нужна куча → Box
Несколько владельцев, один поток, чтение → Rc
Нужны несколько владельцев, один поток, изменение → Rc<Cell> / Rc<RefCell>
Несколько владельцев, несколько потоков, чтение → Arc
Несколько владельцев, несколько потоков, изменение → Arc<Mutex> / Arc<RwLock>
По сути чем более строгий уровень доступа (или какой термин тут лучше?) - тем больше проверок сможет сделать компилятор. Если используете Rc - то уже потенциально возможны циклические ссылки и утечка памяти (с Box - это не возможно). Если RefCell - то компилятор не сможет проверить два borrow_mut() одновременно - будет рантайм проверка или паника.
И вот какая фишка. Часто LLM-ка дает уровень больше чем нужно. Как-то где можно обойтись ссылкой - добавит Rc<RefCell>. Т.е., по сути, код то рабочий, но лишние обертки и послабление компил-тайм проверок немного угнетают.
Но иногда бывает оправданно, когда в процессе уровень нужно ослабить, т.к. не всегда предусмотришь на этапе проектирования.
И далее возникла философская идея. А вот неплохо бы чтобы компилятор сам решал какой уровень применять. Т.е. начинаем от самого малого, если его не достаточно - то использует послабления. Если достаточно классической проверяемой ссылки - то использовать ее. Или если нужно множественное владение, но точно нет потоков - то Arc можно не использовать - достаточно Rc (если нет данных то ослабляем - берем Arc).
При этом все еще остаемся в рамках языка без GC - но вместо ручного выбора - выбор осуществляется компилятором при сборке.
Коннекторы 1С: быстрая интеграция через OData в Digital Q.Integration
Интеграция с решениями 1С остается одной из наиболее востребованных задач в построении корпоративных ИТ-ландшафтов. При этом разработка и сопровождение интеграционных решений зачастую требуют значительных временных и трудовых затрат.
На вебинаре эксперты компании «Диасофт» расскажут, как организовать обмен данными между 1С и внешними системами с помощью готового коннектора платформы Digital Q.Integration, реализованного на базе протокола OData. Вы узнаете, какие подходы для интеграции с 1С существуют, почему именно OData выбран в качестве технологической основы решения и какие преимущества это дает при построении современных интеграционных процессов.
Во время демонстрации покажем, как:
настроить подключение к 1С с помощью коннектора Q.Integration;
получать данные из 1С;
добавлять/изменять данные в 1С;
автоматизировать интеграционные процессы средствами платформы Digital Q.Integration.
Программа
13:00 – 13:10 Введение. Почему интеграция с 1С остается актуальной задачей и какие подходы используются для ее реализации.
13:10 – 13:25 Подходы к интеграции с 1С. Рассмотрим основные способы организации обмена данными, сравним интеграцию через OData и использование специализированных конфигураций 1С, разберем преимущества и ограничения каждого подхода.
13:25 – 13:40 Коннектор 1С в Digital Q.Integration. Расскажем, как реализован коннектор, какие процессы автоматизированы, как устроена работа с OData и какие возможности получает пользователь при настройке интеграции.
13:40 – 13:55 Практическая демонстрация. Покажем настройку коннектора, получение данных из 1С и изменение.
13:55 – 14:00 Вопросы и ответы. Ответим на вопросы участников и обсудим практические кейсы использования коннектора.
Кому полезен вебинар:
ИТ-директорам и техническим руководителям;
архитекторам интеграционных решений;
руководителям проектов цифровой трансформации;
разработчикам и интеграторам;
специалистам по сопровождению корпоративных информационных систем.
Спикеры:
Виктор Овчинников, руководитель продукта Digital Q.Integration компании «Диасофт»
Андрей Даниленко, ведущий разработчик MSA департамента «Цифровые решения» компании «Диасофт»
