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

28 апреля в 11:00 (МСК) мы проводим открытый вебинар, на котором разберем, как подойти к выбору HR-систем системно и собрать целевую архитектуру под задачи бизнеса. Покажем, с чего начинать проект, как структурировать требования, на что смотреть при оценке решений и почему красивое демо от вендора еще не гарантирует, что система подойдет в реальной работе.

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

О чем будем говорить
— Как изменился подход к выбору HR-систем после ухода SAP и Oracle.
— С чего начать сборку целевой HR-архитектуры и как структурировать требования.
— Почему демо от вендора не дает полной картины и что важно проверять на практике.
— Как использовать математическую модель оценки для выбора HR-системы.
— Какие выводы можно сделать из практических кейсов крупных компаний.

Кому будет полезно
Вебинар ориентирован на HRD, руководителей HR-функции, ИТ-директоров, руководителей цифровой трансформации, руководителей HRIS и внутренних HR-продуктов, а также специалистов, которые участвуют в выборе и развитии HR-ландшафта компании.

👉 Участие бесплатное, требуется предварительная регистрация

Сегодня 23 апреля в 11:00 рассмотрим прикладные сценарии, ограничения и старт внедрения. Разберем примеры разработки и внедрения под задачи тестировщиков, разработчиков, сотрудников непроизводственных направлений (маркетологи, рекрутеры, операционисты). Нужна предварительная регистрация, мероприятие бесплатное. в онлайн формате.

О чем расскажем на вебинаре

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

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

Авторы и спикеры вебинара: 

• Роман Садрисламов, директор производственного направления, FabricaONE.AI (акционер — Softline)

• Роман Смирнов, коммерческий директор, FabricaONE.AI (акционер — Softline)

Основной фокус обсуждения

Эксперты покажут опыт компании и заказчиков в трех базовых вопросах:

• в каких сценариях ИИ-агенты дают измеримый эффект;

• чем ИИ-агенты отличаются от чат-ботов в прикладных задачах;

• какие сценарии стоит запускать первыми, а какие — отложить.

Среди кейсов:

1. Снижение ручных операций: сокращение доли рутинных действий в бизнес-процессах.

2. Ускорение процессов: Использование ИИ-агентов для сокращения времени выполнения задач.
   Работа с информацией и знаниями. По направлениям: поиск информации, работа с корпоративными знаниями в разных отраслях, подготовка ответов и решений на основе доступных данных.

3. Работа с неструктурированными данными: включая упрощение обработки больших объемов неструктурированной информации.

Бонус: практический блок по кейсу участника

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

Регистрация открыта по ссылке:
https://clck.ru/3T3cYR 

Кому будет особенно полезна встреча

• руководители бизнеса (CEO, коммерческие директора) — влияние на экономику процессов

• ИТ-руководители (CIO, CTO) — интеграции, архитектурные и безопасностные ограничения

• операционные руководители — снижение нагрузки на команды

• руководители цифровизации — выбор пилотных сценариев внедрения

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

Если хотите попробовать себя в этичном хакинге — загляните на Хабр Карьеру. Там мы собрали курсы, которые помогут разобраться в основах и начать свой карьерный путь. Всё в одном месте: можно спокойно посмотреть варианты и понять, какие темы изучать в первую очередь. Ниже — как раз о них.

— Системное администрирование Linux. Разбираемся с серверами, сетями и доступами.

— Администрирование Windows и Powershell. Уверенно работаем с Windows-инфраструктурой и автоматизируем рутину.

— Администрирование баз данных. Разбираемся, где и как хранятся данные и где находятся уязвимости.

— Мониторинг. Отслеживаем сбои и подозрительную активность.

— Защита от DDOS. Анализируем, как происходят перегрузки сервисов и что с ними делать.

→ Заходите на Хабр Карьеру и выбирайте подходящий курс

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

Информация об исполнителе (продавце)

Полные сведения о лице, оказывающем услугу или продающем товар: наименование/ФИО, ОГРН/ОГРНИП, адрес, контакты для связи.

Существенные условия товара или услуги (предмет договора)

Чётко опишите, что продаётся или оказывается: объём, формат, характеристики, ограничения. Это существенное условие. Без него оферта недействительна. Для вашей защиты пропишите максимально подробно.

Цена и порядок оплаты

