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

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

Мы поговорили с Полиной, бизнес-аналитиком в команде Скорозвон, и задали ей несколько вопросов: где ИИ полезен на практике, какие результаты удалось получить и какие инструменты стоит попробовать.

1️⃣ Где ИИ помогает в работе аналитика?

Чаще всего — в рутине. По данным исследований, до 60% времени аналитик тратит на задачи вроде создания отчетных документов, генерации гипотез и промптов, анализа больших данных и проведения исследований.

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

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

2️⃣ Где ИИ уже приносил заметный результат в вашей команде?

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

Мы подключили анализ диалогов с помощью LLM и выяснили, что корректно работали только около 7% операторов.

Ошибки у них были довольно базовые, но их сложно заметить без детальной аналитики:

• не знали о звонках робота

• сбрасывали звонки клиентов или вызывали негатив

• повторно проводили идентификацию

• работали с плохим оборудованием

LLM помог быстро проанализировать большой объем диалогов и собрать это в понятную аналитику.

3️⃣ Что изменилось после этого?

После таких изменений корректность работы операторов выросла до 90%. Плюс мы закрыли скрытое ожидание клиента — он хотел качественную аналитику, а не только цифры.

А еще:

• итоговая конверсия увеличилась примерно в 1,5 раза

• выручка по проекту выросла в 2 раза

С точки зрения личной эффективности я теперь экономлю до 20 часов в месяц на прослушке диалогов и могу анализировать до 100 диалогов в час. 

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

4️⃣ Какие задачи еще можно отдать ИИ в работе аналитика?

Помимо анализа данных:

• подготовка презентаций 

• написание текстов

• проведение исследований

• сбор и структурирование данных

• оформление документации

Это не заменяет аналитика, но сильно упрощает старт и ускоряет процесс.

5️⃣ Какие инструменты тебе показались полезными?

Из того, что я использовала в работе:

1. GigaChat — хорошо справляется с исследованиями на российском рынке

2. SkyWork.ai и Gamma — помогают быстро собрать презентацию и структуру доклада

3. НейроЭксперт — удобно работать с файлами и базой знаний

4. Ассистенты для генерации промптов от Naumen — чтобы не просто перефразировать промпт, а уточнить задачу через вопросы и сделать его точнее

5. Кастомные агенты с использование Claude Code — чтобы автоматизировать процесс и сократить ручную работу

6️⃣ Есть ли риски или ограничения, о которых важно помнить?

Да, и об этом часто забывают. Перед использованием данных важно:

• уточнять у клиента, что является конфиденциальной информацией

• обезличивать данные

• проверять результаты

ИИ может сильно ускорить работу, но ответственность за итог все равно остается на аналитике.

Я не врач, и этот текст не является прямой медицинской рекомендацией. Ниже — разбор свежих исследований по нейробиологии (в частности, из Frontiers in Nutrition) и системный подход к метаболизму. Прежде чем внедрять такие «патчи» в свой режим, проконсультируйтесь со специалистом и сдайте базовые анализы.

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

Основные «баги» позднего питания:

• Инсулиновый лаг: вечером чувствительность к инсулину падает на 17–27% по сравнению с утром. Углеводы усваиваются хуже и с большей вероятностью уходят «в своп» (жировые депо).

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

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

Механика: eTRE и апгрейд нейронных магистралей

Решение кроется в eTRE (Early Time-Restricted Eating) — ограничении окна питания ранними часами (например, с 08:00 до 16:00). Это не просто диета, а способ синхронизировать метаболизм с циркадным «дирижером» организма.

Согласно свежим данным МРТ-исследований, такой режим за месяц проводит реальный апгрейд «железа» в голове:

• Укрепление белого вещества. Улучшается целостность волокон в левой передней таламической лучистости (ATR_L). Этот тракт соединяет таламус с префронтальной корой, отвечая за скорость передачи данных и когнитивный контроль.

• Оптимизация коры (DLPFC). Наблюдается адаптивное истончение правой дорсолатеральной префронтальной коры. В данном контексте это не деградация, а синаптический прунинг — удаление неэффективных связей, что делает работу мозга более точной и быстрой.

• Метаболическая гибкость. Стабильный уровень глюкозы и снижение инсулинорезистентности создают идеальную среду для нейронной пластичности и памяти.

Источники: Frontiers in Nutrition: eTRE and Brain Structure (2026) ; PubMed: Early time-restricted eating (eTRE) ; ScienceDirect: Meal patterns and cognitive health

