➡️ SQL: ЛОВУШКА ДУБЛЕЙ И ДАТ

Иногда самая коварная задача - найти “покупали 3 дня подряд”. Профи часто делают self-join на даты, но он ломается на дубликатах, таймзонах и нескольких покупках в день.

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

-- Задача:
-- Найти пользователей, которые совершали покупку 3 календарных дня подряд (минимум).
-- Условия:
-- 1) В один день может быть много покупок - считаем день один раз.
-- 2) Нужны именно подряд идущие дни без пропусков.
-- 3) Вернуть user_id и начало/конец самой длинной серии.

WITH days AS (
SELECT DISTINCT
user_id,
DATE(created_at) AS d
FROM orders
),
grp AS (
SELECT
user_id,
d,
-- трюк: для подряд идущих дат разность (дата - номер) постоянна
DATEADD(day, -ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY d), d) AS g
FROM days
),
streaks AS (
SELECT
user_id,
MIN(d) AS streak_start,
MAX(d) AS streak_end,
COUNT(*) AS streak_len
FROM grp
GROUP BY user_id, g
)
SELECT user_id, streak_start, streak_end, streak_len
FROM streaks
WHERE streak_len >= 3
ORDER BY streak_len DESC;

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX

🔥 The Epstein Network

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

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

➡️ https://epstein-doc-explorer-1.onrender.com/

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX

🔥 Вышел 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/

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX

➡️ Timescale выпустил pg-aiguide: практический гайд по ИИ в PostgreSQL

Timescale опубликовал открытый репозиторий pg-aiguide - это собрание лучших практик, примеров и шаблонов по работе с ИИ поверх PostgreSQL (в том числе TimescaleDB).

Что внутри:

⏺️ примеры интеграции LLM и AI-функций с БД
⏺️ готовые SQL-рецепты и расширения
⏺️ семантический поиск и анализ данных
⏺️ шаблоны, которые можно сразу использовать в проде

Это не теория, а набор готовых подходов для реальных проектов.

➡️ https://github.com/timescale/pg-aiguide

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX

➡️ Локальная панель для Cloudflare Workers

Localflare — это инструмент для разработки, который упрощает взаимодействие с вашими ресурсами Cloudflare, такими как D1 базы данных, KV пространства и R2 бакеты. Он предлагает интуитивно понятный интерфейс для визуализации и управления данными в процессе разработки.

Основные моменты:

⏺️ Полнофункциональный SQL-редактор для D1 баз данных
⏺️ Удобный браузер для работы с KV парами
⏺️ Менеджер файлов для R2 бакетов
⏺️Инспектор очередей для тестирования сообщений
⏺️ Работает с любыми фреймворками без настройки

➡️ GitHub: https://github.com/rohanprasadofficial/localflare

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX

➡️ ШПАРГАЛКА: Как правильно поднимать БД перед проектом

Главная ошибка новичков - “у всех база разная”.
В итоге миграции ломаются, схема плывёт, на CI одно, у тебя другое, в проде третье.

Правильный старт всегда одинаковый:

⏺️ Поднимай БД через Docker - чтобы у всей команды окружение было идентичным
⏺️ Все параметры (пароль, порт, имя БД) храни в .env
⏺️ Схему меняй ТОЛЬКО через миграции (Flyway/Liquibase/EF/Alembic)
⏺️ Добавь healthcheck - сервис не должен стартовать раньше БД
⏺️ Сделай команды backup/restore - пригодится в любой момент

Так ты гарантируешь:

⏺️ у всех одна и та же база
⏺️ быстрый старт проекта за 3 минуты
⏺️ деплой без сюрпризов

1) Создай .env
cat > .env << 'EOF'
POSTGRES_DB=app
POSTGRES_USER=app
POSTGRES_PASSWORD=app123
POSTGRES_PORT=5432
EOF

2) docker-compose.yml для Postgres + healthcheck
cat > docker-compose.yml << 'EOF'
services:
  postgres:
    image: postgres:16
    container_name: app-postgres
    restart: unless-stopped
    environment:
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    ports:
      - "${POSTGRES_PORT}:5432"
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 5s
      timeout: 3s
      retries: 20

volumes:
  pgdata:
EOF

3) Запуск
docker compose up -d

4) Проверка
docker compose ps

5) Backup
docker exec -t app-postgres pg_dump -U app app > backup.sql

6) Restore
cat backup.sql | docker exec -i app-postgres psql -U app -d app

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX

➡️ Как не убить базу большими таблицами в SQL - фильтруй и агрегируй как можно раньше

Главная ошибка при работе с большими таблицами - делать SELECT * и потом надеяться, что "оно как-нибудь".

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

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

Практическое правило: если запрос возвращает миллионы строк - ты почти наверняка решаешь задачу неправильно. В 90% случаев тебе нужна витрина: GROUP BY, window-функции, или отдельная агрегированная таблица. А чтобы база не страдала, добавляй индексы под фильтры и под JOIN-ключи, и проверяй план выполнения через EXPLAIN.

 ПЛОХО: тащим весь объём и только потом думаем
SELECT *
FROM events
WHERE created_at >= NOW() - INTERVAL '90 days';

