Бэкенд

Эпоха AI. Бюджет выделен, ждём чуда.

Рынок в РФ наконец дозрел до массового внедрения корпоративных AI-подписок. Бюджеты на Claude/Codex становятся чуть ли не обязательными. И почему-то все ждут, что продуктивность резко увеличится.

Главная проблема - никто не знает, как ИИ влияет на продуктивность. А еще никто не знает как это достоверно оценить. К примеру в исследовании METR в июле 2025 получили ухудшение продуктивности. Существует много исследований, все с очень разными результатами.

И правда, как измерять-то? Влияет проект, задача, стек, промпты, даже время суток (не шучу). Модели ведут себя по-разному, спецификации отличаются, контекст меняется. Все используют разные инструменты и по-разному. Насколько сильно влияют скиллы разработчика? Знание проекта? Документация? Язык общения? На одной задаче мы могли ускорится в два раза, на другой - протупить дополнительно 2 дня. В каждом аспекте полная неизвестность, помноженная на неизвестность.

Ну и относительно какого периода считать прирост? Тут тоже вопрос без ответа. Многие используют ИИ инструменты аж с 2022 года. Значит нужно собирать статистику с 2021. Но там и технологии были другие, и разработчики, и подходы, и задачи... Объективно ли? Нет. Но 2024 за baseline тоже взять нельзя, тогда уже многие сидели на личных подписках. Но бизнес всё же приходит и говорит: мы выделили бюджет на AI, ждём от вас взрывного роста продуктивности. В два, в три, в пять раз! Как в Майкрософт! Как в Фейсбуке!

Но ведь у многих производительность реально растёт! Правильно. Если тебе менеджер по десять раз на дню пишет про твой статус, режет оценки и торопит - можно и правда ненадолго ускориться. ИИ тут не при чем. Методология "галеры" однозначно работает. Только ни один адекватный разработчик в таком месте долго не задержится.

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

Эпоха AI. Бюджет выделен, ждём чуда.

Рынок в РФ наконец дозрел до массового внедрения корпоративных AI-подписок. Бюджеты на Claude/Codex становятся чуть ли не обязательными. И почему-то все ждут, что продуктивность резко увеличится.

Главная проблема - никто не знает, как ИИ влияет на продуктивность. А еще никто не знает как это достоверно оценить. К примеру в исследовании METR в июле 2025 получили ухудшение продуктивности. Существует много исследований, все с очень разными результатами.

И правда, как измерять-то? Влияет проект, задача, стек, промпты, даже время суток (не шучу). Модели ведут себя по-разному, спецификации отличаются, контекст меняется. Все используют разные инструменты и по-разному. Насколько сильно влияют скиллы разработчика? Знание проекта? Документация? Язык общения? На одной задаче мы могли ускорится в два раза, на другой - протупить дополнительно 2 дня. В каждом аспекте полная неизвестность, помноженная на неизвестность.

Ну и относительно какого периода считать прирост? Тут тоже вопрос без ответа. Многие используют ИИ инструменты аж с 2022 года. Значит нужно собирать статистику с 2021. Но там и технологии были другие, и разработчики, и подходы, и задачи... Объективно ли? Нет. Но 2024 за baseline тоже взять нельзя, тогда уже многие сидели на личных подписках. Но бизнес всё же приходит и говорит: мы выделили бюджет на AI, ждём от вас взрывного роста продуктивности. В два, в три, в пять раз! Как в Майкрософт! Как в Фейсбуке!

Но ведь у многих производительность реально растёт! Правильно. Если тебе менеджер по десять раз на дню пишет про твой статус, режет оценки и торопит - можно и правда ненадолго ускориться. ИИ тут не при чем. Методология "галеры" однозначно работает. Только ни один адекватный разработчик в таком месте долго не задержится.

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

