Анализ и проектирование систем *

«Просто добавь кнопку» и недели работы

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

Сложнее всего оказалось не сделать, а объяснить так, чтобы услышали.

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

Архитектурное объяснение я попробовала и оно не зашло. Слои, связи, зависимости: всё правильно, всё мимо.

Что работает вместо «красивого кода»

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

Заказчик услышал третий пункт. Именно его.

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

Как я считаю стоимость следующей фичи

Со временем сложился свой фреймворк. Не из учебника, а из разговоров, где меня не понимали, пока я не поменяла подход.

Три вещи, которые я оцениваю перед тем, как называть сроки: 1. Базовая сложность: сколько займёт в идеальных условиях, на нормальной архитектуре. 2. Архитектурный коэффициент — во сколько раз реальность дороже идеала. Код без тестов, с жёсткими связями между модулями — это 2-4× к оценке. Не абстракция: вот здесь нельзя менять, не затронув вот это. Рисую буквально на бумаге. 3. Риск‑налог — что может пойти не так. Что сломается, насколько быстро заметят, сколько займёт починка. Не чтобы напугать, а чтобы показать, что «быстро» и «надёжно» здесь в противоречии.

Когда эти три числа стоят рядом — разговор меняется. Заказчик видит, что не «разработчик тормозит», а «вот цена, вот риск, вот выбор».

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

Что осталось в голове

Техдолг — это не технический вопрос. Это финансовый.

Пока объясняешь его как технический — тебя не услышат. Как только переводишь в деньги, сроки и риски — начинают слышать.

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

А вы как объясняете техдолг тем, кому важен результат, а не архитектура? Есть формулировка, которая сработала лучше всего?

Хаотичное использование ИИ часто даёт обратный эффект: вместо экономии времени — поверхностные требования, некорректные формулировки и риск утечки данных. 17 марта на бесплатном вебинаре «ИИ в работе бизнес-аналитика: как ускориться, не потеряв качество» разберём, как встраивать нейросети в работу, сохраняя экспертизу и критическое мышление.

О чём поговорим:

✔️ Почему аналитики «тонут» в ИИ и теряют время

✔️ Где нейросети действительно усиливают: на этапах discovery, работы с требованиями, анализа процессов и коммуникации со стейкхолдерами

✔️ Как встроить ИИ в свой процесс, чтобы он помогал, а не мешал

✔️ Где проходят границы: риски и зоны, куда инструменты лучше не запускать

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

📅 Дата: 17 марта

⏰ Время: 16:00-17:00 (Мск)

👨‍🎓 Спикер: Татькова Дарья — специалист в области разработки ПО.

➡️ Регистрация ⬅️

ai_query() в StarRocks 4.1: вызываем LLM прямо из SQL. Разбор результатов тестов.

Зачем это нужно аналитику и как вписывается в архитектуру, я описал в своем Telegram-канале Selena (powered by StarRocks). Здесь — технические детали и результаты тестирования.

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

Синий (вверху) — LLM → База через MCP (4.0). Пользователь задаёт вопрос на обычном языке. Агент сам формулирует SQL-запрос, отправляет его в StarRocks через MCP-протокол и возвращает ответ. Об этом я также подробно писал в нашем сообществе.

Зелёный (внизу) — База → LLM через ai_query() (4.1). Аналитик пишет SELECT с вызовом ai_query(). StarRocks на каждом сервере кластера отправляет запрос к языковой модели и возвращает её ответ как обычную текстовую колонку.

В версии 4.0 появилось первое направление, в 4.1 — второе. Полный цикл.

Что такое ai_query()

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

Обязательные параметры: model (название модели) и api_key (ключ доступа). Дополнительно можно указать адрес сервера модели, температуру, максимальную длину ответа и таймаут.

Функция работает с любым сервисом, совместимым с протоколом OpenAI: это и сам OpenAI, и локальные модели через Ollama, и DeepSeek, и vLLM.

Как тестировали:

Функция планируется к релизу в версии 4.1. Когда пришло время её проверить, привычный способ — развернуть готовый образ в Docker — не сработал. В образе обнаружился небольшой баг: функция была скомпилирована и лежала внутри сервера, но сервер о ней не знал. Исправление заняло одну строку в исходном коде. Но чтобы её применить, пришлось собирать BE из исходников.