Укажите полную стоимость, валюту, порядок и момент оплаты. Никаких скрытых платежей. Цена - твёрдая или по прайсу. Скидки - на определённых условиях. Формулировки важны.

Порядок и сроки оказания услуги или передачи товара

Конкретные сроки либо порядок их определения. Для цифровых продуктов - условия предоставления доступа.

Условия возврата и отказа

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

Порядок направления претензий

Способы обращения потребителя, сроки рассмотрения, контактные данные для досудебного урегулирования.

Порядок устранения недостатков

Чётко прописать, как и в какие сроки исполнитель устраняет недостатки товара или услуг.

Ответственность сторон

Например, неустойка за просрочку оплаты. Но для потребителей многие штрафы незаконны (ст. 16 Закона). Условия ответственности не могут противоречить закону и полностью освобождать исполнителя от ответственности.

Конфиденциальность и персональные данные

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

Подсудность споров

Для потребителя - по его выбору (ст. 17 Закона о защите прав потребителей). Ограничивать это право нельзя.

Момент заключения договора

Чёткое определение акцепта оферты: оплата, регистрация, нажатие кнопки, активация доступа и т.д.

Что нельзя делать в оферте

Нельзя ущемлять права потребителя (п. 2 ст. 16), менять цену без права отказа, запрещать отказ от договора (ст. 32) или ограничивать подсудность по выбору потребителя.

Где размещать оферту

Оферта должна быть доступна клиенту до момента акцепта. Иначе договор может быть признан незаключённым.

Лучшие места для размещения: отдельная страница на сайте с активной ссылкой в форме оплаты; шапка профиля в соцсетях (закреплённый пост со ссылкой); в боте или приложении перед оплатой.

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

Юридическая сила: примеры из судебной практики

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

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

А вот ошибка: предприниматель написал «оферта» в шапке профиля, но не указал цену и порядок возврата. Суд признал, что существенные условия не согласованы, - договор не заключен. Деньги пришлось вернуть полностью.

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

Недавно сделал Aximo — self-hosted микросервис для speech-to-text, который можно запускать локально без облака и без зависимости от внешних SaaS.

Идея была довольно простая: хотелось собрать вменяемый STT API, который работает на CPU, поднимается как обычный сервис и при этом остается достаточно прозрачным с инженерной точки зрения.

В основе — Rust, локальный inference через Parakeet v3, HTTP API для обычной транскрибации и WebSocket-слой для realtime-сценариев. Из коробки также добавил Docker, OpenAPI и разбиение на несколько crates, чтобы проект не выглядел одноразовой демкой и оставался удобным для дальнейшего развития.

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

Из интересного: доработал Swagger, добавив возможность отправки записи с микрофона:

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

Звёзды приветствую

1-битный Bonsai 1.7B весит 290 МБ и запускается прямо в браузере

PrismML выложил Bonsai 1.7B — 1-битную модель в 290 МБ, которая работает в Chrome через WebGPU без сервера и без установки

В браузере оно правдо так и не заработало, но вот 8B модель Bonsai-8B-Q1_0.gguf с квантизацией 1 бит (!) - занимает на диске чуть больше гигабайта и даже отвечает на вопросы. Локально. Ну как отвечает: генерирует какие-то наборы букв, которые похожи на правду. pom.xml для Spring Boot с пятой итерации сгенерировало. Прямая аналогия - jpeg, ужатый до полной мыльности и с дикими артефактами. Зато маленький. Понять, что имелось в виду - можно. Рассмотреть детали - нет.

Модели на 8 - 12 гигабайт уже позволяет более-менее подробно рассказывать про массу интересных вещей. Про любую почти область знаний, пусть и с глюками, и их можно запустить локально на устройстве с современной видеокартой. Деталей больше, изображение богаче, артефактов сжатия сильно меньше. Про "взрослые" и говорить нечего - не то чтобы png, а даже трёхмерная томограмма - посмотреть со всех сторон и сделать выводы.

Очень прикольно жить в центре технической революции

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

И понеслась...

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

Вайбкодеры меня наверняка закидали бы тапками, мол - все можно автоматизировать и перевести хоть тонну файлов за 20 минут. Но - мне это не в кайф =)

Кто хочет помочь в процессе перевода, а заодно и движок потестить - милости прошу: https://github.com/pechoradev/BloggyCms

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

