GitHub Ready | Git

На Stepik завирусился полный курс по вайбкодингу c Claude Code Первым делом вы изучите базу инструмента, а после научитесь: ✓ Разрабатывать MCP-серверы и Claude Skills ✓ Создавать собственных ИИ-агентов под свои задачи ✓ Эффективно работать с Claude и не упираться в лимиты ✓ Проектировать приложения через Claude Design ✓ Строить личную систему знаний на базе Obsidian + Claude Cowork ✓ Автоматизировать разработку через Agent Loops и хуки ✓ Запускать параллельные воркфлоу из нескольких агентов ✓ Проектировать приложения вместе с Claude Code ✓ Автоматизировать задачи через Connectors и внешние сервисы ✓ Перевести Claude Code из помощника в полноценного участника команды разработки ✓ Убирать из текстов типичные ИИ-шаблоны с помощью файла anti-ai-writing-style.md. ✓ Работать с таблицами при помощи Cowork В конце дорожная карта и 7 практических способа обхода ограничений Anthropic 🎉 В течении 48 часов действует скидка 25%

nothing design Кто-то собрал скилл «nothing design» для Claude Code. Просто вызываешь /nothing-design, и он генерирует весь UI в фирменном монохромном индустриальном стиле. Швейцарская типографика, матричные паттерны и глубокий OLED-чёрный — всё зашито прямо в агент. Cсылка на GitHub

🐍 FastAPI BackgroundTasks: Как запускать тяжелый код, не заставляя пользователя ждать Когда пользователь нажимает кнопку «Зарегистрироваться» или «Скачать отчет», твой бэкенд на FastAPI должен среагировать мгновенно. Если внутри этого запроса ты начнешь отправлять приветственное письмо через SMTP, генерировать тяжелый PDF-документ или парсить данные через Telethon, пользователь будет уныло смотреть на крутящийся спиннер несколько секунд. BackgroundTasks — это встроенный в FastAPI инструмент, который позволяет моментально вернуть ответ «Успешно», а тяжелую задачу незаметно докрутить в фоне. Задача: — Разгрузить основные эндпоинты API от долгих, не связанных с мгновенным ответом операций. — Минимизировать время ожидания ответа (TTFB) для клиентов. — Реализовать простую фоновую обработку без развертывания тяжелых очередей задач. Решение: Мы просто добавляем в параметры функции эндпоинта объект BackgroundTasks от самого FastAPI и перекидываем туда нашу тяжелую функцию вместе с нужными аргументами через метод .add_task(). Почему это идеальное быстрое решение? — Из коробки: Тебе не нужно устанавливать, настраивать и оплачивать Celery, Redis или RabbitMQ. Всё работает на стандартных возможностях Python и Starlette. — Не блокирует асинхронность: Если ты передаешь асинхронную функцию (async def), FastAPI запустит её в текущем цикле событий (event loop). Если передаешь обычную функцию (def), фреймворк сам отправит её в отдельный поток (thread pool), чтобы она не тормозила остальное приложение. — Доступ к контексту: Фоновые задачи запускаются *после* того, как ответ уже ушел пользователю, но в рамках того же процесса. Они имеют доступ к тем же пулам баз данных или настройкам приложения. — Чистый код: Логика контроллера остается легковесной — ты просто фиксируешь факт запроса и делегируешь работу дальше. Как это выглядит в коде? import time from fastapi import FastAPI, BackgroundTasks app = FastAPI() # Тяжелая функция (например, долгая запись логов в базу или отправка вебхука) def send_system_notification(email: str, message: str): time.sleep(5) # Имитируем тяжелую работу на 5 секунд print(self_email := f"Email sent to {email}: {message}") @app.post("/subscribe") async def subscribe_user(email: str, background_tasks: BackgroundTasks): # Логика быстрой валидации или сохранения в базу данных здесь... # Ставим задачу в фоновую очередь FastAPI background_tasks.add_task(send_system_notification, email, message="Welcome to our platform!") # Пользователь получает этот ответ МГНОВЕННО, не дожидаясь 5 секунд return {"status": "accepted", "message": "Subscription processing started"} Кому это нужно? — Разработчикам микросервисов и ботов, где нужно быстро подтвердить прием команды, а саму обработку (парсинг, отправку уведомлений в сетку каналов) сделать на секунду позже. — Всем, у кого в проекте есть задачи на 2–10 секунд, ради которых городить полноценный стек Celery + Redis пока объективно рано (оверинжиниринг). Совет: Помни, что встроенные BackgroundTasks живут в оперативной памяти твоего запущенного Python-процесса. Если сервер внезапно упадет или перезагрузится прямо в момент выполнения фоновой задачи, она сотрется и не повторится автоматически. Если тебе нужна гарантированная доставка, строгая очередность и сложная логика повторов (retries), тогда уже стоит смотреть в сторону полноценных брокеров вроде TaskIQ или Celery. 🔥 — если разгружаешь эндпоинты через фоновые задачи 🤝 — если пользователь честно ждет, пока скрипт отработает до конца

