SQL и Анализ данных

🤖 Machine Learning Roadmap: от базы до гуру вайбкодинга Карта обучения машинному обучению (Machine Learning, Deep Learning, LLM, Generative AI, MLOps) - от первого import numpy до уровня инженера, который понимает, как ИИ работает внутри, и может писать прод‑системы, а не только дёргать API. https://github.com/justxor/MachineLearningRoadmap/tree/main

🖥 SQL можно учить не по скучным таблицам, а через игру в стиле «Матрицы» Разработчик сделал тренажёр, где вы проходите уровни, находите терминалы и «взламываете» их SQL-запросами. Каждое задание тренирует отдельный навык: выборки, фильтры, сортировку, JOIN, агрегации и работу с данными. Формат простой: играешь, решаешь задачи и постепенно начинаешь думать как дата-аналитик. Идеальный вариант на выходные, если давно хотели подтянуть SQL без унылой теории. http://sqlprotocol.com/

Открыл Claude, написал большой промпт - получил обычный нейротекст. Рабочая схема другая. Сначала делаете файл about-me.md. Туда кладёте: кто вы, для кого пишете, какой стиль нужен, что бесит в текстах, какой результат хотите получать. Потом подключаете этот файл в Cowork, чтобы Claude читал его перед каждой задачей. И только после этого даёте реальную задачу: пост, план, письмо, разбор, аудит. Главный трюк - перед стартом заставьте Claude задать уточняющие вопросы. Не угадывать, а сначала понять задачу. В итоге он пишет не «как ИИ», а ближе к вашему стилю, потому что у него есть контекст. В комментариях оставлю промпт и схему. Подписывайтесь, если хотите пользоваться Claude как рабочим инструментом, а не генератором красивой воды.

Claude можно превратить в личного сборщика презентаций: https://www.youtube.com/watch?v=5RNTmbbyUHw Большинство людей просят AI: «сделай слайды» - и получают обычный текст, который потом приходится вручную переносить в PowerPoint. Но есть способ лучше: сделать для Claude отдельный Skill под презентации. Открываете Claude, заходите в Customize, выбираете Skills, создаете новый skill и вставляете туда свои правила: какие презентации вы делаете, для какой аудитории, в каком стиле, какая структура нужна и что должно быть на каждом слайде. После этого Claude перестает гадать. Он уже знает, как должен выглядеть ваш deck: где нужен сильный opening slide, где краткий executive summary, где схема, где таблица, где финальный CTA. Главная мысль простая: чем точнее instructions, тем меньше ручной переделки. Вместо хаотичного «сделай презентацию» вы получаете повторяемый workflow: один раз настраиваете skill, а дальше Claude собирает слайды по вашим правилам. Это не магия. Это нормальная упаковка контекста, стиля и структуры в reusable-инструмент. Именно так AI начинает работать не как чат-бот, а как часть вашего production-процесса. https://www.youtube.com/shorts/qyYOG338hyY

⚡️ Один SQL-запрос выполнялся за 298 мс. Почти такой же - за 0,66 мс. Разница в 451 раз из-за одной строки. Ситуация обычная: cursor pagination, сортировка по date DESC, id DESC, лимит на 1000 записей и composite index по (date, id). На первый взгляд, все должно работать быстро. Но EXPLAIN ANALYZE показывает другое: Postgres вроде бы использует Index Scan, но после этого выкидывает 900 000 строк через Filter. То есть индекс есть, но запрос все равно тащит слишком много лишнего. Проблема в условии: `date < @date OR (date = @date AND id <= @lastId)` Для разработчика это выглядит логично: сначала сравниваем дату, потом id. Но для оптимизатора такой OR плохо ложится на composite index. В итоге база не может сразу пойти по нужному диапазону и вынуждена фильтровать огромный кусок данных. Правильнее записать условие через tuple comparison: `(date, id) <= (@date, @lastId)` Смысл тот же, но для Postgres это уже понятный диапазон по составному индексу. И результат: 298 мс превращаются в 0,66 мс. Индекс сам по себе ничего не гарантирует. Важно не только создать индекс, но и написать запрос так, чтобы оптимизатор реально смог его использовать.

Редкий и реально продвинутый SQL-совет: используй логарифмы для произведения вероятностей. В SQL удобно считать SUM, AVG, COUNT, но почти никто не думает про PRODUCT. А в аналитике он часто нужен: вероятность цепочки событий, retention funnel, скоринговые модели, reliability, ML-фичи. Проблема: если перемножать много маленьких чисел, например 0.97 * 0.91 * 0.88 * ..., быстро получишь underflow или потерю точности. Математический трюк:

a * b * c = exp(ln(a) + ln(b) + ln(c))

То есть вместо прямого произведения считаем сумму логарифмов.

SELECT
    user_id,
    EXP(SUM(LN(probability))) AS total_probability
FROM events
WHERE probability > 0
GROUP BY user_id;

Где это полезно:

SELECT
    user_id,
    EXP(SUM(LN(conversion_rate))) AS funnel_survival_rate
FROM funnel_steps
GROUP BY user_id;

Это стандартный численный прием из математики, который делает расчет стабильнее. Особенно полезно, когда у тебя много шагов в воронке, вероятностная модель, риск-скоринг или аналитика событий. Главное правило: LN(x) работает только для x > 0, поэтому нули нужно обрабатывать отдельно. Например, если хотя бы одна вероятность равна нулю, итоговое произведение тоже будет ноль.

🖥 Курс «Git Pro: от первого коммита до уровня senior» - на Stepik project_final_v2_FINAL_truly_final - знакомо? Значит, пора. Большинство разработчиков знают 5 команд Git и боятся шестую. Коммитят в main, гуглят «how to undo» и копируют папку «на всякий случай». Это не работа - это выживание. После курса вы: — делаете rebase, не задерживая дыхание; — разбираете конфликт на 200 файлов по алгоритму; — возвращаете «потерянные навсегда» коммиты за 30 секунд через reflog; — пишете историю, которую не стыдно показать на code review. Git Flow, trunk-based, Pull Request, защита веток, CI/CD-хуки — всё, что отличает джуна от senior в командной работе. Скидка 53%, 48 часов: https://stepik.org/course/284799/

🚀 Примеры использования Cursor SDK для разработки Репозиторий содержит небольшие примеры для работы с Cursor SDK на TypeScript. Он позволяет интегрировать кодирующего агента в ваши приложения, управлять состоянием и взаимодействовать с агентами в облаке и локально. 🚀 Основные моменты: - Примеры для создания агентов и работы с API. - Веб-приложение для быстрой разработки и тестирования. - Канбан-доска для управления агентами и артефактами. - CLI для запуска агентов из терминала. 📌 GitHub: https://github.com/cursor/cookbook

wtf 💀

🖥 На Stepik обновили курс «C# с нуля до профи» Представьте: через четыре месяца вы открываете чужой .NET-проект и читаете его как книгу. IServiceCollection не вызывает ступора. async Task<IActionResult> пишется на автомате. Вы точно знаете, почему EF Core сгенерировал именно такой SQL - и как переписать запрос, чтобы он летал. Это не фантазия. Это результат после 16 модулей, в которых каждая концепция объясняется через код и закрепляется практикой. ООП, SOLID, LINQ, async/await, DI, EF Core, ASP.NET Core, Docker, Kubernetes - всё, что казалось магией, станет рабочим инструментом. А бонусом - портфолио проектов: от CLI-утилит и REST API до собственного SaaS с multi-tenancy, JWT и деплоем в Kubernetes под TLS. Скидка - 58% доступна 48 часов: https://stepik.org/a/282984/

⚡️ Векторные базы данных хорошо ищут похожие куски текста, но плохо понимают связи между ними. Обычный поиск работает так: есть вопрос - база находит top-k самых похожих фрагментов. Это удобно, если нужно вытащить один факт. Но если ответ спрятан в нескольких местах, например в разных документах, сообщениях или частях отчёта, простого similarity search уже мало. Нужно понять, как связаны люди, события, компании, причины и последствия. На этом и делает акцент FalkorDB GraphRAG-Bench. Самый большой отрыв у GraphRAG виден именно в сложных задачах: Complex Reasoning - 83.61 и Contextual Summarization - 85.08. То есть там, где нужно не просто найти похожий текст, а собрать смысл из нескольких связанных фрагментов. Простой вывод: если у вас база знаний, длинные документы или корпоративные данные, одного Vector DB может быть недостаточно. GraphRAG помогает модели не просто искать, а идти по связям. GraphRAG SDK полностью open-source: https://github.com/FalkorDB/GraphRAG-SDK

🚀 Логическая аналитика с LynxDB LynxDB — это легковесная система для анализа логов, работающая в одном бинарном файле без зависимостей. Она использует язык запросов Lynx Flow, позволяющий легко обрабатывать данные в виде конвейера. 🚀 Основные моменты: - Пайплайн-запросы для обработки данных - Полнотекстовый поиск и колоночное хранилище - Поддержка кластерного режима и материализованных представлений - Никакой конфигурации — разумные настройки по умолчанию - Активная разработка, обратная связь приветствуется 📌 GitHub: https://github.com/lynxbase/lynxdb #rust

