Tune IT

Проверяем SSO сессию в открытой вкладке

2026-09-09T16:19:25Z

В одном из проектов мне понадобилось отслеживать состояние SSO-сессии на уже открытой странице. Пользователь выходит из SSO через другое приложение, а наш фронт продолжает показывать прежний интерфейс. Хотелось, чтобы страница сама узнавала об изменении и подтягивала актуальное состояние пользователя.

Механизм описан в OpenID Connect Session Management 1.0. Дальше расскажу, как я встраивал этот механизм в проект на React и Django с Keycloak.

Как я это реализовал

Авторизация в приложении уже работала: браузер уходил в Keycloak, возвращался на callback, backend создавал Django сессию. Полученный при входе session_state сохранялся на сервере. Его и предстояло передавать на фронт для последующих проверок.

На фронте я вынес мониторинг в отдельный React-компонент SsoSessionManager. Он подключается при наличии авторизованного пользователя, ничего не рисует и управляет двумя скрытыми iframe. Один живёт всё время работы manager, второй появляется только для уточнения состояния сессии. Авторизация и работа с токенами оставались на бэкенде, а фронту требовались конфигурация проверки и её результат.

Чтобы фронт мог получить контекст мониторинга, а backend - отдельно от обычного логина уточнить SSO-сессию и обработать результат, я добавил три новые ручки: GET /api/auth/sso-session отдаёт конфигурацию и сохранённый session_state, GET /auth/sso-session/start подготавливает временный флоу авторизации и перенаправляет iframe в Keycloak, а GET /auth/sso-session/callback обрабатывает ответ Keycloak и возвращает HTML во временный iframe. Скрипт этого документа передаёт результат проверки родительской странице через postMessage.

Постоянный iframe загружает login-status-iframe.html из Keycloak. После загрузки SsoSessionManager отправляет в него через postMessage строку client_id + " " + session_state. Пока вкладка скрыта, опрос SSO приостанавливается, а при возвращении проверка запускается снова. Всего, при опросе SSO, может вернуться 3 состояния: При unchanged продолжаем проверять. При changed останавливаем опрос и создаём временный iframe с адресом /auth/sso-session/start. Сам по себе changed ещё не сообщает, нужно ли завершать локальную сессию, поэтому дальше разбирается backend. При error manager отключает мониторинг для текущей страницы.

Ручка /start проверяет локальную сессию, создаёт одноразовые state и nonce, сохраняет ожидаемого пользователя. Затем перенаправляет временный iframe на авторизационную ручку Keycloak с prompt=none. Этот параметр запрещает показывать форму логина и другие интерактивные экраны. Keycloak пытается выполнить запрос на основе уже существующего входа в браузере: если это возможно, возвращает code, но если нужно участие пользователя, то возвращает ошибку. Для нас это способ уточнить состояние SSO в скрытом iframe, не уводя пользователя с открытой страницы и не заставляя его снова вводить пароль.

Чтобы уточнить состояние входа в Keycloak без участия пользователя, SsoSessionManager задаёт временному iframe src="https://www.tune-it.ru/auth/sso-session/start". Браузер проходит внутри этого iframe цепочку редиректов для проверки входа в Keycloak, а /auth/sso-session/callback отдаёт небольшой HTML со скриптом, вызывающим window.parent.postMessage, который отправляет результат родительской странице.

Когда Keycloak возвращает code на /auth/sso-session/callback, Django обменивает его на токены отдельным серверным запросом. Backend делает необходимые проверки, затем сверяет sub с ожидаемым и текущим локальным пользователем. Если пользователь тот же, то сохраняется новый session_state. Инные случаи приводят к завершению локальной сессии. SsoSessionManager проверяет origin, окно-источник и структуру сообщения. Если пришёл session_updated, забирает новый session_state, удаляет временный iframe и возобновляет опрос SSO. Если logged_out - отключает мониторинг и обновляет страницу.

Продвинутая типографика в вебе, как делать текст быстрым и красивым

2026-09-08T21:07:57Z

Каждый, кто пользуется интернетом, сталкивался с ситуацией, когда текст на сайте сначала показывается одним шрифтом, а через секунду «прыгает», меняя размер и положение, когда подгружается «правильное» начертание. Или страница вовсе отказывается показывать текст, пока не загрузятся все шрифты. Подобные сценарии не просто раздражают — они разрушают пользовательский опыт, портят поведенческие метрики и заставляют людей уходить, так и не дождавшись содержимого.

Типографика в вебе — это всегда компромисс между красотой и скоростью. Между тем, как вы хотите, чтобы выглядел ваш проект, и тем, как быстро он будет загружаться.

Вариативные шрифты: Один файл вместо двадцати

Раньше, чтобы использовать шрифт в разных начертаниях, нужно было подключать отдельные файлы: Roboto Regular, Roboto Bold, Roboto Italic, Roboto Bold Italic… И так для каждого веса и стиля. Это создавало кучу HTTP-запросов и заставляло пользователя скачивать мегабайты данных. Вариативные шрифты решили эту проблему кардинально.

Один файл — и внутри него все варианты: от самого тонкого до самого жирного, от узкого до широкого, с курсивом и без. Это дало колоссальную свободу. Вы больше не привязаны к фиксированным значениям вроде 400 или 700. Хотите вес 437? Пожалуйста. 582? Без проблем. Вы можете плавно менять толщину шрифта в зависимости от контекста, создавая более тонкую и выразительную типографику.

Технически это работает через так называемые «оси вариаций» — параметры, которые можно настраивать. Основные оси стандартизированы: это вес (wght), ширина (wdth), и курсив (ital). Но производители шрифтов могут добавлять и свои, уникальные оси — например, для изменения наклона или даже размера засечек.

Важный нюанс: если вы подключаете вариативный шрифт, в CSS вам не нужно указывать конкретный вес при загрузке. Вместо weight: '400' вы просто пишете weight: 'variable', а затем используете свойство font-variation-settings, чтобы управлять всеми доступными осями. Это невероятно гибко и мощно.

Модульные шкалы и математика текста

Красивая типографика не рождается из хаоса. Она подчиняется математике. В основе лежит понятие модульной шкалы — последовательности чисел, где каждое следующее получается из предыдущего путем умножения на постоянный коэффициент. Например, коэффициент 1.25 даёт малую терцию, 1.333 — чистую кварту, а 1.618 — знаменитое золотое сечение.

Зачем это нужно? Чтобы все размеры текста на вашем сайте — от самого маленького подписи до огромного заголовка — были ритмически связаны друг с другом. Глаз чувствует эту гармонию, даже если вы не можете объяснить её словами. Это создает ощущение цельности и профессионализма.

Современные инструменты позволяют автоматизировать этот процесс. Например, есть специальные утилиты, которые генерируют CSS-переменные для каждого шага шкалы, а заодно добавляют к ним плавную адаптивность . Задача дизайнера — не считать вручную, а выбрать правильное соотношение и проверить, насколько хорошо оно работает в контексте проекта.

Адаптивная типографика: Когда текст сам знает, где находится

Помните старый добрый способ: для мобильных экранов — один размер, для планшетов — чуть больше, для десктопов — ещё больше? Это работало, но с одним недостатком: на промежуточных размерах, между вашими брейкпоинтами, текст выглядел либо слишком маленьким, либо слишком большим.

Современный подход — жидкая типографика (fluid typography) на основе CSS-функции clamp(). Вместо того чтобы задавать фиксированные значения для разных разрешений, вы определяете диапазон: минимальный размер, максимальный размер и скорость изменения между ними.

Например, вы пишете: font-size: clamp(1rem, 2vw + 0.5rem, 2.5rem). Это значит: «На маленьких экранах размер будет не меньше 1rem, на больших — не больше 2.5rem, а между ними он будет плавно меняться в зависимости от ширины окна». Текст не делает резких скачков. Он словно «дышит» вместе с экраном.

Некоторые системы идут дальше. Они генерируют целые шкалы clamp() — для каждого типографического уровня, от самого маленького до самого большого. И делают это не только для размера шрифта, но и для интерлиньяжа, отступов, ширины колонок . Результат — интерфейс, который выглядит одинаково гармонично на любом устройстве: от маленького телефона до огромного 4K-монитора.

Загрузка шрифтов: Битва с FOUT и FOIT

Самая большая боль веб-типографики — это то, как браузер ведёт себя, пока шрифт не загрузился. Здесь у нас два злодея:

FOIT (Flash of Invisible Text) — текст не показывается вообще. Вы видите пустую страницу с картинками, но без единой буквы. Это ужасно для пользовательского опыта .
FOUT (Flash of Unstyled Text) — текст показывается системным шрифтом (например, Arial), а потом, когда загружается ваш красивый шрифт, он «перепрыгивает». В этот момент может произойти смещение макета, потому что размеры шрифтов отличаются . Это бьёт по показателю Cumulative Layout Shift (CLS) в Core Web Vitals.

И то, и другое плохо. Спасает нас свойство font-display. Его можно задать внутри @font-face. Вариантов несколько:

swap — показывает системный шрифт сразу, а когда загрузится ваш — заменяет его. Это даёт быстрый FCP (First Contentful Paint), но вы рискуете получить FOUT и смещение.
fallback — даёт браузеру 100 миллисекунд на ожидание (текст скрыт), потом показывает системный. Если через 3 секунды шрифт не загрузился — системный остаётся навсегда. Хороший компромисс.
optional — ещё более строгий вариант. Если шрифт не загрузился за 100 мс, он больше никогда не заменится. Это полностью предотвращает смещение, но ваш «красивый» шрифт может так и не появиться.

Самый надежный способ избежать проблем — использовать font-display: swap в сочетании с предзагрузкой (preload) критически важных шрифтов. Вы говорите браузеру: «Загрузи этот шрифт в первую очередь, он очень нужен». Это ускоряет загрузку, но злоупотреблять не стоит.

Кстати, современные фреймворки вроде Next.js решают эту проблему автоматически. Они сами хостят шрифты на вашем сервере, подгружают их на этапе сборки, а сгенерированный CSS использует технику size-adjust, чтобы системный шрифт и ваш шрифт занимали одинаковое пространство. Таким образом, даже до загрузки вашего шрифта нет смещения макета — текст просто «обновляется» внешне, но не дергается.

Практические шаги к идеальной типографике

Выбор шрифта. Отдавайте предпочтение вариативным шрифтам. Это даёт гибкость и экономию трафика. Используйте WOFF2 — самый сжатый современный формат.
Построение модульной шкалы. Используйте инструменты для генерации типографической шкалы с выбранным коэффициентом (например, малая терция 1.25 или идеальная кварта 1.333). Сгенерируйте CSS-переменные для каждого размера.
Адаптивность. Примените clamp() к вашим переменным. Не для всех сразу, а с умом: для заголовков — более широкий диапазон (чтобы они были действительно разными на большом и маленьком экране), для основного текста — более узкий.
Загрузка. Используйте font-display: swap. Предзагружайте только один-два самых важных шрифта — те, что сразу видны на первом экране. Остальные могут загружаться лениво.
Проверка. Обязательно смотрите на сайт через Lighthouse. Он подскажет, нет ли проблем с CLS или с тем, что текст остаётся невидимым.

Типографика — это не просто «выбрать красивый шрифт». Это сложная инженерная задача, которая требует понимания как эстетики, так и технологий. Но когда вы находите правильный баланс, текст на вашем сайте становится не просто читаемым, а по-настоящему живым: быстрым, плавным и гармоничным. И это то, что пользователи чувствуют, даже если не могут объяснить почему.

Полезные Maven/Gradle плагины для Liferay разработки

2026-09-07T15:38:55Z

Разработка корпоративных решений и интранет-порталов на базе Liferay требует управления сложной экосистемой, включая инициализацию серверов приложений, сборку различных модулей, работу с базой данных и REST-эндпоинтами. Чтобы ускорить разработку, Liferay предоставляет специализированный инструментарий в форме плагинов для популярных систем сборки, таких как Gradle и Maven. В этой заметке мы представим краткий обзор некоторых таких плагинов, которые позволяют автоматизировать рутинные операции и сделать процесс разработки эффективнее. Сегодня в нашей подборке 4 плагина

1. com.liferay.portal.tools.bundle.support

Представляет собой плагин для инфраструктуры, управления окружением и CI/CD. Реализует парадигму «Инфраструктура как код», позволяя избавиться от ручного скачивания архивов портала, распаковки и самостоятельного копирования конфигураций. Этот плагин берет под свой контроль весь жизненный цикл Liferay бандла. На основе указанного URL или версии плагин скачивает сборку сервера (например, Tomcat bundle) и кэширует архив в локальной файловой системе сборщика. Также плагин полностью очищает целевую директорию и разворачивает чистый инстанс Liferay, убирая все временные файлы, которые могут помешать деплою, исключая тем самым появление мусорных артефактов и кэша от старых запусков. Плагин также может накладывать файлы настроек (такие как portal-ext.properties или system-ext.properties) поверх чистого лайфрея в зависимости от выбранного профиля сборки (например, local, dev, test). Конфигурация разбивается на шаги (executions) в рамках конкретных фаз жизненного цикла (покажем пример для maven):

<project xmlns="http://apache.org" 
         xmlns:xsi="http://w3.org"
         xsi:schemaLocation="http://apache.org http://apache.org">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.example.liferay</groupId>
    <artifactId>liferay-workspace-project</artifactId>
    <version>1.0.0-SNAPSHOT</version>
    <packaging>pom</packaging>

    <properties>
        <liferay.portal.tools.bundle.support.version>3.7.10</liferay.portal.tools.bundle.support.version>
        <liferay.bundle.dir>${project.basedir}/bundles</liferay.bundle.dir>
    </properties>

    <build>
        <plugins>
            <plugin>
                <groupId>com.liferay</groupId>
                <artifactId>com.liferay.portal.tools.bundle.support</artifactId>
                <version>${liferay.portal.tools.bundle.support.version}</version>
                
                <executions>
                    <!-- Полная очистка перед сборкой новой среды -->
                    <execution>
                        <id>clean-local-bundle</id>
                        <!-- Привязываем к стандартной фазе clean -->
                        <phase>clean</phase>
                        <goals>
                            <goal>clean-bundle</goal>
                        </goals>
                    </execution>

                    <!-- Скачивание и разворачивание чистого Liferay Bundle -->
                    <execution>
                        <id>initialize-liferay-server</id>
                        <!-- Привязываем к фазе инициализации проекта -->
                        <phase>initialize</phase>
                        <goals>
                            <goal>init-bundle</goal>
                        </goals>
                        <configuration>
                            <!-- URL для загрузки дистрибутива -->
                            <bundleURL>your URL</bundleURL>
                            <!-- Куда распаковывать -->
                            <destDir>${project.basedir}</destDir>
                        </configuration>
                    </execution>

                    <!-- Деплой  -->
                    <execution>
                        <id>deploy-global-configs</id>
                        <!-- Выполняется на этапе валидации или перед деплоем модулей -->
                        <phase>validate</phase>
                        <goals>
                            <goal>deploy</goal>
                        </goals>
                        <configuration>
                            <bundleDir>${liferay.bundle.dir}</bundleDir>
                            <!-- Копируем кастомные конфиги -->
                            <configsDir>${project.basedir}/configs/local</configsDir>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</project>

Кроме того, возможно использование локального бандла (уже собранного), что особенно актуально при использовании Wildfly:

 <configuration>
        <appServerType>wildfly</appServerType>
        <appServerBundleDir>${project.basedir}/bundles/wildfly</appServerBundleDir>
        <!-- директория Liferay Home для этого бандла -->
        <liferayHome>${project.basedir}/bundles</liferayHome>
 </configuration>

2. com.liferay.portal.tools.service.builder

Представляет собой плагин для генерации слоя доступа к данным (Java-классы, интерфейсы, SQL-скрипты, Hibernate/Spring-конфигурации) на основе одного XML-файла описания. Создает интерфейсы и базовые реализации для сервисов, генерирует DDL, обновляет базу и многое другое:

<plugin>
    <groupId>com.liferay</groupId>
    <artifactId>com.liferay.portal.tools.service.builder</artifactId>
    <version>1.0.420</version>
    <executions>
        <execution>
            <id>generate-service</id>
            <!-- Привязываем генерацию к фазе generate-sources, до компиляции Java -->
            <phase>generate-sources</phase>
            <goals>
                <goal>build-service</goal>
            </goals>
            <configuration>
                <!-- Главный файл с описанием сущностей и базы данных -->
                <inputFile>${project.basedir}/src/main/resources/META-INF/service.xml</inputFile>
                
                <!-- Куда сгенерируются интерфейсы и DTO -->
                <apiDir>${project.parent.basedir}/my-app-api/src/main/java</apiDir>
                
                <!-- Куда сгенерируется бизнес-логика и реализация -->
                <implDir>${project.basedir}/src/main/java</implDir>
                
                <!-- Папка для генерации SQL-скриптов создания таблиц и индексов -->
                <sqlDir>${project.basedir}/src/main/resources/META-INF/sql</sqlDir>
                
                <!-- Включать ли генерацию REST/JSON веб-сервисов -->
                <buildRemoteService>true</buildRemoteService>
               
                <!-- Включать ли генерацию локальных Java-сервисов -->
                <buildLocalService>true</buildLocalService>

            </configuration>
        </execution>
    </executions>
</plugin>

Чтобы плагин сработал, ему нужен файл конфигурации, где разработчик декларативно описывает сущности базы данных и их связи. Плагин же создает сотни строк сопутствующего кода. Вот минимальный пример файла src/main/resources/META-INF/service.xml для таблицы БД:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE service-builder PUBLIC "-//Liferay//DTD Service Builder 7.4.0//EN" "http://liferay.com">

<service-builder dependency-injector="ds" package-path="com.example.myapp">
    <namespace>MYAPP</namespace>
    
        <!-- Первичный ключ -->
        <column name="bookId" type="long" primary="true" />
        
        <!-- Поля таблицы -->
        <column name="title" type="String" />
        <column name="author" type="String" />
        <column name="createDate" type="Date" />
        
        <!-- Индекс для быстрого поиска по автору -->
        <finder name="Author" return-type="Collection">
            <finder-column name="author" />
        </finder>
    
</service-builder>

3. com.liferay.portal.tools.rest.builder

Представляет собой плагин для генерации API (эндпоинты, схемы запросов/ответов). Разработчик описывает контракт своего API в стандартном формате OpenAPI (YAML), а плагин автоматически генерирует JAX-RS эндпоинты, DTO-модели, валидацию и Jackson-маппинг. Разработчику остаётся только написать бизнес-логику в классах реализации. Кроме того, плагин автоматически разворачивает эндпоинты в интерфейсе Swagger UI портала, делая API доступным для тестирования фронтенд-разработчиками сразу после деплоя бандла. Подключается так:

<plugin>
    <groupId>com.liferay</groupId>
    <artifactId>com.liferay.portal.tools.rest.builder</artifactId>
    <version>1.0.475</version>
    <executions>
        <execution>
            <id>generate-headless-api</id>
            <phase>generate-sources</phase>
            <goals>
                <goal>build</goal>
            </goals>
            <configuration>
                <!-- Базовая папка, где лежат YAML схемы (rest-config.yaml, rest-openapi.yaml) -->
                <baseDir>${project.basedir}</baseDir>
                
                <!-- Относительный путь к подмодулю API, куда попадут сгенерированные интерфейсы -->
                <apiDir>../my-headless-api/src/main/java</apiDir>
                
                <!-- Путь в текущем модуле, куда попадет реализация REST -->
                <implDir>src/main/java</implDir>
            </configuration>
        </execution>
    </executions>
</plugin>

Для генерации API требуются два файла в модуле:

rest-openapi.yaml -- стандартное описание путей, методов (GET/POST/PUT) и моделей данных по спецификации OpenAPI 3.0.

openapi: 3.0.0
info:
  title: "My Custom API"
  version: v1.0
paths:
  /todos:
    get:
      operationId: getTodosPage
      description: "Получить список задач"
      responses:
        200:
          description: "Успешный ответ"
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: "#/components/schemas/Todo"
components:
  schemas:
    Todo:
      type: object
      properties:
        id:
          type: integer
          format: int64
        title:
          type: string
        completed:
          type: boolean

rest-config.yaml -- служебный файл Liferay, задает метаданные плагина, включая базовые пакеты, автора и системный контекст для OSGi:

apiPackagePath: "com.example.headless.api"
author: "Liferay Developer"
clientDir: "../my-headless-client/src/main/java" # если нужен клиент
compatibilityVersion: "7.4.0"
implPackagePath: "com.example.headless.internal"
jaxRsApplicationBaseUri: "/my-custom-api"
jaxRsApplicationName: "MyCustomAPI"

4. com.liferay.css.builder

Представляет собой плагин, который компилирует файлы стилей Sass (.scss) в стандартный CSS. В экосистеме Liferay этот плагин критически важен при сборке кастомных тем оформления, а также при стилизации отдельных портлетов и UI-компонентов. Он автоматически подтягивает глобальные стили ядра Liferay, обрабатывает импорты, миксины, переменные и минифицирует итоговый код. То есть CSS Builder предстает как Java-обертка над компилятором Sass, полностью интегрированная в сборочные контейнеры Gradle и Maven. Подключение на примере Maven:

<plugin>
    <groupId>com.liferay</groupId>
    <artifactId>com.liferay.css.builder</artifactId>
    <version>3.1.2</version>
    <executions>
        <execution>
            <id>compile-sass-to-css</id>
            <!-- Привязываем компиляцию стилей к фазе генерации ресурсов -->
            <phase>generate-resources</phase>
            <goals>
                <goal>build</goal>
            </goals>
            <configuration>
                <!-- Директория, где лежат исходные файлы .scss -->
                <docRootDir>${project.basedir}/src/main/resources/META-INF/resources</docRootDir>
                
                <!-- Подкаталог внутри docRootDir, где непосредственно искать .scss файлы -->
                <inputDir>/</inputDir>
                
                <!-- Куда складывать скомпилированные .css файлы -->
                <outputDir>/</outputDir>
                
                <!-- Включать ли генерацию Source Maps для удобной отладки в браузере -->
                <generateSourceMap>true</generateSourceMap>
                
                <!-- Стили, которые нужно исключить из прямой компиляции  -->
                <compilerExcludes>**/_*.scss</compilerExcludes>
                
                <!-- Пути к сторонним Sass-библиотекам или темам -->
                <importPaths>
                    <importPath>${project.basedir}/src/main/resources/META-INF/resources/node_modules</importPath>
                </importPaths>
            </configuration>
        </execution>
    </executions>
</plugin>

Итог

В заключение отметим, что комбинация этих четырех плагинов закрывает базовые потребности команды разработки, обеспечивая автоматизацию проекта на всех уровнях: от инфраструктурного слоя до баз данных, сетевых интерфейсов и визуального отображения.

Введение в архитектуру ПО. Часть 2: Три парадигмы и сила ограничений

2026-09-02T02:20:28Z

Введение

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

Но у любого разговора об архитектуре есть неудобный момент. Рано или поздно кто-то спрашивает: хорошо, я согласен, что нужна низкая связанность и высокая согласованность - а как именно её получить? Что конкретно я должен делать завтра утром, открыв редактор?

Ответ начинается гораздо ниже уровня диаграмм и слоёв. Он начинается в коде.

Архитектура не существует отдельно от кода - она из него собирается. Границы между компонентами проводятся не в документации, а вызовами функций и объявлениями интерфейсов. Поэтому, прежде чем обсуждать принципы проектирования и паттерны, стоит разобраться с тем, из чего вообще состоит наш инструментарий. А состоит он из трёх парадигм программирования, каждая из которых была открыта более полувека назад и с тех пор не менялась.

Самое интересное в них - то, как именно они работают. Не так, как обычно предполагают.

Немного истории: как программы стали данными

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

К середине 1940-х он уже писал программы для реальных машин. И если сегодня посмотреть на его код, мы, приложив некоторое усилие, его прочитаем: там есть циклы, ветвления, присваивания, подпрограммы, стеки. Всё то же самое, чем мы пользуемся сейчас. Разница в том, что записывалось это двоичным кодом.

Дальше история пошла быстро. В конце 1940-х появились ассемблеры - они избавили программистов от ручного перевода инструкций в машинные коды. В 1951 году Грейс Хоппер создала первый компилятор A-0 и ввела в оборот сам термин «компилятор». В 1953 году появился Fortran, за ним COBOL, PL/I, C, Pascal, C++, Java - и далее непрерывным потоком до сегодняшнего дня.

Революция языков видна всем: о ней спорят на конференциях, из-за неё меняют место работы, ей посвящены бесконечные сравнительные таблицы. Но была и вторая революция, куда менее заметная и, если честно, куда более важная для архитектуры. Революция парадигм.

Что такое парадигма и почему это не то же самое, что язык

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

Разницу между языком и парадигмой легко почувствовать на практике. Можно писать вполне объектно-ориентированный код на чистом C - через структуры и таблицы указателей на функции, именно так устроены многие драйверы и ядро Linux. И точно так же можно писать на Java или C# в откровенно процедурном стиле: класс с одним статическим методом на тысячу строк - это не объектно-ориентированное программирование, сколько бы ключевых слов из учебника там ни встретилось.

Язык - это набор возможностей. Парадигма - это дисциплина их применения.

Для тех, кто только начинает: представьте, что вам выдали полный набор столярных инструментов. Язык - это то, какие именно инструменты лежат в ящике. Парадигма - это принятая в мастерской практика: например, никогда не забивать шурупы молотком, даже если это быстрее и физически возможно. Инструмент никуда не делся, вы просто договорились им так не пользоваться.

Для тех, у кого есть опыт: отсюда следует практический вывод. Переход на новый язык сам по себе не улучшает архитектуру. Команда, писавшая запутанный код на PHP, напишет ровно такой же запутанный код на Go или Kotlin, если не поменяется дисциплина. Меняет ситуацию не синтаксис, а то, от чего команда сознательно отказалась.

Всего парадигм три: структурное программирование, объектно-ориентированное и функциональное. И у них есть общая особенность, которую редко замечают.

Главный парадокс: парадигмы ничего не дают

Присмотритесь к тому, что делает каждая из трёх парадигм.

Структурное программирование ограничивает прямую передачу управления - забирает у нас безусловные переходы.

Объектно-ориентированное программирование ограничивает косвенную передачу управления - забирает свободное обращение с указателями на функции.

Функциональное программирование ограничивает присваивание - забирает возможность менять значение в любой момент.

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

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

Аналогия здесь простая. Правила дорожного движения не расширяют возможности автомобиля: он и без них способен ехать по встречной полосе. Правила именно что запрещают, и благодаря этому дорожное движение вообще существует как система, а не как набор случайных траекторий. Ценность ограничения - в предсказуемости, которую оно создаёт для всех остальных участников.

В коде происходит то же самое. Когда я открываю незнакомый модуль, написанный в рамках знакомой мне дисциплины, я заранее знаю, чего там точно не будет. Не будет прыжка из середины одной функции в середину другой. Не будет тихой мутации объекта, который я передал третьей стороне. Это резко снижает объём того, что мне нужно держать в голове - ту самую когнитивную нагрузку, о которой шла речь в первой части.

Обратите внимание и на исторический факт: все три парадигмы были открыты в промежутке примерно между 1958 и 1968 годами. За прошедшие с тех пор десятилетия не появилось ни одной новой. И это, скорее всего, не случайность: отнимать больше нечего. Три парадигмы забрали переходы, свободные указатели на функции и неограниченное присваивание - то есть все три способа, которыми программа может выйти из-под контроля.

Разберём каждую подробно. В этой части мы остановимся на первой - структурном программировании. Она кажется самой очевидной и именно поэтому чаще всего применяется формально, без понимания сути.

Структурное программирование: как один спор изменил профессию

Эдсгер Вибе Дейкстра родился в Роттердаме в 1930 году, пережил бомбардировки города и оккупацию Нидерландов, а в 1948 году окончил школу с лучшими оценками по математике, физике, химии и биологии. В 1952 году, в двадцать один год, он устроился в Математический центр Амстердама и стал, по сути, первым программистом в стране.

Есть один эпизод, который хорошо передаёт дух той эпохи. В 1957 году Дейкстра женился, а голландские правила того времени требовали указать в документах профессию. Он написал «программист» - и документы не приняли, потому что о такой профессии никто не слышал. Пришлось указать «физик-теоретик».

Работал он в условиях, которые сегодня трудно вообразить: ламповые машины, ввод программ с перфокарт, цикл «правка - компиляция - проверка» длиной в часы, а иногда и в сутки. Ошибка стоила дорого не в переносном смысле, а в самом прямом: день работы.

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

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

Неограниченные переходы - инструкция goto - ломали саму возможность такого доказательства. Когда управление может прыгнуть в произвольную точку, программу невозможно разложить на независимые части: каждый фрагмент связан со всеми остальными непредсказуемым образом. Принцип «разделяй и властвуй» перестаёт работать.

Но не все переходы вели себя так. Дейкстра заметил, что «безвредные» случаи применения goto укладываются в несколько простых схем - те, что мы знаем как if/then/else и do/while. Модули, построенные только на таких конструкциях, разбирались на доказуемые части без проблем.

И тут сошлись две линии. Двумя годами ранее Коррадо Бём и Джузеппе Якопини доказали теорему: любую программу можно записать, используя всего три конструкции - последовательность, выбор и итерацию. То есть минимальный набор, достаточный для написания чего угодно, в точности совпал с набором конструкций, при которых код остаётся анализируемым.

Так родилось структурное программирование.

В 1968 году Дейкстра опубликовал в журнале CACM своё знаменитое письмо о вреде оператора goto, и профессиональное сообщество взорвалось. Спор шёл около десяти лет - с письмами в редакции, резкими возражениями и не менее резкой поддержкой. Закончился он тем, что Дейкстра просто победил: языки эволюционировали, goto постепенно исчез, и сегодня большинство языков его либо не имеет вовсе, либо жёстко ограничивает границами одной функции.

Как это выглядит на практике

Вот фрагмент в духе того кода, против которого Дейкстра выступал. Псевдокод намеренно упрощён:

 i = 0;
    total = 0;
loop:
    if (i >= n) goto done;
    if (items[i].valid == 0) goto next;
    if (items[i].amount < 0) goto error;
    total = total + items[i].amount;
next:
    i = i + 1;
    goto loop;
error:
    log("bad amount");
    goto next;
done:
    return total;

Формально здесь всё работает. Но попробуйте ответить на вопрос: при каких условиях управление попадает на метку next? Придётся глазами просканировать весь фрагмент в поисках всех переходов. А в реальном коде тех лет такой фрагмент занимал не пятнадцать строк, а несколько сотен.

То же самое в структурном виде:

int total = 0;
for (int i = 0; i < n; i++) {
    if (!items[i].valid) {
        continue;
    }
    if (items[i].amount < 0) {
        log("bad amount");
        continue;
    }
    total += items[i].amount;
}
return total;

Разница не в количестве строк - оно почти одинаковое. Разница в том, что теперь у фрагмента есть чёткая граница. Я вижу тело цикла целиком и знаю: управление войдёт сюда сверху и выйдет снизу, других вариантов нет. Мне не нужно проверять, не прыгает ли сюда кто-то ещё из соседнего модуля.

Именно это свойство и есть суть парадигмы: у каждого блока кода один вход и один выход.

Современный goto, который никто так не называет

Вот здесь начинается самое важное, и об этом обычно молчат. Считается, что тема закрыта: goto в языке нет, значит, структурное программирование соблюдается автоматически. Это не так.

Ключевое слово исчезло, а само явление - нет. Неограниченная передача управления просто сменила форму. Вот несколько её современных обличий, которые я регулярно встречаю в рабочих проектах.

Исключения как штатный поток управления

Когда исключение бросается не при аварии, а как обычный способ вернуть результат из глубины стека вызовов - это ровно тот же прыжок в неизвестное место, только легализованный синтаксисом:

function findDiscount(user) {
  if (user.isVip) {
    throw new DiscountFound(0.2);   // это не ошибка, это возврат значения
  }
  // ...
}

Читатель функции findDiscount не может понять по её сигнатуре, что она вообще-то возвращает результат таким способом. Обработчик находится где-то на три уровня выше по стеку. Это метка goto, до которой сорок минут поиска по проекту.

Флаги состояния, управляющие ходом выполнения

Классика:

let shouldSkip = false;
let hasError = false;

for (const order of orders) {
  if (hasError) { break; }
  if (shouldSkip) { shouldSkip = false; continue; }
  // сто строк логики, где-то внутри которой
  // выставляются shouldSkip и hasError
}

Формально здесь только for, if, break и continue. Фактически - конечный автомат, спрятанный в переменных, и предсказать его поведение можно только выполнением в голове.

Глубокая вложенность

Она не нарушает правил формально, но убивает то самое свойство «один вход, один выход», ради которого всё затевалось:

function handleOrder(order) {
  if (order) {
    if (order.items.length > 0) {
      if (order.customer.isActive) {
        if (hasStock(order)) {
          if (paymentAllowed(order)) {
            // основная логика прячется здесь, на шестом уровне
          }
        }
      }
    }
  }
}

Хорошая новость в том, что лечится это одинаково - декомпозицией и ранними возвратами:

function handleOrder(order) {
  const violation = validateOrder(order);
  if (violation) {
    return Result.rejected(violation);
  }

  reserveStock(order);
  return Result.accepted(createInvoice(order));
}

function validateOrder(order) {
  if (!order.items.length)        return 'EMPTY_ORDER';
  if (!order.customer.isActive)   return 'INACTIVE_CUSTOMER';
  if (!hasStock(order))           return 'OUT_OF_STOCK';
  if (!paymentAllowed(order))     return 'PAYMENT_BLOCKED';
  return null;
}

Функция handleOrder теперь читается за пять секунд и умещается на экране целиком. Проверки собраны в одном месте, и добавление новой не требует трогать основной сценарий. Это ровно та низкая связанность и высокая согласованность, о которых мы говорили в первой части - только выраженная не в терминах модулей, а в терминах пяти строк кода.

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

Функциональная декомпозиция: почему это работает

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

Большая задача раскладывается на несколько функций верхнего уровня. Каждая из них - на функции уровнем ниже. И так далее, пока не дойдём до фрагментов, которые целиком укладываются в голову. Именно на этом фундаменте в конце 1970-х и в 1980-х выросли дисциплины структурного анализа и структурного проектирования, которые продвигали Эд Йордан, Ларри Константин, Том Демарко и Меилир Пейдж-Джонс.

Работает это не потому, что мелкие функции - это красиво. А потому, что у каждой части появляется определённый контракт: что она принимает на входе, что возвращает на выходе. Пока управление входит в блок только сверху и покидает его только снизу, такой контракт существует. Как только появляется свободный переход - контракта нет, и рассуждать о части в отрыве от целого больше невозможно.

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

Для специалистов с опытом: отсюда же растёт и практическая ценность метрики цикломатической сложности. Она измеряет количество независимых путей исполнения через функцию - то есть, по сути, количество случаев, которые придётся разобрать, чтобы убедиться в её правильности. Это не абстрактный показатель для отчётности, а прямая оценка того, сколько усилий потребует проверка кода. Функцию со сложностью 3 держит в голове любой; функцию со сложностью 25 не держит никто, включая её автора через две недели после написания.

Доказательства, которых не случилось

У истории структурного программирования есть неожиданный финал, и он важнее самой истории.

Мечта Дейкстры не сбылась. Евклидову иерархию доказанных теорем для программ так и не построили. Формальное доказательство правильности каждой функции оказалось настолько трудоёмким, что практическая индустрия от него отказалась. Сегодня формальная верификация применяется, но в узких областях, где цена ошибки исключительна: авионика, медицинское оборудование, криптографические примитивы. В обычной разработке её нет.

Но отказ от доказательств не означал отказа от строгости. Просто строгость пришла из другой дисциплины.

Разница между математикой и наукой принципиальна. Математика доказывает истинность утверждений. Наука так не умеет: невозможно доказать второй закон Ньютона. Можно провести множество экспериментов, измерить результат с любой точностью, но всегда остаётся вероятность, что следующий эксперимент покажет границы применимости закона - собственно, с ньютоновской механикой ровно это и произошло.

Наука работает наоборот: она пытается опровергнуть. Утверждение, которое устояло после множества добросовестных попыток его опровергнуть, мы считаем истинным - до тех пор, пока не появится опровержение.

Разработка программного обеспечения устроена по научному принципу, а не по математическому. И у Дейкстры есть на этот счёт афоризм, который стоит помнить любому, кто пишет тесты: «Тестирование показывает присутствие ошибок, а не их отсутствие».

Тестами нельзя доказать, что программа правильная. Можно доказать только обратное - что она неправильная. Всё, что даёт нам зелёная сборка после достаточных усилий, - это обоснованная уверенность в том, что программа работает достаточно правильно для наших целей.

И вот здесь замыкается вся логика этой части. Опровергать можно только то, что поддаётся разбору на части. Программу, в которой управление скачет произвольным образом, нельзя признать правильной ни при каком количестве тестов, потому что вы не можете изолировать проверяемое утверждение. Структурное программирование нужно нам ровно для того, чтобы получить тестируемые единицы.

Тестируемость - это архитектурное свойство

Из сказанного следует вывод, который стоит отдельного разговора: если что-то трудно протестировать, проблема почти никогда не в тестах. Проблема в структуре.

Посмотрите на функцию, которая на первый взгляд не вызывает вопросов:

function isSubscriptionExpired(userId) {
  const user = db.query('SELECT * FROM users WHERE id = ?', userId);
  return user.expires_at < new Date();
}

Здесь три строки и одна простая мысль. Но чтобы её проверить, нужна база данных с подготовленными записями, а ещё нужно как-то подменить системное время - иначе тест на «подписка истекает завтра» сломается ровно завтра. В итоге вокруг трёх строк вырастает инфраструктура на сотню строк, которая работает медленно и ломается по не связанным с логикой причинам.

Теперь то же самое, но с разделением решения и получения данных:

// Чистая функция: решение. Никаких обращений вовне.
function isSubscriptionExpired(expiresAt, now) {
  return expiresAt < now;
}

// Оболочка: получение данных и побочные эффекты.
async function checkUserSubscription(userId, clock) {
  const user = await users.findById(userId);
  return isSubscriptionExpired(user.expiresAt, clock.now());
}

Проверка решения теперь не требует ничего:

test('подписка считается истёкшей на следующий день после даты окончания', () => {
  const expiresAt = new Date('2026-01-01T00:00:00Z');
  const now       = new Date('2026-01-02T00:00:00Z');

  expect(isSubscriptionExpired(expiresAt, now)).toBe(true);
});

Ни базы, ни моков, ни зависимости от календаря. Тест выполняется за доли миллисекунды и падает только тогда, когда логика действительно сломана.

Заметьте, что мы сделали. Мы не «написали тесты» - мы изменили структуру кода так, чтобы его вообще было о чём спрашивать. Время и база данных превратились из скрытых зависимостей в явные параметры. Это ровно то, чем занимается архитектор, только в масштабе одной функции: отделяет то, что решает, от того, что общается с внешним миром.

Практический признак для команды: если в проекте регулярно звучит фраза «это невозможно нормально протестировать», у вас не проблема с тестированием. У вас диагноз архитектуры, и он бесплатный - его выдали вам сами тесты.

Что из этого следует для архитектуры

Может показаться, что мы ушли далеко в сторону от темы. На самом деле нет: три парадигмы напрямую соответствуют трём опорам архитектуры.

Структурное программирование даёт алгоритмическую основу для модулей - оно отвечает за функциональность и за то, что каждый модуль можно проверить по отдельности.

Объектно-ориентированное программирование через полиморфизм даёт механизм пересечения архитектурных границ - оно отвечает за разделение компонентов и за возможность менять реализацию, не трогая тех, кто ею пользуется.

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

Функциональность, разделение компонентов, управление данными. Три парадигмы, три опоры, никаких совпадений.

Заключение

Если собрать главное из этого материала, получится следующее.

Парадигмы - это не про то, что язык вам позволяет, а про то, от чего вы сознательно отказались. Смена языка не улучшает архитектуру; меняет ситуацию только смена дисциплины.

Каждая из трёх парадигм ограничивает, а не расширяет. Ценность ограничения - в предсказуемости: читая код, вы заранее знаете, чего в нём не будет, и это экономит вам главный ресурс - внимание.

Отсутствие ключевого слова goto в языке не означает соблюдения структурного программирования. Исключения в роли возврата значений, флаги-переключатели и глубокая вложенность создают ровно ту же проблему, ради решения которой всё затевалось.

Функциональная декомпозиция ценна не сама по себе, а тем, что превращает одно большое непроверяемое утверждение в набор маленьких проверяемых.

Разработка ближе к науке, чем к математике. Мы не доказываем правильность - мы не смогли доказать неправильность и считаем это достаточным основанием. Отсюда и роль тестов: они не гарантия, а инструмент опровержения.

Трудность тестирования - это не свойство тестов, а свойство архитектуры. Если что-то невозможно проверить без поднятия половины системы, проблема находится в коде, а не в инструментах.

Спасибо, что дочитали до конца.

В следующей части мы разберём вторую парадигму - объектно-ориентированное программирование. Поговорим о том, чем оно на самом деле является, почему полиморфизм оказался главным архитектурным изобретением за пятьдесят лет и как с его помощью развернуть направление зависимостей между модулями в нужную сторону.

Следите за продолжением.

Spring event bus. Гарантия выполнения метода после коммита транзакции.

2026-08-07T18:52:24Z

Сегодня коротко поговорим про Spring Event Bus и разберем одну задачку.

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

Конечно, первым на ум приходит запихивание отправки ивента в конец каждого верхнего роута. А хотелось бы просто опубликовать событие локально и быть уверенным, что оно улетит после успешного коммита внешней транзакции, кем бы она ни открывалась. И Spring event bus вместе с аннотацией @TransactionalEventListener дают возможное решение данной ситуации.

Шина событий в Spring - это такой встроенный publisher/subscriber внутри одного приложения: какой-то компонент системы может отправить событие в шину, а настроенные слушатели обработают его заданным образом.

Создать событие в Kotlin можно проще простого, обычным data class:

data class ActionCompletedEvent(
    val entityId: Long,
    val payload: String
)

В сервисе мы публикуем событие ровно там, где оно должно происходить по логике, и забываем про него. Публикуется оно, кстати, через ApplicationEventPublisher:

@Service
class SomeService(
    private val someRepository: SomeRepository,
    private val eventPublisher: ApplicationEventPublisher
) {

    // Метод вызывается из разных транзакционных роутов
    fun performAction(entity: Entity, payload: String) {
        someRepository.save(...)
        // Публикуем событие локально. 
        // Что будет дальше - нас не волнует.
        eventPublisher.publishEvent(ActionCompletedEvent(entity.id, payload))
    }
}

Если мы в слушателе повесим обычный @EventListener, он сработает прямо в момент вызова publishEvent. То есть проблема с откатом транзакции останется - ивент улетит до того, как внешняя транзакция подтвердит сохранение. Но у Spring есть @TransactionalEventListener:

@Component
class ActionListener(
    private val kafka: kafkaClient
) {

    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    fun handleActionCompleted(event: ActionCompletedEvent) {
        // Этот код выполнится ТОЛЬКО после успешного коммита в БД.
        // Spring сам поймет, к какой внешней транзакции мы привязаны.
        kafka.sendEvent(event.entityId, event.payload)
    }
}

Видите фазу AFTER_COMMIT? Spring сам отслеживает контекст транзакции. Мы можем легально вызывать publishEvent в любом месте метода, сохраняя правильную семантику кода. А Spring гарантирует, что слушатели отработают только после успешного коммита самой верхней транзакции в стеке вызовов. Если что-то упадет и транзакция откатится, событие просто игнорируется.

Единственный нюанс при использовании - это то, что по умолчанию @TransactionalEventListener работает синхронно, в том же потоке, что и основной запрос. Если обработка ивента займет пару секунд, юзер будет сидеть и ждать ответа от сервера, хотя в базу данные уже записаны. Для решения данного казуса можно воспользоваться аннотацией @Async над слушателем.

Итого

Вместо того чтобы тащить отправку ивентов в конец верхних роутов, мы публикуем их локально. Spring берет на себя всю грязную работу по отслеживанию транзакций.