В третьем выпуске «Не воспроизводится» ведущие подкаста Оля Шнайдер и Серёжа Атрощенков отошли от вкусовщины и попробовали разобраться по существу. Когда автотест — это инвестиция, а когда попытка автоматизировать бессмысленность? В каких сценариях ручное тестирование быстрее и точнее? И правда ли, что, уйдя с головой в автотесты, можно потерять связь с реальным пользователем?

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

🎧 Слушайте выпуск подкаста на всех подкаст-платформах:

• Яндекс Музыка

• VK Видео 

• YouTube

Обсуждение тем, тренды в QA и, конечно, мемы — в Telegram-канале «Не воспроизводится».

Добро пожаловать в мир тестирования. Баги прилагаются.

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

У нас в клубе «Фармакод» есть традиция: каждый понедельник в 12.00 мы с резидентами созваниваемся. Без повесток, без строгих регламентов. Просто открываем микрофоны и говорим о том, что болит. Кто-то приходит с вопросом по ИБ, кто-то — по регламентам, кто-то просто хочет услышать, как дела у коллег.

На прошлой неделе один из участников поднял тему, которая, как оказалось, мучает многих: «Ребята, как вы работаете с заграничными сервисами? Ограничения становятся жёстче, бизнес требует стабильности, как ИТ может их гарантировать. Есть ли рабочие схемы? Или хотя бы понимание, в какую сторону смотреть?» Чат оживился. Оказалось, что почти каждый сталкивался с этим. Кто-то пробовал прокси, кто-то — выделенные каналы, кто-то уже начал тестировать другие решения. Но чёткого, проверенного рецепта не было.

Я тогда сказал: «Давайте не будем ограничиваться нашим узким кругом. Соберём круглый стол, пригласим коллег из других компаний, обсудим открыто. Тем более что тема актуальна для всей фармы».

Резиденты поддержали. И мы начали готовить.

Что в итоге получилось

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

Вот о чём поговорим:

• как сохранить доступ к M365, Teams, SharePoint, когда условия постоянно меняются;

• реальные кейсы: у кого что получилось, а где — провал и почему;

• аудит инфраструктуры: с чего начать, какие срезы делать, как классифицировать критичные сервисы;

• сценарное планирование: риски, сроки, бюджеты — как не утонуть в цифрах;

• архитектурные решения: выделенные каналы, split routing, SD-WAN — что реально работает;

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

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

И главное — мы не будем читать лекции.

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

Зачем я это рассказываю

Чтобы вы увидели, как работает «Фармакод» на самом деле. Это не «клуб по интересам», где раз в месяц высылают дайджест. Это место, где:

• твою проблему слышат и не оставляют одного;

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

• ты можешь влиять на повестку, а не просто подстраиваться под неё.

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

Поэтому я приглашаю вас

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

📅 Когда: 24 апреля, 12:00 🔗 Регистрация: https://my.mts-link.ru/j/Digital4pharma/18252549746

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

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

Автор Павел Карасев - основатель закрытого клуба ИТ и ИБ лидеров фармацевтических компаний «Фармакод»

«Битовые маски» возвращаются с новым сезоном! В составе ведущих к Антону Афанасьеву присоединилась Алина Галичина — руководитель группы модульной верификации YADRO. Гостем первого выпуска второго сезона стал Антон Бобков, ведущий инженер по разработке аппаратного обеспечения YADRO.

Антон работает с цифровой обработкой сигналов практически с начала эпохи массового интернета. В выпуске разбираемся:

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

• как регулируются разные частотные диапазоны и радиоспектр;

• какие физические ограничения существуют у беспроводной передачи данных (включая теорему Шеннона);

• почему стандартов связи так много и как они появляются;

• как WiMAX пытался объединить разные типы трафика;

• какую роль сегодня играют LTE, Wi-Fi, Bluetooth и технологии для интернета вещей.

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

Смотреть и слушать →

 Это статья о моём упрощённом опыте оформления Python -скриптов. Я профессиональный программист. Волею судьбы получаю зарплату за программирование на ассемблере AVR. Иногда на C для неосновного программирования. На Python программирую не меньше, пишу разные утилиты и полезные программы для основной работы и для себя.

