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

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

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

В статье покажу, как реализовать механизм повторной отправки сообщений из архива в обработку с использованием DATAREON Platform.

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

Есть разные библиотеки для этого, в т.ч. от MS. Но эта слишком сложная, другие не очень понравились. А главное то, что нет реализаций пайплайна, т.е. в сервис передаётся набор команд с параметрами и значениями, которые потом выполняются по порядку.

Всё началось с наивной мысли: зачем платить за API или тащить 7B-модель, если мне нужна маленькая модель для простых разговоров на одном языке? Логика казалась железной — большие модели умеют всё и на всех языках сразу, но это же избыточно. 0.7B, заточенная под один язык и один стиль общения, должна справляться не хуже.

Спойлер: это было наивно. Но путь оказался ценнее результата.

Беседа Алексея Рыбака с Константином Осиповым (Picodata) о выборе баз данных для хранения больших объёмов. Обсудили MySQL, PostgreSQL, миллионы нод MySQL в одной экстремистской организации, Cassandra, ScyllaDB, автошардирование, особенности и стоимость хранения, LSM, TTL, ScyllaDB в Discord, Cassandra в Netflix и Apple, а также нишу Picodata. TL;DR: касательно СУБД для хранения очень большого количества данных Константин выделяет две ключевые размерности. Горизонтальное масштабирование — насколько СУБД умеет самостоятельно масштабироваться: добавлять и удалять узлы без ручного вмешательства, выдерживать кластер в 100+ нод без деградации. Storage — насколько движок хранилища подходит для данной нагрузки. Здесь важны: тип структуры и место на диске.

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

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

А PSS — Passenger Service Systems — это как раз те самые динозавры. Древние, массивные, неприкасаемые. В них живут бронирования, билеты, тарифные правила и вся логика, объясняющая, почему перелёт с пересадкой в Чикаго стоит как подержанная «Тесла». PSS — это священные реликвии, написанные в эпоху телетайпов и перфолент, и с тех пор тронутые примерно столько же раз, сколько египетские пирамиды. Работает? Работает. Значит, не трогаем. Любая попытка модернизации выглядит как попытка провести МРТ на мамонте: интересно, но зачем?

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

Здравствуй, Хабр! Разработка ингибиторов мутантного онкобелка KRAS ( особенно формы G12D)- одна из главных задач современной онкофармакологии. Используя наш проприетарный матаппарат мы рассчитали несколько секвенсов под целевой карман мишени. Мы оперировали секвенсами от 7 до 21 остатка на мишенях длиной от 102 до 188 остатков, полученные при докинге результаты ipTM в AlfaFold Server варьировались от 0.58 до 0.92.

Марк Цукерберг уволил 8000 сотрудников Meta*. Работников попросили остаться дома в день сокращений, чтобы избежать хаоса, а уведомления об увольнении начали приходить в 4 часа утра.

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

Это не просто новость. Это иллюстрация ближайшего будущего IT-индустрии.

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

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

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

Стек выбирал не по хайпу, а по принципу «доеду и не утону в обслуживании»: FastAPI (быстро, асинхронно, автодоки), Next.js на React (SSR из коробки — критично для SEO), PostgreSQL (SQLite кончился на первых же конкурентных записях), Redis для кэша и рейт-лимитов. Nginx + systemd на обычном VPS. Никакого Kubernetes — для одного это способ обслуживать инфраструктуру вместо разработки.

Грабли, на которых посидел:

• Фоновое состояние в памяти + несколько воркеров = рассинхрон. Пользователи попадают в разные процессы, состояние не шарится. Лечение: либо общее хранилище, либо такие фичи в один воркер.

• Права на файлы после сборки. Собрал под одним пользователем, сервис под другим — EACCES и белый экран. Теперь chown в чек-листе деплоя.

• node_modules не переезжает Windows → Linux. Только чистая установка на целевой ОС.

• dev и prod базы — разные миры. Один запуск скрипта «не туда» — и долго гадаешь, почему данные не меняются (а они меняются, в локальном SQLite, который никому не нужен).

• Не запускай два тяжёлых процесса разом. Фоновая генерация + пересборка фронта = OOM-killer молча прибил процесс. Полчаса искал причину.