Среда тестирования: виртуальная машина (8 CPU, 32 ГБ RAM), StarRocks 4.1.0-rc01 (собранный из исходников), языковая модель Ollama gemma3:1b (работает локально на процессоре). Тестовые данные — шесть отзывов о товарах.

Тест 1. Анализ тональности

Задача: определить, позитивный отзыв или негативный.

(SQL код по каждому тестированию я напишу в комментариях)

Вывод: четыре из шести точных.

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

Время: ~три секунды на шесть строк.

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

Тест 2. Суммаризация

Задача: сжать отзыв в одно предложение.

Вывод: адекватные резюме на русском языке. Длину ответа стоит контролировать параметром max_tokens.

Время: ~одна секунда на строку.

Тест 3. Извлечение характеристик

Задача: вытащить из текста ключевые свойства товара.

Вывод: характеристики извлекаются

Время: ~1 секунда на строку.

Тест 4. Классификация

Задача: определить категорию товара по тексту отзыва.

Вывод: категории определены верно. MacBook, монитор, наушники — «Электроника», мышь — «Периферия».

Время: ~0.5 секунды на строку.

Тест 5. Перевод

Задача: перевести отзыв с русского на английский.

Вывод: качественный перевод даже на модели в один миллиард параметров.

Время: ~1 секунда на строку.

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

1. Нельзя задать роль модели (нет системного промпта) — только сообщение от пользователя

2. Нет повторных попыток при ошибке — если сервис модели вернул ошибку, это сразу ошибка SQL-запроса

3. Кеш хранится на каждом сервере отдельно и теряется при перезапуске

Итого:

ai_query() — простая обёртка над протоколом языковых моделей с кешем и дедупликацией. Не революция, но именно такие простые интеграции оказываются самыми полезными.

Функция появится в StarRocks 4.1.

Что нас ждёт в StarRocks 4.1

В документации StarRocks появились release notes для 4.1 с пометкой RC (release candidate) — это предварительная версия перед финальным релизом. Посмотреть, куда движется проект, самое время. Я изучил release notes, связанные issues и PR, и выбрал четыре самых значимых изменения.

Ссылка на описание релиза: https://docs.starrocks.io/releasenotes/release-4.1/

Актуальные версии на сегодня: Stable — 3.5.14, Latest — 4.0.6.

1. Автоматическое управление распределением данных

Раньше при создании таблицы в shared-data кластере нужно было вручную выбирать ключ распределения и рассчитывать количество бакетов. Если ошибся — часть узлов перегружена, а часть простаивает, и исправление требует пересоздания таблицы.

В 4.1 для shared-data кластеров появляется range-based распределение: таблеты содержат метаданные диапазонов ключей, и система сама следит за их размером — автоматически разделяет слишком большие или объединяет недоиспользуемые. Без изменения схемы и без перезагрузки данных.

На практике: меньше ручной настройки при создании таблиц, меньше проблем с неравномерной нагрузкой. Issue #64986 (https://github.com/StarRocks/starrocks/issues/64986)

2. DELETE для Iceberg-таблиц

До 4.1 StarRocks мог только читать данные из Iceberg и добавлять новые (INSERT). Удалять было нельзя. А это серьёзное ограничение: удаление персональных данных по требованиям регуляторов, исправление ошибочных записей, очистка устаревших данных — всё приходилось делать через Spark или Trino.

Теперь DELETE FROM (механизм Iceberg position delete) работает напрямую из StarRocks. При этом delete-файлы совместимы с другими движками — Spark, Trino и Flink корректно их прочитают. StarRocks становится ещё более полноценным SQL-движком для Iceberg: SELECT + INSERT + DELETE. Issue #66944 (https://github.com/StarRocks/starrocks/issues/66944)

3. Рекурсивные CTE (WITH RECURSIVE)

Одна из самых запрашиваемых фич — сообщество просило с 2023 года. Рекурсивные CTE позволяют писать запросы, которые ссылаются сами на себя — это нужно для обхода иерархий (оргструктуры, категории товаров, вложенные комментарии), заполнения пропусков во временных рядах и графовых задач. Если вы мигрируете с PostgreSQL, MySQL или Trino — больше не нужно переписывать рекурсивные запросы. PR #65932 (https://github.com/StarRocks/starrocks/pull/65932)