Этичный вайбкодинг: Как создавать AI-решения ответственно

2026-08-06T10:40:46Z

Вайбкодинг (vibe coding) — это подход, при котором разработчик не пишет код построчно, а задаёт ИИ направление и общие параметры задачи на естественном языке, а модель генерирует решение . Это творческий, быстрый и демократичный способ создания ПО, где программист становится «дирижёром» . Однако эта свобода несёт и огромную ответственность.

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

Часть 1. Что такое «этичный вайбкодинг»?

Этичный вайбкодинг — это не просто «не нарушать закон». Это ответственное управление всем жизненным циклом AI-сгенерированного кода: от сбора данных для обучения моделей до развёртывания и сопровождения продукта .

Исследователи из Университета Конкордии ввели понятие Ethically Sourced Code Generation (ES-CodeGen) — 11 измерений, которые определяют этичность кода, сгенерированного ИИ :

Часть 2. Основные риски неэтичного вайбкодинга

1. Безопасность: «Доверяй, но проверяй»

Вайбкодер часто берёт код AI без проверки. Это открывает дорогу уязвимостям.

AI-галлюцинации и «slopsquatting»: Злоумышленники мониторят запросы к AI и создают вредоносные пакеты с названиями, которые AI генерирует как «наиболее вероятные». Вайбкодер скачивает такой пакет — и получает бэкдор в систему.
Устаревшие и опасные паттерны: AI генерирует то, что чаще всего встречалось в обучающих данных, а это часто — небезопасные практики

2. Правовые риски: «AI скопировал чужой код, а платить — мне»

Исследования показывают, что 60% ответов AI-моделей содержат элементы плагиата . Если AI сгенерировал код, совпадающий с проприетарным, ответственность за нарушение лицензии ложится на вас .

3. Технический долг и потеря контроля

Когда код пишется быстро и без архитектурного планирования, накапливается «технический долг». Вайб-подход редко предполагает долгосрочное планирование, из-за чего системы сложно адаптировать под новые задачи. Через полгода такой код становится невозможно поддерживать.

4. Дезинформация и манипуляции

AI не предназначен для сообщения правды. Он генерирует вероятные утверждения на основе закономерностей в данных . Если вы используете AI для создания контента, вы рискуете распространять ложную информацию без злого умысла. Многие используют AI для генерации постов, статей, описаний. И забывают, что сгенерированный текст нужно маркировать как AI-контент. А когда этого не делают, возникает иллюзия, что текст написан человеком. Это дезинформация. Она может быть безобидной, когда речь идёт о рецепте запеканки, но смертельно опасной, когда — о медицинских рекомендациях или политических новостях.

5. Профессиональная деградация

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

Часть 3. Как практиковать этичный вайбкодинг

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

Во-первых, научитесь разделять творчество и продукт. Нейросети хороши для того чтобы развить идею, набросать черновик, понять, в каком направлении двигаться. Но когда речь идёт о коде, который будет работать с деньгами, медицинскими данными или критической инфраструктурой, здесь вайбкодинг — зона риска. Используйте его для вдохновения, но не для финального решения.

Вайбкодинг отлично подходит для:

Прототипирования и проверки гипотез .
Личных, pet-проектов.
Генерации «первого черновика» кода.

Не используйте вайбкодинг для:

Продуктов, работающих с чувствительными данными (финансы, медицина) .
Критической инфраструктуры.
Кода, который нельзя переписать с нуля в случае проблем.

Во-вторых, читайте код. Да, это скучно. Да, AI написал его за вас. Но если вы не понимаете, что там происходит, вы не можете гарантировать его безопасность. Запускайте статические анализаторы, проверяйте лицензии всех библиотек, тестируйте граничные случаи. AI генерирует код, но только вы можете сказать: «Этот код правильный».

В-третьих, требуйте от AI прозрачности. Спрашивайте, почему он выбрал именно это решение. Используйте технику цепочки рассуждений — когда AI не просто даёт ответ, а показывает ход мыслей. Это не только помогает вам понять логику, но и часто выявляет ошибки на раннем этапе. Если AI не может объяснить решение, возможно, это решение не стоит использовать.

В-четвёртых, проектируйте ограничения заранее. Задавайте AI жёсткие рамки: «только компоненты из нашей дизайн-системы», «без внешних зависимостей», «с поддержкой доступности (WCAG)» . Это снижает риск «креативных», но опасных решений.

И наконец, создавайте культуру ответственности в команде. Введите код-ревью для AI-сгенерированного кода. Разработайте политику использования AI-инструментов. И главное — признайте, что сгенерированный AI код — это ваша работа, и вы за неё отвечаете. Не говорите «это написал ChatGPT». Говорите «это сделал я с помощью ChatGPT». Разница колоссальная.

Часть 4. Дорога вперёд: от регулирования к осознанности

Этичный вайбкодинг требует не только технических изменений, но и культурных. Образование должно сместиться от «научить писать код» к «научить понимать код, управлять AI-инструментами и оценивать их результат». Иначе мы рискуем вырастить поколение операторов чат-ботов, которые не способны критически мыслить.

Уже сейчас обсуждаются стандарты вроде AI Bills of Material — документирование всех компонентов AI-системы для обеспечения прозрачности. Почти 90% пользователей интернета выступают за регулирование генеративного AI. Вопрос не в том, будет ли регулирование, а в том, насколько разумным оно будет. Слишком жёсткое — задушит инновации. Слишком мягкое — приведёт к катастрофам.

Главное: творчество не отменяет ответственности

Вайбкодинг — это не «лёгкий путь» и не «читерство». Это новый способ создания, который требует от разработчика ещё большего профессионализма, чем раньше. Потому что теперь вы отвечаете не только за свой код, но и за код, который сгенерировал AI.

Адекватный вайбкодер не просто пишет промптики. Он проектирует архитектуру и задаёт ограничения. Он проверяет и тестирует каждое решение. Он понимает правовые и этические последствия. И — самое главное — он несёт ответственность за финальный продукт

AI может написать код. Но только человек может сказать: «Этот код правильный, безопасный и этичный». И это — ваша работа. Это и есть этичный вайбкодинг.

Краткий обзор NiFi 2.x - 5 важнейших (для меня) изменений

2026-08-04T14:23:28Z

В моем блоге уже было множество заметок на тему преобразования и передачи данных с использованием Apache NiFi, однако все наши предыдущие проекты разрабатывались на разных подверсиях NiFi 1.0. И вот, спустя несколько лет после официального выхода, NiFi 2.0 наконец добрался и до нас, в связи с чем возникла потребность кратко описать самые существенные (с точки зрения моего личного опыта и специфики наших проектов) нововведения в обновленном и переработанном NiFi.

1. NiFi Registry устарел, появилась удобная интеграция с Git

Раньше для версионирования потоков и совместной работы нужно было поднимать NiFi Registry как отдельный сервис, в котором хранятся JSON'ы наших потоков данных. В NiFi 2.0 управление версиями встроено прямо «из коробки» через Registry Clients. Теперь появилась возможность напрямую подключить свои Process Groups к GitHub, GitLab или Bitbucket. Компонент GitFlowRegistryClient был и раньше, но его настройка была сложна, а взаимодействие с репозиторием все равно проксировалось через Registry. Теперь все будет делаться напрямую и с меньшим количеством лишних действий.

2. Упростилась настройка SSL контекста

Настройка TLS/SSL в NiFi 1.x с использованием Java Keystore (JKS) и Truststore требовала множество лишних действий и сложных конвертаций с использованием keytool. Теперь же появился Controller Service под названием PEMEncodedSSLContextProvider, представляющий собой новую версию интерфейса SSLContextProvider специально для прямой работы с PEM-файлами. Он позволяет сразу же использовать тот набор файлов, который вам с наибольшей вероятностью пришлет системный администратор (.pem, .crt, .key) без необходимости создавать .jks файлы.

3. Добавили параметризацию Controller Services

В версиях 1.x существовало жесткое архитектурное ограничение: в настройках процессора (например, в поле Database Connection Pool для ExecuteSQL) приходилось жестко выбирать конкретный сервис из выпадающего списка кликом мыши. В Apache NiFi 2.x разработчики реализовали принцип «Parameterize All The Things», добавив возможность передавать Controller Services через параметры. Теперь в свойство процессора можно напрямую вписать текстовый параметр вида #{database_service_id}. Это изменение избавляет от необходимости вручную менять множество процессоров при миграции потоков между контурами. Теперь достаточно в один клик изменить значение самого параметра на ID нужного контроллера в Parameter Context, и NiFi автоматически остановит зависимые компоненты, подменит реализацию сервиса и запустит пайплайн обратно.

4. Новый встроенный Stateless-движок

С NiFi 2.x экспериментальный движок Stateless превратился в полноценный встроенный режим работы групп процессов. Если обычно NiFi протоколирует и сохраняет в свой репозиторий практически любые действия, то теперь переключателем в UI можно перевести выбранный поток данных в режим обработки строго в оперативной памяти, полностью исключив ресурсоемкую запись файлов потока на жесткий диск. Кроме колоссального прироста производительности и ультра-низкой задержки на потоках из тысяч мелких сообщений, Stateless-режим гарантирует строгую транзакционность. При сбое NiFi автоматически откатит всю цепочку шагов назад. Это может быть особенно полезно для контейнерных сред и Kubernetes (поддержка которого также расширена в NiFi 2.0), позволяя создавать легковесные поды в кластере, которым не нужны дисковые хранилища. Раньше возможность stateless-запуска была неудобной, так как требовала использование отдельной CLI-утилиты.

5. Появилась поддержка процессоров на Python

И одно из самых интересных. Множество статей в этом блоге было написано на тему того, как писать на Groovy сложные скрипты для конвертации данных. Теперь же при желании можно использовать полноценный Python. Если старый процессор ExecuteScript опирался на движок Jython (Python внутри JVM), в котором недоступны многие современные библиотеки, то в NiFi 2.x интеграцию с Python переписали с нуля, сделав его языком первого класса (First-Class Support). Благодаря нативной поддержке полноценного CPython, разработчики теперь могут писать кастомные процессоры на чистом Python и бесшовно подключать к потокам данных. NiFi берет на себя всю рутину по управлению инфраструктурой - платформа сама изолирует процессы, автоматически создает виртуальные окружения (venv) для каждого процессора и скачивает нужные зависимости. То есть теперь необязательно добавлять процессор ExecuteScript, внутри которого пишется код, а можно написать собственный Python-скрипт и положить его в специальную папку на сервере NiFi (обычно python/extensions). После перезапуска NiFi скрипт превращается в настоящий процессор в общем списке. Groovy, таким образом, можно оставить только для более простых и быстрых трансформаций. Подробнее см. NiFi Python Developer’s Guide

Вот пример процессора, который принимает входящий FlowFile, парсит JSON и добавляет новое поле с помощью библиотеки numpy (NiFi сам скачает через pip, если указать в зависимостях):

import json
import numpy as np
from nifiapi.flowfiletransform import FlowFileTransform, FlowFileTransformResult

class CalculateStats(FlowFileTransform):
    class Java:
        implements = ['org.apache.nifi.python.processor.FlowFileTransform']

    class ProcessorDetails:
        version = '2.0.0'
        description = 'Пример процессора NiFi 2.0'
        # Указываем внешние библиотеки, NiFi установит их автоматически через pip
        dependencies = ['numpy==1.26.4'] 

    def __init__(self, **kwargs):
        pass

    def transform(self, context, flowFile):
        content = flowFile.read().decode('utf-8')
        
        try:
            data = json.loads(content)
        except Exception:
            return FlowFileTransformResult(relationship="failure")

        data['generated_id'] = int(np.random.randint(1, 9))
        
        output_content = json.dumps(data)

        # Возвращаем обновленный контент в связь success
        return FlowFileTransformResult(
            relationship="success",
            contents=output_content.encode('utf-8')
        )

Итак, сегодня мы рассмотрели наиболее значительные (на мой взгляд) нововведения NiFi 2.0 с точки зрения удобства и возможностей разработки. Кроме них существует еще множество изменений, среди которых более приятный визуал веб-интерфейса, различные оптимизации, добавление новых процессоров и удаление устаревших, и многое другое. Например, отдельно стоит выделить переход на более производительную Java 21 и отказ от поддержки устаревших версий систем (например, kafka 2.0). Таких внешне менее заметных изменений еще много, и для каждого конкретного случая найдется свой процессор, контроллер сервисов и стратегии построения потоков данных. Обо всем этом мы еще поговорим в будущем.

ChatGPT, Claude и Gemini в 2026 году: сравнение ИИ-помощников для разработчиков

2026-08-01T18:24:42Z

Введение

За последние пару лет использование нейросетей в разработке перестало быть чем-то необычным - это часть повседневной работы. С их помощью пишут код, разбираются в чужих багах, готовят техническую документацию и обсуждают архитектурные решения ещё до того, как открыть IDE. Ни один серьёзный разговор о продуктивности разработчика в 2026 году уже не обходится без вопроса «а какой моделью ты пользуешься».

К этому году на первый план вышли три инструмента: ChatGPT от OpenAI, Claude от Anthropic и Gemini от Google. У каждого - свой характер, своя философия и свои сильные стороны, и универсального победителя тут, забегая вперёд, не будет. Выбор скорее похож на выбор инструмента из ящика - гаечный ключ не заменяет отвёртку, даже если оба сделаны качественно.

Ниже - подробный разбор сильных и слабых сторон каждой модели и практических ориентиров, которые помогут понять, в каких сценариях разработки уместнее использовать ту или иную из них.

Сравнение по ключевым параметрам

Критерий	ChatGPT	Claude	Gemini
Сложная логика	Хорошо	Высокий уровень	Хорошо
Отладка	Хорошо	Высокий уровень	Хорошо
Скорость выдачи решений	Высокий уровень	Хорошо	Хорошо
Качество кода	Хорошо	Высокий уровень	Хорошо
Размер контекста	32K токенов	200K токенов	1M токенов
Объяснение кода	Высокий уровень	Высокий уровень	Хорошо
Работа с изображениями и файлами	Хорошо	Хорошо	Высокий уровень
Интеграция с внешними сервисами	Хорошо	Хорошо	Высокий уровень
Скорость работы	Средняя	Средняя	Высокая
Стоимость	20$/мес.	17-20$/мес.	Бесплатно и 20$/мес.

Цифры в таблице - это, конечно, упрощение: ни одна модель не сводится к набору баллов по шкале «плохо-хорошо». Но как отправная точка для дальнейшего разговора такая таблица вполне рабочая.

ChatGPT: на все случаи жизни

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

Что в нём хорошо:

Широкий охват технологий - от классических языков вроде Java и C++ до узкоспециализированных библиотек и совсем новых фреймворков фронтенда.
Быстрое прототипирование: типовые задачи решаются буквально с первого запроса, без необходимости уточнять формулировку.
Встроенный Code Interpreter - можно выполнить Python-код прямо в чате, построить график, обработать датасет или проверить гипотезу, не переключаясь между окнами и средами.
Возможность создавать собственные GPT под конкретные задачи команды - от ревью пул-реквестов до генерации тестовой документации по шаблону.
Экосистема плагинов и интеграций, упрощающая связку с внешними сервисами - от систем управления задачами до баз данных.

Слабые места:

На нестандартных алгоритмических задачах иногда проскальзывают логические неточности - код лучше перепроверять, особенно если он затрагивает граничные случаи или конкурентный доступ к данным.
Контекстное окно в 32K токенов заметно меньше, чем у конкурентов, и это ощущается при работе с крупными проектами: часть кода приходится подавать частями, теряя общую картину.
Знания о самых свежих версиях библиотек могут немного отставать от реальности, особенно если фреймворк выпустил breaking changes недавно.
При долгих диалогах модель иногда «забывает» ранние договорённости о стиле кода или структуре проекта.

Кому подходит: тем, кто занимается разработкой общего профиля, быстро собирает прототипы или работает сразу с несколькими стеками технологий в течение дня.

Claude: вдумчивость и системность

Anthropic делает ставку на глубину анализа, и это заметно буквально с первых секунд общения. Когда дело доходит до запутанных багов или проектирования архитектуры, Claude действует методично и редко торопится с выводами - модель скорее похожа на внимательного senior-разработчика, который сначала прочитает весь контекст, а потом уже начнёт писать код.

Сильные стороны:

Уверенно справляется со сложными алгоритмами, структурами данных и граничными случаями - часто разбирает задачу пошагово, прежде чем выдать итоговое решение, и проговаривает свои допущения вслух.
Хорошо находит нетипичные ошибки и умеет объяснить, откуда они взялись, а не просто предложить патч без объяснений - это особенно ценно при разборе чужого legacy-кода.
Пишет более аккуратный и идиоматичный код - с продуманными именами переменных, логичной структурой файлов и комментариями там, где они действительно нужны, а не «для галочки».
Контекст на 200K токенов позволяет держать в поле зрения сразу большой кусок кодовой базы - например, загрузить несколько связанных модулей и попросить модель проследить, как они взаимодействуют друг с другом.
Реже «додумывает» ответ там, где не уверена - вместо этого модель честно указывает на свою неуверенность и предлагает уточняющие вопросы, что снижает риск получить уверенно звучащую, но неверную рекомендацию.
Хорошо работает с рабочими артефактами: можно попросить модель собрать и отредактировать целый файл или небольшой проект, не разрывая диалог на десятки отдельных фрагментов кода.

Ограничения:

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

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

Gemini: скорость и колоссальный контекст

Флагман Google выигрывает там, где важны скорость и объём. Контекстное окно на миллион токенов - рекорд среди трёх моделей, а глубокая интеграция с экосистемой Google делает Gemini естественным выбором для соответствующих проектов и команд, уже завязанных на облако Google.

Плюсы:

Заметно быстрее генерирует ответы, чем ChatGPT и Claude, что особенно чувствуется при частых коротких запросах в течение рабочего дня.
Контекст в 1M токенов позволяет загружать целые репозитории и объёмную документацию за один раз - можно, например, скормить модели весь монорепозиторий среднего размера и попросить найти все места, где используется устаревший API.
Плотная интеграция с Firebase, Google Cloud Platform и разработкой под Android - от генерации конфигураций до отладки облачных функций.
Сильные мультимодальные возможности: модель уверенно работает со скриншотами интерфейсов, диаграммами архитектуры и даже видео, что удобно при разборе багов, которые проще показать, чем описать словами.
Есть функциональный бесплатный тариф, а для более требовательных задач - платный Gemini Pro.

Минусы:

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

Кому подходит: командам, завязанным на экосистему Google, работе с большими объёмами исходного кода и задачам, где скорость важнее идеальной чистоты первого варианта.

Стоимость и что за неё дают

Формально ChatGPT Plus и Claude Pro стоят плюс-минус одинаково, и на первый взгляд выбор упирается только в качество ответов. Но на практике разница ощущается в лимитах: у ChatGPT более щедрые квоты на использование Code Interpreter и продвинутых моделей в течение дня, а у Claude - больший контекст, который в переводе на практическую пользу означает, что можно реже упираться в ограничение и чаще получать содержательный анализ большого куска кода за один запрос.

Gemini здесь выделяется тем, что предлагает действительно рабочий бесплатный уровень - не урезанную демоверсию, а полноценный инструмент, которого хватает для большинства повседневных задач. Платный Gemini Pro добавляет доступ к более мощной модели и увеличенным лимитам, что имеет смысл в первую очередь для тех, кто уже работает в экосистеме Google Workspace и хочет получить нейросеть прямо в Docs, Sheets или Gmail без переключения контекста.

Отдельная история - использование через API, где тарификация идёт за токены, а не по подписке. Здесь расклад может сильно отличаться от потребительских версий: для одних задач выгоднее окажется Claude из-за качества с первой попытки и меньшего числа повторных запросов, для других - Gemini из-за низкой цены на обработку больших объёмов текста.

Практическая проверка: рефакторинг медленного запроса с N+1-проблемой

Чтобы сравнить модели не только на словах, каждой была дана одна и та же реальная по духу задача: есть обработчик заказов на Python (Django), который выводит список заказов вместе с данными о клиенте и товарах внутри каждого заказа. Страница подгружается медленно, а в логах видно классическую N+1-проблему - на каждый заказ уходит отдельный запрос к базе данных. Модели нужно было найти причину, объяснить её и предложить исправленную версию кода.

ChatGPT довольно быстро определил проблему и предложил использовать select_related и prefetch_related для нужных полей. Решение рабочее и действительно устраняет лишние запросы, но модель не стала проверять, как это скажется на сериализации связанных объектов, и в комментарии не упомянула, что для полей с большим количеством связанных записей prefetch_related стоит комбинировать с Prefetch и явной фильтрацией - это пришлось уточнять дополнительным вопросом.

Claude сначала попросил показать модель данных (или прямо уточнил структуру связей), после чего разложил проблему по шагам: показал, где именно возникает лишний запрос к базе, объяснил разницу между select_related для связей «один к одному» и prefetch_related для связей «один ко многим», и только затем предложил итоговый код с использованием Prefetch и аннотаций через annotate, чтобы заодно избавиться от лишних вычислений на уровне Python. Решение сопровождалось короткими комментариями о том, почему выбран именно такой подход, и предупреждением о том, как изменение повлияет на существующие тесты.

Gemini справился быстрее всех и предложил похожее решение с select_related/prefetch_related, но в первом варианте не учёл, что часть полей уже подгружается через сериализатор с собственной логикой, из-за чего оптимизация частично дублировала запросы. После уточняющего вопроса модель быстро скорректировала ответ.

Победитель в этом тесте - Claude, но с оговоркой: разница проявилась не в том, «заработает ли код», а в глубине понимания последствий изменения и во внимании к деталям, которые легко упустить при беглом ревью. Для задачи, где нужен рабочий вариант здесь и сейчас, разница между тремя моделями была бы куда менее заметна.

Как выбрать инструмент под задачу

ChatGPT стоит выбрать, если:

нужен быстрый рабочий вариант под типовую задачу и нет времени на долгие уточнения;
вы изучаете незнакомый фреймворк или технологию и хотите получить широкий обзор возможных подходов;
важен сбалансированный код с пояснениями по ходу работы;
проект затрагивает сразу несколько языков программирования в течение одного дня;
нужно быстро прогнать расчёты или обработать данные через встроенный интерпретатор кода.