На сайте Hacker News завязалось любопытное обсуждение. Пользователь поделился опытом: в крошечной базе данных на 15 тысяч записей случилась коллизия UUIDv4. Приложение генерировало идентификаторы через uuid, популярный пакет npm, база имела ограничение UNIQUE, и однажды новая запись пришла с тем же UUID b6133fd6-70fe-4fe3-bed6-8ca8fc9386cd, что уже лежал в таблице с прошлого года.

Если что, то в этом плане у UUID должен быть полный иммолейт импрувед: вероятность такого события крайне мала. У 128-битного UUIDv4 122 случайных бита, то есть шанс попадания нового UUID в один из уже 15 000 существующих равен примерно один к 3,5 × 10³². Это какие-то проблемы с генератором псевдослучайных чисел, что сразу же расписали в комментариях к посту на HN. В ходе обсуждений сам автор истории признался, что вообще-то раньше на проекте UUIDv4 генерировались на устройстве пользователя, и уже потом эту часть логики перенесли с клиента на сервер.

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

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

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

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

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

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

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

Телеграм канал автора, где он что‑то пишет про ML, NLP и разработку

Где разобраться в прикладных программах?

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

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

— Excel. Работаем с таблицами, считаем данные, строим графики и быстро находим нужную информацию.

— PowerPoint. Создаем презентации, проекты и визуальные материалы.

— Word. Оформляем тексты, документы, отчеты и другие рабочие материалы.

— Canva. Создаем визуальный контент: карточки, афиши, презентации, обложки и посты.

— Google Analytics. Отслеживаем поведение пользователей на сайте и понимаем, какие материалы или страницы работают лучше.

— Notion. Планируем задачи, ведем заметки, создаем базы знаний и организуем командную работу.

→ Больше онлайн-курсов по выгодным ценам

Минус 15% на подписку OTUS, плюс три курса сразу — до 10 мая

Привет, Хабр!

IT‑специалисты редко развиваются строго в одном направлении. Сегодня нужен Kubernetes, завтра — observability, потом внезапно приходится разбираться в архитектуре, безопасности или аналитике данных. Покупать отдельный курс под каждую задачу — дорого и неудобно. Особенно когда хочется собрать собственный трек развития, а не идти по шаблону.

Мы в OTUS заметили странную вещь: многие совсем забыли, а может, и вовсе не знали, что у нас есть формат «Подписка», который даёт доступ к 200+ IT‑курсам и позволяет учиться сразу на трёх направлениях. Причём это не «запилили и забыли» — мы постоянно добавляем новые курсы и улучшаем условия.

Поэтому захотели напомнить: до 10 мая включительно на подписку действует тающая скидка 15%.

Особенно полезно тем, кто:

— хочет расширить стек, а не точечно изучить одну технологию;

— планирует переходить в lead/architect‑роли;

— устал выбирать между несколькими курсами и хочет взять всё нужное сразу;

— понимает, что рынок требует T‑shaped специалистов, а не узких исполнителей.

📌 Актуальные тарифы и условия — по ссылке. Успевайте до 10 мая.

👉 [Выбрать тариф]

От Go-интерфейсов до AI-агентов: 16 открытых уроков для IT-специалистов

На этой неделе — серия бесплатных открытых вебинаров для разработчиков, архитекторов, DevOps‑инженеров, аналитиков и специалистов, которые работают с AI‑инструментами.

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

4️⃣ мая

➡ 20:00. «Интерфейсы в Golang изнутри»
_{Разберём, как устроены интерфейсы в Go, что происходит под капотом и почему понимание внутренней механики помогает писать более предсказуемый код.}

5️⃣ мая

➡ 20:00. «Postgres + JSON: реляционная мощь, документная гибкость»
_{Поговорим о том, как использовать JSON в PostgreSQL, когда это оправдано и как совместить строгую реляционную модель с гибкостью документного подхода.}

➡ 20:00. «Архитектурные решения в backend‑разработке»
_{Обсудим, как принимать архитектурные решения в backend‑проектах, где проходит граница между полезной инженерной дисциплиной и избыточным усложнением.}

➡ 20:00. «Ansible: быстрый старт»
_{Практический вводный вебинар для тех, кто хочет автоматизировать рутинные задачи администрирования и быстрее перейти от ручных действий к воспроизводимой инфраструктуре.}

➡ 20:00. «Как не допустить ошибок при написании пользовательских историй (User Story)?»
_{Разберём типичные ошибки в User Story и посмотрим, как формулировать требования так, чтобы они были понятны команде разработки и полезны для продукта.}

6️⃣ мая

➡18:00. «Методы работы с LLM: промпт‑инжиниринг, LoRA и RAG»
_{Поговорим о практических подходах к работе с большими языковыми моделями: от промптов до дообучения и retrieval‑augmented generation.}

➡ 19:00. «Разработка проекта на Kotlin: коллаборация человека, архитектурных шаблонов и ИИ‑команды»
_{Практический вебинар о том, как совмещать инженерный подход, архитектурные паттерны и AI‑инструменты при разработке Kotlin‑проекта.}

➡ 20:00. «Rust в деле: пишем многопользовательский чат с сервером, клиентом и CLI»
_{На примере чата посмотрим, как Rust применяется в реальной задаче: сервер, клиентская часть, CLI и работа с многопользовательским взаимодействием.}

➡ 20:00. «Ключевые тренды AI Governance в 2026 году»
_{Обсудим управление AI‑системами, риски, регулирование, ответственность и подходы, которые становятся важными для компаний, внедряющих искусственный интеллект.}

➡ 20:00. «LangGraph + MCP в Cursor IDE: создаем автономного агента для глубокого анализа Google Trends»
_{Практический вебинар о создании AI‑агента с использованием LangGraph, MCP и Cursor IDE для анализа данных Google Trends.}

7️⃣ мая

➡ 20:00. «Стоп рутина: как self‑service деплой экономит ресурсы команды»
_{Поговорим о self‑service deployment: как снять часть операционной нагрузки с команды, ускорить поставку изменений и сделать процесс деплоя понятнее.}

➡ 20:00. «Настройка удобного рабочего окружения для Python‑проекта»
_{Разберём, как подготовить рабочее окружение для Python‑разработки, чтобы меньше времени тратить на хаос в зависимостях и больше — на сам код.}

➡ 20:00. «От кода до Kubernetes за полтора часа»
_{Посмотрим путь приложения от локального кода до запуска в Kubernetes и разберём базовые шаги, которые помогают понять production‑подход.}

➡ 20:00. «Тестирование микросервисов на Go: почему ваш сервис ломается под 1000 RPS»
_{Разберём, почему микросервисы могут вести себя нестабильно под нагрузкой, и какие подходы помогают находить проблемы до того, как они попадут в продакшен.}

➡ 20:00. «Как бизнес‑аналитик управляет рисками при разработке IT‑продукта?»
_{Поговорим о роли бизнес‑аналитика в управлении рисками: от требований и коммуникации со стейкхолдерами до влияния на итоговое качество продукта.}

➡ 20:00. «Качество C#‑кода: от модульных тестов к системному подходу»
_{Разберём, почему качество кода не сводится только к unit‑тестам, и как выстраивать более системный подход к поддерживаемости C#‑проектов.}

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

Стоит ли садиться в 2026 за разработку своей CMS?

Не так давно я писал несколько постов о своем opensource движке, при помощи которого можно вести свой блог. И естественно мне за это навтыкали в комментариях, мол - какая нахрен CMS в 2026 году? Кому она вообще нужна?

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

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

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

Перенес. Написал пару контроллеров. Дизайн сохранил в исконном виде (пришлось правда переписывать весь ужасный инлайн-css от тильды). Но - клиент доволен, что теперь все круто, и не нужно ежемесячно платить за хостинг Тильды (зато нужно платить целых 99 рублей за хостинг для текущего сайта).

Так вот к чему я? Прежде чем переносить сайт с тильды - я перелопатил штук 15 действующих CMS, на которых сейчас клепают сайты - включая всем известный WP и менее известную InstantCms. И ни один двиг не дал того, что мне было нужно.

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

Ни один движок этого не дает. (Ну или может я плохо искал).

Тут конечно я должен подвести к своей CMS - а вот моя так умеет! Пользуйтесь!

Сейчас вы подумаете: «Ага, сейчас он начнет впаривать свою CMS!» А вот нет. Не буду.

Потому что вопрос реально открытый: а нужна ли своя CMS в 2026 году? Или проще наваять на php под конкретного клиента мини-админку для управления сайтом-визиткой?

В TOML нет null. У меня — есть (только для Python)

TLDR: TOML — удобный формат конфигураций, но ему не хватает поддержки null. Создатели языка осознанно отказались и отказываются добавлять null. Я столкнулся с этой проблемой при слиянии TOML-конфигураций в своём Python-проекте и решил её, форкнув популярные библиотеки и добавив в них поддержку значения null : tomli-null (парсер) и tomli-w-null (генератор).

TOML — популярный с недавних пор язык конфигурационных файлов, сочетающий избегающий проблемы других языков:

• TOML стандартизован, имеет типы данных, позволяет кодировать вложенные структуры (привет, INI);

• TOML относительно прост и парсится без хитростей (привет, YAML),

• синтаксис TOML легко читаем, поддерживает комментарии и не имеет нюансов вроде ошибок от далёких скобок и лишних запятых (привет, JSON).

TOML, согласно спецификации, "стремится быть минимальным форматом для файлов конфигурации, который легко читается благодаря очевидной семантике". С "минимальностью" языка в принципе можно поспорить — там и отдельные типы для даты/времени (4 штуки, 3 из них имеют варианты синтаксиса), и сахар в числовых литералах вроде 0xFF00_0000, и непростой синтаксис для ключей (чтобы допускать и сочетать простые ключи, составные ключи, произвольные ключи в кавычках).

Но вот что я совершенно не ожидал и проглядел, когда выбирал TOML основным форматом для человеко-редактируемых структур данных в своём проекте, — что в TOML нет null. Вообще. Это осознанное решение создателей языка. Разные аргументы против null, прозвучавшие за это время:

• "Если значение не определено, пару ключ-значение просто нужно не указывать." Нужно, не можно.

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

• "null создаёт неоднозначность между значением null и отсутствием пары ключ-значение."

• "Если мы разрешим null, это повлияет на всю систему типов; например, целое число теперь будет не "целое число", а "целое число или null"."

  ???

• "Если очень нужно, вы можете использовать специальные значения по своему усмотрению: 0, -1, "", "null", [], {}. Ещё можно использовать дополнительные поля для обозначения наличия значения (типа { present=true, value=100500 }, или null_values = ["key_a", "key_c"])."

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

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

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

Поэтому я форкнул пару библиотек и добавил в них поддержку null самым очевидным образом, не нуждающимся даже в примерах — просто литерал null на стороне TOML соответствует None на стороне Python.

• tomli-null — парсер, форк tomli (tomli включена в Python 3.11 как tomllib);

• tomli-w-null — генератор, форк tomli-w.

(100% покрытие тестами прилагается само собой.)

P.S. PyPI очень... интересным образом показывает информацию об авторах из пакета, несколько раз напоролся, пока пытался убрать автора оригинальных библиотек из поля "для связи" на сайте.

Финальная книга на тему разработки публичных API: «API как искусство: разработка, поддержка, интеграция» [2025] — Сергей Константинов. Книга бывшего руководителя сервиса «Яндекс.Карты», которую можно назвать самой практичной, самой приземлённой и наиболее требовательной к квалификации читателя.

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

Книжку нужно читать внимательно, так как автор часто приводит ссылки на свои же рассуждения и выводы из предыдущих глав. Однако для ленивого читателя он приводит методички по различным моментам проектирования API — например, «Вот 30 правил хорошего API», — тщательно поясняя, почему считает именно так.

Из интересного: поскольку автор работал в «Яндекс.Картах», он уделил целый раздел разработке SDK и UI-клиентских библиотек. Разработчикам, которые занимаются только server-side API, этот раздел, возможно, не нужен, но тем, кому это актуально, подобный материал нигде, кроме этой книги, не найти.

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

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

Поэтому я бы сказал так: первой книгой по проектированию API стоит читать «Проектирование веб-API» от Лоры Арно. А уже на эту базу — книгу Сергея с большим количеством практических примеров и кейсов из реальной жизни.

Это хорошая книга, которая заслуживает покупки и прочтения!

P. S. Возможно, в следующих изданиях книги стоит части 4 и 6 перенести в начало, вместо их текущей позиции. Тогда книжка будет идти от простого к сложному более предсказуемо.

Я давний пользователь Geeknote - это cli для Evernote. Несколько лет назад проект застрял на втором Питоне - и никто не хотел его портировать на третий. Я ждал что кто-то займётся этим - но пришлось самому - так что я форкнул, починил, и даже связался с Виталием Роденко - одним из создателей Geeknote и администратора на PyPI, чтобы получить право туда пушить. За десяток лет я видел как Geeknote переходил из одни руки в другие - и как он забрасывался, и через несколько лет находился новый мантейнер. Было забавно осознать, что теперь и я стал мантейнером программного продукта, который всегда установлен на все мои машины.

Как и большинство из нас, я стал пробовать LLM - как замену поиску, для анализа кодов, советов, и вот наконец - несколько проектов - даже не читая кода - только давая команды и тестируя результат. Известная шутка - переписать на Rust. Почему бы у нет - Geeknote не велик - около пяти тысяч строк на Питоне, что я и попробовал - через Codex gpt-5.5. Несколько десятков итераций, "добавь это", "добавь то", "пропали теги", "пропала анимация" - и за несколько часов я получил рабочий Geeknote на Rust, назвал его reeknote.

Результат: быстрее работает, раза в два. Теперь буду им пользоваться.

P.S.: CLI хороши для перфоманса, SSH, быстрее разработка без GUI, а ещё похоже и для LLM - можно попросить сохранить ответ в Evernote. Как и прочие интеграции, в том числе в скриптах.

MVP в стартапе давно мёртв...

Интернет полон буллшита на тему MVP. Вам продали удобную сказку. Сделай как-нибудь. Пользователь схавает. Главное, протестируешь гипотезу. Нет. Не схавает! Уже лет пять как это не работает.

Пользователь в 2026 году живет в мире, где у него в кармане продукты уровня Apple, Spotify, Telegram и ИИ-ассистенты, которые угадывают ваши мысли быстрее, чем вы их сами формулируете.

И вы правда думаете, что пользователь будет разбираться в вашем кривом MVP, чтобы помочь вам протестировать идею? Пользователь не инвестор. Не ваш кофаундер. Он вам ничего не должен. Он быстро закрывает ваше приложение, чтобы забыть о нем как о страшном сне из детства.

Ищу таких как ты, опытных backend и full-stack разработчиков, а также performance & growth маркетологов и продактов, которые хотят выходить за границы скучных простых задач. В нашей стартап-студии все партнеры, все профессионалы, работаем на результат. Я более 20 лет занимаюсь разработкой и выводом на рынок новых продуктов. Напиши мне, если интересно поучаствовать.

То, что вы называете MVP это чаще всего не Minimum Viable Product. Это Minimum Viable Excuse.

Оправдание, почему:

• нет нормального UX

• нет ясной ценности

• нет ощущения "хочу вернуться"

• нет даже базового уважения к вниманию пользователя

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

И когда они не терпят, вы делаете гениальный вывод: Гипотеза не зашла.

Чтобы быстро тестировать гипотезы, нужно сначала сделать нормально! А вы умеете делать нормально??? Один из тысячи может и умеет!

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

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

WT Max библиотека для интеграции с Joomla.

Вышла Joomla-библиотека для API мессенджера MAX с системным плагином для настроек и диагностики подключения. Библиотека предназначена для разработчиков.

Расширение является Joomla-обёрткой над самостоятельным PHP Composer-пакетом Webtolk\Max. PHP SDK разрабатывалось с учётом стандартов PSR и полностью не зависит от какого-либо фреймворка и/или пакета.

Библиотека может использоваться для:

• отправки сообщений через бота в мессенджере Макс с сайта (разного рода уведомления),

• отправки контента с сайта в мессенджер - видео, аудио, картинки

• кнопок-ссылок к сообщениям

• приёма и обработки реакций на эти кнопки

• обработки ответов в чате / личных сообщениях

• работы с пользователями, чатами, статусами “печатает/просмотрено” и т.д.

PHP SDK работает с:

• PHP 8.1+

• любым PSR-18 HTTP-клиентом (Guzzle, Symphony Http client, Joomla HTTP и другие)

• стандартом PSR-17 RequestFactoryInterface и StreamFactoryInterface

• любым PSR-3 логгером

Joomla-библиотека интегрирует в ваш сайт PHP SDK, использующий инструменты ядра Joomla: http клиент, фабрики PSR-17, стандартный PSR-3 логгер из ядра Joomla.

<?php

declare(strict_types=1);

use Webtolk\Wtmax\Wtmax;

defined('_JEXEC') or die;
// В Joomla отдаёт подготовленный объект Webtolk\Max\Max 
// с фабриками, HTTP-клиентом и штатным логгером Joomla
$max = Wtmax::getInstance();

$bot = $max->bots()->me();

echo $bot->getId();
echo $bot->getUsername();

В составе Joomla-библиотеки собирается коллекция полей Joomla Form. В частности сейчас в ней есть стандартное поле выбора чата из списка доступных чатов для бота в Максе в модальном окне (поле ModalSelect).

• PHP SDK, Composer-пакет

• Joomla-обёртка WT Max

Rust GUI: поверхностный обзор и шпаргалка

Это не туториал, а карта‑шпаргалка, чтобы не потеряться среди десятка библиотек и быстро понять, куда копать под свою задачу.

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

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

Immediate Mode (пересобирается каждый кадр). Суть: «Опиши, что должно быть на экране прямо сейчас». Не «создай кнопку и запомни её», а линейная пересборка каждый кадр: «если сейчас здесь нажали — сделай действие, и в любом случае нарисуй кнопку вот здесь».

— egui, Ply, Rust bindings dear imgui

Retained Mode (дерево виджетов в памяти). Суть: «Измени то, что уже есть». Один раз описывается структуру UI (создал кнопку, положил в layout), а потом меняются её свойства: текст, цвет, видимость. Кнопка «живёт» в памяти как объект.

— GTK и FLTK.

Reactive (реактивный режим). Суть: «UI — это функция от состояния». UI описывается как отображение некоторого состояния. Когда состояние меняется, фреймворк сам пересчитывает, что именно в UI нужно обновить.

— Azul, Cushy, Floem, Ribir, Yew, Xilem, Dioxus (использует Virtual DOM), Leptos.

Hybrid Mode (декларативный API + оптимизированный retained‑рендеринг)

— GPUI(Zed)

Теперь — к конкретным фреймворкам, которые сейчас на слуху.

Tauri. Аналог Electron. Бэкенд пишется на Rust, фронтенд — с помощью JS фреймворков (React, Vue, Svelte). Но архитектура платформы не ограничивается этим стеком. Благодаря поддержке WebAssembly можно использовать и полностью Rust-решения. Например, фреймворк Leptos компилируется в WASM-модуль и запускается во встроенном WebView Tauri.

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

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

Dioxus. Фреймворк, похожий на React. Использует собственный Virtual DOM и макрос rsx!, позволяя писать HTML‑подобный код прямо внутри Rust. Dioxus Native: экспериментальный рендерер на базе WGPU, отрисовывает дерево компонентов напрямую, без использования WebView или CSS‑движка. UI‑логика и бэкенд выполняются в одном процессе, в отличие от Tauri, где фронтенд и бэкенд разделены.

Slint. Фреймворк, нацеленный на легковесность, вплоть до использования на встраиваемых устройствах. Для описания интерфейса используется собственный язык разметки (.slint), для кода доступны биндинги к Rust, C++ и JavaScript. Предлагает инструмент Live‑Preview для визуальной разработки.

Xilem. Экспериментальный фреймворк от команды Linebender на основе оригинальной архитектуры (Xilem architecture), вдохновленной Elm, SwiftUI и Flutter. Разрабатывается как преемник библиотеки Druid, работа над которой была прекращена.

Следующий шаг.

Выбор фреймворка по документации и отзывам — это половина дела. Вторая половина — попробовать его руками на минимальном примере.

Многие Rust‑фреймворки требуют системных библиотек для графики и оконных систем. Настройка «на голой» машине может занять ощутимое время и зависеть от ОС. Чтобы не разворачивать отдельное окружение под каждый вариант, удобно использовать dev‑контейнеры в VS Code. Контейнер фиксирует эту настройку один раз, и она работает одинаково на Windows, macOS и Linux (с учётом специфики Docker).

Преимущества контейнеров:

• Изолированное, воспроизводимое окружение для каждого фреймворка.

• Отсутствие конфликтов версий и зависимостей на основной машине.

• Возможность переключаться между фреймворками параллельно, не теряя контекст.

Этот подход позволяет за пару часов собрать минимальные приложения в 3–4 фреймворках и сравнить ощущения от кода, скорость сборки, поведение окна, качество документации к старту.

Что такое magicgui и зачем он нам?

magicgui — это Python‑библиотека для быстрой разработки простых интерфейсов. Если нужен сложный интерфейс с кастомной вёрсткой и нестандартным поведением — лучше взять PyQt‑Pyside. Когда задача обернуть функцию в окошко за 5 минут — magicgui справится.

В настоящее время magicgui поддерживает следующие бэкэнды:

• Qt (через PySide2 / PySide6 или PyQt5 / PyQt6 )

• Виджеты Jupyter

API организовано на двух уровнях:

Верхний уровень — магия типов. Декораторы @magicgui, @guiclass, автоопределение виджетов по аннотациям.

Нижний уровень — ручная сборка из готовых виджетов (SpinBox, Slider, PushButton).

Примеры работы: https://pyapp‑kit.github.io/magicgui/generated_examples/

Github: https://github.com/pyapp‑kit/magicgui

Прочитал книжку, которую можно скорее назвать методичкой в силу её небольшого размера: «A Practical Approach to API Design» Кейта Кейси и Джеймса Хиггинботама, 2014 года. Это неплохой материал для понимания, что такое публичное API и каких принципов и паттернов стоит придерживаться при его проектировании.

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

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

Читать этот материал в целом уже нет особого смысла, поскольку Лоре Арно в своей книге «Проектирование веб-API» прямо опирался на эту работу (и сам это указал). Поэтому лучше сразу уделить время книге Арно: в ней материал раскрыт в широком обучающем формате. К тому же книга Арно вышла в 2019 году и содержит более актуальную информацию.

Паттерны проектирования еще актуальны?

Вокруг все чаще говорят, что ИИ скоро будет писать код за нас. Логичный вопрос — нужны ли тогда паттерны? Зачем разбираться в паттернах GoF, если нейросеть и так сгенерирует рабочий код по описанию?

У меня ощущение обратное.

Я плотно вошел в разработку в 2019 году. Переходил из 1С в .NET. Книги по паттернам GoF у меня были, но долго лежали как «книга на полке». Казалось, они оторваны от повседневных задач. Теорию вроде понимал, но не видел, где это реально применяется.

Все поменялось, когда я стал использовать ИИ как инструмент для обучения. Просил давать задачи, искать проблемы в решениях, объяснять, почему в одном месте уместен Strategy, а в другом лучше Mediator. Через практику и обсуждение паттерны перестали быть абстракцией.

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

Из этого и вырос мой pet-project gofinsights.com. Я делаю его тренажером по паттернам проектирования. Не просто «прочитал и забыл», а через практику, сравнение решений и постепенное распознавание типовых архитектурных ходов.

Сейчас там есть интерактивный квиз, где можно проверить базу и не перепутать Factory Method с Abstract Factory. Дальше хочу развивать проект в сторону более глубокого ИИ-разбора. Чтобы можно было не только узнавать паттерн, но и разбирать кодовые запахи, причины проблем и возможную эволюцию решений.

Как вы это видите? Паттерны проектирования все еще рабочая база для разработчика? Или с появлением ИИ они станут менее важны?

Наконец-то поднял публичную демку Aximo на Hugging Face Spaces 🎙️

Это локальный speech-to-text API, который работает на CPU, использует Parakeet v3 и позволяет тестировать транскрибацию прямо из браузера через Swagger UI с записью с микрофона, о котором писал в одном из своих предыдущих постов.

• демо: https://ifif-aximo.hf.space/docs

• репозиторий: https://github.com/agent-axiom/aximo

Сейчас довольно много предложений по покупке курсов о «промпт-инженеринге». Я много работал и работаю с ИИ, но ещё больше — без него (примерно в десять раз). Готов поделиться рабочим рецептом, который позволит писать мастерские промпты. Прям лучшие. Это скорее даже фундаментальный принцип.

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

Еще больше дельных советов в моем ТГ канале.

Чернобыльское лето 1986 года, когда все киевские одноклассники разъехались по разным концам СССР подальше от радиации, было для меня супер-продуктивным в смысле изучения программирования. Я ходил в контору человека по фамилии Долина, бывшего полковника танковых войск из Донецка, который переквалифицировался в компьтеризатора украинского образования. Там я работал на компьютерах MSX Yamaha, выучил программирование на Си. Компилятор назывался ASCII C (сейчас в комментах появятся умники которые будут мне говорить, что ASCII это кодировка, а я им буду кидать ссылку что это еще и японская компания).

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

В конце лета я полетел на Новосибирскую Летнюю Школу Юных Программистов, где выучил ассемблер Z80 и сделал поддержку параллельного выполнения нескольких Си функций с помощью переключения контекстов в обработчике прерывания по таймеру. С сохранением регистров в дексрипторе задачи в списке задач. За это я получил диплом первой степени. По-моему дипломы вручал академик Ершов, хотя может я путаю и мы встретились с ним в академгородке куда на тоже возили.

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

Еще там я увидел первые советские программы западного качества - редактор tor(?), программу низкоуровневой работы с диском и оконный отладчик. Они были написаны на Си и ассемблере аккуратно, как примеры в западных книжках. Советский код который я видел до этого (и большинство после этого) был написан тяп-ляп. Писали эти программы местные аспиранты которые были также преподавателями школы.

Помимо этих программ я привез на флоппи-дисках со школы CP/M (хуже файловая система чем в MSX-DOS), среду Turbo Pascal, интерпретатор Lisp, компилятор Nevada Fortran, еще два компилятора Си (Aztec C и BDS C) и даже компилятор с подмножества языка Ada, который я знал теоретически, но никогда не использовал.

29 лет спустя, в 2017 году я приехал на ту же новосибирскую школу в качестве инструктора по Verilog и FPGA. Еще там был Борис Файфель который учил детей Лиспу или чему-то такому.