wtf 💀

🚀 Примеры использования Cursor SDK для разработки

Репозиторий содержит небольшие примеры для работы с Cursor SDK на TypeScript. Он позволяет интегрировать кодирующего агента в ваши приложения, управлять состоянием и взаимодействовать с агентами в облаке и локально.

🚀 Основные моменты:
- Примеры для создания агентов и работы с API.
- Веб-приложение для быстрой разработки и тестирования.
- Канбан-доска для управления агентами и артефактами.
- CLI для запуска агентов из терминала.

📌 GitHub: https://github.com/cursor/cookbook

Редкий и реально продвинутый 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, поэтому нули нужно обрабатывать отдельно. Например, если хотя бы одна вероятность равна нулю, итоговое произведение тоже будет ноль.

⚡️ Один 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 мс.

Индекс сам по себе ничего не гарантирует.

Важно не только создать индекс, но и написать запрос так, чтобы оптимизатор реально смог его использовать.

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

Открыл Claude, написал большой промпт - получил обычный нейротекст.

Рабочая схема другая.

Сначала делаете файл about-me.md.
Туда кладёте:
кто вы,
для кого пишете,
какой стиль нужен,
что бесит в текстах,
какой результат хотите получать.

Потом подключаете этот файл в Cowork, чтобы Claude читал его перед каждой задачей.

И только после этого даёте реальную задачу:
пост, план, письмо, разбор, аудит.

Главный трюк - перед стартом заставьте Claude задать уточняющие вопросы. Не угадывать, а сначала понять задачу.

В итоге он пишет не «как ИИ», а ближе к вашему стилю, потому что у него есть контекст.

https://youtube.com/shorts/JjGrRyt_HBM

🤖 Machine Learning Roadmap: от базы до гуру вайбкодинга

Карта обучения машинному обучению (Machine Learning, Deep Learning, LLM, Generative AI, MLOps) - от первого import numpy до уровня инженера, который понимает, как ИИ работает внутри, и может писать прод‑системы, а не только дёргать API.

https://github.com/justxor/MachineLearningRoadmap/tree/main

🔥 Huawei хочет обойти санкции не нанометрами, а задержками в чипе

Huawei представила Tau Scaling Law - подход, который должен ускорять чипы не только за счёт уменьшения транзисторов, а за счёт сокращения времени прохождения сигнала внутри схемы.

Идея простая: если нельзя быстро догнать TSMC и Intel по литографии, нужно выжимать больше из архитектуры, трассировки, памяти, interconnect и софта. Меньше лишнего пути для сигнала - меньше задержка, выше плотность и эффективность.

Ключевая техника называется LogicFolding. Связанные логические блоки размещают ближе друг к другу, укорачивают критические провода, снижают сопротивление и паразитную ёмкость. Это даёт прирост без полноценного скачка на новый техпроцесс.

Huawei утверждает, что за последние шесть лет уже спроектировала и массово выпустила 381 чип с этим подходом, а будущие Kirin осенью 2026 года станут первым крупным тестом LogicFolding.

Самая громкая заявка - к 2031 году выйти на плотность уровня 14Å, то есть примерно 1,4 нм, без прямой зависимости от классического shrink.

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

Это не отменяет физику и не делает Huawei новым TSMC завтра. Но показывает, куда может сдвинуться гонка чипов: не только «у кого меньше нанометры», а «кто лучше сокращает задержки по всему стеку».

huawei.com/en/news/2026/5/ieee-iscas-tau-scaling

🆓 Ваши SQL-запросы работают, но через месяц их уже сложно прочитать и изменить?

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

На открытом уроке разберём: как использовать обобщенные табличные выражения (CTE), чтобы писать сложные запросы по шагам.
Покажем, как упростить структуру, сделать код читаемым и работать с иерархиями через рекурсивные CTE.

🗓 Урок проходит в преддверии старта курса «PostgreSQL для администраторов баз данных и разработчиков».

Если вы хотите писать SQL, который легко читать и поддерживать — подключайтесь 27 мая в 20:00 МСК.

🔗 Регистрация открыта: https://tglink.io/e6a3872408e743?erid=2W5zFJG1JPK


Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.