Claude подойдёт, если:

нужно найти и исправить сложный или «плавающий» баг, который другие инструменты уже не смогли объяснить;
качество, чистота и предсказуемость кода важнее скорости получения первого варианта;
предстоит разобрать крупный модуль или весь проект целиком, держа в голове множество взаимосвязей;
принимаются архитектурные решения или проводится код-ревью, где важна аргументация, а не только итоговый код;
команда ценит, когда модель честно говорит «не уверен» вместо того, чтобы правдоподобно ошибаться.

Gemini имеет смысл использовать, если:

критична скорость ответа, а объём диалога в течение дня большой;
проект завязан на Google Cloud, Firebase или Android;
нужно передать модели большой объём кода, документации или даже видео и скриншотов;
важен бесплатный, но при этом достаточно сильный инструмент без необходимости сразу оформлять подписку.

Что касается вопроса, какой инструмент вообще «лучше» - тут, честно говоря, нет однозначного ответа, и это не попытка уклониться от прямой оценки. Практика показывает, что для сложной логики и отладки увереннее ведёт себя Claude: он реже допускает логические ошибки и лучше объясняет ход рассуждений. ChatGPT при этом остаётся самым универсальным решением на каждый день - если задача типовая, а времени мало, он почти всегда выдаёт рабочий вариант с первой попытки и охватывает при этом более широкий круг технологий. Gemini, в свою очередь, не столько соперничает с двумя другими моделями в глубине логики, сколько предлагает другой набор преимуществ - скорость и контекст, которых физически не хватает конкурентам, особенно при работе с большими кодовыми базами или проектами в экосистеме Google.

Отдельно стоит сказать про написание кода как таковое. Если сравнивать именно чистоту и структуру итогового результата, а не только его работоспособность, Claude обычно выигрывает: переменные называются осмысленно, комментарии появляются там, где они правда нужны, а сама архитектура решения ближе к тому, что можно сразу отправить на код-ревью без правок. Код от ChatGPT и Gemini при этом тоже вполне рабочий и решает поставленную задачу - но чаще нуждается в стилистической доработке перед тем, как попасть в основную ветку проекта. Для команд, где на счету каждая минута ревью, это может оказаться решающим фактором.

Вместо заключения

Если собрать всё сказанное воедино, получается следующая картина.

Во-первых, единого лидера среди трёх моделей нет - выбор всегда зависит от контекста: отладка, проектирование, быстрый прототип или работа с объёмной кодовой базой требуют разных сильных сторон, и ни один инструмент не закрывает все сценарии одинаково хорошо.

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

В-третьих, ChatGPT остаётся самым универсальным вариантом - для повседневной разработки, быстрых проверок гипотез и знакомства с новыми технологиями он подходит лучше всего именно за счёт скорости и широты охвата.

В-четвёртых, Gemini берёт скоростью и объёмом контекста - миллион токенов делает его по-настоящему удобным инструментом для анализа целых репозиториев и работы в стеке Google, а щедрый бесплатный тариф снижает порог входа.

И наконец, на практике лучший результат чаще всего даёт не выбор одного-единственного инструмента на все случаи жизни, а осознанная комбинация всех трёх под конкретные этапы работы: быстрый прототип на ChatGPT, вдумчивое ревью и отладку на Claude, анализ большого объёма кода и работу с Google-сервисами на Gemini. Такой подход требует немного больше организационной дисциплины, зато позволяет использовать сильные стороны каждой модели именно там, где они действительно раскрываются.

Java и деньги

2026-07-09T16:13:11Z

Главная проблема работа с деньгами в программировании заключается в том, что привычные нам десятичные дроби компьютер хранит в двоичной системе. Из-за этого 0.1 + 0.2 в double превращается в 0.30000000000000004. В финансовой сфере такая погрешность недопустима.

В Java есть три основных способа обойти эту проблему. Разберем их:

Два long: рубли и копейки отдельно

Первое, что приходит в голову - разделить сумму на две части и хранить рубли и копейки в разных переменных типа long.

long rubles = 100;
long kopecks = 50;

Плюсы: Максимальная точность, никаких проблем с двоичным представлением.
Минусы: Любая математическая операция превращается в сложный код. Вам нужно вручную переносить разряды при сложении копеек, учитывать знаки при отрицательных суммах и т.д. В общем ад для разработчика.

Один long: всё в копейках

Более прагматичный подход. Мы отказываемся от дробей и храним всю сумму в минорных единицах (в копейках, центах и т.д.).

long totalKopecks = 10050; // 100 рублей 50 копеек

Плюсы: Скорость работы примитивов, нет проблем с округлением при сложении и вычитании.
Минусы: Проблемы начинаются при умножении и делении. Например, при расчете налога 13% от 100.50 рублей вы получите 1306.5 копеек. Придется вручную реализовывать логику округления. Помимо этого становиться сложно работать с валютами, где нет минорных единиц.

BigDecimal: золото

Основная часть профессиональных финансовых систем на Java использует java.math.BigDecimal. Этот класс представляет число в виде массива цифр произвольной длины и отдельной переменной для позиции запятой. Он лишен проблем двоичного округления.

Имейте ввиду - создавать BigDecimal из double это ошибка:

// ТАК ДЕЛАТЬ НЕЛЬЗЯ
BigDecimal bad = new BigDecimal(0.1); // 0.1000000000000000055511151231257827021181583404541015625

// ТАК ПРАВИЛЬНО
BigDecimal good = new BigDecimal("0.1"); // Из строки
BigDecimal alsoGood = BigDecimal.valueOf(0.1); // Или через фабричный метод

Главная сила BigDecimal - строгий контроль над округлением. При делении всегда нужно указывать правило округления, иначе программа упадет с ArithmeticException, если результат это бесконечная дробь.

BigDecimal total = new BigDecimal("100.00");
BigDecimal percent = new BigDecimal("0.13"); // 13%

// Делим нацело с округлением до копеек
// RoundingMode.HALF_EVEN — банковское округление
BigDecimal tax = total.multiply(percent)
                      .setScale(2, RoundingMode.HALF_EVEN);

Итог

BigDecimal - выбор для 99% бизнес-приложений, банковских систем. Он медленнее примитивов, но спасает от критических багов с округлением и потерей точности.
Хранение в минорных единицах - может подходить для того самого одно процента высоконагруженных систем, где важна каждая наносекунда.
Два long - cложность поддержки перевешивает любые плюсы.

Gstack: Как Гэрри Тан превращает вайб-кодинг в рабочий процесс

2026-07-09T11:33:18Z

Вайб-кодинг подкупает лёгкостью: описываешь словами, что нужно, и через минуту на экране рабочий прототип. Никаких тикетов, ревью и совещаний, поток идей сразу в код. Но у потока есть ограничения. Пока проект маленький, всё живёт; как только он вырастает, агент уверенно выдаёт код, который выглядит правильным, но таким не является, архитектура плывёт, баги всплывают в проде.

В эту боль и целится gstack - набор инструментов, который президент и CEO Y Combinator Гэрри Тан выложил в открытый доступ под лицензией MIT.

Что это

gstack это не приложение, а два с лишним десятка специализированных скиллов для Claude Code и набор инструментов. Значительную часть репозитория Тан написал в соавторстве с самим Claude. За пару недель репозиторий собрал десятки тысяч звёзд на GitHub. И это похоже на ожидаемый результат.

Ставка тут почти еретическая для индустрии, привыкшей строить тулинг: правильный уровень абстракции для ИИ-разработки позволит копилоту стать настоящей командой, хоть и глупых, но полноценных разработчиков у вас под рукой. Выстраданные промпты, которые заставляют агента вести себя, как дисциплинированная команда, больше похожи на должностные инструкции у реальных людей.

Не умнее программисты, а лучше процесс

Идея простая. Разработчики одиночки проигрывают большим командам не из-за квалификации, они пропускают процесс распараллеливания задач (очевидно, так как они одиночки). Кроме того, человек, вайбкодящий по вечерам очередной фитнес трекер, что-нибудь да соберёт, но у него нет ни осмысления задачи до старта, ни адекватной цели. А вся разница между рабочим продуктом и грудой техдолга живёт именно там.

Gstack внедряет эти этапы в вайбкодинг и превращает Claude Code из реактивного автодополнения в процесс с контрольными точками. Тан построил оргструктуру для выпуска софта и зашил в неё то, как сам оценивает продукты после тысяч стартапов, прошедших через YC.

Один скилл играет CEO, который переосмысляет продукт. Другой — инженерного менеджера, фиксирующего архитектуру. Третий — дизайнера, отлавливающего генеративную серость, которую агент выдаёт по умолчанию. Четвёртый — параноидального ревьюера, что ищет баги до прода. Пятый — QA, который открывает настоящий браузер, кликает по приложению и заводит на вас баги.

А что, так можно было

Отдельные умные промпты можно написать и без gstack. Отличают его хендоффы — передачи между этапами.

/office-hours не бросается кодить, а спорит с вашей формулировкой: сказали «приложение для утренней сводки» — получите ответ, что это персональный AI-начштаба, и вот пять возможностей, которые вы описали, сами того не заметив. Дальше

/plan-ceo-review ищет «десятизвёздочный продукт внутри запроса» в одном из четырёх режимов — от расширения замысла до сокращения. Проектный документ из /office-hours читает инженерное ревью, пишет тест-план, а его подхватывает /qa.

Эту цепочку случайным промптингом не воспроизвести. Последовательность повторяет настоящий спринт: подумать, спланировать, собрать, проверить, протестировать, выкатить, отрефлексировать.

Есть и защитные команды. /careful предупреждает перед деструктивными командами, /freeze запирает правки в одной директории, /guard включает оба сразу, а /investigate при отладке замораживает всё, кроме чинимого модуля, чтобы агент в запале не переписал полпроекта.

/codex зовёт независимое ревью от Codex CLI и показывает, где модели сходятся, а где спорят.

Зачем это

Пайплайн и есть продукт, агент — рабочая сила. Проведя с ИИ-агентом достаточно времени, ты перестаёшь видеть в нём гения-универсала, начинаешь управлять им как командой: каждой роли узкая задача и чистая передача дальше. Так всегда работали нормальные команды, просто теперь в терминале.

Цифры Тан приводит бодрые: по его замерам он пишет примерно в восемьсот раз больше кода в день, чем в 2013-м, когда программировал сам. К таким метрикам стоит относиться со скепсисом, но порядок величины впечатляет.

Кому подойдёт

gstack это всего лишь набор скиллов, и он ровно настолько точен, насколько конкретен ваш контекст: расплывчатое описание проекта даёт бесполезные роли.

Лучше всего применение gstack ложится на основателя или инженера ранней стадии, которому надо закрывать продукт, инженерию и ресёрч. Хуже - на большие команды с устоявшимся разделением ролей, где вся эта машинерия избыточна, и на тех, кто ждёт коробку без настройки: вложиться на старте придётся, и gstack рассчитывает, что свой продукт вы понимаете.

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

2026-07-07T15:20:47Z

Вы когда-нибудь просили нейросеть нарисовать «современный интерфейс для интернет-магазина» и получали нечто, напоминающее сайт 2010 года с кислотными цветами и непонятными кнопками? Или просили сгенерировать компонент на React, а AI выдавал код, который невозможно поддерживать, полный устаревших практик и багов?

Это не «глупая нейросеть». Это вы плохо объяснили задачу.

Промпт-инжиниринг (prompt engineering) — это искусство формулировать запрос к AI так, чтобы на выходе получался качественный, пригодный к использованию результат. В эпоху, когда нейросети стали стандартным инструментом дизайнера и разработчика, умение писать хорошие промпты — это базовый профессиональный навык, не менее важный, чем знание Figma или React.

Эта статья — практическое руководство по промпт-инжинирингу для дизайна и кода. Никакой магии. Только конкретные техники, примеры и принципы, которые работают прямо сейчас.

Часть 1. Почему промпт-инжиниринг — это новая суперсила

В 2026 году нейросети умеют очень многое. Midjourney и DALL-E 3 создают фотореалистичные изображения. Figma AI генерирует многостраничные прототипы по текстовому описанию. Lovable и v0 превращают промпт в работающее React-приложение за минуты.

Но есть одна проблема: AI не читает ваши мысли.

Он не знает ваш брендбук. Не понимает, что «современный» для вас — это минимализм с крупной типографикой, а не неоморфизм с кислотными градиентами. Не догадывается, что «быстрый компонент» означает без лишних зависимостей и с мемоизацией.

Хороший промпт — это не «пожелание». Это техническое задание, написанное на языке, который AI понимает идеально.

Разница между плохим и хорошим промптом

В первом случае AI гадает, что вы имели в виду. Во втором — у него есть чёткая инструкция, и он выдаёт предсказуемый, качественный результат.

Почему это особенно важно для дизайна и кода?

Дизайн и код — это дисциплины с высокой ценой ошибки. Плохой дизайн убивает конверсию. Плохой код создаёт тонну технического долга. AI генерирует быстро, но он также быстро генерирует плохие решения, если вы не задали правильные ограничения.

Часть 2. Базовые принципы хорошего промпта

Прежде чем переходить к продвинутым техникам, давайте зафиксируем фундамент. Хороший промпт всегда содержит четыре компонента:

1. Контекст (Context)

AI должен знать, для чего он это делает. Кто пользователь? В каком продукте будет использоваться результат? Какие ограничения накладывает среда?

Плохо: «Нарисуй дашборд для аналитики»
Хорошо: «Создай дизайн дашборда для менеджеров интернет-магазина. Основные метрики: выручка за сегодня, конверсия, средний чек, количество заказов. Данные обновляются каждые 5 минут. Пользователи смотрят на дашборд на 24-дюймовых мониторах по 8 часов в день — информация должна быть плотной, без лишних отступов. Приоритет — быстрый поиск аномалий, не эстетика.»

2. Роль (Role)

Скажите AI, кем он должен себя представлять. Это один из самых эффективных приёмов.

Пример для дизайна: «Ты — senior-дизайнер с 10-летним опытом в B2B-продуктах. Ты специализируешься на дашбордах и аналитических интерфейсах. Твои работы — лаконичные, функциональные, без лишнего визуального шума.»

Пример для кода: «Ты — ведущий фронтенд-разработчик, фанатик производительности и доступности. Ты не используешь неоправданные зависимости, пишешь чистый TypeScript и всегда добавляешь атрибуты aria-* для скрин-ридеров.»

3. Конкретные требования (Specifications)

Чем детальнее — тем лучше. Цвета, шрифты, размеры, структура компонентов, поведение при ошибках, состояния загрузки.

Приём «инвертирования»: скажите AI не только что делать, но и чего не делать.

«Не используй синий цвет — он ассоциируется с конкурентом. Не делай анимацию длиннее 200 мс. Не добавляй карусели — исследования показывают, что их никто не листает. Не генерируй SVG-иконки, используй импорт из react-icons.»

4. Формат вывода (Output Format)

Скажите AI, в каком виде вы хотите получить результат. JSON, HTML/CSS, React-компонент, описание дизайн-системы, список токенов.

Пример: «Верни ответ в формате JSON с полями: "prompt" (использованный промпт), "reasoning" (почему выбрана такая структура), "code" (React-компонент), "designTokens" (цвета и шрифты в формате CSS-переменных).»

Часть 3. Продвинутые техники промпт-инжиниринга

Базовый уровень позволит вам получать «нормальные» результаты. Продвинутые техники — превращать AI в предсказуемого, профессионального ассистента.

3.1. Chain-of-Thought (CoT) — цепочка рассуждений

Вместо того чтобы просить AI дать готовый ответ, попросите его показать ход мыслей. Это невероятно повышает качество результата, особенно для сложных задач.

Пример для дизайна:

«Сначала подумай и напиши свои рассуждения в тег <thinking>. Проанализируй задачу: кто пользователь, какова его главная цель, какие болевые точки. Затем предложи 3 разных подхода к организации информации. Потом выбери лучший и обоснуй выбор. И только после этого создавай финальный дизайн в Figma-совместимом формате.»

Пример для кода:

«Прежде чем писать код, напиши в комментариях:

Какие состояния есть у этого компонента?
Какие побочные эффекты нужно учесть?
Какой подход к управлению состоянием выбран и почему?
Какие edge cases (пустые данные, ошибки, загрузка) обрабатываются? После этого — реализация.»

3.2. Few-shot examples — учим AI на примерах

Самый мощный способ задать стиль, структуру или паттерн — показать пример. 1-3 примера достаточно, чтобы AI «схватил» нужный формат и тон.

Пример для дизайна:

Вот как я хочу, чтобы выглядела карточка товара. [Вставьте ссылку на Figma или скриншот]

А вот как я не хочу: [вставьте контр-пример]

Теперь создай карточку для категории "Спортивные товары", следуя тому же стилю.

Пример для кода:

Вот пример компонента, который я считаю эталонным по качеству:

type ButtonVariantType =
  | "primary"
  | "destructive"
  | "secondary"
  | "blue-button"
  | "link"
  | "link-blue";

const VARIANT_COLOR_TEXT_MAP: Record<ButtonVariantType, ColorToken> = {
  primary: "white",
  destructive: "white",
  secondary: "black-800",
  link: "black-800",
  "blue-button": "white",
  "link-blue": "blue-1000",
};

const DISABLED_VARIANT_COLOR_TEXT_MAP: Partial<Record<ButtonVariantType, ColorToken>> = {
  secondary: "black-400",
};

const getSvgIconWithColor = (svgIcon: ReactNode, color: ColorToken) => {
  if (!isValidElement<{ color?: ColorToken }>(svgIcon)) return svgIcon;

  return cloneElement(svgIcon, { color: svgIcon.props.color ?? color });
};

type SvgPositionType = "left" | "right";

type ButtonSizeType = "regular" | "small";
type ButtonRadiusType = "default" | "none";

export type ButtonProps = Props<
  {
    variant: ButtonVariantType;
    size?: ButtonSizeType;
    radius?: ButtonRadiusType;
    buttonJustify?: CSSProperties["justifyContent"];
    svgIcon?: ReactNode;
    svgPosition?: SvgPositionType;
    isLoading?: boolean;
    fitContent?: boolean;
  },
  true,
  ButtonHTMLAttributes<HTMLButtonElement>
>;

export const Button = componentWithRef<ButtonProps, HTMLButtonElement>(
  (
    {
      variant,
      svgIcon,
      svgPosition = "left",
      size = "regular",
      radius = "default",
      buttonJustify = "center",
      isLoading = false,
      fitContent = false,
      type = "button",
      disabled = false,
      children,
      className,
      style,
      ...rest
    },
    ref
  ) => {
    const isDisabled = disabled || isLoading;
    const currentColor =
      (isDisabled && DISABLED_VARIANT_COLOR_TEXT_MAP[variant]) ||
      VARIANT_COLOR_TEXT_MAP[variant];
    const svgIconWithColor = getSvgIconWithColor(svgIcon, currentColor);

    return (
      <button
        ref={ref}
        type={type}
        className={clsx(
          "pm-button",
          {
            [`button--${variant}`]: variant,
            [`button--${size}`]: size,
            [`button--radius-${radius}`]: radius,
            "button--fit-content": fitContent,
          },
          className
        )}
        style={{ ...style, justifyContent: buttonJustify }}
        disabled={isDisabled}
        {...rest}
      >
        {isLoading && <Loader color={currentColor} />}
        {svgPosition === "left" && svgIconWithColor}
        <Text variant="text3" color={currentColor}>
          {children}
        </Text>
        {svgPosition === "right" && svgIconWithColor}
      </button>
    );
  }
);

Теперь создай похожий компонент для дропдауна с поиском. Используй те же паттерны: мемоизация, обработка клика вне компонента, TypeScript, JSDoc.

3.3. Ограничения (Constraints) — границы творчества

AI любит придумывать «креативные» решения, которые нарушают ваши требования. Задавайте жёсткие ограничения.

Категории ограничений:

Контекст и среда: «Сайт будет работать в регионах с плохим интернетом. Все изображения должны быть оптимизированы, максимальный размер страницы — 500KB.»
Доступность: «Соответствие WCAG 2.2 уровня AA. Контраст текста 4.5:1, управление с клавиатуры, скрытие контента от скрин-ридеров там, где это нужно.»
Производительность: «Компонент не должен вызывать лишних ререндеров. Используй React.memo и useCallback. Анимации только через CSS transform и opacity — ничего, что вызывает reflow.»
Бренд: «Только фирменные цвета: #1E3A8A, #3B82F6, #F59E0B. Не используй красный — он триггерит негативные ассоциации. Типографика — только Inter.»
Технические ограничения: «Не используй сторонние библиотеки для UI. Только нативные CSS-модули. Поддержка браузеров: последние 2 версии Chrome, Firefox, Safari.»

3.4. Итеративный промптинг

Почти никогда первый результат не бывает идеальным. Но вместо того чтобы переписывать промпт с нуля, используйте диалог.