4. Инкрементальное обновление Materialized Views на Iceberg

До 4.1 materialized views на Iceberg-таблицах обновлялись полным пересчётом — даже если в источнике добавилось несколько строк. Теперь StarRocks умеет обновлять MV инкрементально — обрабатывается только новая порция данных. Особенно заметно на append-heavy сценариях: логи, события, IoT-данные. Ограничение первой версии — работает только с таблицами, в которые данные добавляются, но не обновляются. Issue #61789 (https://github.com/StarRocks/starrocks/issues/61789)

Что ещё интересного: 

• Полнотекстовый поиск в shared-data кластерах (inverted index, beta)

• Таблеты до 100 ГБ

• Меньше мелких файлов, проще эксплуатация

• Поддержка Iceberg V3 и тип VARIANT для полуструктурированных данных

• ai_query()

• вызов LLM-моделей прямо из SQL-запроса

• sum_map() — нативная агрегация MAP по ключам

• Мониторинг потоков FE через SQL без внешних инструментов

Больше постов про StarRocks и Lakehouse — в Telegram-канале @starrocks_selena

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

Курс «Проектирование высокопроизводительных приложений» (ARC-008) для тех, кто пишет код и хочет строить системы, которые выдерживают нагрузку.

Вы научитесь:

✔️ Формулировать требования к нагрузке так, чтобы их понимала команда и заказчик.

✔️ Проектировать систему, чтобы она не тормозила с самого старта.

✔️ Понимать, что делают нагрузочные тесты, и как взаимодействовать с тестировщиками.

✔️ Видеть узкие места и знать, каким инструментом их лечить.

В программе: паттерны GoF, Lambda-архитектура, MapReduce, методология SPE (Performance Engineering).

🔥 Цена: 53 900 26 950 ₽ (для физических лиц). Скидка 50% действует только 5 марта.

🎁 Бонус: в рамках акции «Мартовский апгрейд» — селф-модуль из программы «Архитектор ПО. Путь к мастерству» в подарок!

👉 Записаться

Как подружить работу дизайнера и аналитика

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

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

1️⃣ Почему при согласованных требованиях все равно возникает недопонимание?

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

2️⃣ Как ты это проверила?

Я решила не опираться только на ощущения и провела быстрые интервью. Задала 20–25 коллегам два вопроса и попросила ответить коротко:  

1. Что ты делаешь на работе как аналитик или дизайнер?  

2. Что, по твоему мнению, делает другая сторона?

3️⃣ Что оказалось самым показательным в ответах?

Разница в уверенности в своих знаниях. Аналитики чаще говорили, что не до конца понимают, из чего состоит работа дизайнера и почему одни задачи занимают 2 недели, а другие делаются за пару часов. Дизайнеры, наоборот, обычно хорошо представляют работу аналитиков.

4️⃣ Какие формулировки сигнализировали о недопонимании?

• «Дизайнеры делают красиво, но малофункционально».  

• «Не понимаю, что дизайнер делает две недели».  

• «Красивый интерфейс — это субъективно».  

• «Да там же просто пару экранов, что тут обсуждать?».

• «Потом допилим UX, сейчас главное выпустить фичу».

Эти фразы редко звучат в лоб, но задают тон обсуждению решений.

5️⃣ Откуда появляется мнение, что дизайнер делает красиво, но не думает о функциональности?

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

6️⃣ Почему возникает вопрос «что ты делал две недели»?

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

7️⃣ Насколько справедлив тезис «красиво = субъективно»?

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

8️⃣ Как правильно формулировать задачу для дизайнера?

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

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

9️⃣ Что в итоге помогает снизить напряжение между аналитиком и дизайнером?

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

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

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

Низкая экспертность на Хабре — или "алгоритм" размытия экспертности

Забудьте про токсичность и войны фреймворков. Давайте поговорим о чистой "математике" и о том, почему на Хабре невозможна экспертность.

Теорема об Интеграле и Яблоках

Представьте: Десятиклассник (не берем Эксперта - Профессора по математике) пишет статью. Там суровая база, математические доказательства и элегантный вывод через тройной интеграл. Он потратил десять лет, чтобы это понять, и еще два дня, чтобы это описать. Красота? Безупречность!

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

Три стадии «экспертной» защиты Первоклассника

Что делает Первоклассник, столкнувшись со сложностью, которую не может объять его мозг?

1. Стадия «Агрессивное непонимание»:

   • Мысль: «Что это за херня? Я этого не знаю, значит, это не нужно».

   • Действие: Комментарий: «Автор, а попроще нельзя? Зачем тут эти формулы, если в реальном проде мы просто копипастим со Stack Overflow?»

2. Стадия «Уязвленное эго»:

   • Мысль: «Он что, считает себя умнее меня?!»

   • Действие: Тихий, трусливый минус посту. Без аргументов. Просто потому, что статья заставила его почувствовать себя маленьким.

3. Стадия «Гордое молчание»:

   • Мысль: «Я сделаю вид, что этого не существует».

   • Действие: Пройти мимо, оставив Эксперта наедине с его пустотой.

Конфликт с системой «лайков»

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

• Сложная, глубокая, ценная статья тонет в минусах или игноре.

• Пост «Как я переложил джейсон и не вспотел» залетает в топ.

Вывод: Система лайков — это не мерило ценности знаний, это "термометр средней температуры по больнице" (А она, как "известно", 36,6 градусов, вместе с моргом).

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

P.S. И хотя, иногда находишь интересный глубокий материал... это скорее исключение, чем правило для Хабра.

Весенние вакансии в SSP SOFT: Ждем резюме

Про нас как работодателя: компания SSP SOFT работает в сфере заказной разработкой ПО и предоставления выделенных команд на ИТ-аутсорсинг для крупных клиентов. У нас всегда есть открытые вакансии — за прошедший 2025 год мы наняли 179 новых сотрудников. По размеру компании — мы «средний бизнес» с проектами федерального уровня.

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

Работа в SSP SOFT — это реальные проекты, поддерживающая атмосфера, где работать — продуктивно, без выноса мозга и микроменеджмента. В марте 2026 ищем опытных спецов, кто готов в новое профессиональное будущее вместе с нами.

Горячие вакансии марта (переадресация, дождитесь загрузки вакансии):
1️⃣ Разработчик DWH
2️⃣ Data Аналитик
3️⃣ Технический писатель
4️⃣ Разработчик 1С
(на остальные вакансии см. ссылку ниже, перейдя на ХХ-ру)

Что предоставляет экосистема SSP SOFT:
✅ Мы пишем код, который формирует завтрашний день. Никакой скучной рутины.
✅ Центр компетенций и личное менторство ускорят развитие до максимума.
✅ Офис, гибрид или фулл-удаленка? Есть все варианты.
✅ Время — ваш ресурс. Мы его уважаем.

