На этой неделе — серия бесплатных открытых вебинаров для разработчиков, архитекторов, 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, программированию и не только смотрите в дайджесте.

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

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

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

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

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

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

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

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

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

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

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

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 перенести в начало, вместо их текущей позиции. Тогда книжка будет идти от простого к сложному более предсказуемо.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вышла 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

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

Перед выбором любого фреймворка — откройте 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 — это 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. Дальше хочу развивать проект в сторону более глубокого ИИ-разбора. Чтобы можно было не только узнавать паттерн, но и разбирать кодовые запахи, причины проблем и возможную эволюцию решений.

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

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

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

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

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

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

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

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

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

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

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

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

Jer Crane, основатель PocketOS, сервиса для компаний по аренде автомобилей. Агент Cursor (на базе Claude Opus) работал в staging-среде, наткнулся на ошибку credentials и сам решил "починить" проблему: удалил Railway-volume одним GraphQL-запросом.

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

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

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

Если вы используете Railway и AI-агенты в проде, сегодня хороший день проверить скоупы токенов и то, где реально хранятся ваши бэкапы

Привет, коллеги! Традиционная подборка открытых онлайн‑мероприятий для тех, кто хочет прокачать скиллы в IT, управлении, аналитике и автоматизации. На этой неделе — фокус на архитектуру, тестирование, Computer Vision и внутреннюю кухню разработки. Всё бесплатно, но нужна регистрация.

📅 Расписание по дням

_{Понедельник, 27 апреля}

• 20:00 — «Рисуем в формате онлайн модель процесса BPMN в Camunda Modeler»

• 20:00 — «Настройка кластера Elasticsearch»

_{Вторник, 28 апреля}

• 20:00 — «Коучинговые инструменты для мотивации и повышения продуктивности команды»

• 20:00 — «Архитектура ИИ врагов в играх на Unity»

• 20:00 — «Первый нагрузочный тест в Apache JMeter»

• 20:00 — «Архитектура тестового фреймворка: от хаоса к стабильности»

• 20:00 — «Контрактные тесты в Kotlin: как подружить фронт и бэкэнд»

• 20:00 — «Фоновые задачи в Django: работа с Celery»

• 20:00 — «Как работают современные модели компьютерного зрения „из коробки“ на базе популярных библиотек и фреймворков (Hugging Face, OpenCV, YOLO, Roboflow)»

• 20:00 — «Почему только 5% компаний получили реальную выгоду от ИИ в 2025 году?»

_{Среда, 29 апреля}

• 20:00 — «Деревья решений для задач классификации и регрессии»

• 20:00 — «Свой язык на PHP за 60 минут»

• 20:00 — «Трекинг с подвижной камеры: алгоритмы и механика компьютерного зрения на роботах для индустриальных задач»

• 20:00 — «Разрешите себе карьеру технического директора»

• 20:00 — «Качество C#‑кода: от модульных тестов к системному подходу»

• 20:00 — «Продакт‑менеджер, маркетолог и PMM — в чём разница»

_{Четверг, 30 апреля}

• 19:00 — «МОК‑интервью на позицию Руководитель Проектов»

• 19:00 — «От стратегии к портфелю изменений: как архитектор связывает цели бизнеса, инициативы и архитектурные решения»

• 20:00 — «Yahoo Finance и не только — работа с российскими торговыми площадкам»

• 20:00 — «Поиск в базе знаний: где векторы ошибаются, а графы помогают»

• 20:00 — «Как управлять тимлидами?»

• 20:00 — «Битрикс24 + MAX: разработка чат‑ботов и автоматизация коммуникаций» 

• 20:00 — «Планируем внедрение DevSecOps — что следует учесть?»

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

Прочитал книжку «API Design Patterns» от бывшего разработчика Google — JJ Geewax, и это, на удивление, полностью ненужная книжка.

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

Особенно доставляет, что на большинство вопросов автор приводит несколько подходов, но не даёт никакого обоснования, где и когда нужно применять тот или иной подход. «Просто есть несколько вариантов — выбирай мудро» (с).

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

Ну и самое главное — в книге нет никакой целостности. Словно автор просто брал какую-то тему, писал про неё 6–8 страничек, потом брал новую тему и снова писал 6–8 страничек. И какой-то связи между этими главами нет.

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

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

Впереди - куча оптимизации, например вынесение всех форм шаблона админки в контроллеры, и последующий их рендеринг через render_form(). Данные контроллеров в json и так далее.

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

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

Приглашаю к тестированию: https://github.com/pechoradev/BloggyCms

Также буду рад видеть новых контрибьюторов CMS.

Если бы я наткнулся на эту статью в самом начале работы с блокчейном ТОН, это бы сэкономило мне кучу времени на понимание архитектуры и принципов работы смарт контрактов.

Что такое смарт контракт с точки зрения разработчика.

Я постараюсь уберечь вас от терминологии блокчейна, вместо этого на пальцах показать из чего состоит смарт контракт и как его собрать. Если говорить совсем просто, то смарт контракт - это ячейка в памяти, хранящая в себе:

• Адрес

• Баланс

• Любые данные, которые вы туда запишите

• Код смарт контракта

• Текущий статус смарт контракта

Ну или если перевести вышесказанное в код, то:

class SmartContract{ 
   readonly address: string; 
   readonly balance: number; 
   readonly code: string; 
   readonly status: 'uninitialized' | 'active' | 'frozen'; 

   storage: object; 
   ... 
}

Плавное погружение...

Представьте, вы написали код класса на своем любимом языке программирования, как полагается, с полями и методами, и превратили этот код в строку. Code - это и есть код вашего смарт контракта. Он будет выполняться в блокчейне. Точкой входа в таком коде будет метод onInternalMessage или onExternalMessage. Чтобы состояние полей класса можно было сохранять и перезаписывать, к смарт контракту прилагается объект Storage , в котором хранятся значения ваших полей.

При сохранении смарт контракта в блокчейн вы отправляете { code, data } , где code - это код вашего смарт контракта, data - начальные данные. По этим двум полям вычисляется будущий адрес смарт контракта: address = hash({ code, data }). По этому адресу будет доступен ваш смарт контракт в блокчейне ТОН. На него можно совершать переводы, просматривать историю транзакцию, с него может переводить средства и вызывать другие смарт контракты.

Как происходит деплой смарт контракта.

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

1) Другой смарт контракт делает перевод ТОН, прикрепляя код вашего смарт контракта вместе с начальными значениями(data) в поле Init = { code, data }. Блокчейн видит в переводе это поле и автоматически делает деплой. Статус смарт контракта становится "active".

2) Другой смарт контракт так же делает перевод ТОН, но только не прикрепляя ничего. В таком случае средства останутся висеть на адресе пустого смарт контракта, который будет выглядеть примерно так:

{ 
   "address": "401bf...3004", 
   "balance": 3000, 
   "code": "", 
   "storage": {}, 
   "status": "uninitialized" 
}

Он ждет внешнее сообщение, где в него передадут код и начальные данные таким образом, чтобы address = hash({ code, data }), только тогда он сохранит код и сможет выполняться. Для вызова внешнего сообщения используется обычное API, где передается адрес и Init = { code, data } . Запрос сначала попадет в блокчейн, после чего при совпадении адреса address = hash({ code, data }) произойдет деплой, и статус станет "active".

Заключение

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

Вчера OpenAI выпустил GPT-5.5. Сегодня DeepSeek выложил V4 – открытые веса, MIT-лицензия, 1М токенов контекста. Тайминг, конечно...

8 технических инноваций

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

1. Гибридное внимание (CSA + HCA)

Классический механизм Attention был серьёзно доработан. Теперь используется комбинация Compressed Sparse Attention и Heavily Compressed Attention, заменившая Multi-head Latent Attention из V3 и DeepSeek Sparse Attention из V3.2. У этого есть свои ньюансы и "цена". Эксперты пишут, что это может серьезно влиять на применимость модели в задачах с легаси кодом, так как компрессия контекста будет приводить к тому, что Дипсик 4 сможет корректно работать только с тем, кодом, который написал сам, а на легаси могут быть сюрпризы.

Результат: на окне в 1 миллион токенов модель потребляет лишь 27% вычислений и 10% памяти (KV-кэша) по сравнению с V3.2. Читать целые кодовые базы и книги стало экстремально дешево.

2. Оптимизатор Muon на триллионном масштабе

Индустрия привыкла к оптимизатору AdamW – он де-факто стандарт для обучения трансформеров. DeepSeek перевёл большую часть параметров на Muon – это первый публично известный случай применения Muon на модели масштаба 1.6T параметров.

Muon дал более быструю сходимость и стабильность при обучении гигантской MoE-архитектуры. Ранее он валидировался только на существенно меньших масштабах.

3. Гиперконнекции (mHC)

Классические остаточные связи (residual connections) между слоями нейросети были заменены на Manifold-Constrained Hyper-Connections. С помощью проекции на многообразие Биркгофа через итерации Синкхорна–Кноппа они устранили риск того, что сигналы "взорвутся" при обучении очень глубокой сети – проблему, которая убивала предыдущие попытки сделать обучаемые остаточные связи.

Накладные расходы: всего ~6.7% дополнительных вычислений. Техника была впервые опубликована DeepSeek в январе 2026 года.

4. Слияние знаний через On-Policy Distillation (OPD)

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

1. Сначала обучили 10+ узких ИИ-экспертов (отдельно математик, отдельно кодер, отдельно логик и т.д.) через SFT + GRPO (reinforcement learning).

2. Затем через On-Policy Distillation аккуратно "перелили" знания каждого эксперта в единую финальную модель.

Это устранило проблему, когда знания из одной области мешают другой – так называемое cross-domain interference.

5. Генеративный судья (GRM)

Для обучения сложным задачам DeepSeek отказался от классических скалярных "оценщиков" (как в стандартном RLHF). Вместо числовой оценки "хорошо/плохо" модель теперь сама текстово анализирует свои шаги – Generative Reward Model. Это качественно более богатая обратная связь при обучении.

6. Три режима мышления "из коробки"

Глубиной рассуждений модели можно управлять:

• Non-Think – быстрый интуитивный ответ

• Think-High – вдумчивый анализ

• Think-Max – "выжми педаль в пол": модель расписывает все гипотезы, ищет краевые случаи и доказывает свой ответ (требует ≥384K контекста)

Think-Max – это режим, в котором DeepSeek замеряет свои лучшие бенчмарки. На HLE он поднимает score с 34.5 до 37.7, на SimpleQA-Verified – с 46.2 до 57.