За всё время наработалось много решений для удобства программирования, испробовано много разных IDE. Сейчас использую по большей части VSCode и иногда по старой памяти PyScripter. Программирование Jupyter Notebook выполняю обычно только в VSCode. Отлаживать код в Jupyter Notebook довольно удобно, возможно даже удобнее чем IDE. Потом Jupyter Notebook можно автоматически преобразовать в Питон-скрипт или обратно при помощи jupytext (использую это в отдельном скрипте при перетаскивании на него файлов). Да, утилиты для обработки разных файлов организовываю так, чтобы можно было их запускать простым перетаскиванием файла или файлов на скрипт, чтобы не заморачиваться лишний раз с GUI.

Отладку и запуск скриптов и блокнотов можно производить в IDE. Но как только попытаемся запустить отдельный скрипт в Проводнике Виндовс без IDE, сразу проявляется одно неудобство – терминальное окно немедленно закрывается по окончании работы скрипта. Точно так же ведёт себя скрипт при возникновении не перехваченной ошибки.

Но если добавить в конце скрипта команду ввода – то терминальное окно не будет закрываться немедленно и появится возможность оценить результаты работы скрипта. Для предотвращения закрытия окна при ошибке есть тоже не одно решение, но это тема другой статьи (если интересны мои варианты, то можна такой пост написать).

Однако команда ввода в конце скрипта создаёт обратные неудобства при отладке скрипта в IDE и Jupyter Notebook. Удобнее всего было бы, если бы в IDE команда ввода не выполнялась, а при запуске в проводнике – что бы выполнялась. Осталось придумать, как скрипт узнает о способе своего запуска. Для этого я использую шаблон, которым хочу поделиться с вами.

import os

print("Привет Мир!")

if not ('__cached__' not in dir() 
        or {'PROMPT', 'TERM_PROGRAM'} & set(os.environ)):
        input('\nЖми Enter для выхода ...')
#        os.system('timeout /t 60')
#        os.system('pause')

Ключ '__cached__' отсутствует в dir(), если код выполняется в PyScripter или в Jupyter Notebook. 'PROMPT' присутствует в os.environ, если код выполняется в терминале. 'TERM_PROGRAM' присутствует в os.environ, если код выполняется в VSCode. Именно в этих случаях нет необходимости в команде ввода для задержки закрытия терминального окна. При запуске скрипта в Проводнике эти условия выполняться не будут. Анализ именно этих признаков может быть для Вас не актуален, но Вы можете изменить их под свой случай.

Недавно в Гугл Плей появилось приложение
BookFusion Voice
которое даёт возможность установить нейро-голоса Piper в качестве системных. Соответственно, они будут доступны в любых приложениях.
Русских голосов 4, но хорошего качества из них один- “Irina” (звучит заметно лучше, чем стандартные от Гугл).

Есть небольшая проблема- если установить несколько голосов, то могут быть проблемы с выбором конкретного (это зависит от приложения, которое использует синтез).

Мне не так часто в последнее время попадаются книги, где есть что-то ценное, кроме пары идей, которые автор повторяет по 10 раз разными словами. Однако книга «Проектирование веб-API» от французского разработчика веб-стандартов и публичных API Арно Лоре прямо сильно порадовала. 

Фактически это такая книга-чеклист, где автор поднимает вопросы создания публичного API и делится тем, что API должно учитывать при разработке. Помимо этого он приводит свои таблички, которые использует при согласовании веб-API, и делится опытом использования инструментов в практическом поле. 

Отдельно автор уделяет внимание использованию формата OpenAPI (бывший Swagger), который автор сам и развивал как активный участник OpenAPI-сообщества. Это немного иронично, ибо автор опубликовал эту книгу в 2019 году, а в 2022 году ушёл работать в Postman, которые развивают фактически конкурирующий стандарт. 

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

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

p.s. делитесь своими книгами и ресурсами по проектированию api, которые вам понравились

Если задать это простой вопрос самой нейросети, то получим ответ что это важно, и даже очень. Хочешь хороший ответ, подумай над структурой - это продают как аксиому.

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

Если задать такой промт на английском языке, где на минуточку последовательность слов важна даже для правильной грамматической конструкции (я уже молчу про формы слова, так как например в предложении о постройке дома лучше использовать слово house):

popular cheap north materials home build best russia time mistakes

то плюс минус все нейронки ответят примерно так:

You seem to be asking about popular, cheap building‑materials for homes in Russia, what’s “best,” how long it takes, and what mistakes to avoid. Here’s a concise, practical answer for building a house in Russia right now.

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

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

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