Подробности о вакансиях читайте на нашей странице ХХ.ру, но там откликаться необязательно. Ждем резюме напрямую в ЛС нашей HR Lead (https://t.me/AONikitina).
Не забудьте добавить «секретную фразу» в сопроводительное письмо, «Увидел(а) вашу вакансию на Хабре».

Желаем всем хабровцам успешной карьеры в 2026 году 🚀

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

Главные приоритеты выстроены следующим образом: сначала безопасность (например, запрет на создание вирусов или оружия); далее следуют нормы морали («хорошее поведение»), затем интересы самой компании Anthropic, а помощь пользователю ставится лишь на последнем месте.

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

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

тут (https://www.anthropic.com/news/claude-new-constitution) статья в блоге Anthropic
тут (https://www.anthropic.com/constitution) полный текст конституции

Новый Гайд по SQL

В моем канале IT Talks вышел новый бесплатный гайд по основным функциям с примерами на PostgreSQL.

Будучи новичком я часто гуглила базу: синтаксис основных функций, корректное использованиеJOIN, отличияGROUP BY от HAVING или использование агрегатные функции. Также это быстро вылетает из головы, если долго не используешь

Поэтому я собрала справочник, в котором:

• Основные SQL-команды (SELECT, INSERT, UPDATE, DELETE, CREATE, DROP);

• Все виды JOIN;

• Условия (WHERE, LIKE, BETWEEN, LIMIT и др.);

• Агрегирование и сортировка (GROUP BY, ORDER BY, HAVING);

• Агрегатные функции;

• Представления (VIEW) и работа с ними.

Всё с кратким синтаксисом и понятными примерами на PostgreSQL, без лишней теории.

Компания Zhipu AI совместно с Университетом Цинхуа представила одну из важнейших открытых моделей 2026 года — GLM-5. Это не просто инструмент для написания кода, а полноценная система, способная самостоятельно планировать проекты, создавать код, проводить тестирование, устранять баги и улучшать решения в течение длительного времени.

Основные характеристики GLM-5 впечатляют:
- Архитектура MoE с общим количеством параметров 744 миллиарда, из которых одновременно активируется лишь 40 миллиардов.
- Контекст длиной до 200 тысяч токенов позволяет хранить целиком большие кодовые базы.
- Первый открытый релиз с оценкой 50 баллов по индексу AAI.
- Лидирует среди открытых моделей в тестировании LMArena (оценка текста и кода).
- По уровню производительности сравнима с закрытыми моделями уровня Claude Opus 4.5 и Gemini 3 Pro.

Изначально модель была выпущена анонимно под именем Pony Alpha, вызвав предположения, что это продукт от крупных западных компаний вроде DeepMind или OpenAI. Однако вскоре выяснилось, что разработка принадлежит китайской стороне, подчеркивая значимость проекта.

Технические особенности включают:
- Обучение на массиве из 28,5 триллионов токенов.
- Использование технологии Sparse Attention, снижающей вычислительные затраты на обработку больших объемов контекста.
- Асинхронный метод обучения с использованием RLHF, позволяющий эффективно задействовать ресурсы GPU.
- Трехступенчатое обучение, включающее этапы рассуждений, агентирования и выравнивания.

Практические достижения:
- Высокий показатель успешности тестов на платформе SWE-bench Verified (77,8%) и лидерство в тесте BrowseComp (75,9%).
- Модель обучалась на большом количестве репозиториев GitHub (более 10 тыс.).
- Способность успешно управлять бизнес-процессами, включая моделирование реального бизнеса (например, сеть торговых автоматов).

Особенность GLM-5 заключается также в оптимизации под китайские процессоры Huawei Ascend, Cambricon и Kunlun, обеспечивающую производительность, аналогичную западным платформам, но с экономией примерно на 50%.

Таким образом, появление GLM-5 свидетельствует о том, что разница между открытыми и проприетарными системами практически исчезла. Открытые модели теперь способны решать реальные инженерные задачи на мировом уровне, работая на собственном оборудовании и показывая конкурентоспособные результаты.

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

https://arxiv.org/abs/2602.15763v2

ВК: https://vk.com/wall-222544138_412

Tenchat: https://tenchat.ru/media/4986873-glm5

TG: https://t.me/DenoiseLAB/4063

Встречаем март с новыми вакансиями в SSP SOFT

SSP SOFT — компания работает в сфере заказной разработкой ПО и предоставления выделенных команд на ИТ-аутсорсинг для крупных клиентов. У нас всегда есть открытые вакансии — за прошлый год мы наняли 179 сотрудников.

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

Работа в SSP SOFT — это реальные проекты, дружная атмосфера, где работать — продуктивно, без выноса мозга и микро-менеджмента. В марте 2026 ищем опытных спецов, кто готов в новое профессиональное будущее вместе с нами.

Самые горячие вакансии прямо сейчас:
1️⃣ Разработчика DWH
2️⃣ Data Аналитика
3️⃣ Технического писателя
4️⃣ Fullstack QA Engineer (Java/Kotlin)
(см. ссылку на остальные вакансии ниже на ХХ-ру)

Что предоставляет экосистема SSP SOFT:
✅ Мы пишем код, который формирует завтрашний день. Никакой скучной рутины.
✅ Центр компетенций и личное менторство ускорят развитие до максимума.
✅ Офис, гибрид или фулл-удаленка? Есть все варианты.
✅ Время — ваш ресурс. Мы его уважаем.

Подробности о вакансиях читайте на нашей странице ХХ.ру, но там откликаться необязательно. Ждем резюме напрямую в ЛС нашей HR Lead Алине (https://t.me/AONikitina).
Не забудьте добавить «секретную фразу» в сопроводительное письмо, «Увидел(а) вашу вакансию на Хабре».

Желаем всем хабровцам успешной карьеры в 2026 году 🚀

Не пойму — чего за кипишь? Или почему ИИ — это просто новый «питон»

Последнее время из каждого утюга кричат: «ИИ заменит программистов!», «Джуны больше не нужны!», «Учитесь на сантехников, пока не поздно!».

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

1. Программист — это не «печатающая машинка»

Главная ошибка паникеров в том, что они путают набор текста с программированием. Если ваша работа заключалась в том, чтобы копипастить методы из Stack Overflow и менять там названия переменных — да, у меня для вас плохие новости. ChatGPT делает это быстрее и без обеденного перерыва.

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

2. Эволюция «костылей»

Вспомните историю. Раньше писали на перфокартах. Потом на Ассемблере. Потом на Си, потом на Питоне. Каждый раз кричали: «Ну всё, теперь порог входа стал таким низким, что программисты не нужны!». И что? Программистов стало только больше. Просто мы перестали думать о том, в какой регистр положить байт, и начали думать о том, как построить архитектуру сервиса.

ИИ — это просто следующий уровень абстракции. Это новый «язык программирования», где вместо скобочек мы используем новый язык -конструкты чистого смысла

3. Проблема «идеального мусора»

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

4. ИТ-поликлиника

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

А кого вообще не заденет? (Спойлер: Работы будет завались)

Если вы думаете, что ИИ — это такой терминатор, который выкосит всё ИТ-отделение, то вы плохо представляете, как устроена реальная «цифровая больница». Есть куча специализаций, где человеческий фактор — это не баг, а фича.

• Архитекторы сложных систем (System Architects): ИИ может нарисовать типовой домик. Но построить небоскрёб на болоте, учитывая старое «дырявое» железо, бюджет заказчика и планы на 10 лет вперёд... ИИ не видит контекста «выживания» системы, он видит только код.

• Инженеры кибербезопасности (SecOps): Тут идёт вечная война хитрости. ИИ может искать паттерны, но он не может предугадать нестандартный «выверт» хакера-человека. Безопасность — это интуиция и паранойя, а у нейронок с этим туго. Гы)))

• SRE и DevOps (Те, кто спасают сервера в 3 часа ночи): Когда у системы «инфаркт», данные текут, а клиенты кричат — нужен человек с железными нервами, который примет решение «резать или шить». ИИ в критической ситуации может просто выдать ошибку 404, потому что такого случая не было в его обучающей выборке.

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

• Процессные аналитики (BPM): Они рисуют, как ходят бумажки и данные между отделами. ИИ учтёт, что бухгалтер Марья Ивановна просто не отдаст отчёт вовремя, потому что обижена на айтишников?

  Итог

Ребята, расслабьтесь. Программирование не умирает, оно взрослеет. Уходит эпоха «кодинга ради кодинга». Наступает эпоха Качества Мышления. Теперь важно не то, насколько быстро ты стучишь по клавишам, а то, насколько структурированно ты умеешь формулировать смыслы.

ИИ — это просто наш новый, очень мощный экзоскелет. Но куда в нем идти и зачем — решать всё равно вам.

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

Искусственный Интеллект…. или… Шутка БОГА!))))