Данные: результаты 30-дневного спринта

Исследование на группе мужчин с метаболическим синдромом показало впечатляющие результаты всего за 4 недели работы в окне 08:00–16:00:

• Метаболические метрики: значительное снижение веса, ИМТ и индекса HOMA-IR (маркер инсулинорезистентности).

• Когнитивные тесты:

  • Память: рост показателей немедленного и отсроченного воспроизведения по тесту RAVLT.

  • Исполнительные функции: сокращение времени выполнения теста TMT-B, что говорит о лучшей переключаемости внимания и планировании.

  • Processing Speed: улучшение средней скорости реакции при обработке информации.

• Структура мозга: изменения в толщине коры DLPFC на 60% объяснили прогресс в долгосрочной памяти участников.

  Вывод: питание как часть когнитивного стека

Циркадное питание — это не про ограничения в еде, а про управление временем (scheduling). Перенос основного объема калорий на первую половину дня позволяет организму тратить ресурсы не на ночное пищеварение, а на консолидацию памяти и очистку мозга.

TL;DR для тех, кто проскроллил:

• Окно 8/16: старайтесь закрывать окно питания к 16:00–17:00. Это дает максимальный буст памяти и концентрации.

• Завтрак — это база: регулярный завтрак защищает от когнитивного снижения.

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

• Вечерний конфиг: если приходится есть поздно, выбирайте белок и клетчатку (рыба + овощи), исключая быстрые углеводы.

1. Добавляем в систему раскладку сербской латиницы в варианте Qwerty, делается это через Keyboard -> Layouts

2. Заходим в терминал и пишем: setxkbmap -query
   Видим примерно такое:

   rules:      evdev
   model:      pc105
   layout:     us,ru,rs
   variant:    ,,latinyz
   options:    grp:win_space_toggle,terminate:ctrl_alt_bksp,grp:caps_toggle

   Внимание на us,ru,rs и вариант - latinyz

3. Пилим исполняемый shell скрипт, например в ~/use_default_layout.sh
   Этот скрипт будет временно убирать сербскую раскладку, чтобы не мешалась.

   #!/bin/bash
   current_layouts=$(setxkbmap -query | grep layout | awk '{print $2}')
   
   if [[ "$current_layouts" != "us,ru" ]]; then
       setxkbmap -layout "us,ru"
   fi

4. Идём в Keyboard, добавляем кастомные сочетания клавиш:

   

   Я переключаю раскладку с помощью Caps Lock, поэтому рассказываю как удобно мне. Вы делайте на те клавиши, которые удобны вам (иначе какой смысл).
   
   - Переключение на сербскую раскладку: CTRL+Caps Lock, команда:
   setxkbmap -layout rs -variant latinyz
   
   - Отмена сербской раскладки: просто Caps Lock, который зовёт скрипт use_default_layout.sh из пункта 3.

Готово, вы великолепны.

Привет, друзья! Я готовлю небольшое исследование на тему определенных особенностей использования различных платформ виртуализации на просторах РФ (чуть позже вы узнаете все детали). И, поскольку я не аналитическое агентство, а просто инженер, у которого нет возможности обзвонить 100+ компаний, за информацией я решил обратиться к наиболее подходящей для этого аудитории.

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

Что бы я хотел узнать? За последние годы ситуация с используемым в РФ софтом сильно изменилась — виртуализации это тоже касается. В связи с этим я бы хотел задать пару вопросов:

1. Какую платформу виртуализации вы используете?

2. Как получаете обновления?

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

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

Спасибо!

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

Все это я к чему - большой вопрос, существует ли какая-то защита от некорректного ввода значений? Точно сказать нельзя - ошибка всего одна.
При наличии проверок в интерфейсе такое возможно только если нет проверок на уровне СУБД и данные записывали, или корректировали, непосредственно в БД.

Но, что важнее - а насколько можно доверять остальной информации в реестрах ФИПС ? ...

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

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

В итоге сервис вроде живой, а дальше начинается админская археология.

Поэтому для каталога мало просто уметь подняться из копии. Нужно ещё уметь нормально разруливать логические потери без отката всего подряд.

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

При этом у классических CLI есть очевидные преимущества:

- Их банально легче разрабатывать

- Они прозрачнее и понятнее в работе

- Применяться они могут не только агентами, но и людьми

- Их уже существует огромное множество под любые задачи