Конечно данный пример это слишком маленькое контекстное окно, и на самом деле это показательно. С увеличением контекста важность каждого токена и его расположение в промте стремительно падает. Вы конечно можете использовать слова Important, must, don't и подобные что бы разметить промт, но в конечном счете дешевле и точнее будет отправить несколько запросов с ключевыми словами, уточняя запрос 1-2 словами при необходимости.

Моя текущая стратегия по экономии это естественно английский язык - требует меньше всего токенов и легко сокращается. Контекст наращиваю очень аккуратно по 3-5 токенов (1-2 слова). Для примера исходный запрос можно сократить так и получить такой же результат.

pplr cheap north materials home bld best rus time mistakes

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

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

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

• 22 апреля 20:00. Bun + ИИ: создаём быстрый сервер нового поколения на JavaScript

• 22 апреля 20:00. Symfony Workflow: конечный автомат для реализации бизнес-логики

• 23 апреля 20:00. Многопоточность в C++: как писать быстрые и безопасные приложения

• 23 апреля 20:00. Паттерны RESTful API. Как проектировать удобные, масштабируемые и гибкие API?

• 28 апреля 20:00. Фоновые задачи в Django: работа с Celery

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

• 4 мая 20:00. Интерфейсы в Golang изнутри

• 5 мая 20:00. Postgres + JSON: реляционная мощь, документная гибкость

• 5 мая 20:00. Архитектурные решения в бэкенд-разработке

• 6 мая 19:00. Разработка проекта на Kotlin: коллаборация человека, архитектурных шаблонов и ИИ-команды

• 6 мая 20:00. Rust в деле: пишем многопользовательский чат с сервером, клиентом и CLI

• 7 мая 20:00. От кода до Kubernetes за полтора часа

• 7 мая 20:00. Тестирование микросервисов на Go: почему ваш сервис ломается под 1000 RPS

• 13 мая 20:00. Kafka Streams DSL

• 13 мая 20:00. ClickHouse для аналитики больших данных: практические кейсы и связь с NoSQL-экосистемой

• 14 мая 20:00. Взаимодействие с базой данных и миграции на Go

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

Но главного: кросспостинга в VK с фото до сих пор нет. И вот почему.

Я думал, это будет просто. Создал API-ключ в группе VK, дал ему права на стену, фото, файлы, потом попросил ИИ написать код. Первая публикация прошла. Текст лёг на стену как надо. Добавил фото и сразу ошибка:

error_code: 27 — Group authorization failed: method is unavailable with group auth.

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

error_code: 15 — Access denied: no access to call this method with current scopes.

Расширенные права? Пишу на devsupport@corp.vk.com. Ответ:

Из-за изменения политики дистрибуции API-методов расширенные API-доступы больше не выдаются.

Кольцо замкнулось. Токен сообщества - нельзя. Пользовательский токен - нельзя. Расширенные права - не дают.

Я пока не понимаю: это я что-то упускаю, или VK тихо закрыл эту возможность и просто не обновил документацию?

Кто-нибудь встречался с VK API и получал что-то кроме боли? 👇

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

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

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

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

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

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

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

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

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 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 мск

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

Управленческие и околоуправленческие роли в 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 часа

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

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

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

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. Договоренности фиксируются и превращаются в конкретные действия.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В 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 минут. Делитесь ссылкой на опрос с коллегами, которые вовлечены в ИИ-проекты.

Участвуй!

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

Майские праздники и выходные в 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

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

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

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

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

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

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

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

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

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

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

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

Допускаются в том числе:

• на биологии, химии, физике и географии — непрограммируемый калькулятор;

• линейка без справочной информации — на математике;

• на литературу можно взять орфографический словарь, выданный в пункте проведения экзамена;

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

• во время ЕГЭ на столе должны лежать чёрная гелевая или капиллярная ручка и паспорт.

Остальные личные вещи должны быть оставлены в специально отведённом месте до рамки металлоискателя.

Когда бизнес получил self-service BI и построил внутри него собственное хранилище данных

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

В ОТП Банке за год с момента запуска FineBI выросли до 1 000 пользователей и 660 отчётов при приросте 50 пользователей в месяц. Масштаб впечатляет, но вместе с ним пришло и теневое хранилище.

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

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

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

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