Все потоки

5 человек, 1 300 дашбордов, 2 200 пользователей в месяц. Как не сойти с ума

В Уралсибе self-service BI вышел на масштаб, который сложно представить: 12 000 датасетов, 200+ разработчиков в разных бизнес-блоках, 1 000 потоков данных обновляются каждый день. И всё это поддерживает команда из пяти человек.

При таком масштабе неизбежно появляются дубли, забытые дашборды, сломанные компоненты, разработчики, которые не знают о существовании друг друга, и пользователи, которые всё ещё спрашивают «а зачем BI, если есть Excel?».

Как с этим справляться? Семён Юников расскажет про систему, которую они выстроили: автоматические рассылки разработчикам с рекомендациями по их же объектам, кастомный каталог дашбордов с ИИ-поиском, геймифицированный марафон на 80 разработчиков, после которого количество сломанных компонентов сократилось вдвое. И да, заставки на корпоративных ноутбуках с надписью «Ты ещё в Excel? Переходи в FineBI» тоже часть стратегии.

📅 22 апреля | 15:00 МСК

Бесплатно, онлайн ~3 часа

→ Регистрация

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

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

РБПО по ГОСТ Р 56939—2024: вебинар №06 из 30 – Разработка, уточнение и анализ архитектуры программного обеспечения

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

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.6. – "Разработка, уточнение и анализ архитектуры программного обеспечения". Слайды.

Цели шестого процесса по ГОСТ Р 56939—2024:

5.6.1.1 Создание условий для снижения количества возможных недостатков при разработке архитектуры ПО.

5.6.1.2 Уточнение архитектуры ПО в процессе разработки кода.

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

«А мне вообще нужен MCP-сервер в AI-агентах?»

Проверить можно за пару минут. В AI-агентах появилась галерея готовых MCP-серверов: выбираете нужный, вставляете токен/API-ключ и сразу за работу.

Сейчас доступны: Яндекс Поиск, amoCRM и Контур.Фокус. Скоро добавим Битрикс24, Google Drive и — барабанная дробь — наш собственный MCP-сервер.

Чего-то не хватает? Отправьте заявку со своими предложениями через форму в галерее MCP.

Галерея нужна, чтобы вы быстро подключили агента к привычным сервисам. Он сам будет искать информацию, подтягивать данные из CRM и работать с базами. Централизованное управление доступами, безопасность, разрешения и связь между агентами — бизнес оценит.

Подробнее о подключении → в доке.

Настроить MCP-сервер за пару кликов →

Как распределить доли в проекте? Мой опыт и принципы.

Распределение долей - вопрос, который мы решаем с партнером “на берегу”. Расскажу о методике, которой пользуюсь я. Когда-то я сам узнал ее во время обучения в “Сколково”: о ней рассказал юрист и адвокат Дмитрий Гриц. Мне очень понравилось все то, о чем он говорил, и потом я даже брал у него отдельную консультацию. Сейчас мы используем именно такой подход в работе стартап-студии.

Немного теории: Доля - это соотношение капиталов, которые вносят партнёры. Капитал может быть:

• экономическим (деньги, сырье, продукция, здания, помещения, сотрудники и т.д.);
• человеческим (опыт и квалификация самих партнёров, труд самих партнёров);
• социальным (социальные связи, нетворкинг, умение и возможность привлекать инвестиции и т.д).

Если с экономическим капиталом все ясно (он легко переводится в цифры), то два других вида капитала считаются по таким формулам:

• Человеческий капитал: Компетенции партнера х Время, которое он уделяет проекту в месяц (берется во внимание время, не оплачиваемое рыночным образом, т.е. бесплатно) = Польза, которую партнер приносит проекту.

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

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

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

Энтузиаст собрал дома самодельную тритиевую батарейку (нановаттную ядерную электростанцию) из старых калькуляторов, тритиевых колб и фольги.

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

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

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

Вебинар о том, как обеспечить стабильность баз данных при росте проекта и нагрузок

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

Это третий вебинар из большого трека про эволюцию приложения в облаке. На этот раз разберем, как передать обслуживание PostgreSQL управляемому сервису в облаке и настроить архитектуру Master/Replica для стабильной работы при высоких нагрузках.

О чем будем говорить:

• сравним управляемую и self-hosted СУБД PostgreSQL: выясним, когда пора задуматься о переезде;

• разберем ключевые метрики БД: на что обращать внимание в мониторинге, чтобы не доводить до инцидента;

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

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

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

📅 Встречаемся во вторник, 28 апреля, в 11:00 мск

Зарегистрироваться на вебинар

Из сильного специалиста — в руководителя: 11 открытых уроков про управление, архитектуру и карьерный рост

Управленческие и околоуправленческие роли в IT давно перестали быть только про «руководить людьми». Сегодня это и делегирование, и продуктовые границы, и работа с рисками, и архитектура изменений, и умение принимать решения в условиях дефицита.

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

① Управление командой

➡ 22 апреля, 20:00 — «Делегирование без боли: как перестать быть „главным исполнителем“ и не скатиться в микроменеджмент»
_{Для тех, кто уже руководит или только переходит в управление и хочет перестроить свою роль без потери контроля.}

➡ 28 апреля, 20:00 — «Коучинговые инструменты для мотивации и повышения продуктивности команды»
_{Если хочется не просто ставить задачи, а реально влиять на вовлеченность и результат команды.}

➡ 30 апреля, 20:00 — «Как управлять тимлидами?»
_{Урок для тех, кто уже управляет не только исполнителями, но и руководителями внутри команды.}

② Карьерный рост в управление

➡ 29 апреля, 20:00 — «Разрешите себе карьеру технического директора»
_{Полезно тем, кто уже вырос из роли сильного технического специалиста и думает о следующем карьерном шаге.}

➡ 30 апреля, 19:00 — «МОК‑интервью на позицию Руководитель Проектов»
_{Практический формат для тех, кто готовится к переходу в управление проектами или хочет проверить себя на интервью.}

➡ 12 мая, 18:00 — «Какие метрики использует технический директор?»
_{Для тех, кто хочет понять, как на уровне CTO смотреть на эффективность команды, процессов и продукта.}

③ Продукт, проекты и аналитика

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

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

➡ 12 мая, 19:00 — «Управление ресурсами в условиях жестокого дефицита»
_{Актуально для тех, кто работает в условиях перегруженных команд, ограниченного бюджета и постоянных компромиссов.}

④ Архитектура и изменения

➡ 30 апреля, 19:00 — «От стратегии к портфелю изменений: как архитектор связывает цели бизнеса, инициативы и архитектурные решения»
_{Для тех, кому важно понимать архитектуру не только как набор схем, а как инструмент управления изменениями.}

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

﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋﹋

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

☛ [Перейти к каталогу]

Две попытки миграции FineBI, поломанная синхронизация кластера и выводы, которые пригодятся и вам

На FineBI 6.0 единственным способом резервирования было копирование папки через rsync. Восстановление медленное, переключение на резервный сервер требовало ручной правки конфигураций. Проще было чинить прод, чем восстанавливаться из бэкапа.

В ОТП Банке решили мигрировать сразу на 7.0: нужен был кластер, нормальное резервирование и новые фичи. Первая попытка выглядела логично, прошла без ошибок, но на выходе получился кластер с поломанной синхронизацией между нодами. Как нашли рабочую схему со второй попытки, почему заменили стандартный балансировщик на корпоративный и какие точки отказа остались, расскажет Евгений Иванов на FineDay Online.

📅 22 апреля | 15:00 МСК | FineDay Online 2026

Бесплатно, онлайн, ~3 часа

→ Регистрация

Клиент + Продакт + Сервис = любовь QBR

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

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

1️⃣ Что такое Quarterly Business Review (QBR)

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

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

2️⃣ Зачем вообще появился этот формат

Он вырос из конкретных проблем. 

1. Клиентский сервис чаще реагировал, чем инициировал диалог — клиент приходил сам, когда уже есть проблема.

2. Продукт общался с клиентами точечно — под конкретные задачи, без системности.

3. Клиенту не хватало понимания, влияет ли он вообще на продукт.

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

3️⃣ Почему не сработали Excel-таблицы

До QBR мы пробовали собирать запросы клиентов через Excel-таблицы: менеджеры фиксировали идеи, передавали продукту, но дальше все разваливалось.

Не хватало контекста + появлялись вопросы = мотивация заполнять таблицы падала.

4️⃣ Что изменилось, когда позвали клиента в диалог

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

5️⃣ Как устроена встреча

Есть базовая структура:

• разбираем текущие вопросы и контекст по клиенту;

• обсуждаем, что происходит в бизнесе клиента;

• синхронизируемся по метрикам эффективности;

• собираем обратную связь и сложности в работе;

• рассказываем про обновления и планы продукта;

• фиксируем договоренности.

6️⃣ Что важно в ролях

1. Менеджер клиента — ведет встречу и держит контекст.

2. Руководитель сервиса — подключается к сложным вопросам.

3. Менеджер продукта — отвечает за продуктовую экспертизу.

Без полного состава встреча сильно теряет в качестве.

7️⃣ Что может пойти не так

• Встреча превращается в список «хотелок»

Тут нужно вернуть разговор к структуре: сначала бизнес и контекст, потом — пожелания.

• Клиенту некомфортно отвечать на вопросы про бизнес

Стоит заранее объяснить, зачем это нужно — чтобы лучше настроить продукт под задачи бизнеса.

• Клиент приходит с негативом

Это нормально. Лучше обсудить проблему открыто, чем получить ее в отложенном виде. 

• К следующей встрече нет изменений

Возможности и планы продукта проговариваем заранее: какие задачи в приоритете, что планируется, а что нет. Если планы изменились, обязательно объясняем причины.

8️⃣ QBR работает, если

1. Клиентский сервис и продукт готовятся к встрече вместе.

2. Разговор идет про бизнес клиента, а не только про продукт.

3. Подключены участники со стороны клиента на разных уровнях.

4. Договоренности фиксируются и превращаются в конкретные действия.

Обновили Yandex Cloud Video — облачную платформу для управления видеоконтентом

Cloud Video — сервис на базе видеоплатформы Яндекса, созданной командой Yandex Infrastructure. В новой версии появились возможности для защиты и быстрой обработки контента. Теперь можно добавлять логотипы в видео, загружать ролики с других площадок и управлять задержкой и стабильностью видеопотоков.

Защита контента

В Cloud Video появилась возможность добавлять логотипы в загруженное видео. Это позволит защищать контент от переиспользования и применять новые сценарии для брендирования и рекламы.

Стабильный и быстрый просмотр без задержек

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

Также видео можно выкладывать быстрее — загрузка не задержится из‑за транскодирования. Контент загрузится в оригинальном качестве, а система будет обрабатывать его параллельно.

Новые интеграции

Теперь можно переносить видеоконтент с других хостингов через службу поддержки. Для вузов и образовательных компаний появилась возможность внедрять плеер в LMS‑системы. Это поможет быстрее интегрировать видеоконтент в программы онлайн‑обучения.

❗️В мае всем ИТ-компаниям нужно проходить переаккредитацию. Ну почти...

Все аккредитованные ИТ-компании раз в год ОБЯЗАНЫ проходить процедуру переаккредитации до 1 июня. Это очень важно, чтобы не потерять льготы и статус. 

Отвечаем на самые популярные вопросы о процедуре:

📍Кому нужно проходить? ВСЕМ* компаниям, у кого есть ИТ- аккредитация.

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

* Проходить плановую проверку НЕ нужно, только если ваша компания: 

🟢зарегистрирована в 2026 году;

🟢подала заявку после 25 апреля 2026.

📍Что нужно подготовить? 

– согласие на раскрытие налоговой тайны;

– сведения о 30% выручки от ИТ-деятельности за 2025 год;

– сведения о средней зарплате в компании за 4 кв 2025 г. и 1 кв.2026 г. (проверить можно через бот в тг @agsalary_bot);

– официальный сайт компании;

– документы о сотрудничестве с вузами (для крупных ИТ-компаний).

📍Какой срок подачи? До 1 июня.

📍Как подать заявление? Через специальную форму на Госуслугах, которая откроется в начале мая (в прошлом году открыли 8 мая).

📍Когда ждать результатов? До конца июля.

Я готовлю большую статью о переаккредитации в 2026 году. Скоро ее опубликуем!

Терабайты данных из Teradata в Trino — эффективный способ передачи

В Data Ocean Nova был добавлен новый Trino Teradata Connector, который упрощает ad hoc-доступ к данным из Teradata и позволяет выгружать терабайты данных без кратного роста нагрузки на источник. Коллеги в новой статье объясняют, почему привычная параллельная выгрузка через несколько запросов плохо масштабируется, и показывают более правильный подход: распределять чтение по AMP’ам Teradata так, чтобы каждый из них читался только один раз.

Авторы разбирают архитектуру Teradata, типичные ошибки при многопоточном извлечении данных и принцип работы федеративного доступа через Trino. Отдельно показывают, как коннектор в Data Ocean Nova помогает организовать эффективную многопоточную передачу данных и использовать push-down для фильтрации, агрегаций и join’ов, когда это действительно уменьшает объем выборки.

Как всегда, в статье много полезных советов. Читайте и комментируйте!

🔌Форматы обмена и хранения данных

В предыдущих постах Разбираемся в in-memory базах и Выбираем базу я написал, что собираюсь сделать исследовательский проект по in-memory базам данных  и имя ему MemifyDB. Так же выбрал направление движения: это key-value хранилище, которое потом доработаю до документо-ориентированной системы.

Теперь ключевой вопрос: как клиенты будут с ней общаться?

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

Human readable (JSON, XML and etc.)

В современных системах активно используется как для транспорта так и для хранения текстовый формат данных, а точнее json и его вариации. У этого подхода есть несколько несомненных плюсов, например:

• Простота реализации: не нужно поддерживать разные типы на уровне протокола, всё передаётся как строки, а клиент сам разбирается.

• Гибкость: строкой можно закодировать что угодно — число, JSON, бинарные данные.

Но у этого подхода есть обратная сторона:

• ❌ Нет нативной поддержки типов: Клиент сам должен сериализовать/десериализовать.

• ❌ Оверхед на парсинг: Каждый раз нужно преобразовывать “42” в число и обратно.

• ❌ Неэффективное использование памяти: Число 123456 занимает 6 байт как строка, хотя в бинарном виде — 4 или 8.

• ❌ Невозможность частичного обновления сложных структур: Чтобы изменить одно поле в JSON-объекте, приходится переписывать весь объект (можно конечно поспорить).

## 🎯 Наш подход: типизированные данные с рождения В MemifyDB мы пойдём другим путём.
Мы будем хранить данные в памяти в типизированном виде: строки, числа, списки, хеши, документы — каждый тип со своим внутренним представлением.

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

Это даст:

1. Типизированность Формат должен явно различать типы данных: строки, числа (разной разрядности), булевы значения, null, массивы, объекты (документы).
   Это позволит серверу правильно интерпретировать данные без дополнительных метаданных.

2. Компактность Формат не должен раздувать данные. Число 42 должно занимать 8 байт (или 4, если это int32), а не 2 символа ASCII.

3. Быстрая навигация Мы должны иметь возможность быстро «прыгнуть» к определённому полю документа без полного парсинга.
   Это важно для частичных обновлений и запросов.

4. Потоковость Формат должен допускать частичную отправку/приём, чтобы можно было обрабатывать большие документы по частям.

5. Самодостаточность Данные должны содержать всю информацию для интерпретации, но при этом не дублировать имена полей без необходимости (как в JSON).

🔍 Что дальше?

Существуют несколько бинарных: CBOR, BSON, FlatBuffer и пр. Если у вас есть опыт работы с этим форматами, пишите в комментариях какие у них есть плюсы, минусы и подводные камни.

📎 Исследование: как компании внедряют ИИ на самом деле

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

Мы проводим исследование «ИИ в российском бизнесе». Соберем честный срез по рынку:
🟨 Как компании подходят к внедрению ИИ
🟨 Где застревают ИИ-инициативы
🟨 Как управляют ИИ-проектами
🟨 Какие направления внедрения сегодня в приоритете

Ответьте на несколько вопросов — это займет не более 5 минут. Делитесь ссылкой на опрос с коллегами, которые вовлечены в ИИ-проекты.

Участвуй!

Новости законодательства: майские выходные, домовые чаты в MAX и новая кассация

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

Майские праздники и выходные в 2026 году: как отдыхаем и работаем

В этом году майских каникул не вышло)

В связи с праздниками отдохнем по 3 дня подряд:
⦁ с 1 по 3 мая;
⦁ с 9 по 11 мая.

Между ними будет полная рабочая неделя.

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

Как распределены другие выходные в 2026 году, можно посмотреть в производственном календаре для 5-дневной и 6-дневной рабочей недели.

Домовые чаты в мессенджере MAX: Минстрой дал разъяснения

На весьма интересное письмо Минстроя наткнулась. Оказывается, домовые чаты и применение для них MAX уже есть в законодательном регулировании.

Что важно знать управляющим компаниям и жителям:

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

Верификация участников чатов пока не предусмотрена. Компания вправе сама определять, какие личные сведения нужны для общения с жителями, исходя из целей оказания ЖКУ.

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

Это важное разъяснение, потому что многие УК до сих пор не понимали, могут ли они вообще создавать такие чаты и кто за что отвечает. Теперь позиция Минстроя есть - пользуйтесь. Но вопрос к Минстрою: а что делать, если жители сами сливают чужие данные? Компания не обязана администрировать, но отвечать за утечки придётся ей?

Ранее ведомство уже поясняло:
⦁ домовыми чатами владеют органы жилищного госнадзора;
⦁ управляющие компании и прочие организации ЖКХ не обязаны вести каналы в мессенджере MAX.

Документ: Письмо Минстроя России от 25.03.2026 N 16592-КМ/14

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

С 10 мая 2026 года по ГПК РФ вступившие в силу судебные приказы, решения и определения мировых судей можно обжаловать в президиуме Верховного суда республики, суда города федерального значения, области и других.

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

Пока вышестоящая инстанция в данных случаях - кассационный суд общей юрисдикции (КСОЮ). Похожим образом поправят КАС РФ и КоАП РФ.

Сейчас самое слабое место КоАП - в нём нет порядка кассационного обжалования, нет даже срока для подачи жалобы. Это огромная проблема для тех, кто хочет защитить свои права по административным делам. Надеюсь, поправки это исправят, но в анонсе пока только ГПК.

Важно: кассационные жалобы и представления, которые подадут в КСОЮ до 10 мая 2026 года, рассмотрят по прежним правилам.

Документы: Федеральный закон от 09.04.2026 N 79-ФЗ; Федеральный закон от 09.04.2026 N 80-ФЗ

А что вы думаете об этих изменениях? Стоит ли обязать УК всё-таки администрировать домовые чаты? Как вам новые правила кассации? Делитесь мнением в комментариях! 👇

Тимлид: ожидания, реальность и внутренние вопросы

Быть тимлидом — это не только про процессы и задачи, но и про людей, ожидания и собственные сомнения.

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

Посмотреть вебинар можно и на этих площадках:

• Наш сайт

• Rutube

• YouTube

Следите за анонсами следующих вебинаров в нашем канале!

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

Очень интересно мнение сообщества: какова сейчас реальная ситуация на рынке? Есть ли те, кто только начинает, или кто работает давно? Стоит ли сейчас новичку идти в курьеры как на подработку, или рынок уже перенасыщен?

Давайте обсудим, без рекламы, просто обменяемся опытом. Интересны любые города, не только Москва и Питер.

Рокировка. По Chess'ноку.

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

Сыграно много партий. Ошибки повторяются. Надо увидеть ошибку и найти ее корень. Возможностей это сделать масса. Одна из таких - это посмотреть на рокировки. Статистику по рокировкам в таком виде предложил Михаил (тренер по шахматам), спасибо ему. В большинстве случаев по этой статистике многого и не скажешь. Редко бывают перекосы в какую-то сторону. Но, если бывают, то это бросается в глаза и явно свидетельствует о чем-то нехорошем в игре.

На скрине статистика игры моего сына. Видно, что черные в плюсе, а белые проседают. Это неслучайно. Мы почти прекратили следить за игрой белых и игра поползла вниз. Больше упор был на черных. Честно, просто увлеклись и потеряли из виду. И вот сейчас пришла пора все вернуть назад. Но, что и как возвращать?

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

Что это означает? Это означает, что если сын делает рокировку после дебюта, то эти партии он проигрывает. Если опоздал - или совсем не делай рокировку или сдавайся (шучу).

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

Спасибо, Михаил!

Заходите на огонек: lanchess.ru