• Кэш сборки трогать нельзя — «почистил на всякий» и сломал инкрементальную регенерацию страниц на сутки.

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

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

Не ради пиара, а как живой пруф того, о чём пишу: всё описанное работает прямо сейчас — vibemuvik.ru Можно зайти и потыкать вживую.

А вы тащите что-то в одиночку? На каком стеке, как боретесь с выгоранием и бесконечным бэклогом?

Алексей Андреевич Ляпунов был математиком - специалистом по математической логике. В 1954 году, когда кибернетика официально называлась реакционной буржуазной лженаукой, он открыл в Московском университете семинар по кибернетике. Это было примерно как читать запрещенную литературу в читальном зале публичной библиотеки. Только публичной библиотекой был МГУ.

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

Полчаса в день у меня уходило на ручной обход шести нод Proxmox через веб-интерфейс — он показывает по одной ноде за раз. И часть рутины всё равно проскакивала: задание PBS остановилось — никто не заметил, ZFS scrub отключили на maintenance и забыли включить, на ноде накопились pending kernel updates, и о них узнаёшь, когда уже надо ребутить.

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

Стандартный путь — полноценный observability-стэк: Zabbix или Prometheus + Alertmanager + Grafana. Это правильный путь, но он плохо подходит к задаче «быстро получить единый экран по Proxmox-кластеру». В этой статье — про другой вариант: лёгкий read-only слой над Proxmox/PBS, который разворачивается за несколько часов и закрывает первый уровень видимости. Инструмент называется Pulse — где он работает, где нет, и что выяснилось в первый месяц эксплуатации.

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

Каждый раз проблема не в модели (GPT-4 и Claude отвечают хорошо, если им дать правильный контекст), а в retrieval — в том, как мы ищем релевантные куски документов. Модель отвечает ровно настолько хорошо, насколько хорош контекст, который ей подсунули.

Рассмотрим три основные причины.

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

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

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

Это не проблема протокола совещания.

Мы все привыкли строить производство софта как конвейер. Продакт берёт идею, отдаёт аналитику. Аналитик пишет требования, отдаёт разработчику. Разработчик пишет код, отдаёт QA. QA проверяет, отдаёт DevOps. DevOps выкатывает в прод.

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

Так работало 30 лет. И вот в каждый из этих участков пришёл AI-агент. И конвейер начал барахлить.

В этом году на конференции Google I/O 2026 команды Flutter и Dart отмечают важную тему: «Везде, каждый день, создано всеми, для всех».

Dart 3.12 воплощает эту идею в жизнь. Мы делаем язык более доступным и продуктивным. Лаконичные новые примитивы, такие как приватные именованные параметры, наряду с экспериментальной поддержкой основных конструкторов, делают повседневное программирование более чистым. Но мы не остановились на синтаксическом уровне. Новые функции, такие как Agentic Hot Reload и добавление Genkit в экосистему Dart, гарантируют, что вы сможете создавать высокопроизводительные, готовые к использованию ИИ и агентные приложения, которые будут доступны пользователям в любой точке мира. Это справедливо как для индивидуального программирования, так и для парного программирования с ИИ-агентом.

Так что вперед flutter upgrade, следуйте инструкциям, чтобы изучить новые возможности Dart 3.12. Но помните, что более мощный Dart — это только половина дела. Когда вы будете готовы увидеть, как эти функции преобразуются в красивый пользовательский интерфейс, ознакомьтесь с публикацией в блоге «Что нового во Flutter» или на Хабре.

Стивен Порджес в 1988 году работал с данными кардиомониторинга новорождённых в интенсивной терапии. Он смотрел не на патологию — он смотрел на норму. На здоровых детей. И заметил странную вещь: вариабельность сердечного ритма у разных детей в одинаковых условиях покоя вела себя по-разному. Не случайным образом — паттерно. Будто у каждого сердца был собственный почерк, заложенный ещё до того, как ребёнок научился говорить, читать или заполнять психологические тесты.

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

Он объяснил. Но объяснение поставило под вопрос большую часть того, что мы думали про типологию личности.

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

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