В Google это тоже осознали и выкатили [свой инструмент](https://github.com/googleworkspace/cli). Сделан он явно для агентов (его выпустили только в этом месяце), но это именно CLI, а не очередной MCP-сервер.

Точных фактов по этой теме пока нет. Кто-то говорит, что [в простых задачах MCP требует больше контекста, а в сложных — меньше, чем CLI, если инструменты грамотно обернуты и хорошо обнаруживаются агентом](https://portofcontext.com/blog/cli-vs-mcp-vs-code-mode). Кто-то, что этой разницей можно пренебречь, да и вызвана она тем, что не все CLI адаптированы под экономию контекста. Но все согласны, что CLI может дать агенту доступ ко всем тем же инструментам и обеспечить одинаковый процент успеха при выполнении задач, при этом будучи куда понятнее для человека и значительно проще в написании и поддержке.

В моих проектах я буду использовать CLI.

«Искусство спора. Как читать книги» Поварнин С.И.

Книга состоит из двух несвязанных половин. Первая – про ведение споров, вторая – как читать книги.

Первая часть, про споры – максимально практичная, с конкретными приёмами, видами споров, стратегиями их ведения, прекращения, выхода из спора и т.д. Книга написана в начале 20 века, но по сути, ничего с тех пор не изменилось, поэтому всё – актуально. Разве что письменные споры стали быстрее, чем 100 лет назад.

Вторая часть, про чтение книг – покороче, т.к. материала меньше. Но тоже всё чётко и конкретно. Рассмотрены виды чтения по степени глубины, а также даны рекомендации по выбору книг. Я запомнил три вида книг, которые рекомендует автор – классику (чтобы быть образованным человеком), книги для вдохновения (вот это прям удивительно было), ну и профессиональную литературу по своей специальности.

Я эту книгу прочитал недавно, но очень порадовался – она сильно попала в подходы, которые я сформулировал сам для себя, но автор сформулировал три потока тем для чтения более чётко, конкретно и объяснил, зачем и почему.

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

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

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

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

Раньше, до прочтения этой книги, я называл это правилом Ральфа (т.к. видел его в мультфильме «Ральф против интернета»). Там сказали: «Первое правило интернета – никогда не читать комментарии». Я трансформировал в «никогда не вступать в дискуссии в комментариях».

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

Тогда же и придумал себе правило – «отвечай статьёй». С тех пор беззастенчиво использую комментарии, как источник идей для новых статей.

Книгу рекомендую. Хорошая, старая, добротная, для читателя.

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

Формат классический для сильных хакатонов: 48 часов на разработку решения, команда (или индивидуальное участие), реальные кейсы и ограниченное время на принятие решений. Но ключевое отличие — контекст. Хакатон проходит в рамках Международного экономического форума «Россия — Исламский мир: KazanForum», что задает более высокий уровень задач и ожиданий.

Что будет происходить

Участникам предстоит за два дня:

— разобраться в кейсе (финтех / продукт / технологии)

— предложить рабочую концепцию решения

— реализовать прототип

— подготовить презентацию

Фокус — не просто на коде, а на продукте в целом: логика, применимость, масштабируемость.

Для кого это ?

Организаторы ориентируются на широкий круг участников:

— ИТ-команды, которые хотят проверить себя в конкурентной среде

— Студенты профильных направлений

— Разработчики и дизайнеры с продуктовым мышлением

— Аналитики, умеющие работать с данными и бизнес-кейсами

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

Почему это может быть интересно ?

Хакатоны давно перестали быть просто «соревнованием программистов». Сейчас это:

— быстрый способ протестировать идеи

— возможность собрать сильную команду

— доступ к экспертной обратной связи

— нетворкинг с индустрией

Плюс, в данном случае — интеграция в международную повестку форума.

Организаторы

Хакатон проводят:

— Министерство цифрового развития Республики Татарстан

— ИТ-парк

— компания «Технократия»

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

Условия участия

📅 Даты: 11–13 мая 2026

📍 Место: Казань, ИТ-парк

⏱ Формат: 48 часов

👥 Участие: индивидуально или в команде

🎯 Направления: финтех, продукт, технологии

💰 Призовой фонд: 500 000 рублей

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

Итог

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

Такие события редко дают «волшебный билет», но почти всегда дают опыт, контакты и понимание своего уровня.

Регламент хакатона доступен по ссылке.

⚡️Подайте заявку на участие прямо сейчас

Многие компании сегодня вынуждены заново выстраивать 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 году. Скоро ее опубликуем!