-- ХОРОШО: сразу сужаем, берем нужные колонки, считаем агрегаты
SELECT
  user_id,
  COUNT(*) AS events_7d,
  MAX(created_at) AS last_event_at
FROM events
WHERE created_at >= NOW() - INTERVAL '7 days'
GROUP BY user_id;

-- Индекс под фильтр по времени + join по user_id (частый паттерн)
CREATE INDEX IF NOT EXISTS idx_events_created_user
ON events (created_at, user_id);

-- Проверяй план, чтобы не было Seq Scan на миллионах строк
EXPLAIN (ANALYZE, BUFFERS)
SELECT user_id, COUNT(*)
FROM events
WHERE created_at >= NOW() - INTERVAL '7 days'
GROUP BY user_id;

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX

Материалы для подготовки к собеседованиям

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

🔴10 ключевых лайфхаков по резюме
🔴Нужны ли сопроводительные и что там писать
🔴Как отвечать на вопрос «Расскажите о себе»
🔴Как рассказывать о своем факапе?
🔴13 шаблонных отказов рекрутеров - что они означают.
🔥 Разборы резюме для разработчиков c нанимающим СТО

ну и то, что нам особенно интересно - про офферы и ЗП
🔴45 офферов по разным ИТ ролям: от аналитика до тим тим лида за 850к
🔴Какой тим лид получил 1,2 млн
🔴Оффер на Product lead в Яндекс
🔴Оффер на Руководителя проектов на 540к
🔴Оффер на функционального архитектора 1С на 460к
🔴Пошаговый план как выйти в найме на 1 млн руб

Сохраняйте, читайте, подписывайтесь

🔥 Теперь можно ничем не беспокоиться

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX

➡️ ML-модель пересобирает логику ранжирования маршрутов

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

Второе важное изменение — переход от задачи ранжирования к задаче выбора (Softmax + one-hot таргет). Модель больше не отвечает на вопрос «какой маршрут лучше в рейтинге?» — она учится угадывать единственный вариант, по которому пользователь действительно поедет. Фактически навигация сместилась от абстрактной оптимизации ETA к предсказанию реального выбора водителя — как если бы система пыталась угадать, какой маршрут человек сам бы выбрал, взглянув на карту. Почему выбрали в итоге не классический для такой задачи YetiRank — в разборе команды на Хабре.

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX

🔥Появился сервис для прожарки вашего стартапа — ShipOrDie

Механика простая — вставляешь ссылку (или описываешь идею) и отдаёшь на растерзание боту и другим участникам. Сервис не щадя проходится по тексту и смыслам, находит размытые формулировки и перегретые обещания.

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

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX

🔥 Что внутри ИИ-стартапа?

А внутри у него Claude или ChatGPT в 70% случаев.

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

Довольно часто в описаниях этих ИИ-продуктов можно встретить что-то про «файн-тюнинг», «проприетарные LLM» и другие интересные термины. Они как бы намекают, что компания предлагает какие-то свои собственные технологии или хотя бы доступ к улучшенным, дообученным и докрученным моделям.

➡️ Мини-исследование на выборке из 200 стартапов показало, что подавляющее большинство с этим не заморачиваются.

Автор, разработчик ПО и создатель ИИ-систем, на протяжении 3 недель изучал активность 200 ИИ-стартапов. Он промониторил трафик, разобрал и проанализировал из JavaScrist бандлы, а потом сравнил свои выводы с тем, как они сами описывают свой продукт.

73% в своих обещаниях потребителям наврали. Их уникальные ИИ-тулы оказались:
⏺️OpenAI API с парочкой промптов (ну хоть их сами написали). У одной из таких компаний автор нашел промпт: «Ты эксперт в (название компании). Всегда отвечай в профессиональной манере. Никогда не упоминай свою связь OpenAI и что ты языковая модель».
⏺️OpenAI API с RAG-архитектурой — векторной БД, обычно Pinecone и Weaviate. Уже лучше, хотя ничего уникального и авторского тут нет.
⏺️OpenAI API, Claude с библиотекой промптов или модель с HugginFace с LoRA.

Он также привел несколько советов, как отличить честный стартап от тех, кто продает доступ к OpenAI или Claude по оверпрайсу:
⏺️Проверить трафик их ИИ-продукта на запросы к api.openai.com, api.anthropic.com или api.cohere.ai.
⏺️Засечь скорость ответа. Если он приходит через 200–350 мс, то отвечает, скорее всего GPT-4.
⏺️Поискать в бандлах JavaScript openai, anthropic, sk-proj-, claude и cohere.
⏺️Внимательно почитать, как разработчики рекламируют свой продукт. Если вы видите много громких слов без деталей и конкретики, это повод напрячься.

Использование готовых моделей — это не всегда красный флаг. Некоторые компании честно признаются, чей ИИ под капотом их продукта. И обычно они продают не сам ИИ, а оптимизацию работы с ним: удобный интерфейс, управление несколькими моделями сразу, грамотно выстроенную RAG-архитектуру. Это все не плохо — плохо врать и называть это «продвинутой проприетарной ИИ-инфраструктурой».

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX