Переход в ML часто выглядит как шаг в неизвестность, даже если вы давно в данных.

Вроде бы уже умеешь работать с данными, строить модели, делать выводы, но при этом не совсем понятно, что именно отличает ML-инженера от аналитика на практике. Какие навыки усиливать, как перестроить свой профиль, чтобы он выглядел не как “человек из data”, а как специалист, способный доводить модели до прода.

На мастер-классе по машинному обучению karpovꓸcourses подробно разбирают, как выглядит реальная роль ML-инженера в компании, какие задачи он решает, как обычно строится карьерный путь и какие шаги помогают быстрее и осознаннее перейти в эту роль, не теряя годы на хаотичное обучение.

Узнайте, какие навыки нужны и на примере реальной задачи по обучению модели посмотрите, как работает ML-инженер: https://clc.to/erid_2W5zFG1guAp

Реклама. ООО "КАРПОВ КУРСЫ". ИНН 7811764627. erid: 2W5zFG1guAp

🧱 Миграции без боли: как обновлять БД безопасно и без простоя

Сохраняй себе: в реальных проектах миграции - это не “ALTER TABLE и поехали”, а зона риска.

Один неверный шаг = даунтайм, блокировки и откат вручную.

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

Рабочая стратегия (2 шага)
1) Сначала добавляй новое, не ломая старое
- добавляй новые колонки/таблицы
- не удаляй и не переименовывай сразу
- не делай NOT NULL без дефолта

2) Потом переключай код
- сначала раскатываешь схему
- потом деплоишь код, который пишет/читает новое
- и только после этого убираешь старое

Это называется “expand → migrate → contract” и это стандарт продакшн-миграций.

Фишки, которые спасают на проде
- всегда делай миграцию идемпотентной (IF EXISTS / IF NOT EXISTS)
- не держи транзакцию долго
- избегай тяжёлых ALTER на больших таблицах
- проверяй количество строк, прежде чем апдейтить
- делай бэкап/дамп перед большим изменением

-- safe-migration.sql

-- 1) EXPAND: добавляем новое, не ломая старое
ALTER TABLE users
ADD COLUMN IF NOT EXISTS email_verified BOOLEAN DEFAULT FALSE;

CREATE INDEX IF NOT EXISTS idx_users_email
ON users(email);

-- 2) MIGRATE: переносим данные маленькими шагами (пример)
-- (в реальности делается батчами на больших таблицах)
UPDATE users
SET email_verified = TRUE
WHERE email IS NOT NULL AND email <> '';

-- 3) CONTRACT: удаляем старое только после деплоя кода
-- (делать отдельной миграцией!)
-- ALTER TABLE users DROP COLUMN old_email_flag;

Как продакт-менеджеру выжить и вырасти в эпоху AI

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

Центральный университет запускает бесплатные открытые онлайн-уроки «Продуктовый менеджмент в эпоху AI».

Кто будет говорить:
— Ваня Замесин — автор AURA и Advanced JTBD, основатель курса «Как делать продукт»
— Глеб Кудрявцев — ex CPO Skyeng и автор курса «Вайб-кодинг на максималках»
— Илья Красинский — основатель & CEO Rick. ai и продуктового курса Product Heroes.
О чем пойдет речь:
— Какие навыки остаются базовыми для продакта в эпоху нейросетей.
— Что уже сегодня можно делать в 10 раз быстрее с AI.
— Как писать промпты, которые дают качественный результат.
— Почему понимание юнит-экономики остается важным навыком в любую эпоху.
— Зачем продакту вайб-кодинг и как меняется профессия.
Когда: уроки с 28 января по 2 февраля, в 19:00 мск.
Участие полностью бесплатное.


После уроков сможете попасть на интенсив для продакт-менеджеров с возможностью получить грант до 75% на обучение в магистратуре Центрального университета.

Регистрируйтесь уже сейчас!

⚡️ ИИ для SQL: пусть он объяснит «почему запрос тормозит»

Профессиональный лайфхак:
не проси ИИ «оптимизировать запрос» вслепую.
Вместо этого — давай ему EXPLAIN / EXPLAIN ANALYZE и структуру таблиц.

ИИ отлично умеет:
- разбирать план выполнения
- находить узкие места (Seq Scan, лишние JOIN, сортировки)
- предлагать индексы и переписывание запроса по факту, а не наугад

Алгоритм простой:
1️⃣ запускаешь EXPLAIN ANALYZE
2️⃣ прикладываешь схему таблиц
3️⃣ спрашиваешь: *где bottleneck и что бы ты поменял?*

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

пример «правильного» запроса к ИИ с реальными данными

-- запрос
SELECT *
FROM orders o
JOIN customers c ON c.id = o.customer_id
WHERE o.created_at > NOW() - INTERVAL '30 days'
AND c.country = 'US'
ORDER BY o.created_at DESC
LIMIT 100;

-- план выполнения
EXPLAIN ANALYZE
SELECT ...
-- (сюда вставь полный план: Seq Scan / Index Scan / сортировки и т.п.)

-- схема таблиц (важно!)
\d orders
\d customers

-- вопрос ИИ:
"Разбери план выполнения. 
Где узкие места? 
Нужны ли индексы и какие именно? 
Можно ли переписать запрос быстрее, не меняя логику?"

@sqlhub

🚀🐬 Вышел MySQL 8.4.8 (LTS) - что нового

Доступен релиз MySQL 8.4.8 - это ветка Long-Term Support, то есть лучший выбор для продакшена: стабильность, долгий цикл поддержки и предсказуемые обновления.

Ключевые улучшения:
👉 InnoDB Redo Logging
- сообщения об ошибках стали информативнее
- теперь показывают текущий LSN и детали по redo log capacity
=> проще диагностировать проблемы с redo log и производительностью

👉 OpenSSL обновили до 3.0.18
- важное обновление для безопасности и совместимости

👉 Исправления багов и стабильность
- закрыли race conditions в InnoDB
- починили проблемы с очисткой binary logs (binlog purging)
- в целом релиз направлен на надёжность и производительность

Если ты сидишь на MySQL в проде - LTS 8.4.x выглядит как правильный путь обновления.

https://dev.mysql.com/downloads/mysql/

@sqlhub