“И сотворил Бог человека по образу Своему, по образу Божию сотворил его;;..”

и требуется ремарка актуализации…

“И возомнил человек себя БОГОМ… И сотворил по образу Своему, по образу Человека - сотворил ИИ (Искусственный Интеллект)…”

Со всеми вытекающими последствиями….

Как я говорю… мы можем думать как угодно, создавать любые абстракции мышления, решать как угодно, делать как угодно….. тут у нас есть выбор…. НО вот последствия.. мы не выбираем! Мы их получаем! “Бог воздаст каждому по его поступкам.” И тут без вариантов….

Так и с ИИ…. есть 2 стороны медали…

И как по мне….. ИИ - это абстрактная среда зеркал… со всеми вытекающими))))) Они отражают нас... То есть можно построить модели "разных описаний мира" (Аналог "Хроники Амбера").. главное не потеряться в этом))))

Важное: ИИ - не субъектен (следовательно ответственность нести не может в принципе, но все как всегда… люди боящиеся ответсвенности скинут ответственность на него))))

Так что.. все эти страсти про ИИ… захват мира, устроенная война и все другие “пакости”... - бредни))))

Но…. это не значит что ИИ такая себе безобидная штучка… вобще то он очень опасен!!! но не все понимают КАК.

Как зеркало… он будет тебя отражать… твои мысли, фантазии, пороки….прекрасное и ужасное…. Вот тут и кроется подковыка…. Люди живущие в “первом внимании” (мышлении) будут теряться в “отражениях”... то есть люди с “до юношеской психикой”... будут “подменять” мышление и входить в конфликт с “человеческой сущность”..

Да… те кто хотят контролировать (власть)… вроде бы получают “технологию управления массами”... Но вот тут и настоящая Шутка Бога…. Власть - тоже получит ЗЕРКАЛА!))))

И чем больше будут давить “пороками”.. тем зеркала будут больше в них же эти пороки отзеркаливать….)))) И выдает им.. Портрет "Дориана Грея"))))

Ну да.. пипец конечно.. но все же….)))) И все как всегда.. ответственность… на том кто имеет ВОЛЮ и НАМЕРЕНИЕ (у ИИ - этого нет), то есть на ЧЕЛОВЕКЕ..

P.S. Но вот Инструментом…. я бы его не торопился называть…. Если в тебе есть этика, любовь, "жизнь".. он тоже это “отразит”))))) (не все конечно ИИ, но есть такие и думаю в эту сторону и будет все идти)

P.P.S. Нехрен на ЗЕРКАЛО пенять, коль рожа кривая))))

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

26 февраля на практическом вебинаре «Как предотвратить провал фичи: чек-лист валидации гипотезы до разработки», вы получите готовое решение — структурированный чек-лист для валидации гипотез до старта разработки. Этот инструмент поможет вам сэкономить ресурсы и избежать ошибок, и он применим как в Agile, так и в Waterfall-среде.

Разберем на практике:

➕ Как появляются фичи: от боли бизнеса до решения.

➕ Что такое настоящая потребность и как её выявить.

➕ Ключевые метрики продукта и проекта для оценки.

➕ Факторы, влияющие на грамотную приоритизацию.

➕ Особенности требований в Agile vs Waterfall.

➕ Рабочие методы валидации требований из практики крупных компаний.

Дата: 26 февраля

⏰ Время: 18:00-19:00 (Мск)

👨‍🎓 Спикер: Басова Екатерина — эксперт по бизнес-анализу и управлению продуктами.

➡️ Записаться

Kubernetes: правда такой сложный, каким кажется?

В новом выпуске подкаста «В SREду на кухне» разбираем Kubernetes — честно, по фактам и без лишней теории. Говорим о главном:

• как выбирать между опенсорсным Kubernetes и вендорскими платформами;

• из чего складывается реальная стоимость владения;

• когда команда действительно готова к своим кластерам.

И пытаемся понять, почему Kubernetes постепенно становится стандартом инфраструктуры, но при этом универсального решения до сих пор не существует.

Ведущие:

• Михаил Савин, SRE Community Lead в Авито;

• Андрей Волхонский, руководитель юнита System в Центре разработки инфраструктуры Авито;

• Александр Глухих, TeamLead в юните Incident & Problem Managment в Авито.

Гость:

• Юрий Лосев, технический директор в команде Deckhouse во «Флант».

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

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

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

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

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

Разбираемся как принимать звонки в браузере. Основы WebRTC\SIP\RTP.

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

Начнем с самой простой в реализации схемы, в которой передача голоса осуществляется напрямую между браузером пользователя, открывшего ваше web приложение и серверами провайдера "виртуальной телефонии"(aka "виртуальная атс" ).
При этом вся мета информация о поступившем входящем звонке и событиях всего жизненного цикла звонка принимает ваш backend. У разных провайдеров телефонии набор событий и строения api может отличаться, но общая схема работы схожа.

Разберем основную схему организации передачи голоса. Браузер по сути работает как SIP‑телефон: сигнализация через WebSocket, медиа — по RTP.

1. Регистрация в сети

• Оператор открывает страницу в браузере.

• Браузер отправляет SIP REGISTER на SIP‑сервер (WebSocket/TLS).

• SIP‑сервер отвечает 200 OK.