Шаблон: «Результат хороший, но нужно исправить три вещи: (1) сделай отступы между карточками 24px вместо 16px, (2) измени цвет кнопки на акцентный (#F59E0B), (3) добавь состояние hover для карточек. Не меняй ничего больше.»

Более продвинутый вариант — «аджайл-промптинг»: Разбейте большую задачу на маленькие итерации.

«Создай скелет страницы: хедер, основная область, футер. Пока без контента.»
«Теперь добавь три карточки товаров в основную область. Используй структуру: изображение, название, цена, кнопка.»
«Сделай карточки адаптивными: на десктопе — 3 колонки, на планшете — 2, на мобильном — 1.»
«Теперь добавь интерактив: при наведении на карточку — лёгкая тень и увеличение на 2% (transition 200ms).»

3.5. Негативный промптинг (Negative prompting)

Скажите AI не только что делать, но и что категорически нельзя.

Для генерации изображений (Midjourney, DALL-E):

Лендинг для IT-конференции. --no gradients, drop shadows, neon colors, 3D elements, stock photos, serif fonts, rounded corners on buttons

Для кода:

Создай хук useLocalStorage. Требования:

- НЕ используй try/catch (обработку ошибок я добавлю сам)
- НЕ используй useEffect для инициализации
- НЕ используй any в TypeScript
- НЕ генерируй лишних ререндеров

Часть 4. Промпты для дизайна: практические шаблоны

4.1. Генерация UI-компонента

Роль: senior UI-дизайнер, специалист по доступным интерфейсам.

Задача: создать карточку профиля пользователя для мобильного приложения соцсети.

Контекст: приложение для людей 35+, цель — общение по интересам. Интерфейс должен быть понятным, без "молодёжного" дизайна.

Требования:

Компоновка: аватар (слева), имя и статус (центр), кнопка "Написать" (справа).
Под аватаром — три иконки с числом друзей, фотографий, постов.
Цветовая схема: нейтральная (#F5F5F5 фон, #333 текст), акцент — #0066CC.
Адаптив: карточка растягивается на всю ширину экрана, внутренние отступы 16px.
Анимация: при нажатии на карточку — лёгкий ripple-эффект.
Доступность: контраст 4.5:1 для текста, фокус клавиатуры, атрибуты aria-label для иконок.

Не использовать: фотографии в кружочках (только квадратные с border-radius 12px), градиенты, выносные элементы.

Верни результат как структуру Figma (слои, компоненты, стили) или как JSON-схему.

4.2. Генерация дизайн-системы

Роль: архитектор дизайн-систем.

Задача: спроектировать дизайн-систему для B2B-платформы управления проектами.

Требования:

Цвета: основной нейтральный (серый), акцентный (синий), предупреждения (жёлтый), ошибки (красный), успех (зелёный). Каждый цвет — в 10 градациях.
Типографика: системные шрифты, 7 уровней заголовков (от H1 до H7), 4 уровня текста. Метрики: line-height, letter-spacing.
Сетка: 12-колоночная на десктопе, 8 — на планшете, 4 — на мобильном. Отступы: 8, 16, 24, 32, 48, 64px.
Компоненты: кнопки (4 варианта), инпуты (3 состояния), карточки, модалки, тултипы, таблицы, дропдауны. Для каждого — все состояния (default, hover, active, disabled, loading, error).
Анимации: 5 стандартных easing-функций, длительности (100, 200, 300, 500ms).

Выдай результат как структуру JSON с полями: colors, typography, spacing, components, animations.

Часть 5. Промпты для кода: практические шаблоны

5.1. Генерация React-компонента

Роль: senior фронтенд-разработчик, фанатик TypeScript и производительности.

Задача: создать компонент Modal на React + TypeScript с порталом.

Контекст: используется в дашборде с тяжёлыми графиками. Важна производительность и отсутствие лишних ререндеров.

Требования:

Props: isOpen (boolean), onClose (() => void), title (string), children (ReactNode), size ("sm" | "md" | "lg" | "full"), closeOnOverlayClick (boolean, default true).
При открытии — блокировка скролла body.
Закрытие: по Escape, клику на оверлей (если closeOnOverlayClick=true), кнопке "X".
Анимация: появление/исчезновение через CSS transition (opacity, transform). Длительность 200ms.
Доступность: role="dialog", aria-modal="true", focus trap (фокус не уходит из модалки), возврат фокуса при закрытии.
Технические ограничения: без внешних библиотек (кроме React и react-dom). Используй createPortal. CSS Modules.

Выдай полный код компонента с комментариями, объясняющими ключевые решения.

5.2. Генерация хука

Роль: lead разработчик, специалист по пользовательским хукам.

Задача: написать хук useDebounce.

Требования:

Типизация: <T>(value: T, delay: number) => T
Возвращает дебаунснутое значение.
Сброс таймера при размонтировании.
Поддержка опции immediate: если true — значение обновляется сразу, а потом игнорируется указанное время.
Использовать useRef для хранения таймера, useEffect для подписки/отписки.
Обработка edge cases: delay <= 0, изменение delay на лету, очистка при быстром переключении компонента.
JSDoc для каждого параметра.

Пример использования:
const [searchTerm, setSearchTerm] = useState('')
const debouncedSearch = useDebounce(searchTerm, 300, { immediate: false })

Выдай код хука + пример использования в компоненте SearchInput.

Часть 6. Инструменты для промпт-инжиниринга

Писать хорошие промпты помогает не только голова, но и специальные инструменты.

Для работы с текстовыми AI (ChatGPT, Claude, Gemini)

PromptPerfect — оптимизирует ваши промпты, предлагая улучшения для конкретной модели.
LangChain — фреймворк для создания цепочек промптов, памяти и инструментов.
Anthropic Console — встроенные шаблоны и режим "chain of thought" для Claude.

Для дизайна

Figma AI — плагины вроде "Design System Prompter" помогают переводить текстовые требования в дизайн-токены.
Midjourney Prompt Helper — конструктор промптов с подсказками по стилям, параметрам и весам.

Для кода

Cursor и Continue — AI-ассистенты, которые умеют работать с промптами прямо в редакторе кода, включая few-shot examples из ваших файлов.
Aider — утилита командной строки для промпт-инжиниринга в Git-репозиториях.

Часть 7. Заключение: промпт-инжиниринг как образ мышления

Промпт-инжиниринг — это не просто набор техник. Это способ мышления.

Хороший промптист (а в 2026 году каждый уважающий себя дизайнер и разработчик должен им быть) мыслит как:

Инженер — чётко, структурированно, с учётом ограничений.
Психолог — понимает, как AI интерпретирует слова, и выбирает формулировки, исключающие двусмысленность.
Коммуникатор — умеет объяснить сложную задачу простыми словами, но с нужной степенью детализации.
Итератор — не ждёт идеального результата с первого раза, а последовательно улучшает его через диалог.

Главный совет на прощание:

Не думайте о промпте как о «магическом заклинании». Это техническое задание, которое вы пишете для очень умного, но буквально мыслящего стажёра.

Чем точнее и полнее вы опишете контекст, роли, требования и ограничения — тем меньше «магии» потребуется, чтобы результат оказался полезным. И тем больше времени вы сэкономите на бесконечных правках.

Помните: AI делает то, что вы сказали, а не то, что вы имели в виду. Ваша задача — исключить разрыв между этими двумя понятиями. И хороший промпт — это единственный инструмент, который это позволяет.

Циклическое кодирование времени для прикладных задач

2026-07-03T10:00:03Z

Сегодня мы поговорим о простом, но действенном математическом способе преобразования данных о времени из линейного промежутка в окружность, имитирующую циферблат часов. Необходимость таких трансформаций появляется в тех случаях, когда алгоритму машинного обучения или разрабатываемому нами сервису важно понимать, что время в сутках идет по кругу и что разница в отметках (например, времени входа) 23:59 и 00:01 незначительная. Подобным образом происходит трансформация периодических временных признаков (не только часы, но и дни, месяцы) в непрерывные числовые значения, сохраняющие связь между концом и началом цикла. Это может использоваться, скажем, при обнаружении аномалий в поведении пользователя. Так, при моделировании профиля поведения нам важно знать, что активность, происходящая в ночь с одного дня на другой, принадлежит примерно к одному промежутку времени, а не к противоположным на временной оси точкам. Кроме того, применяться метод может при прогнозировании сезонных значений разного рода признаков от погоды и климата до числа продаж.

Итак, каким же образом мы можем проецировать время на окружность, где 23:00 и 00:00 окажутся рядом? Для любого временного признака расчет выполняется через перевод значения в радианы внутри текущего цикла по формулам:

В этих формулах:

t - текущее значение времени: час (0-23), месяц (1-12), день недели (0-6 или 1-7) и т.п.
T - максимальный период цикла, т.е. количество делений в периоде: 24 для часов в сутках (можно на 60 умножить для минут), 12 для месяцев, 7 для дней недели и т.п.

Для примера возьмем случай, когда нам нужно анализировать время входа в приложение в часах и минутах. Покажем, как 23:15 и 00:45 в случае кодирования через синусы и косинусы оказываются примерно в одной области нашей воображаемой временной окружности. В первую очередь, переведем часы в минуты от начала суток (это будет значение t). В таком случае 23:15 превратится в 1395 минут, а 00:45 соответственно в 45 минут. Значение T в таком случае будет 24*60=1440 минут.

Далее по формулам выше рассчитаем, что для 23:15:

x_sin = -0,195
x_cos = 0,981
Итоговые координаты для кодирования времени: (x_cos ; x_sin) = (0,981; -0,195)

Для 00:45:

x_sin = 0,195
x_cos = 0,981
Итоговые координаты для кодирования времени: (x_cos ; x_sin) = (0,981; 0,195)

Примерно так это будет выглядеть на тригонометрическом круге, имитирующем циферблат часов:

Как мы видим, 23:15 и 00:45 оказались достаточно близко, расстояние между ними небольшое (длина хорды около 0,4, тогда как для полуночи и полудня как самых отдаленных точек оно равняется 2,0). В связи с этим модель поймет, что данные временные отметки располагаются достаточно близко друг к другу, что события происходят примерно в одно время, тем самым существенно повышая точность решаемой задачи. Программная реализация в общем случае также не является сложной. Типичный пример кода на Python:

import numpy as np

def encode_time_with_minutes(time_str):
    hours, minutes = map(int, time_str.split(':'))
    t = hours * 60 + minutes
    T = 24 * 60 
    sin_val = np.sin(2 * np.pi * t / T)
    cos_val = np.cos(2 * np.pi * t / T)
    return round(cos_val, 3), round(sin_val, 3)

print("23:15 ->", encode_time_with_minutes("23:15"))
print("00:45 ->", encode_time_with_minutes("00:45"))

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

Git: как перенести проект на новый сервер без старой истории

2026-07-02T21:32:09Z

Введение

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

Хорошее решение в такой ситуации - начать историю проекта заново: собрать один аккуратный Initial commit с текущим состоянием кода и перенести его на новый сервер. Сначала разберем простой алгоритм - пять шагов, которых достаточно в большинстве случаев. А после - уточним важные детали и нюансы, которые стоит знать перед тем, как применять этот способ на реальном проекте.

Простой алгоритм

Перед началом работы откройте терминал и перейдите в корневую папку локального репозитория.

Шаг 1. Создание независимой ветки

Создаем новую независимую (orphan) ветку. Она не тянет за собой историю предыдущих коммитов, позволяя начать с чистого листа. Назовем ее temp-branch:

git checkout --orphan temp-branch

После этой команды вы окажетесь в новой ветке. В ней пока нет ни одной записи в истории, но все файлы остаются на своих местах.

Шаг 2. Индексация файлов и создание коммита

Добавляем все рабочие материалы проекта в индекс Git и фиксируем их первым коммитом:

git add -A
git commit -m "Initial commit"

Теперь у вас есть ветка с единственным коммитом, который содержит актуальное состояние проекта.

Шаг 3. Замена старой ветки на новую

Убираем старую основную ветку (обычно master или main) и переименовываем временную ветку, делая ее главной:

# удаляем старую локальную ветку master
git branch -D master

# переименовываем временную ветку в master
git branch -m master

Шаг 4. Привязка нового сервера

На этом шаге есть два разных сценария, и важно сразу определить свой - от этого зависит, какие команды выполнять дальше.

Вариант А. Старый сервер больше не нужен, работаем только с новым

Это самый частый случай: вы полностью переезжаете на новый хостинг, а старый репозиторий планируете архивировать или удалить. Тогда просто заменяем адрес, на который указывает origin:

git remote set-url origin <URL_НОВОГО_РЕПОЗИТОРИЯ>

Само имя origin остается прежним - меняется только URL за ним. Проверить результат можно командой:

git remote -v

Вы увидите, что origin теперь указывает на новый адрес и для скачивания (fetch), и для отправки (push). Дальше все команды: git push, git pull - работают как обычно, без каких-либо изменений в синтаксисе, потому что Git по умолчанию обращается именно к origin.

Вариант Б. Старый сервер должен остаться доступным

Такой случай встречается, если старый репозиторий нужно временно сохранить как резервную копию, зеркало, или часть команды пока продолжает работать со старым сервером. В этой ситуации origin не трогаем, а добавляем новый сервер под отдельным именем:

git remote add new-server <URL_НОВОГО_РЕПОЗИТОРИЯ>

Теперь у репозитория два адреса одновременно: старый под именем origin и новый под именем new-server. Проверить это можно той же командой:

git remote -v

В выводе будут обе записи со своими адресами. Обратите внимание на важный нюанс: команда git push без указания имени сервера по-прежнему будет отправлять изменения в origin, то есть на старый сервер. Чтобы отправить коммит именно на новый сервер, имя нужно указывать явно:

git push -u new-server master

Флаг -u в этом случае привязывает вашу локальную ветку master к ветке master на new-server - после этого для последующих отправок туда достаточно будет просто git push, находясь в этой ветке.

Шаг 5. Отправка коммита на новый сервер

Если вы выбрали Вариант А из предыдущего шага, загружаем коммит стандартной командой - она автоматически уйдет на новый сервер, так как origin уже переключен:

git push -u origin master

Если же вы выбрали Вариант Б и добавляли новый сервер под именем new-server, используйте это имя вместо origin - команда та же, что приведена в шаге 4:

git push -u new-server master

Если репозиторий на новом сервере уже создан и там есть автоматические базовые файлы (README.md, .gitignore), Git может предложить сначала объединить изменения. Поскольку задача - заменить содержимое одним новым коммитом, используем принудительную отправку:

git push -f -u origin master

На этом перенос завершен: в новом репозитории лежит аккуратная история из одного коммита с актуальным кодом проекта.

Пояснения и важные детали

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

Когда этот способ действительно оправдан

Передача проекта заказчику. Вы работали над проектом полгода, использовали внутренние ветки для экспериментов, коммитили черновики и временные решения. Заказчику не нужна эта "внутренняя кухня" - ему нужен рабочий код в аккуратном репозитории с одним понятным коммитом.
Публикация в open source. В истории коммитов часто остаются следы конфигурационных файлов с внутренними адресами серверов, тестовыми учетными данными или устаревшими API-ключами. Даже если сейчас эти данные удалены из кода, они все равно доступны через git log любому, кто клонирует репозиторий. Обнуление истории - самый надежный способ закрыть эту проблему.
Смена хостинга с оптимизацией репозитория. Если в истории когда-то были закоммичены большие бинарные файлы (архивы, видео, дампы баз данных), которые впоследствии удалили, файл .git все равно продолжает хранить эти данные. Перенос с чистой историей избавляет от этого балласта.

Если история коммитов важна для аудита изменений или юридических требований - обнулять ее не стоит. Здесь лучше подойдут более точечные инструменты вроде git filter-repo, которые чистят историю выборочно, не удаляя ее целиком.

Что стоит проверить перед началом

Резервная копия. Скопируйте проект целиком или создайте архив - операция необратима, и лучше иметь возможность вернуться к исходному состоянию.
Файл .gitignore. Убедитесь, что в него добавлены node_modules, venv, dist и прочие директории со сборочными артефактами - они не должны попасть в новый Initial commit.
Сабмодули. Если в проекте используются git submodules, при создании orphan-ветки связи с ними могут потребовать переинициализации.
Незавершенная работа в других ветках. После обнуления истории прочие ветки продолжат указывать на старую историю. Если там есть что-то важное - смержите это в рабочую ветку заранее.

Уточнения к шагу 1: orphan-ветка

Проверить, что переключение прошло успешно, можно командой git status - она покажет, что все файлы проекта отмечены как неотслеживаемые, и это нормально: для Git это действительно первая ветка без единой точки отсчета.

Например, если у проекта были ветки master, feature/payments и feature/auth, после команды появится четвертая ветка temp-branch, полностью изолированная от истории остальных трех. Посмотреть список всех веток можно командой git branch -a.

Уточнения к шагу 2: индексация и коммит

Флаг -A добавляет в индекс не только новые и измененные файлы, но и учитывает удаленные - это важно, если какие-то файлы должны остаться за пределами нового репозитория, но по ошибке все еще присутствуют на диске.

После коммита стоит убедиться, что в истории действительно ровно одна запись:

git log --oneline

Если строк больше одной - ветка была создана не как orphan, и стоит вернуться к первому шагу. Если в проекте есть папка вроде logs/ с многолетними файлами отладки, которую забыли добавить в .gitignore, эти файлы попадут в коммит и раздуют размер репозитория с самого начала - проверить состав будущего коммита удобно командой git status до выполнения git add -A.

Уточнения к шагу 3: замена ветки и очистка локального репозитория

Если проект использует в качестве основной ветки main вместо master, используйте соответствующее имя в обеих командах.

Важная деталь, которую часто упускают: удаление ветки командой git branch -D убирает лишь указатель на историю - сами коммиты физически остаются в локальном хранилище .git до сборки мусора. Если в проекте были и другие второстепенные ветки, их тоже стоит удалить:

git branch -D feature/payments feature/auth

Чтобы полностью очистить локальный репозиторий и уменьшить размер папки .git, выполните после удаления всех лишних веток:

git reflog expire --expire=now --all
git gc --prune=now --aggressive

Оценить размер репозитория до и после очистки можно командой du -sh .git - разница может быть весьма ощутимой, особенно если в истории раньше присутствовали крупные бинарные файлы.

Уточнения к шагу 4: подключение нового сервера

Проверить, что адрес обновился корректно, можно командой git remote -v

Она выведет текущие адреса для чтения (fetch) и записи (push), оба должны указывать на новый сервер.

При переносе, например, с GitLab на GitHub URL обычно меняется с git@gitlab.com:team/project.git на git@github.com:team/project.git. Если используется SSH-доступ, заранее убедитесь, что соответствующий ключ добавлен в настройках нового аккаунта, иначе push завершится ошибкой авторизации.

Уточнения к шагу 5: отправка и force push

Force push перезаписывает историю на удаленном сервере безвозвратно. Если с репозиторием уже работают другие участники команды или от него сделаны форки, их локальные копии разойдутся с сервером, и им потребуется заново клонировать проект. Прежде чем выполнять force push в уже используемый репозиторий, обязательно предупредите всех, кто с ним работает.

На некоторых платформах основная ветка может быть защищена от принудительной отправки настройками по умолчанию - в этом случае временно снимите защиту в настройках репозитория, выполните push, а затем включите ее обратно.

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

git ls-remote origin

Что еще не переносится автоматически:

Теги. Ссылаются на старую историю и не переносятся вместе с кодом - их нужно создать заново поверх нового Initial commit командой git tag v1.0.0.
Настройки CI/CD. Пайплайны, вебхуки и секреты придется настроить заново на новом сервере.
Права доступа и участники команды. Список коллабораторов и ролей настраивается отдельно на новой платформе.
Локальные копии у коллег. Даже после чистого переноса у других участников команды могут остаться клоны со старой историей. Лучше явно попросить их удалить старую папку и склонировать проект заново, чем полагаться на git pull.

Заключение

Чему мы сегодня научились:

Работать с независимыми ветками. Флаг --orphan в Git - удобный инструмент, который позволяет создавать ветки без привязки к прежней истории, что отлично помогает при реорганизации репозиториев или подготовке кода к публикации.

Грамотно пересобирать локальную структуру. Мы узнали, как откреплять старые ветки (git branch -D) и переименовывать текущие (git branch -m), а также как полностью очищать .git от следов старой истории с помощью git reflog expire и git gc.

Управлять удаленными репозиториями. Теперь мы умеем не только переназначать адрес сервера через git remote set-url, но и понимаем, когда вместо этого стоит добавить второй сервер через git remote add - и как выбор между ними влияет на поведение git push.

Правильно применять Force Push. Мы закрепили понимание того, когда оправдан флаг -f. Он полезен, когда нужно полностью синхронизировать удаленный сервер с новой локальной историей, но требует предварительного предупреждения команды.

Учитывать сопутствующие детали переноса. Теги, настройки CI/CD и права доступа не переносятся вместе с кодом автоматически - их нужно настроить заново уже на новом сервере.

Теперь в вашем арсенале есть понятный и надежный алгоритм для комфортного переезда проектов на новые репозитории!

Strapi в эпоху AI-coding: почему dev-first CMS выигрывает

2026-06-10T09:31:36Z

Состояние рынка

Headless CMS перестал быть нишевой темой. Рынок оценивается в $3,94 млрд в 2026 году и прогнозируется к росту до $22 млрд к 2034-му (CAGR >21%). Для большинства команд это уже инфраструктурное, а не инструментальное решение.

Рынок сложился в два лагеря:

Enterprise-Grade Orchestrators — Contentful, Sanity, Kontent.ai. Проприетарные SaaS-платформы с высоким ценовым порогом, позиционирующие себя как «Composable DXP» или «Content Operating System». Высокий уровень managed-сервисов, global CDN из коробки, но данные живут у провайдера.

Developer-Owned Backends — Strapi, Payload CMS. Open-source, self-hosted, максимальный контроль над инфраструктурой. Strapi — самый популярный headless CMS с открытым исходным кодом по числу GitHub-звёзд и задокументированных enterprise-деплойментов.

Что такое Strapi

Strapi — headless CMS на Node.js с MIT-лицензией. Self-hosted Community Edition полностью бесплатен.

Ключевые параметры платформы:

API: REST и GraphQL генерируются автоматически для каждого content type. OpenAPI v3 spec с v5.20
База данных: PostgreSQL (рекомендован для production), MySQL/MariaDB, SQLite. Только SQL — намеренный выбор под реляционную enterprise-инфраструктуру
TypeScript: 100% кодовая база с Strapi 5, сборка через Vite
i18n, Draft/Publish, версионирование контента — из коробки

Архитектура: схема как код

Главное архитектурное решение Strapi — content type как файл в репозитории. Каждый тип — это schema.json, который версионируется в git, открыт для диффа в PR и читаем любым инструментом.

// src/api/article/content-types/article/schema.json
{
  "kind": "collectionType",
  "options": { "draftAndPublish": true },
  "attributes": {
    "title":   { "type": "string", "required": true },
    "slug":    { "type": "uid", "targetField": "title" },
    "content": { "type": "richtext" },
    "author":  { "type": "relation", "relation": "manyToOne", "target": "plugin::users-permissions.user" }
  }
}

Из этой схемы Strapi автоматически генерирует полный CRUD-слой. REST-эндпоинт поддерживает фильтрацию, сортировку, пагинацию и populate для связей:

GET /api/articles?filters[author][username][$eq]=john&populate[author][fields][0]=username&sort=createdAt:desc&pagination[pageSize]=10

Тот же запрос через GraphQL — через /graphql, который подключается одним плагином.

Кастомная бизнес-логика

Lifecycle hooks перехватывают события без написания отдельных эндпоинтов:

// src/api/article/content-types/article/lifecycles.ts
export default {
  async beforeCreate(event) {
    const { data } = event.params;
    if (!data.slug && data.title) {
      data.slug = slugify(data.title, { lower: true });
    }
  },
};

Кастомные роуты добавляются декларативно:

// src/api/article/routes/custom-article.ts
export default {
  routes: [
    { method: 'GET', path: '/articles/trending', handler: 'article.findTrending',
      config: { policies: ['global::is-authenticated'] } },
  ],
};

Официальный @strapi/sdk-js генерирует типизированные клиентские методы из OpenAPI-спецификации инстанса — IntelliSense и type narrowing без ручных деклараций.

Почему dev-first архитектура выигрывает у AI-агентов

Это принципиальный момент для современного рабочего процесса.

AI-агенты (Claude Code, Cursor, Copilot Workspace) работают с файловой системой и документацией. Когда схема контента существует как JSON-файл в репозитории, агент может прочитать её, добавить поле, написать lifecycle hook и сгенерировать seed-скрипт — всё в рамках одного PR без выхода в браузер.

В CMS с UI-first архитектурой (Contentful и подобных) схема живёт только в базе данных провайдера. Агент вынужден делать аутентифицированные API-вызовы к Management API, не имея статического контекста. Это не техническое ограничение — это архитектурное.

Задача	Strapi	UI-first SaaS
Прочитать схему	JSON из репозитория	API-вызов к провайдеру
Добавить поле	Редактирование файла	POST к Management API
Добавить логику	Lifecycle hook в TS	Отдельная Lambda/Function
Ревью изменений	git diff в PR	Только в UI провайдера

Strapi AI и MCP

В 2025 году Strapi выпустил Strapi AI — генерацию content models из текстового промпта или Figma-дизайна. Параллельно разрабатывается нативный MCP-сервер, который позволяет AI-ассистентам управлять схемой через Model Context Protocol. Пока он в разработке, доступен community-плагин @sensinum/strapi-plugin-mcp.

Документация публикует специальные файлы: llms.txt, llms-full.txt, llms-code.txt — структурированный, токен-экономный контекст для RAG-систем и IDE-агентов.

Сравнение с конкурентами

	Strapi	Contentful	Sanity	Payload
Лицензия	MIT	Проприетарный	Проприетарный	MIT
Self-hosting	Да	Нет	Да	Да
Schema as code	JSON в git	API-only	TypeScript	TypeScript
MCP-поддержка	plugin + roadmap	Нет	Нативный	Да
DB freedom	SQL (PG/MySQL)	Vendor	Vendor	PG/MongoDB/SQLite
Цена (managed)	Бесплатно / $18+	$300+/мес	$15+/мес	Бесплатно
Admin UI зрелость	Высокая	Высокая	Высокая (Studio)	Базовая

Payload CMS — ближайший конкурент в open-source нише. Устанавливается прямо в Next.js-приложение и работает внутри App Router. Figma приобрела Payload в июне 2025 года, MIT-лицензия сохранена. Если проект Next.js-first и минимальный network overhead важен — Payload стоит рассматривать наравне со Strapi.

Contentful — правильный выбор для global enterprise с требованиями к SLA, managed CDN и zero-ops. Ценовой порог отражает реальную стоимость этих гарантий.

Sanity выигрывает на real-time collaboration и кастомизации редактора через Portable Text.

Self-hosting: что нужно учесть

Strapi в production стандартно деплоится за reverse proxy (Cloudflare, nginx) с frontend на Vercel/Netlify. Для медиа нужен отдельный CDN (S3 + CloudFront или аналог) — Strapi не предоставляет его из коробки.

Для multi-region деплоймента придётся самостоятельно проектировать топологию репликации и кэширования. Именно это managed-платформы берут на себя за деньги.

Честно про миграции: upgrade между major-версиями Strapi исторически требует значительных усилий. Переход v4 → v5 не исключение. Это нужно учитывать при оценке long-term стоимости ownership.

Когда выбирать Strapi

Сценарий	Вывод
Data sovereignty, GDPR/HIPAA compliance, self-hosted	Strapi
Code-first команда, схема в git, CI/CD пайплайн	Strapi
AI-агенты работают с кодовой базой	Strapi
Ограниченный бюджет, нужен production-ready CMS	Strapi (MIT)
Next.js-monorepo, минимальный инфраструктурный overhead	→ Payload
Global CDN, 99.99% SLA, zero-ops	→ Contentful
Real-time collaboration редакторов	→ Sanity

Dev-first архитектура была преимуществом удобства. В мире, где AI-агенты читают, пишут и изменяют кодовую базу напрямую, она стала архитектурным преимуществом: инструменты работают с кодом, а не с UI провайдера.

Именованное деструктурирование в Kotlin

2026-06-10T07:30:12Z

Доброго дня! Сегодня поговорим об одной из экспериментальных фич Kotlin, а именно о деструктурировании.

Проблема

Деструктурирование в Kotlin - удобная вещь. Всё работает через сгенерированные методы componentN(), и синтаксис получается приятным:

data class User(val name: String, val age: Int)
 
val user = User("Max", 23)
val (name, age) = user
println("$name is $age years old")

Но за этим удобством скрывается ловушка. Деструктурирование позиционное - значит, name получает значение component1(), age - component2(). И если кто-то решит переставить поля местами или добавить новое поле в начало класса:

data class User(val id: Long, val name: String, val age: Int)

Компилятор не выдаст ошибку, код соберётся - просто name теперь будет содержать id, а age - name. Ещё хуже ситуация с интерфейсами: деструктурировать объект через интерфейс нельзя, потому что componentN() объявляется только в data class.

В Kotlin 2.3.20 появилась экспериментальная поддержка именованного деструктурирования. Идея простая: вместо позиций используем имена свойств, а синтаксис разделяется на два вида.

Именованное деструктурирование - круглые скобки:

val (val name, val age) = user

Теперь name привязывается к свойству name, а не к позиции. Переставляйте поля
как угодно - код не сломается.
Если нужно переименовать переменную на месте:

val (val years = age, val theName = name) = user
println("$theName is $years years old")

Позиционное деструктурирование - квадратные скобки:

val [x, y] = point

Таким образом разработчики чётко разделили намерение: если хочешь по именам, то используй (), но если хочешь по позициям - то будь добр, используй [].

Деструктурирование через интерфейс

Это пожалуй самое интересное. Теперь можно деструктурировать через интерфейс, если свойства в нём объявлены:

interface Named {
    val name: String
    val age: Int
}
 
data class User(override val name: String, override val age: Int) : Named
 
fun printInfo(entity: Named) {
    val (val name, val age) = entity
    println("$name is $age")
}

Раньше такой код просто не компилировался. Теперь компилятор ищет свойство по имени и находит его в интерфейсе.

Поддержка экспериментальная, поэтому включается флагом компилятора:

-Xname-based-destructuring=only-syntax

Для Gradle:

kotlin {
    compilerOptions {
        freeCompilerArgs.add("-Xname-based-destructuring=only-syntax")
    }
}

Итог

Именованное деструктурирование - небольшое, но важное изменение. Оно убирает целый класс тихих ошибок, которые легко допустить при рефакторинге, и открывает деструктурирование для интерфейсов. Синтаксис с () и [] хорошо передаёт намерение.

Если вы активно используете деструктурирование в data-классах - стоит уже сейчас попробовать новый синтаксис и пробежаться по коду.

Микроанимация в интерфейсах: Как сделать цифровой продукт живым, понятным и комфортным

2026-06-08T21:09:03Z

Представьте, что вы нажимаете на кнопку в приложении, и... ничего не происходит. Тишина. Кнопка даже не меняет цвет. Возникло ли ощущение, что вы сделали что-то не так? Или что приложение «зависло»?

А теперь вспомните, как приятно, когда кнопка слегка «вдавливается» под пальцем, когда переключатель плавно скользит из положения «выкл» в «вкл», когда сердечко лайка пульсирует после нажатия. Это и есть микроанимация — маленькая деталь, которая превращает холодный цифровой интерфейс в теплый, отзывчивый и понятный диалог между пользователем и системой.

Часть 1. Что такое микроанимация и зачем она нужна?

Микроанимация (или микровзаимодействие) — это небольшие, целенаправленные анимации, которые происходят в ответ на действие пользователя или изменение состояния интерфейса. Они длятся доли секунды (обычно 200–400 мс) и не привлекают к себе излишнего внимания, но именно они делают интерфейс «живым» и интуитивно понятным.

Важно понимать разницу: микроанимация — это не декоративная заставка и не полноценный видеоролик. Это функциональный инструмент, который помогает пользователю понять, что происходит.

«Микроанимации — это как специи в еде. Без них — пресно. Слишком много — несъедобно. Правильная дозировка — шедевр».

Сам термин был введен дизайнером Дэном Саффером, который определил четыре ключевых компонента любого микровзаимодействия:

Почему микроанимации так эффективны?

Наш мозг запрограммирован обращать внимание на движение. С эволюционной точки зрения движение могло означать «еду», «опасность» или «потенциального партнера». Микроанимации обращаются к этой древней части нашего сознания, выполняя сразу несколько важных функций:

Предоставление обратной связи — пользователь видит, что его действие зарегистрировано.
Снижение когнитивной нагрузки — плавные переходы помогают не «терять» элементы из виду.
Направление внимания — анимация указывает, куда смотреть или что делать дальше.
Маскировка задержек — интересная анимация загрузки скрашивает ожидание.
Создание эмоциональной связи — приятные мелочи вызывают радость и формируют лояльность.

Исследования подтверждают: 70% пользователей чувствуют себя более вовлеченными при работе с интерфейсами, которые используют продуманные микровзаимодействия. А люди распознают анимированные элементы на 60% быстрее, чем статичные.

Однако есть и обратная сторона. Те же исследования показывают: 73% пользователей раздражаются от излишних анимаций и ищут способ их отключить. Google, например, выяснил, что каждые 100 мс задержки в интерфейсе снижают конверсию на 1%. Медленные анимации — это не «красиво», это дорого.

Часть 2. Типы микроанимаций: что, где и когда уместно?

Микроанимации решают разные задачи. Условно их можно разделить на несколько категорий:

1. Обратная связь (Feedback)

Это самый базовый и важный тип. Пользователь совершил действие — интерфейс подтвердил, что заметил это.

Где использовать: кнопки, переключатели, чекбоксы, поля ввода.
Как выглядит: кнопка слегка «вдавливается» при нажатии (scale: 0.98), чекбокс плавно заполняется галочкой, поле ввода подсвечивается зеленым при правильном заполнении или красным при ошибке.
Зачем: устраняет тревогу «а сработало ли?». Исследование Якоба Нильсена показало: 82% пользователей нажимают кнопку повторно, если нет видимой реакции в первые 200 мс.

2. Статус системы (Status)

Информирует о процессе, который происходит в данный момент.

Где использовать: загрузка страниц, отправка форм, синхронизация данных.
Как выглядит: спиннеры (крутящиеся индикаторы), прогресс-бары, skeleton screens (пульсирующие каркасы страницы).
Зачем: показывает, что система «жива» и работает, даже если процесс занимает время. Skeleton screens, в частности, создают иллюзию быстрой загрузки и снижают воспринимаемое время ожидания.

3. Навигация и переходы (Transition)

Объясняют, как изменилась структура интерфейса и куда «переместился» пользователь.

Где использовать: переключение между экранами, открытие/закрытие меню, модальные окна, аккордеоны.
Как выглядит: новый экран въезжает справа, старый уезжает влево (как в мобильных приложениях); меню выезжает сверху; аккордеон плавно раскрывается, показывая скрытый контент.
Зачем: помогает пользователю не потерять контекст. Исследования показывают, что анимированные переходы снижают время поиска элементов на 30–40%.

4. Направление внимания (Guidance)

Подсказывают пользователю, куда смотреть или что делать дальше.

Где использовать: онбординг (обучение), сложные формы, важные призывы к действию.
Как выглядит: кнопка «Далее» мягко пульсирует; поле ввода подсвечивается; появляется подсказка со стрелкой, указывающей на нужный элемент.
Зачем: снижает когнитивную нагрузку в процессе обучения и помогает пользователю не «застревать» на сложных этапах.

5. Эмоциональная связь (Delight)

Самый «необязательный», но самый запоминающийся тип. Создает вау-эффект и укрепляет бренд.

Где использовать: лайки, достижения, поздравления, пустые состояния.
Как выглядит: сердечко лайка не просто закрашивается, а пульсирует или превращается в стаю бабочек; при завершении задачи вылетает анимированное конфетти; в «пустой корзине» грустная корзинка вздыхает.
Зачем: вызывает положительные эмоции, делает продукт «человечным» и запоминающимся. Классический пример — анимированный единорог, пролетающий по экрану в Asana после завершения сложной задачи.

Часть 3. Принципы хорошей микроанимации: как не навредить?

Микроанимация — это мощный инструмент, но в неумелых руках она становится источником фрустрации. Вот основные принципы, которые помогут сделать анимацию помощником, а не врагом.

1. Функциональность прежде всего

Каждая анимация должна решать конкретную задачу, а не просто «быть красивой». Прежде чем добавить эффект, спросите себя: «Помогает ли эта анимация пользователю понять, что происходит?» Если нет — откажитесь от нее.

2. Скорость и тайминг

Микроанимация должна быть быстрой. Пользователь не должен ждать.

Базовые интеракции (наведение, нажатие): 100–200 мс.
Переходы между экранами, раскрытие элементов: 300–400 мс.
Сложные, кастомные анимации: максимум 500–600 мс.

Всё, что длится дольше 600 мс, — это уже не «микро», а полноценная анимация, которая начинает раздражать и тормозить работу.

3. Скорость и «характер движения» (Easing)

Не менее важно, как движется объект. Линейное движение (с постоянной скоростью) выглядит неестественно и роботизированно. Используйте easing-функции, которые имитируют физику реального мира:

ease-out — для появления элементов (быстро вначале, плавно замедляется в конце). Создает ощущение мягкого прибытия.
ease-in-out — для переходов между состояниями (плавно ускоряется и плавно замедляется). Выглядит органично.

4. Консистентность (единообразие)

Анимации должны быть предсказуемыми и соответствовать друг другу на всем протяжении продукта. Если кнопка «Сохранить» при нажатии слегка увеличивается на одной странице, она должна делать то же самое и на всех остальных. Единый «характер» анимации создает у пользователя ощущение целостности и мастерства продукта.

5. Ненавязчивость (Subtlety)

Хорошая микроанимация — это фон, а не главный герой. Она не должна отвлекать от основной задачи. Анимация должна быть заметна ровно настолько, чтобы быть полезной, и не более того.

6. Доступность (Accessibility)

Это критически важный принцип. У некоторых пользователей (например, с вестибулярными расстройствами) анимация может вызывать головокружение и тошноту.

Всегда используйте CSS-медиа-функцию prefers-reduced-motion.
Предусматривайте возможность отключить «тяжелую» (декоративную) анимацию в настройках, оставив только функциональную.
Дублируйте визуальную обратную связь тактильной (вибрация) или звуковой, где это уместно, но не делайте ни один из каналов единственным источником информации.

Часть 4. Лучшие примеры микроанимаций

Теория хороша, но примеры вдохновляют. Вот несколько ярких кейсов, которые стоит изучить.

Поиск Google

Анимация не в самом поиске, а в автоподсказках. По мере ввода текста появляются и обновляются варианты запросов. Это не просто удобно, но и создает ощущение, что система «думает вместе с вами» и реагирует на каждое ваше действие.

Google Assistant

Когда вы говорите «Окей, Google», на экране появляются четыре цветные точки, которые начинают двигаться, показывая, что ассистент «слушает». Когда вы замолкаете, анимация меняется, сигнализируя о готовности к ответу. Это идеальный пример того, как анимация делает невидимый процесс (обработку голоса) понятным и прозрачным.

Анимация на сайте Apple

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

Завершение задач в Asana

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

Часть 5. Инструменты и технологии

Внедрить микроанимацию можно разными способами — от простых CSS-стилей до сложных библиотек.

CSS-анимации — идеальны для простых эффектов при наведении (hover), изменении цвета, размера, прозрачности. Легко реализуются, отлично поддерживаются всеми браузерами.
GreenSock Animation Platform (GSAP) — мощнейшая JavaScript-библиотека для создания сложных, высокопроизводительных анимаций с точным контролем тайминга и последовательности. Выбор профессионалов для нестандартных задач.
Lottie — библиотека от Airbnb, которая позволяет встраивать сложные векторные анимации (созданные в Adobe After Effects) в веб и мобильные приложения. Файлы Lottie (в формате JSON) легковесны и масштабируются без потери качества. Идеально для иконок, иллюстраций, заставок.
Framer Motion, React Spring — для тех, кто работает в экосистеме React. Позволяют декларативно описывать анимации прямо в компонентах.
Конструкторы сайтов (Tilda, Webflow, Readymag) — имеют встроенные инструменты для создания микроанимаций (эффекты при наведении, появление при скролле) без единой строки кода.

Часть 6. Заключение

Микроанимация — это не просто «приятный бонус», а неотъемлемая часть современного пользовательского опыта. Она — тот самый «секретный ингредиент», который превращает функциональный, но холодный интерфейс в отзывчивого, понятного и даже эмпатичного цифрового собеседника.

Она решает конкретные задачи:

Убирает неопределенность, давая мгновенную обратную связь.
Снижает когнитивную нагрузку, делая навигацию интуитивной.
Создает положительные эмоции, формируя лояльность к бренду.

Но, как и любой мощный инструмент, микроанимация требует осознанного подхода. Слишком много, слишком быстро, слишком хаотично — и вместо помощи она становится помехой. Ваша задача — найти ту самую золотую середину, где анимация работает незаметно, но эффективно, где она комфортна и доступна для всех.

Начните с малого: добавьте плавное изменение цвета на кнопке, анимируйте появление подсказки, сделайте переход между экранами менее резким. Протестируйте это на реальных пользователях. Вы увидите, как маленькие изменения сделают ваш продукт значительно более «живым» и любимым. Ведь дьявол, как известно, кроется в деталях, но именно в этих деталях — и вся магия.

Gitlab CI: запуск пайплайна при обновлении upstream-репозитория

2026-06-04T13:22:57Z

Сегодня в этой небольшой заметке мы покажем пример файла .gitlab-ci.yml, который описывает пайплайн, осуществляющий какие-либо действия с нашим репозиторием в момент, когда в другом проекте выходит новая версия. Типичный сценарий, при котором подобное может пригодиться – это необходимость вызова скрипта для обновления локальной копии репозитория, представляющего собой форк другого проекта (назовем его upstream), когда в оригинальном репозитории появляются изменения.

В первую очередь, необходимо решить, каким образом мы будем определять наиболее актуальную версию upstream. Чтобы не скачивать репозиторий целиком, удобнее будет воспользоваться командой git ls-remote, которая показывает список всех ссылок (веток, тегов и HEAD) в удаленном репозитории вместе с их ID коммитов (SHA-1). Так мы узнаем, появились ли новые коммиты. В нашем случае будем искать по тегам, так как это весьма удобный способ получить список готовых к использованию версий с номерами, чтобы по ним фильтровать и отслеживать, как далеко ушли изменения.

Если запустить команду без дополнительных флагов, то мы получим нечто вроде

b9a2c14f7...1a2b3c4d    HEAD
b9a2c14f7...1a2b3c4d    refs/heads/main
a1b2c3d4e...5f6g7h8i    refs/tags/v1.0.0

где будет длинный список вообще всех ссылок. Чтобы из этого получить последнюю актуальную версию, придется применить несколько фильтров. В итоге получится подобная команда:

git ls-remote --tags "$UPSTREAM_URL" | awk -F'/' '{print $3}' | grep -v '\^{}' | grep -E '^v?[0-9]+\.[0-9]+\.[0-9]+$' | sort -V | tail -n 1

Здесь мы последовательно указываем, что берем лишь теги; очищаем строки от хэшей коммитов и части с refs/..; оставляем только числа и точки, чтобы вычленить версию; сортируем и берем только последний (самый актуальный) тег. В итоге будет лишь строка с версией, которая соответствует тегу.

Чтобы понять, есть ли в нашем репозитории самая актуальная версия upstream, можно проверить, существует ли ветка, содержащая в названии номер версии (хотя это сильно зависит от специфики проекта, но вариант кажется логичным). Для этого также вполне подойдет git ls-remote, но уже с флагом --heads. Так мы сможем получить ветку нашего репозитория, которая содержит в себе тег (точки заменили на дефис)

git ls-remote --heads "${YOUR_REPO}" | grep "${LATEST_TAG//./-}"

Переходя же непосредственно к пайплайну, предположим, что исходным у нас является базовый питоновский докер образ (например python:3.10-slim), в который через Dockerfile добавили произвольный python скрипт, призванный обновить локальный репозиторий правками из upstream. Его логику рассматривать не будем, поскольку она своя для кажого конкретного случая. Но что может понадобиться, так это определить ту ветку в нашем проекте, где лежат самые актуальные изменения (например, чтобы перенести их оттуда в ветку для новой версии). Для этого придется использовать уже git branch -r --sort=-committerdate | grep "origin/.*-main$", чтобы отсортировать ветки репозитория по дате последнего коммита.

В итоге получим вот такой файл .gitlab-ci.yml (с поясняющими комментариями):

image:
  name: dr.example.ru/your-script:latest
  entrypoint: [""]

variables:
  UPSTREAM_URL: "https://github.com/something.git"
  YOUR_APPLICATION_REPO_URL: "${CI_SERVER_HOST}/your-application.git"
  YOUR_APPLICATION_REPO_PATH: "${CI_PROJECT_DIR}/your-application"
  
stages:
  - check-version
  - update-repo


# проверка, есть ли новая версия upstream репозитория
check_new_version:
  stage: check-version
  rules:
    # Запускаем по планировщику, а после коммита - только при ручном действии
    - if: $CI_PIPELINE_SOURCE == "schedule"
      when: always
    - if: $CI_PIPELINE_SOURCE == "web"
      when: always
    - if: $CI_PIPELINE_SOURCE == "push"
      when: manual
  script:
    - YOUR_REPO="https://oauth2:${PROJECT_PUSH_TOKEN}@${YOUR_APPLICATION_REPO_URL}"
    # самый актуальный тег версии из upstream, как описывали
    - LATEST_TAG=$(git ls-remote --tags "$UPSTREAM_URL" | awk -F'/' '{print $3}' | grep -v '\^{}' | grep -E '^v?[0-9]+\.[0-9]+\.[0-9]+$' | sort -V | tail -n 1)
    # проверка на наличие ветки с таким тегом в названии уже в нашем репозитории
    - IF_CORRESPONDING_BRANCH_EXISTS=$(git ls-remote --heads "${YOUR_REPO}" | grep "${LATEST_TAG//./-}" || true)
    # если есть века - все обновлено, выставляем флаг, если нет - то нужно какое-то действие
    - |
      if [ -n "$IF_CORRESPONDING_BRANCH_EXISTS" ]; then
        echo "Состояние актуально. Новой версии upstream не обнаружено"
        echo "NEEDS_UPDATE=false" >> check.env
      else 
        echo "Обнаружена новая версия ($LATEST_TAG)"
        echo "NEEDS_UPDATE=true" >> check.env
        echo "NEW_UPSTREAM_VERSION=$LATEST_TAG" >> check.env
      fi
  artifacts:
    # сохраняем переменные окружения для следующего этапа
    reports:
      dotenv: check.env


# полезная работа при обновлении upstream
do_on_update:
  stage: update-repo
  before_script:
    # проверяем переменную, если обновление не нужно, то выходим, не вызывая ошибку 
    - |
      if [ "$NEEDS_UPDATE" != "true" ]; then
        echo "Состояние актуально. Ничего не требуется"
        exit 0
      fi
  script:
    # клонируем наш репозиторий с фильтром blob:none, чтобы он не занимал много места, а хранил лишь саму структуру репозитория (что надо подгрузится лениво) 
    - git clone --filter=blob:none --no-checkout https://oauth2:${PROJECT_PUSH_TOKEN}@${YOUR_APPLICATION_REPO_URL} ${YOUR_APPLICATION_REPO_PATH}
    - cd ${YOUR_APPLICATION_REPO_PATH}
    # получаем по регулярному выражению самую свежую ветку в локальном репозитории (например, забрать оттуда наши правки)
    - REQUIRED_BRANCH=$(git branch -r --sort=-committerdate | grep "origin/.*-main$" | head -n 1 | awk '{$1=$1; print $1}')
    # запустить скрипт, который нужно запустить при новой версии upstream
    - python /app/your_script.py --branch ${REQUIRED_BRANCH}

Для настройки запуска по планировщику стандартно надо перейти в интерфейс Gitlab, выбрать там Build -> Pipeline schedules и задать нужные параметры.

В конечном итоге мы получим пайплайн, который запускается в указанный промежуток времени, проверяет upstream. Если там появляется новый тег (в нашем репозитории еще нет ветки для такой версии), то запускается скрипт для обновления, который обрабатывает самую новую ветку из локального репозитория. Если такой тег у нас уже есть (то есть нет обновлений в upstream), то пайплайн просто покажет все стадии успешно выполненными.

Эволюция инженера: как перейти в AI Engineering, не бросая всё, что вы умеете

2026-06-01T08:56:46Z

Введение: почему этот разговор важен именно сейчас

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

Речь идёт не об очередной волне хайпа, которую можно переждать. Это структурное изменение в том, как строятся программные продукты. И здесь возникает закономерный вопрос: что делать опытному разработчику, который строил надёжные системы на протяжении многих лет, но никогда не обучал нейронные сети и не работал с векторными базами данных?

Ответ, как это ни парадоксально, гораздо менее пугающий, чем кажется на первый взгляд. AI Engineering - это не новая профессия с нуля. Это расширение классической инженерной практики новым инструментальным слоем. Большая часть того, что вы уже умеете - проектирование API, работа с базами данных, управление состоянием, асинхронная обработка, паттерны проектирования - остаётся не просто релевантной, а критически важной.

Эта статья написана именно для тех, у кого есть крепкая инженерная база и кто хочет понять, как органично встроить AI-инструменты в свой профессиональный арсенал.

Часть первая: Деконструкция иллюзий

Почему опытные разработчики избегают AI-тематики

Парадокс состоит в следующем: именно те инженеры, которым проще всего войти в AI Engineering, нередко сопротивляются этому дольше всех.

Причин несколько, и они вполне понятны:

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

Вторая - профессиональная идентичность. Инженер, который годами гордился умением строить надёжные, предсказуемые системы, сталкивается с инструментами, которые по самой своей природе являются вероятностными. Это создаёт когнитивный дискомфорт: как строить систему, если один из её ключевых компонентов может давать разные ответы на один и тот же вопрос?

Третья - профессиональный снобизм, который иногда принимает форму скептицизма.

"Это просто автодополнение текста в промышленных масштабах".

Это отчасти верно с технической точки зрения, но совершенно не отменяет практической ценности инструмента.

Ни одна из этих причин не является достаточным основанием для того, чтобы игнорировать происходящие изменения.

Часть вторая: Технические основы - архитектурный взгляд

Шаг 1. Понимание механики генеративного ИИ

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

Для практикующего бэкенд-инженера взаимодействие с LLM через API - это, по существу, вызов внешнего микросервиса. Разница в одном: этот сервис не детерминирован. На один и тот же запрос он может вернуть разные ответы. Это не баг - это фундаментальное свойство, которым нужно научиться управлять.

Несколько концепций, которые необходимо понять на базовом уровне:

Токенизация. Токен - это не слово и не символ. Это единица текста, которую модель обрабатывает за один шаг. В зависимости от языка и модели один токен приблизительно соответствует четырём символам в английском тексте или двум-трём символам в русском. Это имеет прямые практические следствия: вы платите за токены, контекстное окно измеряется в токенах, и именно токены определяют, сколько информации модель может "удержать в голове" за один вызов.

Эмбеддинги. Представьте, что любой текст - слово, предложение, абзац - можно описать точкой в многомерном пространстве так, что семантически близкие тексты окажутся рядом друг с другом. Именно это делают эмбеддинги. Если вы работали с индексами в базах данных или с алгоритмами хеширования, думайте об эмбеддингах как о семантическом индексе смысла. Расстояние между двумя векторами - это мера смысловой близости двух текстов.

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

Контекстное окно. Это максимальный объём информации, который модель может обработать за один вызов. Современные модели имеют контекстные окна от нескольких десятков тысяч до нескольких миллионов токенов. Управление контекстом - одна из ключевых инженерных задач при построении AI-приложений.

Вот базовый пример взаимодействия с языковой моделью через API:

import openai
 
client = openai.Client(api_key="your_api_key")
 
response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {
            "role": "system",
            "content": (
                "Ты — старший инженер-программист. "
                "Отвечай точно и по существу, без лишних слов."
            )
        },
        {
            "role": "user",
            "content": "Объясни разницу между эмбеддингами и хэш-функциями."
        }
    ],
    temperature=0.0,   # Нулевая температура для точных, воспроизводимых ответов
    max_tokens=500
)
 
print(response.choices[0].message.content)
 
# Не забывайте обрабатывать метаданные вызова:
usage = response.usage
print(f"Использовано токенов: {usage.total_tokens} "
      f"(запрос: {usage.prompt_tokens}, ответ: {usage.completion_tokens})")

Обратите внимание на параметр temperature=0.0. Когда вы строите систему, которая должна анализировать логи, парсить документы или генерировать структурированные данные, детерминированность важнее разнообразия. Это инженерное решение, а не "магический" параметр.

Шаг 2. Структурирование хаоса: от текста к типизированным объектам

Одна из главных болей при интеграции языковых моделей в классический бэкенд - это работа с неструктурированным выводом. Ваша база данных ожидает конкретные типы, фронтенд - строгий JSON-контракт, а оркестрирующий код - предсказуемые объекты с известными полями. Языковая модель по умолчанию возвращает свободный текст.

Решение этой проблемы - принудительная типизация вывода через валидационные схемы. Концептуально это аналог паттерна DTO (Data Transfer Object) в классической архитектуре, только применённый к вероятностному компоненту системы.

В экосистеме Python стандартом де-факто стал Pydantic в связке с соответствующими инструментами LangChain.

Принцип прост: вы описываете схему ожидаемого ответа, передаёте её инструкции в промпт, и парсер принудительно приводит вывод модели к заданному типу.

from pydantic import BaseModel, Field
from typing import Literal
from langchain_openai import ChatOpenAI
from langchain.output_parsers import PydanticOutputParser
from langchain.prompts import PromptTemplate
 
# Описываем схему так же, как описывали бы DTO или схему базы данных
class LogAnalysis(BaseModel):
    severity: Literal["INFO", "WARNING", "ERROR", "FATAL"] = Field(
        description="Уровень критичности события"
    )
    affected_service: str = Field(
        description="Название микросервиса, в котором произошла ошибка"
    )
    root_cause: str = Field(
        description="Краткое описание предполагаемой причины проблемы"
    )
    recommended_action: str = Field(
        description="Рекомендуемое первоочередное действие для устранения проблемы"
    )
    is_production_affecting: bool = Field(
        description="True, если ошибка влияет на продакшен прямо сейчас"
    )
 
parser = PydanticOutputParser(pydantic_object=LogAnalysis)
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)
 
prompt = PromptTemplate(
    template=(
        "Ты — старший SRE-инженер. "
        "Проанализируй следующую строку лога и верни структурированный анализ.\n\n"
        "{format_instructions}\n\n"
        "Строка лога:\n{log_entry}\n"
    ),
    input_variables=["log_entry"],
    partial_variables={"format_instructions": parser.get_format_instructions()},
)
 
chain = prompt | llm | parser
 
log_line = "[2024-01-15 03:47:22] FATAL: Connection pool exhausted in payment-gateway-service. Active connections: 512/512. Queue depth: 847."
 
result: LogAnalysis = chain.invoke({"log_entry": log_line})
 
# Теперь result — это строго типизированный объект, а не свободный текст
print(f"Сервис: {result.affected_service}")
print(f"Критичность: {result.severity}")
print(f"Влияет на продакшен: {result.is_production_affecting}")
print(f"Рекомендация: {result.recommended_action}")

Практическая ценность этого подхода становится очевидна, когда вы встраиваете подобный анализатор в реальный пайплайн: результат можно сразу записывать в базу данных, отправлять в систему управления инцидентами или использовать как условие для маршрутизации алертов.

Важно учитывать, что Pydantic-парсер внутри себя делает дополнительный вызов модели при ошибке формата. Если надёжность важнее скорости, используйте with_structured_output напрямую через OpenAI - это использует нативную поддержку JSON Schema на уровне API и более устойчиво к ошибкам:

from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
 
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)
structured_llm = llm.with_structured_output(LogAnalysis)
 
prompt = ChatPromptTemplate.from_messages([
    ("system", "Ты — старший SRE-инженер. Проанализируй строку лога."),
    ("user", "{log_entry}")
])
 
chain = prompt | structured_llm
result = chain.invoke({"log_entry": log_line})

Шаг 3. От простых вызовов к агентам

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

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

С точки зрения классической архитектуры это напоминает паттерн Strategy: у вас есть интерфейс "инструмент", конкретные реализации (поиск в базе данных, вызов внешнего API, расчёт), и оркестратор, который выбирает нужную стратегию. Только в данном случае оркестратором выступает языковая модель.

from langchain_openai import ChatOpenAI
from langchain.agents import create_tool_calling_agent, AgentExecutor
from langchain_core.tools import tool
from langchain_core.prompts import ChatPromptTemplate
import requests
 
# Определяем инструменты как обычные Python-функции
@tool
def get_service_metrics(service_name: str) -> dict:
    """
    Возвращает текущие метрики сервиса: CPU, память, количество запросов в секунду.
    Используй этот инструмент, когда нужно проверить состояние конкретного сервиса.
    """
    # В реальном коде здесь был бы запрос к Prometheus или DataDog
    return {
        "service": service_name,
        "cpu_usage": 87.3,
        "memory_mb": 1842,
        "rps": 1243,
        "error_rate": 0.023,
        "p99_latency_ms": 342
    }
 
@tool
def create_incident(severity: str, title: str, description: str) -> str:
    """
    Создаёт инцидент в системе управления инцидентами (например, PagerDuty или Opsgenie).
    Используй только при severity ERROR или FATAL.
    """
    # В реальном коде здесь был бы вызов API системы инцидентов
    incident_id = f"INC-{hash(title) % 10000:04d}"
    return f"Инцидент создан: {incident_id}"
 
@tool
def get_recent_deployments(service_name: str, hours: int = 24) -> list:
    """
    Возвращает список деплойментов сервиса за последние N часов.
    Полезно для корреляции проблем с недавними изменениями в коде.
    """
    return [
        {"time": "2024-01-15 02:30:00", "version": "v2.4.1", "author": "deploy-bot"},
        {"time": "2024-01-15 00:15:00", "version": "v2.4.0", "author": "deploy-bot"}
    ]
 
tools = [get_service_metrics, create_incident, get_recent_deployments]
 
llm = ChatOpenAI(model="gpt-4o", temperature=0)
 
prompt = ChatPromptTemplate.from_messages([
    ("system", (
        "Ты — автоматизированный SRE-ассистент. "
        "Анализируй проблемы, собирай метрики и при необходимости создавай инциденты. "
        "Всегда проверяй метрики перед созданием инцидента."
    )),
    ("human", "{input}"),
    ("placeholder", "{agent_scratchpad}"),
])
 
agent = create_tool_calling_agent(llm, tools, prompt)
executor = AgentExecutor(agent=agent, tools=tools, verbose=True)
 
response = executor.invoke({
    "input": "Получили алерт: payment-gateway-service начал возвращать 503 ошибки. "
             "Проверь метрики, посмотри недавние деплойменты и реши, нужно ли создавать инцидент."
})
 
print(response["output"])

В этом примере агент самостоятельно решает, в каком порядке вызывать инструменты: сначала собирает метрики, затем проверяет деплойменты, и только после этого принимает решение о создании инцидента. Вы не пишете эту логику явно - модель выводит её из описаний инструментов и контекста задачи.

Шаг 4. Управление состоянием сложных агентных систем

Когда число шагов в агентном пайплайне растёт, а логика ветвления становится нетривиальной, код на базе простого AgentExecutor начинает деградировать в запутанный клубок условных операторов. Это знакомая проблема: достаточно вспомнить любой крупный сервис, где бизнес-логика постепенно превратилась в лабиринт if-else.

Индустрия решает эту проблему с помощью LangGraph - библиотеки для построения агентных систем на основе ориентированных графов. С архитектурной точки зрения LangGraph реализует конечный автомат (Finite State Machine), где узлы - это функции или сервисы обработки, а рёбра - это правила переходов между ними.

Ключевое отличие от классической FSM заключается в том, что решение о переходе из одного состояния в другое может принимать языковая модель, а не жёстко заданное условие.

from typing import TypedDict, Annotated, Optional
from langgraph.graph import StateGraph, END
from langchain_openai import ChatOpenAI
from langchain_core.messages import HumanMessage, AIMessage
import operator
 
# Состояние, которое передаётся между узлами графа
class SupportTicketState(TypedDict):
    ticket_id: str
    user_message: str
    category: Optional[str]           # Категория обращения (billing, technical, general)
    sentiment: Optional[str]          # Тональность (positive, neutral, negative, angry)
    response: Optional[str]           # Сгенерированный ответ
    needs_human: bool                 # Флаг эскалации на живого оператора
    history: Annotated[list, operator.add]  # Лог обработки
 
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)
 
# Узел 1: классификация обращения
def classify_ticket(state: SupportTicketState) -> SupportTicketState:
    classification_prompt = f"""
    Классифицируй обращение пользователя. Верни ТОЛЬКО JSON с двумя ключами:
    - "category": одно из ["billing", "technical", "general", "complaint"]
    - "sentiment": одно из ["positive", "neutral", "negative", "angry"]
    
    Обращение: {state['user_message']}
    """
    response = llm.invoke([HumanMessage(content=classification_prompt)])
    
    import json, re
    data = json.loads(re.search(r'\{.*\}', response.content, re.DOTALL).group())
    
    return {
        "category": data["category"],
        "sentiment": data["sentiment"],
        "history": [f"Классифицировано: {data['category']}, тональность: {data['sentiment']}"]
    }
 
# Узел 2: генерация ответа
def generate_response(state: SupportTicketState) -> SupportTicketState:
    system_context = {
        "billing": "Ты — специалист по биллингу. Будь чётким и предоставь конкретные цифры.",
        "technical": "Ты — технический специалист поддержки. Давай пошаговые инструкции.",
        "general": "Ты — специалист общей поддержки. Будь дружелюбным и полезным.",
        "complaint": "Ты — менеджер по работе с клиентами. Проявляй эмпатию и предлагай решения."
    }
    
    context = system_context.get(state["category"], system_context["general"])
    response = llm.invoke([
        HumanMessage(content=f"Системный контекст: {context}\n\nОбращение: {state['user_message']}")
    ])
    
    return {
        "response": response.content,
        "history": ["Ответ сгенерирован"]
    }
 
# Узел 3: эскалация на человека
def escalate_to_human(state: SupportTicketState) -> SupportTicketState:
    return {
        "needs_human": True,
        "response": "Ваше обращение передано старшему специалисту. Ожидайте ответа в течение 2 часов.",
        "history": ["Эскалировано на живого оператора"]
    }
 
# Маршрутизатор: определяет, нужна ли эскалация
def route_after_classification(state: SupportTicketState) -> str:
    # Гневные обращения или жалобы сразу идут к живому оператору
    if state["sentiment"] == "angry" or state["category"] == "complaint":
        return "escalate"
    return "generate_response"
 
# Сборка графа
workflow = StateGraph(SupportTicketState)
 
workflow.add_node("classify", classify_ticket)
workflow.add_node("generate_response", generate_response)
workflow.add_node("escalate", escalate_to_human)
 
workflow.set_entry_point("classify")
 
workflow.add_conditional_edges(
    "classify",
    route_after_classification,
    {
        "escalate": "escalate",
        "generate_response": "generate_response"
    }
)
 
workflow.add_edge("generate_response", END)
workflow.add_edge("escalate", END)
 
app = workflow.compile()
 
# Запуск
result = app.invoke({
    "ticket_id": "TKT-001",
    "user_message": "Вы списали деньги дважды! Это уже второй раз за месяц!",
    "category": None,
    "sentiment": None,
    "response": None,
    "needs_human": False,
    "history": []
})
 
print(f"Нужен оператор: {result['needs_human']}")
print(f"Ответ: {result['response']}")
print(f"Лог обработки: {result['history']}")

Граф явно описывает все возможные пути обработки. Любой инженер, пришедший в проект после вас, может за несколько минут понять, какие состояния существуют и как осуществляются переходы между ними. Это и есть инженерная культура, применённая к AI-системам.

Шаг 5. Архитектура RAG: дать модели доступ к вашим данным

У любой языковой модели есть фундаментальное ограничение: она знает только то, на чём была обучена. Ваша внутренняя документация, база знаний, архивы тикетов, технические спецификации - всё это для неё terra incognita. Паттерн RAG (Retrieval-Augmented Generation) решает именно эту проблему.

Для опытного инженера RAG - это хорошо известная архитектурная связка: поисковый индекс плюс кэш контента плюс сервис обработки запросов. Новизна заключается в том, что поиск осуществляется не по ключевым словам, а по семантической близости - с использованием эмбеддингов.

Схема работы следующая: документы разбиваются на фрагменты, каждый фрагмент превращается в вектор (эмбеддинг) и сохраняется в специализированной векторной базе данных. При поступлении пользовательского запроса система находит семантически близкие фрагменты и передаёт их языковой модели вместе с исходным вопросом. Модель отвечает, опираясь на предоставленный контекст.

from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_community.vectorstores import FAISS
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.runnables import RunnablePassthrough
from langchain_core.output_parsers import StrOutputParser
from langchain.schema import Document
 
# --- Этап 1: Подготовка индекса (выполняется один раз при инициализации) ---
 
# Ваша документация или база знаний
documents = [
    Document(
        page_content="""
        API аутентификации использует JWT-токены с временем жизни 15 минут.
        Refresh-токены хранятся в Redis с TTL 30 дней.
        При истечении access-токена клиент должен вызвать endpoint /auth/refresh.
        Endpoint /auth/refresh принимает только HTTP POST запросы.
        При невалидном refresh-токене возвращается 401 с кодом ошибки TOKEN_EXPIRED.
        """,
        metadata={"source": "auth-service-docs.md", "section": "authentication"}
    ),
    Document(
        page_content="""
        Сервис платежей поддерживает следующие провайдеры: Stripe, PayPal, YooKassa.
        Все транзакции логируются в таблицу payment_transactions с retention 7 лет.
        При сумме транзакции свыше 100 000 рублей требуется дополнительная верификация.
        Верификация осуществляется через SMS-код или подтверждение по email.
        Максимальное число попыток верификации — 3, после чего транзакция блокируется.
        """,
        metadata={"source": "payment-service-docs.md", "section": "payments"}
    ),
    Document(
        page_content="""
        Деплойменты в продакшен осуществляются через GitLab CI/CD.
        Каждый деплоймент проходит 4 стадии: test, build, staging, production.
        Стадия production требует ручного подтверждения от tech lead или CTO.
        Rollback выполняется командой: kubectl rollout undo deployment/<service-name>.
        Среднее время полного деплоймента — 12 минут при отсутствии проблем.
        """,
        metadata={"source": "deployment-runbook.md", "section": "deployments"}
    )
]
 
# Разбиваем на чанки с перекрытием для сохранения контекста
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,        # Символов в одном фрагменте
    chunk_overlap=50,      # Перекрытие между фрагментами — важно для сохранения контекста
    separators=["\n\n", "\n", ". ", " "]
)
 
split_docs = text_splitter.split_documents(documents)
 
# Создаём векторный индекс
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
vectorstore = FAISS.from_documents(split_docs, embeddings)
 
# --- Этап 2: Построение цепочки RAG ---
 
retriever = vectorstore.as_retriever(
    search_type="similarity",
    search_kwargs={"k": 3}  # Возвращаем 3 наиболее релевантных фрагмента
)
 
def format_docs(docs):
    """Форматируем найденные документы для передачи в промпт"""
    return "\n\n---\n\n".join(
        f"Источник: {doc.metadata.get('source', 'неизвестен')}\n{doc.page_content}"
        for doc in docs
    )
 
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)
 
prompt = ChatPromptTemplate.from_messages([
    ("system", (
        "Ты — внутренний технический ассистент компании. "
        "Отвечай ТОЛЬКО на основе предоставленной документации. "
        "Если ответ не содержится в документации, прямо скажи об этом. "
        "Всегда указывай источник информации.\n\n"
        "Документация:\n{context}"
    )),
    ("human", "{question}")
])
 
rag_chain = (
    {"context": retriever | format_docs, "question": RunnablePassthrough()}
    | prompt
    | llm
    | StrOutputParser()
)
 
# --- Этап 3: Использование ---
 
questions = [
    "Как долго живёт refresh-токен?",
    "Что происходит при попытке перевести 150 000 рублей?",
    "Сколько длится деплоймент в продакшен?"
]
 
for question in questions:
    print(f"\nВопрос: {question}")
    print(f"Ответ: {rag_chain.invoke(question)}")
    print("-" * 60)

Здесь важно понять одну вещь: 80% качества RAG-системы определяется не выбором языковой модели, а качеством инженерии вокруг неё. Как вы разбиваете документы на фрагменты? Насколько правильно структурированы метаданные? Как настроены параметры поиска? Это классические инженерные вопросы, а не задачи машинного обучения.

Ключевые решения при построении RAG:

Размер чанка определяет компромисс между точностью поиска и полнотой контекста. Слишком маленькие чанки - модель не получает достаточного контекста; слишком большие - снижается точность семантического поиска. Хорошая отправная точка для технической документации: 400-600 символов с перекрытием 10-15%.
Метаданные критически важны для фильтрации. Добавляйте к каждому фрагменту источник, дату обновления, раздел, тип документа. Это позволяет строить гибридный поиск: сначала фильтрация по метаданным, затем семантический поиск внутри отфильтрованного подмножества.
Оценка качества - это инженерная задача. Стройте набор тестовых пар "вопрос - ожидаемый ответ" и измеряйте качество системы автоматически при каждом изменении параметров.

Шаг 6. Потоковая передача и асинхронность

Вызов языковой модели - это долгая операция. Типичный ответ на сложный запрос занимает от 3 до 30 секунд. Если вы строите API, которое синхронно ждёт полного ответа модели, прежде чем вернуть что-либо клиенту, пользовательский опыт будет неприемлемым.

Решения те же, что и в классическом бэкенде: стриминг и асинхронность.

import asyncio
from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
 
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0.3, streaming=True)
 
prompt = ChatPromptTemplate.from_messages([
    ("system", "Ты — технический писатель. Пиши чётко и структурированно."),
    ("human", "{topic}")
])
 
chain = prompt | llm | StrOutputParser()
 
# Асинхронный стриминг — идеально для API на FastAPI
async def stream_response(topic: str):
    async for chunk in chain.astream({"topic": topic}):
        print(chunk, end="", flush=True)
        # В реальном API здесь был бы yield chunk для SSE или WebSocket
    print()  # Новая строка в конце
 
# Параллельная обработка нескольких запросов
async def process_multiple_queries(queries: list[str]) -> list[str]:
    tasks = [chain.ainvoke({"topic": q}) for q in queries]
    return await asyncio.gather(*tasks)
 
# Запуск
asyncio.run(stream_response(
    "Объясни разницу между RAG и fine-tuning языковых моделей"
))
```
 
Пример интеграции со стримингом в FastAPI:
 
```python
from fastapi import FastAPI
from fastapi.responses import StreamingResponse
from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
import asyncio
 
app = FastAPI()
llm = ChatOpenAI(model="gpt-4o-mini", streaming=True)
 
@app.get("/generate")
async def generate_stream(query: str):
    prompt = ChatPromptTemplate.from_messages([
        ("system", "Ты — полезный технический ассистент."),
        ("human", "{query}")
    ])
    chain = prompt | llm | StrOutputParser()
    
    async def event_generator():
        async for chunk in chain.astream({"query": query}):
            yield f"data: {chunk}\n\n"
        yield "data: [DONE]\n\n"
    
    return StreamingResponse(
        event_generator(),
        media_type="text/event-stream"
    )

Обратите внимание: astream не просто ускоряет ответ - он фундаментально меняет пользовательский опыт. Первые токены появляются уже через 200-500 миллисекунд, и пользователь видит, что система работает, даже если полный ответ формируется ещё несколько секунд.

Часть третья: Инженерный фундамент как конкурентное преимущество

Почему опыт классической разработки - это преимущество, а не балласт

Здесь возникает парадокс, который многие не сразу замечают. Рынок AI-инженеров сегодня переполнен людьми, которые умеют вызывать API языковых моделей и получать ответы. Но построить из этого надёжную, масштабируемую, поддерживаемую систему - совсем другая история.

Разработчик с десятью годами опыта проектирования распределённых систем принесёт в AI Engineering то, чего у энтузиастов-самоучек нет: понимание того, как системы ломаются, как они масштабируются, как ими управляют в продакшене.

Observability.

Классический бэкенд-инженер знает, что без нормального логирования, трейсинга и метрик система неуправляема. В AI-системах это особенно важно, потому что вероятностный компонент делает отладку значительно сложнее. Трассировка LLM-вызовов с захватом промптов, токенов и времени ответа - это не опциональная функция, это базовая good-practice.

import time
import logging
from functools import wraps
from dataclasses import dataclass
from typing import Any
 
logger = logging.getLogger(__name__)
 
@dataclass
class LLMCallMetrics:
    model: str
    prompt_tokens: int
    completion_tokens: int
    latency_ms: float
    success: bool
    error: str | None = None
 
def track_llm_call(func):
    """Декоратор для автоматического трекинга вызовов LLM"""
    @wraps(func)
    async def wrapper(*args, **kwargs):
        start = time.time()
        try:
            result = await func(*args, **kwargs)
            latency = (time.time() - start) * 1000
            
            # В реальной системе здесь — отправка в Prometheus/DataDog
            logger.info(
                "LLM call completed",
                extra={
                    "latency_ms": latency,
                    "function": func.__name__,
                }
            )
            return result
        except Exception as e:
            latency = (time.time() - start) * 1000
            logger.error(
                "LLM call failed",
                extra={
                    "latency_ms": latency,
                    "error": str(e),
                    "function": func.__name__,
                }
            )
            raise
    return wrapper

Управление стоимостью.

Каждый вызов языковой модели стоит денег. Классический инженер немедленно задаётся вопросами кэширования: какие запросы повторяются? Какой TTL у кэша разумен для данного типа запросов? Можно ли батчевать вызовы?

Обработка ошибок.

LLM API возвращает ошибки: rate limits, timeout, временная недоступность сервиса. Стратегия retry с экспоненциальным backoff, circuit breaker, fallback на альтернативную модель - всё это стандартная практика надёжного бэкенда, перенесённая в новый контекст.

import asyncio
from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type
from openai import RateLimitError, APITimeoutError
 
@retry(
    stop=stop_after_attempt(3),
    wait=wait_exponential(multiplier=1, min=4, max=10),
    retry=retry_if_exception_type((RateLimitError, APITimeoutError))
)
async def resilient_llm_call(messages: list, model: str = "gpt-4o-mini"):
    """Вызов LLM с автоматическим retry при временных ошибках"""
    response = await client.chat.completions.acreate(
        model=model,
        messages=messages,
        timeout=30
    )
    return response

Тестирование.

Как тестировать систему, компонент которой вероятностен? Классический инженер инстинктивно понимает, что нужно изолировать вероятностный компонент через моки и тестировать остальную логику детерминированно. Тесты на интеграцию с реальной моделью - это отдельный, более редкий уровень тестирования, который запускается не при каждом коммите.

Инструментальный стек AI-инженера в 2026 году

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

Оркестрация и цепочки: LangChain остаётся наиболее распространённым фреймворком для построения LLM-приложений. LangGraph - его расширение для сложных агентных систем. Для более лаконичного кода существует LlamaIndex, особенно популярный в RAG-сценариях.

Векторные базы данных: Chroma подходит для прототипов и небольших объёмов данных; Pinecone - для облачных продакшен-решений; Qdrant и Weaviate - для самостоятельного развёртывания с расширенными возможностями фильтрации; pgvector - если вы уже используете PostgreSQL и не хотите вводить дополнительную инфраструктуру.

Observability: LangSmith (от команды LangChain) - специализированный инструмент для трассировки LLM-вызовов; Weights & Biases - для более глубокого мониторинга и экспериментов; Phoenix от Arize - для оценки качества RAG-систем.

Оценка качества: RAGAS - фреймворк для автоматической оценки RAG-систем по метрикам faithfulness (верность источнику), answer relevancy (релевантность ответа) и context precision (точность контекста).

Заключение: правильный взгляд на трансформацию

Переход в AI Engineering - это не смена профессии. Это расширение профессионального контекста. Если переформулировать это в инженерных терминах: вы не мигрируете на новую платформу, вы добавляете новый слой абстракции поверх существующего стека.

Технические концепции, которые мы рассмотрели в этой статье: типизированный вывод, управление состоянием через конечные автоматы, поиск по векторным индексам, асинхронная обработка, стриминг - это не революционно новые идеи. Это переосмысление хорошо известных инженерных принципов применительно к новому классу компонентов.

Несколько практических рекомендаций для тех, кто готов начать:

Начните с задачи, которую вы хорошо понимаете. Возьмите реальную проблему из своей области: анализ логов, автоматизация code review, обработка технической документации, и решите её с помощью языковой модели. Знание предметной области поможет вам объективно оценить качество результата.

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

Читайте исходный код инструментов, которыми пользуетесь. LangChain, LangGraph - это Python-библиотеки с открытым кодом. Понимание того, что происходит под капотом, помогает избежать многих неожиданных проблем в продакшене.

Не переоценивайте роль модели. Подавляющее большинство проблем в AI-приложениях - это инженерные проблемы: качество данных, архитектура системы, обработка ошибок, управление состоянием. Смена модели к примеру с GPT-4o на Claude или наоборот редко кардинально меняет ситуацию. Инженерные решения - меняют.

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

У вас уже есть для этого фундамент. Теперь есть и карта.

UX-тексты для новичков: Как писать интерфейсы, которые говорят на языке пользователя

2026-05-06T17:33:50Z

Представьте: вы открываете приложение, чтобы удалить давно надоевшую подписку. Вы находите нужную кнопку... а на ней написано: «Деактивировать рекуррентный платёжный мандат». Что вы сделаете? Скорее всего, закроете приложение и подумаете: «Я слишком стар для этого».

Это не ваша проблема. Это проблема UX-письма (UX Writing).

UX-письмо — это проектирование слов в интерфейсе. Технически это написание текстов для кнопок, ошибок, подсказок, уведомлений — всего, с чем взаимодействует пользователь. По сути — это создание диалога между продуктом и человеком.

В этой статье разберём основы, на которые должен обратить внимание новичок, и главное — как не облажаться в первые же дни.

Что такое UX-тексты и чем они отличаются от копирайтинга?

Частая ошибка новичка: думать, что UX-тексты— это просто «покороче и подушевнее».

Золотое правило UX-текста:

Пользователь не должен думать о словах. Он должен смотреть на интерфейс и уже знать, что делать.

Пример:

Плохо (копирайтинг в интерфейсе): «Нажмите на эту волшебную кнопку, чтобы отправиться в захватывающее путешествие по миру скидок!»
Хорошо (UX-письмо): «Получить скидку»

На что обратить внимание новичку

1. Ясность превыше всего (Clarity > Cleverness)

Самый частый грех новичков — пытаться быть остроумным. Запомните: пользователь не ищет в вашем интерфейсе юмор. Он ищет способ закончить дело и уйти.

❌Остроумно, но непонятно: «Ой, что-то пошло не так с нашим магическим шаром...» (ошибка 500)
✅Понятно и полезно: «Не удалось загрузить данные. Проверьте соединение и попробуйте снова.»

Как проверить себя:
Прочитайте текст вслух. Если кто-то за стеной не поймёт, о чём речь, — переписывайте.

2. Действие в кнопке — глагол

Кнопка — это самый важный микротекст в интерфейсе. Пользователь должен мгновенно понимать, что случится после нажатия.

❌ Окей, но расплывчато: «Подтвердить», «Отправить», «Далее»
✅ Конкретно и честно: «Оплатить 590 ₽», «Удалить профиль», «Перейти к загрузке»

Правило «Да/Нет — это зло»: Если вы спрашиваете «Вы уверены?», не давайте ответы «Да» и «Нет». Дайте ответы, которые повторяют действие:

❌ «Вы уверены?» [Да] [Нет]
✅ «Удалить навсегда?» [Удалить] [Отменить]

3. Ошибки — не конец света, а подсказка

Пользователь и так расстроен, что у него что-то не получилось. Ваша задача — не добить его, а помочь.

Что должна содержать хорошая ошибка:

Информацию о том, что произошло
Объяснение почему это произошло
Ответ на вопрос «Что делать?»

❌ Бесполезная ошибка: «Ошибка валидации формы. Код: 0x000A12»
✅ Полезная ошибка: «Пароль слишком короткий. Используйте минимум 8 символов.»

4. Пустые состояния (Empty States) — это не мусорка

Пустое состояние — это когда в списке нет задач, корзина пуста, поиск не дал результатов. Новички часто оставляют там просто «Нет данных».

Пустое состояние должно:

Объяснить почему здесь пусто («У вас пока нет сохранённых адресов»).
Предложить действие («Добавить адрес»).
(Опционально) Показать пример или успокоить.

❌ Плохо: «Список наблюдения пуст»
✅ Хорошо: «Вы ещё не добавили ни одного товара в избранное. Самое время найти что-то особенное! [Перейти в каталог]»

5. Последовательность (их консистенция)

Ваши тексты должны быть предсказуемыми. Если на одной странице кнопка называется «Купить», а на следующей «Оформить заказ» — это разные действия в голове пользователя.

Создайте глоссарий для себя:

«Войти» — всегда «Войти», а не «Логин» или «Sign in».
«Товар» — всегда «Товар», а не «Продукт» или «Позиция».
Обращение на «ты» или «вы» — выберите одно и придерживайтесь везде. (Для массовых B2C-сервисов чаще «ты», для B2B и госуслуг — «вы»).

Как не облажаться: Типичные ошибки новичков и как их избежать

Ошибка №1: «Сейчас я им объясню...»

Вы пишете длинный, детальный текст, чувствуя себя профессором. Пользователь его не читает. Вообще. Люди сканируют интерфейсы, а не читают.

Как избежать: Напишите текст. Затем сократите его вдвое. Затем ещё раз вдвое. Если осталось 2-3 слова — идеально.

Плохо: «Для того чтобы завершить регистрацию, пожалуйста, нажмите на ссылку, которую мы отправили на ваш электронный почтовый ящик...»
Хорошо: «Проверьте почту. Мы отправили ссылку для подтверждения.»

Ошибка №2: Копирование «крутых» фраз из чужих интерфейсов

Увидели в Telegram при регистрации «Ваш код — как секретная подушка для объятий: никому не показывайте». Скопировали текст к себе в банковское приложение — получился абсурд.

Как избежать: Голос продукта должен соответствовать его контексту. Банк — строго, лаконично, надёжно. Игровое приложение — игриво. Медицинский сервис — заботливо и спокойно.

Ошибка №3: Смешение «я» и «ты» (мы/вы/я)

В одном сообщении писать «Мы не смогли обработать вашу карту», а в следующем — «Я удалю этот платёж» (от лица робота). Это сбивает с толку.

Лучшая практика:

От лица системы = мы. «Мы обновили политику конфиденциальности.»
От лица пользователя = вы/твой. «Вы сохранили файл.», «Ваша подписка активна.»
Смешивать без нужды — не надо.

Ошибка №4: Игнорирование негативных сценариев

Вы продумали идеальный путь «вход > оплата > спасибо». Но забыли про «забыл пароль», «карта отклонена», «соединение потеряно». В результате, когда случается проблема, пользователь выпадает в осадок.

Как избежать: Составьте карту всех возможных ошибок в вашем интерфейсе и напишите для каждой короткий, полезный текст с инструкцией. Сначала плохие сценарии, потом — хорошие.

Чек-лист для проверки: 15 вопросов перед публикацией

Перед тем как отдать текст разработчикам или выкатить в прод, пройдитесь по списку:

Ясность: Поймёт ли мой текст человек, который видит интерфейс впервые?
Лаконичность: Можно ли удалить из этого текста хотя бы одно слово без потери смысла?
Действие: Понятно ли, что произойдёт после нажатия на кнопку?
Ошибка: Помогает ли она решить проблему, а не просто констатирует факт?
Единообразие: Так же ли я называю эту кнопку/объект в других местах?
Тон: Соответствует ли стиль текста задачам продукта (банк, игра, доставка еды)?
Призыв: Есть ли у пользователя понятное следующее действие после прочтения текста?
Пустые состояния: Не оставлены ли они без внимания?
Тревога: Не пугаю ли я пользователя без нужды («Вы уверены?» там, где достаточно «Отменить»)?
Орфография: Есть ли опечатки? (Это убивает доверие мгновенно).
Капитализация: Не пишу ли я целыми предложениями ЗАГЛАВНЫМИ БУКВАМИ? (Не кричите на пользователя).
Обращение: Везде ли выбрано единое «ты» или «вы»?
Негативные сценарии: Написал ли я текст для случая, когда пошло не так?
Адаптив: Помещается ли текст в кнопку на мобильном телефоне? (Проверьте!)
Тест: Показал ли я эти тексты хотя бы одному коллеге/другу, который не в теме?

UX-текст — это уважение

Писать хорошие интерфейсные тексты сложнее, чем кажется. Потому что это требует не столько литературного таланта, сколько эмпатии и самоограничения.

Ваша задача как UX-писателя — убрать себя из интерфейса. Убрать остроты, сложные конструкции, гордость за удачную фразу. Оставить только то, что нужно пользователю здесь и сейчас, чтобы он сделал своё дело и почувствовал себя умным и успешным.

Помните:
Пользователь не пришёл к вам восхищаться вашим слогом. Он пришёл удалить подписку, заказать пиццу или перевести деньги. Помогите ему сделать это быстро и без головной боли. И тогда ваш продукт полюбят. А хороший UX-текст останется незамеченным — это и есть высшая оценка.

Неоднозначные отношения Kotlin с Hibernate

2026-05-06T13:34:09Z

Kotlin позиционируется как язык, который призван сделать жизнь Java разработчика счастливее. Код становится лаконичнее, Null-safety спасает от NPE, а стандартная библиотека - удовольствие. Но когда мы подключаем к этому котлу JPA-провайдер (например Hibernate), начинаются интересные сюрпризы.

Хотя Kotlin и Java отлично совместимы, их парадигмы иногда конфликтуют. Hibernate изначально проектировался под Java-бины, а Kotlin привносит свои концепции: immutable data classes, свойства вместо геттеров/сеттеров и строгую типизацию.

Ловушка `data class` и `equals`/`hashCode`

Это, пожалуй, самая популярная ошибка. Все мы любим data class, но сущности помеченные @Entity - это не просто DTO.

@Entity

data class User(
 @Id 
 @GeneratedValue
 val id: Long? = null,
 val username: String
)

Так в чем же проблема? Первое - это Lazy Loading: Hibernate создает прокси-объекты, наследующие сущность. Если в equals используется == или ===, вы можете получить некорректные сравнения. Второе это - изменение ID: Когда вы сохраняете новую сущность, Hibernate присваивает ей ID. Если equals/hashCode опираются на ID (как генерирует data class), хеш-код объекта изменяется прямо в момент сохранения. Если этот объект лежал в HashSet, он «потеряется», так как хеш изменился после добавления.

Не используйте data class для сущностей, либо отключите генерацию методов и напишите их руками, используя бизнес-ключ (например, уникальный username), а не ID.

Проблема `final` и отсутствие `open`

В Kotlin все классы и методы по умолчанию final. Hibernate же требует наследоваться от класса сущности для создания прокси (например, для Lazy Loading). Без дополнительных настроек вы получите ошибку при попытке подгрузить данные лениво.

Самый простой способ - использовать магию плагинов в build.gradle. Плагин kotlin-spring (или all-open) делает все классы, помеченные аннотациями (в т.ч. @Entity), открытыми, а плагин kotlin-jpa еще и open-ит методы, имеющие аннотации @Entity и т.д.

Конструкторы без аргументов

JPA-провайдеру нужен конструктор по умолчанию (без аргументов), чтобы создать экземпляр класса через рефлексию, а затем заполнить его поля данными из ResultSet. В Kotlin, если вы напишете primary конструктор с параметрами, конструктора по умолчанию не будет.

Здесь на помощь приходит тот же плагин kotlin-jpa. Он сгенерирует для вас невидимый конструктор без аргументов, если вы пометите класс аннотацией @Entity.

Проблема Default values

Допустим, у нас есть такое поле:

@Entity

class Task(

   val status: String = "NEW"

)

Разработчик ожидает, что если он сохранит объект, не задавая статус, то в БД будет "NEW". Но Hibernate при построении SQL-запроса (INSERT) смотрит на значение поля. Если мы создали объект через new Task(), в памяти статус "NEW". Но если мы мапим результат из базы, Hibernate использует конструктор без аргументов (о котором говорили выше) и сеттеры.

Если в БД колонка не имеет DEFAULT, а вы передаете null (или Hibrenate решит не вставлять это поле), возникнет ошибка. И наоборот, значение по умолчанию в Kotlin не синхронизируется со схемой БД.

Всегда дублируйте дефолтные значения на уровне бд и инициализируйте поле в классе. Либо, что более надежно в Enterprise-разработке, используйте @PrePersist.

В итоге получается, что Kotlin и Hibernate - отличная связка, но она требует понимания того, что происходит «под капотом». Плагины kotlin-jpa и kotlin-allopen решают 90% проблем с магией байт-кода, а остальные 10% решаются внимательным отношением к equals, hashCode и контрактам JPA.