🖱 Экспортёр директорий проекта в читаемые файлы Dir2txt — инструмент командной строки, который позволяет быстро экспортировать структуру и содержимое директории в файлы форматов .txt или .json. 👉 Главная цель тулзы — помощь в структурировании кода для интеграции с AI-пайплайнами, такими как GPT-агенты и Retrieval-Augmented Generation. Клик

🎧 ИИ-музыку почти никто не слушает В новом исследовании изучили Spotify и выяснили, что 93% нейротреков не набирают даже 1000 прослушиваний. Авторы называют это music slop. Тысячи композиций заливают пачками в разные жанры, надеясь случайно попасть в рекомендации. Дистрибьюторы почти этому не мешают, а детекторы пока легко обходятся. А как часто вам попадается в реках нейрохрючево? • Источник

🍿 ИИ становится более контекстным: пользователям все реже нужны идеальные промпты Руководитель группы продукта «Поиск и Рекомендации» Яндекс Маркета Любовь Горбунова считает, что необходимость в предельно точных формулировках снижается: нейросеть все лучше понимает запросы и в перспективе с ней можно будет общаться как с консультантом в магазине — в свободной форме и с уточнениями по ходу диалога. Еще один тренд — использование ИИ вместе с VR/AR-технологиями. Уже сейчас такие решения улучшают сценарии виртуальной примерки одежды. А в будущем подход может распространиться и на другие категории, например, на «примерку» мебели в интерьере.

🍿 Мультивселенная схлопнулась.

LSP Enforcement Kit for Claude Code Механизм принудительного использования LSP-навигации в Claude Code: 6 хуков + 1 трекер состояния, которые блокируют неэффективные поиски через Grep и направляют Claude к использованию LSP-инструментов для навигации по коду. Поддерживаются MCP-серверы cclsp и Serena LSP. По словам автора, в тестах это дало примерно 73% экономии токенов. Cсылка на GitHub

🔒 Poetry: Наводим идеальный порядок в зависимостях Python-проектов Каждый, кто хоть раз писал более-менее крупный скрипт на Python, сталкивался с болью управления зависимостями. Классический requirements.txt постоянно разрастается, в него попадают лишние подзависимости (транзитивные пакеты), а при попытке развернуть проект на другом сервере всё ломается из-за конфликта версий. Poetry — это современный инструмент, который берет на себя управление виртуальными окружениями, пакетами и сборкой, заменяя собой pip, virtualenv и setup.py разом. Задача: — Изолировать зависимости каждого проекта без ручного создания папок .venv. — Гарантировать, что проект развернется на продакшене с точно такими же версиями библиотек, как и на компьютере разработчика. — Легко разделять пакеты для разработки (например, pytest, black, dive) и для продакшна (FastAPI, Pydantic). Решение: Poetry отказывается от кучи разрозненных конфигов и переносит всё управление в один стандартизированный файл — pyproject.toml. Он автоматически создает виртуальное окружение и жестко контролирует дерево зависимостей. Почему это маст-хэв для Python-разработчика? — **Файл блокировки (poetry.lock):** Когда ты устанавливаешь библиотеку, Poetry записывает в этот файл точные версии всех скачанных подпакетов и их хэш-суммы. При деплое команда poetry install поставит именно эти проверенные версии, что полностью исключает ситуацию «у меня локально всё работает, а на сервере упало». — Умное разрешение конфликтов: Если две разные библиотеки требуют одну и ту же утилиту, но разных версий, Poetry не даст молча перезаписать пакет (как это делает pip), а проведет глубокий анализ дерева зависимостей и выдаст четкую ошибку или найдет компромиссную версию. — Удобное разделение окружений (Dependency Groups): Можно одной командой добавить пакет исключительно для тестов или линтинга: poetry add pytest --group dev. При сборке продакшн-образа в Docker эти тяжелые библиотеки можно просто проигнорировать ключом --without dev. — Публикация в один клик: Если ты пишешь свою библиотеку, Poetry позволяет собрать её и загрузить в PyPI всего парой команд: poetry build и poetry publish. Основные команды, которые заменят тебе старый подход: — poetry init — интерактивно создает правильный pyproject.toml в существующем проекте. — poetry add fastapi — скачивает библиотеку, обновляет конфиг и фиксирует изменения в lock-файле. — poetry run python main.py — запускает твой скрипт прямо внутри изолированного виртуального окружения без необходимости предварительно писать source .venv/bin/activate. — poetry shell — активирует виртуальное окружение в текущей сессии терминала. Кому это нужно? — Разработчикам, которые устали вручную чистить requirements.txt от «мусорных» зависимостей после удаления крупных библиотек. — Командам, которым важна стопроцентная воспроизводимость окружения на компьютерах разных разработчиков и CI/CD пайплайнах. Совет: Чтобы виртуальное окружение создавалось прямо в папке твоего проекта (в привычной директории .venv), а не в глобальном кэше системы, сразу после установки Poetry выполни команду: poetry config virtualenvs.in-project true. Это сильно упростит интеграцию с VS Code или PyCharm и позволит Docker-контейнерам легче подхватывать окружение. 🔥 — если давно перешел на Poetry и забыл про pip 🤝 — если старого доброго requirements.txt до сих пор хватает ➡️ GitHub Ready | #Уроки