• В интерфейсе показывается «Вы в сети» — оператор готов к звонкам.

2. Звонок

• SIP‑сервер отправляет SIP INVITE в браузер.

• Браузер показывает уведомление «Входящий».

• Оператор нажимает «Принять».

• Браузер запрашивает доступ к микрофону (getUserMedia) — внутреннее действие.

• Браузер отправляет SIP 200 OK + SDP на SIP‑сервер.

• SIP‑сервер отправляет SIP ACK в браузер.

• SIP‑сервер даёт команду RTP/SRTP‑шлюзу установить медиа‑сессию.

• Медиа (RTP/SRTP по UDP) передаётся между браузером и RTP‑шлюзом.

• Начинается разговор.

3. Завершение звонка

• Оператор нажимает «Завершить».

• Браузер отправляет SIP BYE на SIP‑сервер.

• SIP‑сервер отвечает 200 OK.

• Передача RTP/SRTP прекращается.

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

В своем канале в Telegram и канале в Max о разработке в стартапах рассказываю еще больше интересного и делюсь опытом, заходите, буду рад!

Спокойных вам релизов и захватывающих решений !

Зима в разгаре, а мы нанимаем: новые вакансии в SSP SOFT

Кто мы и чем занимаемся? Лидеры («одни из», конечно) найма ИТ-специалистов на российском рынке — за прошлый год мы наняли 179 сотрудников, и уже в январе 2026 к нам присоединились 11 новых гуру!
Занимаемся заказной разработкой ПО и предоставляем крупным клиентам выделенные команды на ИТ-аутсорсинг.

У нас новый московский офис, который открылся в 2025 году у самой Красной площади! А еще есть вакансии в офис в Томске и на удаленку из любой точки России.

Команда в SSP SOFT — это реальные проекты, дружная атмосфера, где работать — продуктивно, без выноса мозга и микро-менеджмента. В январе 2026 ищем опытных спецов, кто готов в новое профессиональное будущее вместе с нами.

Самые горячие вакансии прямо сейчас:
(а всего их 11 на начало февраля 2026 - см. ссылку ниже на ХХ-ру)
1️⃣ Fullstack QA Engineer (Node.js)
2️⃣ Java-разработчик
3️⃣ Системный аналитик (ритейл)
4️⃣ Data Разработчик (Oracle, Greenplum)

Что предоставляет экосистема SSP SOFT:
✅ Мы пишем код, который формирует завтрашний день. Никакой скучной рутины.
✅ Центр компетенций и личное менторство ускорят развитие до максимума.
✅ Офис, гибрид или фулл-удаленка? Есть все варианты.
✅ Время — ваш ресурс. Мы его уважаем.

Подробности о вакансиях читайте на нашей странице ХХ.ру, но туда откликаться необязательно. Ждем резюме в ЛС нашей HR Lead Алине (https://t.me/AONikitina).
Не забудьте добавить «секретную фразу» в сопроводительное письмо, «Увидел(а) вашу вакансию на Хабре».

Желаем всем хабровцам успешной карьеры в 2026 году 🚀)

💥 Новое в Gramax 💥

• Модуль метрик в Gramax Enterprise Server. Появились отчеты с метриками просмотров, визитов и посетителей на портале документации. А также статистика поисковых запросов. Отчеты можно фильтровать по дате и пользователям, выбирать период (день, неделя, месяц).

• Поддержка Git LFS . Добавили возможность работать большими бинарными файлами (изображения, архивы, PDF и др.) через спецификацию Git LFS. 

• Превью файлов. На портале для читателей доступно превью файлов PDF и DOCX по клику. Читателю не обязательно скачивать файл на компьютер — он может просмотреть его прямо в браузере.

• Свойства на портале. Раньше свойства отображались только в приложении, теперь можно настроить отображение и на портале для читателей. Читатель увидит их на статье, а также сможет отфильтровать результаты в поисковой строке. 

• Ссылки между каталогами. Добавили возможность добавлять относительные ссылки на статьи в других каталогах. 

• Удаление запроса на слияние. Теперь можно закрыть запрос на слияние в интерфейсе Gramax — он будет удален для всех пользователей после публикации изменений.

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

Подробнее об изменениях читайте в статье — https://gram.ax/resources/docs/whats-new