Kurgan-Telecom Ru | Информационные технологии

Google I/O 2026.

Flutter 3.44 уже здесь, и это грандиозное событие! Этот релиз знаменует собой важную веху в истории Flutter: Hybrid Composition++ для Android, Swift Package Manager в качестве нового менеджера пакетов по умолчанию для iOS/macOS и улучшенную поддержку Vulkan для Impeller. Мы представляем предварительную версию поддержки многооконного режима для настольных компьютеров, и Canonical станет нашим новым ведущим разработчиком, а также начинаем масштабную архитектурную эволюцию, отделяя Material и Cupertino от основного фреймворка. Мы переосмысливаем UX для агентного взаимодействия с пользователями с помощью GenUl и переосмысливаем опыт разработчиков с помощью Agentic Hot Reload и Dart & Flutter Agent Skills. Flutter расширяет возможности приложений следующего поколения — повсюду, от мультимедийной системы Toyota RAV4 2026 года до грядущего SDK для webOS от LG. Мы очень рады поделиться с вами всеми новостями и обновлениями; добро пожаловать в Flutter 3.44!

В этой статье — о том, почему стартапу недостаточно просто поднять оффер, как меняется роль senior-инженера, почему собеседования должны быть похожи на реальную работу и почему найм инженеров все больше становится не HR-процессом, а частью инженерной системы компании.

Вечный спор в среде MVC-фреймворков - что лучше? Толстые модели и тонкие контроллеры или наоборот?

Классический подход Rails — “Fat Model, Skinny Controller”. Но что происходит, когда ваша модель User разрастается до 800 строк кода, содержит 15 валидаций, 10 коллбеков и 30 методов бизнес-логики? Тестировать это становится кошмаром, а понять что и когда вызывается — квестом для детектива.

Сегодня мы рассмотрим альтернативный вариант — тонкие контроллеры и… тонкие модели!

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

Сегодня мы расскажем необычную историю легендарного Т9, которая чуть не закончилась крахом для своих создателей. (А еще о том, как буддизм помог стартапу).

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

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

Собрали для вас подробный материал про DWH — корпоративное хранилище данных:

— что это такое и как работает КХД - простыми словами
— когда DWH действительно нужно и какие задачи решает
— как устроена архитектура DWH (LSA, A16Z, подходы к проектированию)
— как данные проходят путь от источников до дашбордов
— какие сложности чаще всего могут возникнуть при внедрении

Этот разбор DWH — от базовых понятий до архитектуры и стека — даст вам целостное понимание и поможет ответить на основные вопросы о хранилищах данных.

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

Да, решил нарушить ваши правила, хочу поделиться сервисом, а тут какие-то кармы нужно для пиар-хабов, поэтому пишу как есть

И да, это MVP пока что

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

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

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

Стек решения: Python 3.10+, Flask, requests, python-dotenv, SQLite, YCLIENTS API, голосовой робот и SMS API МТС Exolve, MWS Tables.

14-й выпуск IT-новостей от OpenIDE!

Побывал на HolyJS в Москве, пообщался с фронтендерами и понял разницу в вайбе. Плюс — прогрев к блокировке GitHub, эксперимент Bun с переписыванием на Rust за 9 дней, и немного про частный российский космодром.

Raptor Engine: Как 30 000 строк кода на TypeScript вдохнули жизнь в компилятор AsmX

Можно ли объединить абсолютный контроль низкоуровневого ассемблера x86-64 с изяществом ООП, шаблонов и безопасных абстракций в духе C++? Разбираем масштабное обновление отечественного компилятора AsmX. Под капотом — честные 30 тысяч строк хардкорной архитектуры: от прямого доступа к аппаратной SIB-адресации CPU и хитрых махинаций с регистрами при вызове знаковых movsx/imul/idiv, до разбора анатомии новой стандартной библиотеки (std::optional и std::pair), работающей по принципу Zero-Cost Abstractions. Узнайте, как мономорфизация AST-деревьев и System V ABI позволяют выжимать максимум из кремния без единого байта накладных расходов.

Это третья статья из цикла о том, как я пытался сделать алерты Zabbix в домашней лаборатории чуть умнее, прикрутив к ним локальную LLM и не получить на выходе архитектурного монстра Франкенштейна.

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

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

Часть 1: Вводная и формирование ТЗ
Часть 2: Выбор локальной LLM
Часть 3: Формирование HLD и немного LLD -> вы здесь
Часть 4: Что из этого вышло

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

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

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

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

Вся система будет строиться на gRPC, так как он из коробки идёт со всем необходимы, включая простую интеграцию систем аутентификации и TLS, плюс описание интерфейсов в .proto файлах позволит писать клиенты и агентов на различных языках и фреймворках. Единственный минус, так это то, что двунаправленное взаимодействие не укладывается в философию фреймворка, но это решим в процессе написания.

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