🐳 FastAPI + Lifespan: Правильный способ управлять запуском и остановкой приложения Когда ты пишешь бэкенд на Python с использованием FastAPI, тебе часто нужно выполнить какой-то код при старте сервера (например, подключиться к базе данных, прогреть кэш в Redis или инициализировать клиента для Telegram-бота через Telethon) и аккуратно закрыть эти соединения при остановке приложения. Раньше для этого использовались декораторы @app.on_event("startup") и "shutdown", но они уже официально устарели (deprecated). Современный и безопасный стандарт — это Lifespan-контексты. Задача: — Инициализировать тяжелые ресурсы (пулы подключений, клиенты API) строго в момент старта сервера. — Гарантировать безопасное закрытие всех коннектов при выключении приложения, чтобы не терять данные и не вешать сокеты. — Использовать единую, чистую асинхронную логику вместо разрозненных функций. Решение: Мы пишем специальную асинхронную функцию-контекстный менеджер с использованием декоратора @asynccontextmanager. Весь код до ключевого слова yield выполнится при запуске, а код после yield — перед самым выключением сервера. Почему это киллер-фича? — Единая логика: Весь жизненный цикл приложения собран в одном месте. Тебе не нужно искать по разным файлам, где создается подключение, а где оно закрывается. — Безопасная обработка ошибок: Если на этапе старта (до yield) что-то пойдет не так (например, база данных недоступна), FastAPI сразу остановит запуск и выдаст ошибку. Спецификация гарантирует, что приложение не поднимется в "сломанном" состоянии. — Удобство для тестирования: Передавая кастомный lifespan в тестовый клиент TestClient, можно легко подменять реальные подключения на моки (mock-объекты) для тестов, сохраняя ту же логику инициализации. — Поддержка State: Всё, что ты запишешь в словарь контекста через yield {"client": client}, автоматически станет доступно во всех твоих роутах (эндпоинтах) через объект request.state. Как это выглядит в коде? from contextlib import asynccontextmanager from fastapi import FastAPI, Request # 1. Создаем lifespan-контекст @asynccontextmanager async def lifespan(app: FastAPI): # --- Секция STARTUP --- # Код здесь выполняется ДО того, как приложение начнет принимать запросы print("Подключаемся к базе данных и Redis...") db_pool = "Тут реальный пул подключений" # Передаем ресурсы в state приложения, чтобы использовать их в роутах yield {"db": db_pool} # --- Секция SHUTDOWN --- # Код здесь выполняется ПЕРЕД полной остановкой сервера print("Закрываем все соединения и сохраняем логи...") # Очистка ресурсов: db_pool.close() # 2. Передаем lifespan в экземпляр FastAPI app = FastAPI(lifespan=lifespan) # 3. Используем ресурсы в эндпоинтах @app.get("/items") async def get_items(request: Request): # Достаем наш пул из объекта request.state database = request.state.db return {"status": "success", "db_info": str(database)} Кому это нужно? — Разработчикам высоконагруженных API, где критически важно не плодить лишние коннекты к СУБД на каждый чих, а использовать один глобальный пул. — Всем, кто переходит на современные версии FastAPI и хочет писать чистый, поддерживаемый асинхронный код. Совет: Если твое приложение использует много независимых сервисов (база, очереди, микросервисы), ты можешь разбивать логику на несколько контекстных менеджеров и вкладывать их друг в друга или использовать утилиты вроде contextlib.ExitStack, чтобы не превращать один lifespan-файл в бесконечную простыню кода. 🔥 — если уже переписал свои проекты на lifespan 🤝 — если по старинке используешь on_event или инициализируешь всё в глобальной области ➡️ GitHub Ready | #Уроки