🖥️✨ Hermes Web UI: Интуитивный веб-дашборд для управления AI чатами. Позволяет отслеживать использование, настраивать каналы и управлять заданиями через удобный интерфейс. 🚀Основные моменты: - Мультисессионное управление чатами с поддержкой различных платформ. - Аналитика использования токенов и отслеживание затрат. - Настройка и управление заданиями по расписанию. - Интегрированный терминал для работы с несколькими сессиями. 📌 GitHub: https://github.com/EKKOLearnAI/hermes-web-ui #javascript

Продвинутый SQL-прием: partial index вместо “универсального” индекса Если в таблице много строк, но запрос почти всегда смотрит только активные записи, не обязательно индексировать всё. Например, есть таблица заказов:

SELECT *
FROM orders
WHERE user_id = 42
  AND status = 'active';

Обычный индекс:

CREATE INDEX idx_orders_user_status
ON orders(user_id, status);

Работает, но он хранит данные по всем статусам: active, cancelled, archived, failed и так далее. Если чаще всего нужны только активные заказы, можно сделать partial index:

CREATE INDEX idx_orders_active_user
ON orders(user_id)
WHERE status = 'active';

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

SELECT *
FROM orders
WHERE user_id = 42
  AND status = 'active';

Индекс не обязан покрывать всю таблицу. Иногда лучший индекс - это индекс только по тем строкам, которые реально участвуют в горячих запросах. Особенно полезно для флагов вроде deleted_at IS NULL, status = 'active', is_published = true, processed = false. #sql #postgresql #database #backend

⚡️ Вы слышали про Rust. Знаете, что он быстрый, безопасный и что за ним будущее. Осталось одно: сесть и выучить. Этот курс со Stepik- кратчайший путь от «знаю что такое Rust» до «пишу на нём». 6 модулей, 50 уроков, 143 теста. Ownership, borrowing, traits, async, Tokio, Axum, макросы, WASM — всё разложено по полочкам и закреплено практикой. Никакого видео на 40 минут ради одной мысли. Подробный текст, много кода, реальные задачи после каждого урока. На выходе — портфолио из 10+ проектов: от CLI-утилит до REST API с базой данных. 48 часов действует скидка 55 процентов: stepik.org/course/269250

✔️ Hunyuan выпустил превью Hy3 в опенсорсе: 295B параметров, 21B активных, контекст 256K. Это гибридный MoE с режимами быстрого и медленного мышления, и первая модель после полной перестройки инфраструктуры предобучения и RL. Агент тянет цепочки до 495 шагов в продакшене, работает с документами, аналитикой данных и MCP-инструментами. По скорости инференса: время до первого токена сократили на 54%, полное время ответа - на 47%. При этом на живых задачах CodeBuddy и WorkBuddy модель падает меньше чем раз на десять тысяч запросов. На стандартных бенчах (SWE-bench Verified для кода, Terminal-Bench 2.0 для терминала, BrowseComp и WideSearch для веб-поиска) Hy3 идёт вровень с топовыми кодинговыми и поисковыми агентами. Совместима с OpenClaw, OpenCode и KiloCode, запускается через vLLM и SGLang. https://modelscope.cn/models/Tencent-Hunyuan/Hy3-preview https://github.com/Tencent-Hunyuan/Hy3-preview @ai_machinelearning_big_data #Hunyuan

Как за 1 час собрать рабочий Skill в Claude Это не теория, а простой пайплайн, который реально работает. Сначала идея Берёшь повторяющуюся задачу и сразу формулируешь, что именно должен делать скилл. Лучше максимально конкретно. Дальше сборка Запускаешь skill-creator и отвечаешь на вопросы. На выходе получаешь папку и SKILL.md с логикой, триггерами и инструкциями. Потом тест Пробуешь на реальных запросах. Смотришь, срабатывает ли там, где нужно. Оценка Смотришь eval. Это шаг, который почти все пропускают, а зря. Он показывает, где скилл ведёт себя нестабильно. Доработка Чистишь формулировки, уточняешь триггеры, убираешь лишние срабатывания. Финал Загружаешь в Capabilities → Skills и проверяешь уже в живом чате. Как ускорить процесс Открой Claude Cowork Выбери Opus + Extended Thinking И просто напиши: "Помоги создать скилл для моей повторяющейся задачи" Главное правило Если скилл срабатывает лишний раз, проблема почти всегда в описании. Хороший скилл - это не код, а правильно заданный контекст. https://www.youtube.com/shorts/GhgKXX0mdxk