Вместо тысячи слов - вот реальное видео на 4 часа.

https://www.youtube.com/watch?v=6DQW8ZaEP5Y&list=PLJIT5r0YsdjMAXkqo9laup1HImu_yHu65

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

---

(вот это вступление я попросил написать ИИ )))

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

Отрицание: «Да эта железяка даже YAML без отступов генерит, куда ей доступ в AWS!»

Гнев: «Какого черта он опять выдумал несуществующий параметр в манифесте?!»

Торг: «Ладно, пусть пишет простенькие bash-скрипты, но стейт Терраформа я ему точно не отдам».

Депрессия: «Кажется, этот кусок кода понимает документацию AWS лучше меня...»

Принятие: «Агент, задеплой мне кластер в новом регионе, а я пошел пить кофе».

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

Что вообще происходит на видео? Я разворачиваю инфраструктуру и деплою микросервисное приложение с нуля в AWS аккаунт

Стек - классика здорового человека:

Почему повторяющиеся ночные кошмары — это не поломка психики, а её работа?

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

Самое простое — назвать это поломкой. Что-то сломалось, что-то зациклилось, что-то не работает как надо — и хоть в этих установках появляется ощущение призрачного контроля. Ведь поломку можно пофиксить.

Нейробиология и психоанализ с таким бытовым взглядом на кошмар не согласны. Но по разным причинам — и именно в этом различии скрыто самое интересное.

Что происходит в мозге во время кошмара

Кошмар — это не просто неприятный сон. С нейробиологической точки зрения это специфическое состояние, при котором нарушается нормальная работа лимбико-префронтальной системы.

В норме во время REM-сна (от rapid eye movement — быстрые движения глаз; это фаза, в которой мозг наиболее активен, а глаза под закрытыми веками двигаются) эмоциональная регуляция обеспечивается взаимодействием префронтальных и лимбических сетей — в частности, миндалины, центра страха. При кошмаре этот баланс нарушается: миндалина гиперактивна, регуляторные механизмы не справляются. Система перегружается, и человек просыпается.

Исследование Луи-Филиппа Марки с коллегами (Marquis L.-P. et al., Frontiers in Neuroscience, 2021) показало неожиданное: мозг людей с частыми кошмарами работает иначе даже днём, когда они ни о чём плохом не думают. Не только во сне — а в состоянии покоя. Это говорит о том, что повторяющийся кошмар — не случайный сбой, а устойчивое состояние, которое живёт в мозге постоянно.

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

Причина в том, что у продакта есть четыре проверенных методики: теория потребностей, Jobs to be Done, мотиваторы, оценка ценности. Каждая хороша. Каждая отвечает на свой вопрос. Любая из них может оказаться правильной для вашей задачи. И именно в этом проблема.

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

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

llms.txt - это файл в корне сайта, который говорит языковым моделям, что у вас за сайт, какие источники канонические и что цитировать. ChatGPT, Perplexity и Claude уже его читают. Большинство сайтов в Рунете его не имеют, поэтому AI-краулеры цитируют их или плохо, или никак. Файл пишется за 30 минут, эффект на цитируемость в AI-выдаче появляется в течение 1–4 недель.

В статье разбираю: что такое llms.txt, чем отличается от robots.txt, какие 5 блоков должны быть внутри, как написать свой за час, и показываю живой пример с production-сайта.

20 мая в 06:01:55 МСК Watchtower по расписанию проверил 14 контейнеров на нашем VPS, нашёл 5 обновлений и пересоздал. Среди обновлённых - n8n, который крутит production-вебхуки нескольких проектов студии (в том числе SaaS aiseen.ru для GEO-аудита бренда в Яндекс Нейро и Google AIO). На новой версии 2.21.4 загрузчик нод стал строго проверять дубликаты регистрации, а в volume с сентября 2025 лежал n8n-nodes-base-1.14.1.tgz от какой-то старой ручной установки. n8n упал на инициализации, ушёл в crash-loop. Webhook'и перестали отвечать.

Discovery: 2 часа 48 минут спустя, когда юзер случайно открыл админку и увидел Failed to fetch. MTTR: 7 минут.

Главный урок не про :latest и не про Watchtower по отдельности - про то что 95% downtime - это «никто не знал». Собственно ремонт занял 5% времени. Разбираю кейс с точными таймстампами и выводами для observability.

Привет, Хабр! Меня зовут Юрий Соловьёв, я ведущий инженер в команде экосистемы Tarantool. С опытом я пришел к тому, что конфигурация должна иметь строгую спецификацию, так же как и HTTP API. В этой статье я предлагаю альтернативный подход на базе protobuf и постараюсь показать, что это не избыточная сложность, а необходимый уровень инженерной гигиены — особенно для систем, рассчитанных на долгую и стабильную жизнь. Это в какой-то мере технорассказ, которым я хочу поделиться — и именно в такой форме.