GitHub Ready | Git
6K subscribers
645 photos
75 videos
1 file
573 links
По всем вопросам: @AdilNow
Download Telegram
📝 Stirling-PDF: Твой личный и приватный веб-редактор PDF без подписок

Каждый раз, когда нужно объединить два PDF-файла, сжать документ для госуслуг или распознать текст со скана (OCR), приходится либо идти на сомнительные онлайн-сервисы и сливать туда свои документы, либо покупать тяжелый софт. Stirling-PDF — это полноценный швейцарский нож для работы с PDF, который работает прямо в браузере и крутится локально на твоем сервере.

Задача:
— Редактировать, объединять, разрезать и конвертировать PDF-документы.
— Распознавать текст со сканов и картинок (OCR) на десятках языков.
— Сжимать файлы, снимать пароли и ставить водяные знаки без отправки данных в сторонние облака.

Решение:

Разворачиваем один контейнер Stirling-PDF. Проект написан на Java, работает быстро и предоставляет чистый, современный интерфейс со всеми возможными утилитами на главном экране.

Почему это маст-хэв в 2026 году?

100% приватность: Все операции с файлами происходят внутри твоего контейнера. Никакие данные не улетают на чужие серверы, что критично для договоров, сканов паспортов и финансовых отчетов.
Огромный функционал: Умеет конвертировать PDF в Word/Excel/PowerPoint и обратно, добавлять подписи, генерировать изображения из страниц, чистить метаданные и даже выравнивать перекошенные сканы.
Полноценный OCR: Благодаря интеграции с Tesseract, инструмент намертво вшивает текстовый слой в отсканированные документы, делая их доступными для поиска.
Легковесность и кастомизация: Можно настроить авторизацию для нескольких пользователей, изменить внешний вид панели и убрать ненужные инструменты из меню.

Как запустить через Docker Compose?

# docker-compose.yml
services:
stirling-pdf:
image: frooodle/s-pdf:latest
container_name: stirling-pdf
ports:
- '8080:8080'
volumes:
- ./trainingData:/usr/share/tessdata # Для языковых пакетов OCR
- ./extraConfigs:/configs
environment:
- DOCKER_ENABLE_SECURITY=false # Включи true, если нужна авторизация
- LANGS=ru_RU,en_US # Языки интерфейса и OCR
restart: unless-stopped



Кому это нужно?

— Студентам для сборки дипломов, чертежей и курсовых из разных кусков и сканов.
— Фрилансерам и разработчикам для быстрой подготовки документов и договоров.
— Всем, кто устал от лимитов и рекламы на бесплатных сайтах-конвертерах.

Совет: Если тебе часто приходится распознавать русскоязычный текст, обязательно скачай файл rus.traineddata с гитхаба Tesseract и закинь его в примонтированную папку tessdata. Это поднимет точность распознавания сканов практически до идеала.


🔥 — если за приватность и локальные инструменты
🤝 — если продолжаешь гуглить «объединить pdf онлайн»

➡️ GitHub Ready | #урок
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥41
🐳 Dozzle: Простой и реактивный просмотр логов Docker в реальном времени

Когда на сервере что-то идет не так, первое, что ты делаешь — открываешь терминал и пишешь docker logs -f имя_контейнера. Но если контейнеров много, переключаться между ними в консоли и вчитываться в бесконечные строки логов становится неудобно. Dozzle — это ультралегкий и быстрый инструмент, который выводит логи всех твоих контейнеров в красивый веб-интерфейс прямо в браузере.

Задача:
— Читать логи Docker-контейнеров в реальном времени без SSH и терминала.
— Мгновенно искать нужные ошибки и варнинги по ключевым словам.
— Иметь под рукой легкую админку, которая не грузит процессор и память сервера.

Решение:

Разворачиваем Dozzle рядом со своими сервисами. Он не использует базы данных и не сохраняет логи к себе — он просто подключается к сокету Docker и транслирует то, что происходит прямо сейчас.

Почему это круче тяжелых систем логирования?

Легче некуда: Написан на Go. Потребляет всего пару мегабайт оперативной памяти и запускается за доли секунды.
Живой поиск и фильтрация: Можно искать по регулярным выражениям, фильтровать логи конкретного контейнера или искать текст сразу по всем запущенным сервисам.
Удобство UI: Поддерживает умный скроллинг, темную тему, автопрокрутку и позволяет скачать полный лог-файл в один клик.
Никаких сложных настроек: Инструмент сам находит все запущенные на хосте контейнеры. Тебе не нужно регистрировать их в конфигах.

Как запустить через Docker Compose?

# docker-compose.yml
services:
dozzle:
image: amir20/dozzle:latest
container_name: dozzle
ports:
- 8888:8080
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro # Доступ к логам в режиме Read-Only
restart: unless-stopped



Кому это нужно?

— Разработчикам для быстрой отладки приложений (бэкенда, очередей, баз данных) на тестовом сервере.
— Всем, кому надоело открывать консоль ради простой проверки print() или трейсбеков в коде.

Совет: По умолчанию Dozzle открывает доступ к логам всем, кто знает порт. Если ты выводишь его в интернет (например, через Nginx Proxy Manager), обязательно закрой его паролем с помощью встроенной в Dozzle авторизации (через переменные окружения DOZZLE_USERNAME и DOZZLE_PASSWORD) или средствами самого прокси-сервера.


🔥 — если за быстрый дебаг через браузер
🤝 — если docker logs --tail 100 — твой лучший друг

➡️ GitHub Ready | #Уроки
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3
Nginx Proxy Manager: Идеальный веб-менеджер для твоих доменов и SSL

Если ты поднял на сервере несколько контейнеров (например, FastAPI-бэкенд, базу данных и пару утилит из прошлых постов), перед тобой встает вопрос: как сделать так, чтобы они открывались не по портам вроде :8080 или :3001, а по красивым субдоменам с HTTPS? Nginx Proxy Manager (NPM) — это спасение для тех, кто не хочет вручную ковыряться в громоздких конфигурационных файлах Nginx.

Задача:
— Привязать домены и субдомены (например, api.myproject.com) к конкретным Docker-контейнерам.
— Автоматически выпустить бесплатные SSL-сертификаты Let's Encrypt и настроить их автопродление.
— Защитить админки сервисов с помощью базовой авторизации или ограничить доступ по IP.

Решение:

Разворачиваем стек из NPM. Мы получаем чистый и понятный веб-интерфейс, где добавление нового прокси-маршрута занимает ровно три клика.

Почему это маст-хэв?

Все гениальное — просто: Тебе больше не нужно писать proxy_pass http://localhost:8000; в терминале. Ты просто вводишь имя домена, выбираешь контейнер и жмешь «Сохранить».
SSL в один клик: NPM сам связывается с Let's Encrypt, проходит проверку, выпускает сертификат и настраивает автоматический редирект с HTTP на безопасный HTTPS.
Удобное управление: В одном окне видны все твои хосты, кастомные редиректы, 404-страницы и статус активных SSL-сертификатов.
Безопасность (Access Lists): Можно прямо в панели создать список «Логин-Пароль» и повесить его, например, на админку Portainer или Dozzle, создав дополнительный рубеж обороны.

Как запустить через Docker Compose?

# docker-compose.yml
services:
npm:
image: 'jc21/nginx-proxy-manager:latest'
container_name: nginx-proxy-manager
restart: unless-stopped
ports:
- '80:80' # HTTP трафик
- '443:443' # HTTPS трафик
- '81:81' # Порт для входа в админку NPM
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt



Кому это нужно?

— Разработчикам для быстрой организации полноценного продакшн-окружения с HTTPS.
— Всем, кто держит домашний сервер или VPS и хочет удобно управлять своими веб-ресурсами без боли в консоли.

Совет: Чтобы NPM мог перенаправлять трафик на другие твои контейнеры по их внутренним именам (например, http://backend-api:8000), обязательно объедини NPM и твои приложения в одну общую Docker-сеть (network). Это избавит тебя от необходимости пробрасывать порты приложений на хост-машину наружу.


🔥 — если за удобный веб-интерфейс для проксирования
🤝 — если пишешь конфиги Nginx вручную через nano/vim

➡️ GitHub Ready | #Уроки
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥31
⚡️Группа хакеров взломала сервера Skillbox, Geekbrains, Skillfactory и ещё 12 онлайн-школ, чтобы выгрузить их курсы в Telegram

Юристы пытаются удалить каналы за Авторские Права🤡 – потому вот актуальные ссылки на архивы:

По школам: 

Skillbox (1.12 ТБ)
├ Нетология (846 ГБ)
├ SkillFactory (720 ГБ) 
├ GeekBrains (934 ГБ)
└ Другие (3.21 ТБ)

По ЯП:

Python (1.48 ТБ)
SQL (982 ГБ)
C++ (590 ГБ)
С (318 ГБ)
GoLang (290 ГБ)
Другие (3.17 ТБ)

Ссылка на общий архив: @schools_hack_arc
😁10👎4
📊 Polars: Сверхбыстрая альтернатива Pandas на Rust для работы с данными

Если твой скрипт на Python начинает мучительно долго задумываться при обработке CSV-файлов или логов размером в пару гигабайт, пора менять инструмент. Polars — это современная библиотека для анализа данных, написанная на Rust, которая создана специально для эпохи многоядерных процессоров и больших объемов информации. Она работает в разы (а иногда и в сотни раз) быстрее классического Pandas.

Задача:
— Обрабатывать огромные датасеты, не упираясь в лимиты оперативной памяти.
— Эффективно утилизировать все ядра процессора при тяжелых операциях (группировки, джойны).
— Писать чистый, читаемый и поддерживаемый код для манипуляции данными.

Решение:

Polars уходит от старой архитектуры Pandas и использует под капотом Apache Arrow, ленивые (lazy) вычисления и глубокую оптимизацию запросов.

Почему это меняет правила игры?

Многопоточность из коробки: Pandas по умолчанию работает в один поток. Polars написан на Rust и параллелит любые операции на все доступные ядра процессора без твоего участия.
Ленивые вычисления (Lazy Evaluation): Вместо мгновенного выполнения каждой строчки кода, Polars может сначала построить граф запроса, оптимизировать его (например, выкинуть ненужные столбцы и отфильтровать строки *до* того, как загрузить весь файл в память) и только потом выдать результат.
Экономия памяти: Благодаря эффективному внутреннему представлению данных, Polars потребляет гораздо меньше RAM и реже падает с ошибкой Out of Memory.
Привычный синтаксис: Переучиваться заново не придется — структура выражений очень логична и напоминает смесь SQL и чистого Python.

Как это выглядит в коде?

import polars as pl

# Используем ленивое чтение для экономии памяти
df = (
pl.scan_csv("huge_logs.csv")
.filter(pl.col("status_code") == 500)
.group_by("endpoint")
.agg(
pl.len().alias("errors_count"),
pl.col("response_time").mean().alias("avg_time")
)
.sort("errors_count", descending=True)
.limit(10)
.collect() # Вот только здесь запускаются вычисления
)

print(df)



Кому это нужно?

— Разработчикам и дата-инженерам, которые пишут парсеры, аналитические скрипты или бэкенд-сервисы, работающие с тяжелыми отчетами.
— Всем, кто устал ждать по 5 минут, пока Pandas сожрет очередной массив данных.

Совет: Всегда начинай цепочку методов с pl.scan_csv() или pl.scan_parquet() вместо read_csv(). Именно префикс scan_ активирует ленивый режим (LazyFrame), который позволяет Polars применить всю магию оптимизации под капотом.


🔥 — если за скорость Rust в Python-скриптах
🤝 — если Pandas до сих пор хватает для мелких таблиц

➡️ GitHub Ready | #Уроки
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4👍1
Не крипта, не мемкоины, не казино

🥇 Твой пассивный доход должен строиться на понятных активах
А не на СКАМерских проектах-однодневках.

Notal 📈 — канал о том, как зарабатывать на автоматической торговле золотом и серебром без вечной жизни на графиках.

Начните с простого: получите БЕСПЛАТНУЮ версию робота с доходностью до 25% годовых. Без подписок. Без настроек.
🤖 SilentGain

Как возможны 25% годовых? Узнай⤵️
https://t.me/+SZaP3SGi1uZjNzYy
👎2👍1
🐳 Dive: Как заглянуть внутрь Docker-образа и выкинуть лишний мусор?

Когда ты собираешь Docker-образ для своего Python-приложения, он часто весит гораздо больше, чем ожидалось. Обычный docker images показывает только итоговый размер, но не дает понять, какой именно слой сожрал всю память. Dive — это крутейший TUI-инструмент для терминала, который позволяет буквально "разобрать" любой образ по слоям.

Задача:
— Увидеть структуру Docker-образа изнутри.
— Понять, какие файлы добавились, изменились или удалились на каждом шаге сборки (каждой строчке Dockerfile).
— Найти неэффективно используемое пространство и уменьшить размер финального билда.

Решение:

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

Почему это маст-хэв для оптимизации?

Пошаговый анализ: Перемещаясь стрелочками по слоям слева, ты видишь, как менялся состав файлов справа. Добавленные файлы подсвечиваются зеленым, измененные — желтым, удаленные — красным.
Коэффициент эффективности (Image Efficiency): Dive автоматически сканирует образ и выдает оценку в процентах. Он сразу подсвечивает "мусор" (wasted space) — например, файлы, которые были созданы в одном слое, а затем удалены в следующем (в Docker они все равно занимают место!).
Быстрый поиск: Можно мгновенно отфильтровать только измененные файлы, чтобы понять, какая именно команда RUN закинула в контейнер кэш пипа (.cache/pip) или временные apt-пакеты.
Интеграция в CI: Инструмент можно запускать в режиме проверки (CI=true). Если эффективность образа падает ниже заданного порога (например, 90%), сборка в CI/CD просто упадет.

Как пользоваться?

Установка не нужна, можно запустить утилиту прямо через сам Docker:

docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive:latest my-app-image:latest



Кому это нужно?

— Разработчикам, которые хотят довести свои Dockerfile до идеала.
— DevOps-инженерам, сражающимся за скорость деплоя и свободное место в Docker Registry.

Совет: Если ты видишь много "красных" (удаленных) файлов, которые все равно занимают место в кэше слоев, объединяй команды в Dockerfile через оператор &&. Например, установку зависимостей и очистку кэша нужно делать в рамках одной инструкции RUN apt-get install ... && rm -rf /var/lib/apt/lists/*.


🔥 — если вычищаешь образы до минимального размера
🤝 — если гигабайтные образы на сервере тебя не пугают

➡️ GitHub Ready | #Уроки
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3👎1
🐍 Telethon: Создаем мощных Telegram-ботов и скрипты автоматизации на Python

Если для работы с Telegram ты до сих пор используешь только стандартные библиотеки для обычных ботов (вроде aiogram или telebot), ты ограничен правилами Bot API. Ты не можешь читать историю чатов, анализировать активность пользователей в чужих группах или автоматически пересылать посты. Telethon — это мощная асинхронная библиотека на Python, которая работает напрямую через протокол MTProto (как официальные приложения), позволяя автоматизировать абсолютно любые действия от лица обычного пользователя.

Задача:
— Парсить контент, собирать базу пользователей или анализировать сообщения из любых открытых каналов.
— Создавать юзерботов (скрипты, которые работают от твоего личного имени), автоматизирующих ответы в личке или управление группами.
— Переносить и бэкапить медиафайлы, архивы чатов и логов без ограничений Bot API.

Решение:

Мы регистрируем приложение на официальном портале Telegram, получаем ключи api_id/api_hash и пишем асинхронный скрипт, который управляет аккаунтом на чистом Python.

Почему это киллер-фича для автоматизации?

Полная свобода действий: Скрипт умеет всё то же самое, что и ты в своем смартфоне: вступать в каналы, отправлять реакции, скачивать тяжелые файлы, мониторить сообщения в реальном времени и даже звонить.
— **Асинхронность (asyncio): Библиотека полностью асинхронна из коробки. Это позволяет одновременно следить за сотнями чатов и обрабатывать потоки данных без зависания скрипта.
Удобная работа с медиа: Скачивание картинок, видео или документов из постов реализуется буквально одной строчкой кода.
Обход жестких лимитов: Хотя у MTProto есть свои ограничения (Flood Wait), они гораздо лояльнее, чем лимиты для стандартных HTTP-ботов.

Как это выглядит в коде?**

Простой пример скрипта, который подключается к аккаунту и автоматически пересылает новые посты из одного канала в другой:

from telethon import TelegramClient, events

api_id = 1234567 # Твой api_id с my.telegram.org
api_hash = 'your_hash_здесь'

client = TelegramClient('my_session', api_id, api_hash)

# Слушаем новые сообщения в определенном канале
@client.on(events.NewMessage(chats='source_channel_username'))
async def handler(event):
# Пересылаем сообщение в свой целевой канал
await client.send_message('my_target_channel', event.message)

print("Скрипт автоматизации запущен...")
client.start()
client.run_until_complete()



Кому это нужно?

— Разработчикам, создающим сложные системы мониторинга упоминаний брендов или ключевых слов в соцсетях.
— Админам сеток Telegram-каналов для настройки автопостинга, кросспостинга и бэкапа контента.
— Всем, кто хочет автоматизировать рутинные ответы в мессенджере или собрать датасет для обучения нейросети.

Совет: При первом запуске скрипт попросит ввести номер телефона и код подтверждения из Telegram — так создается файл сессии (my_session.session). Береги этот файл и не выкладывай его в открытый доступ (например, на GitHub), так как он заменяет собой пароль и дает полный доступ к твоему аккаунту.


🔥 — если за мощные скрипты и работу через MTProto

🤝 — если для всех задач хватает обычного Bot API

➡️ GitHub Ready | #Уроки
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5🤝1
📄 JSON:API: Как раз и навсегда стандартизировать твой REST API

Когда ты пишешь бэкенд на Python или Node.js, перед тобой всегда встает вопрос: в каком формате отдавать данные фронтенду? Один разработчик завернет ответ в {"data": [...]}, другой сделает {"results": {}, "status": "ok"}, а третий забудет про пагинацию. В итоге клиентское приложение постоянно ломается, а на согласование JSON-схем уходят часы. JSON:API — это строгая спецификация, которая определяет конкретный формат для запросов и ответов.

Задача:
— Перестать спорить с командой о структуре JSON-ответов.
— Автоматизировать сложную выборку данных, фильтрацию, пагинацию и загрузку связанных сущностей.
— Уменьшить количество запросов от фронтенда к бэкенду за счет умного связывания ресурсов.

Решение:

Вместо того чтобы придумывать велосипед, ты берешь готовый стандарт. Ответ сервера всегда имеет предсказуемую структуру: data для основных ресурсов, included для связанных данных, meta для пагинации и errors для ошибок.

Почему это киллер-фича для архитектуры?

Решение проблемы N+1 на клиенте: Спецификация поддерживает параметр include. Если фронтенду нужно получить пост и сразу же автора с его комментариями, он просто делает запрос GET /posts/1?include=author,comments. Сервер отдает всё в одном JSON, распределяя связи по своим местам.
Экономия трафика (Sparse Fieldsets): Клиент может явно указать, какие именно поля ему нужны: GET /users?fields[users]=name,email. Бэкенд не будет вытягивать из базы тяжелые текстовые описания или аватарки, если они сейчас не нужны на экране.
Стандартизованные ошибки: Формат ошибок жестко прописан. Каждая ошибка содержит понятные ключи: status (HTTP код), title, detail (описание для разработчика) и source (указатель на конкретное поле в запросе, которое вызвало проблему).
Готовые библиотеки: Под JSON:API написаны десятки готовых сериализаторов и ORM-адаптеров для всех языков программирования (например, marshmallow-jsonapi для Python). Ты просто скармливаешь им модель из базы, а правильный JSON собирается сам.

Пример структуры ответа (Пост и его автор):

{
"data": {
"type": "posts",
"id": "1",
"attributes": {
"title": "Docker Compose для новичков"
},
"relationships": {
"author": {
"data": { "type": "users", "id": "42" }
}
}
},
"included": [
{
"type": "users",
"id": "42",
"attributes": {
"name": "Alex",
"role": "DevOps"
}
}
]
}



Кому это нужно?

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

Совет: Если ты используешь FastAPI, ты можешь настроить кастомный ResponseClass, который будет автоматически валидировать и оборачивать выходные Pydantic-модели в формат JSON:API. Это позволит сохранить скорость разработки, получив все плюсы строгого стандарта.


🔥 — если за строгие стандарты и порядок в API

🤝 — если под каждую задачу накидываешь кастомный JSON руками

➡️ GitHub Ready | #Уроки
Please open Telegram to view this post
VIEW IN TELEGRAM
2🔥2
📝 Pydantic V2: Валидация данных в Python на космической скорости

Если ты пишешь бэкенд на Python (особенно на FastAPI), ты точно знаком с Pydantic. Это главная библиотека для парсинга и валидации данных, которая превращает сырой JSON в строгие Python-объекты. Но если в твоем проекте до сих пор используются старые модели первой версии (V1), ты теряешь огромный запас производительности. Вторая версия Pydantic была полностью переписана, и её ядро теперь работает на Rust.

Задача:
— Валидировать огромные объемы входящих данных (API-запросы, логи, конфигурации) без просадки по CPU.
— Избавиться от костылей при очистке и преобразовании полей (например, автоматическое удаление пробелов или приведение строк к нижнему регистру).
— Получить строгую типизацию и предсказуемое поведение моделей при интеграции с базами данных.

Решение:

Переходим на Pydantic V2. За счет того, что вся тяжелая логика проверки типов и разбора строк теперь происходит на уровне скомпилированного кода на Rust, скорость работы выросла в 5–50 раз в зависимости от структуры модели.

Что изменилось и почему это круто?

— **Rust-мотор под капотом (pydantic-core): Библиотека больше не тратит циклы интерпретатора Python на циклы и проверки. Все базовые типы проверяются на максимальной скорости.
Два режима валидации:** Появился метод model_validate_json(). Он позволяет парсить сырую JSON-строку напрямую, минуя промежуточную стадию перевода в стандартный Python-словарь через json.loads(). Это дает колоссальный прирост производительности на высоконагруженных эндпоинтах.
Встроенные модификаторы (Annotated): Больше не нужно писать кастомные валидаторы через @validator для тривиальных задач. Очистка строк, ограничение длины массивов или проверка регулярных выражений теперь нативно нанизываются на типы.
Разделение на Python и JSON структуры: Метод model_dump() заменил старый .dict(), а model_dump_json() пришел на замену .json(). Архитектура стала чище и логичнее.

Как это выглядит в коде?

from typing import Annotated
from pydantic import BaseModel, Field, StringConstraints
from pydantic_core import ValidationError

# Ограничиваем строку: убираем пробелы по краям и приводим к нижнему регистру на уровне Rust
UsernameStr = Annotated[
str,
StringConstraints(strip_whitespace=True, to_lower=True, min_length=3)
]

class UserTarget(BaseModel):
id: int
# Использование встроенных проверок Field
username: UsernameStr
balance: float = Field(ge=0.0, default=0.0) # Баланс не может быть отрицательным

# Парсим сырой JSON напрямую на максимальной скорости
json_data = '{"id": 42, "username": " Admin_Sanya ", "balance": 150.50}'

try:
user = UserTarget.model_validate_json(json_data)
print(user.username) # Выведет: "admin_sanya" (пробелы удалены, регистр изменен)
print(user.model_dump()) # Быстрый перевод в dict
except ValidationError as e:
print(e.json())



Кому это нужно?

— Разработчикам микросервисов, обрабатывающих тысячи запросов в секунду, где важна каждая миллисекунда ответа сервера.
— Дата-инженерам для первичной фильтрации и валидации грязных данных перед их сохранением в СУБД или передачей в аналитические движки (вроде Polars).

Совет: Если ты мигрируешь старый проект с V1 на V2, тебе не обязательно переписывать все файлы разом. Разработчики оставили legacy-модуль. Достаточно изменить импорт с from pydantic import BaseModel на from pydantic.v1 import BaseModel, и старый код продолжит работать в изолированном режиме, пока ты постепенно обновляешь архитектуру приложения.


🔥 — если уже перешел на V2 и кайфуешь от скорости

🤝 — если в проектах до сих пор крутится старый добрый Pydantic V1

➡️ GitHub Ready | #Уроки
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3
🐳 Docker Init: Секретная команда, которая сама напишет Dockerfile за тебя

Когда нужно контейнеризировать новый проект на Python, Node.js или Go, процесс всегда начинается одинаково: ты идешь гуглить правильный шаблон Dockerfile, вспоминаешь, как правильно прокидывать зависимости, копировать файлы и настраивать docker-compose.yml. В итоге тратится время на рутину. Но начиная с версии Docker Desktop 4.18 (и в актуальном CLI 2026 года), встроена крутейшая команда — **docker init, которая делает всю эту работу за секунды.

Задача:**
— Быстро и без ошибок контейнеризировать проект с нуля.
— Получить оптимизированные под продакшн конфигурационные файлы без ручного копирования шаблонов.
— Сразу настроить правильное кэширование слоев, безопасного non-root пользователя и .dockerignore.

Решение:

Ты просто открываешь терминал в корне своего проекта и пишешь одну команду: docker init. Скрипт сам проанализирует исходный код, поймет язык программирования и запустит интерактивный конфигуратор.

Почему это киллер-фича?

Умное сканирование: Утилита видит файлы вроде requirements.txt, package.json или go.mod. Она сама определяет версию языка и предлагает оптимальный базовый образ.
Production-Ready конфиги: Сгенерированный Dockerfile — это не просто три строчки кода. Он сразу разбит на этапы (multi-stage build), содержит очистку кэша менеджеров пакетов и не запускает приложение от имени root (что критично для безопасности).
Полный комплект: Команда создает сразу четыре файла: Dockerfile, docker-compose.yml, .dockerignore и файл README.Docker.md с инструкциями по запуску конкретно для твоего стека.
Минимум вопросов: Тебе нужно лишь указать порт, на котором крутится приложение, и команду для старта (например, uvicorn main:app --host 0.0.0.0).

Как это выглядит на практике?

Для обычного FastAPI-приложения docker init создаст структуру, где в Dockerfile будут автоматически прописаны:
— Создание изолированного виртуального окружения.
— Монтирование кэша (--mount=type=cache), чтобы при повторной сборке и изменении одной строчки кода pip не скачивал все библиотеки заново.
— Переключение на системного пользователя uid=10001 для безопасного выполнения внутри контейнера.

Кому это нужно?

— Разработчикам, которые часто создают новые микросервисы и пет-проекты и хотят тратить время на код, а не на написание инфраструктурных конфигов.
— Тем, кто только знакомится с Docker и боится ошибиться в синтаксисе манифестов.

Совет: Перед запуском команды убедись, что в корне проекта лежат файлы зависимостей (например, pyproject.toml или requirements.txt). Если проект будет абсолютно пустым, docker init не сможет автоматически определить стек и предложит выбрать его вручную из списка общих шаблонов.

🔥 — если уже используешь встроенные утилиты Docker

🤝 — если по старинке копируешь Dockerfile из старых проектов

➡️ GitHub Ready | #Уроки
Please open Telegram to view this post
VIEW IN TELEGRAM
5🤝1
🐳 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 | #Уроки
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2
🔒 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 | #Уроки
Please open Telegram to view this post
VIEW IN TELEGRAM
🤝31
LSP Enforcement Kit for Claude Code

Механизм принудительного использования LSP-навигации в Claude Code: 6 хуков + 1 трекер состояния, которые блокируют неэффективные поиски через Grep и направляют Claude к использованию LSP-инструментов для навигации по коду.

Поддерживаются MCP-серверы cclsp и Serena LSP. По словам автора, в тестах это дало примерно 73% экономии токенов.

Cсылка на GitHub
👍2
This media is not supported in your browser
VIEW IN TELEGRAM
🍿 Мультивселенная схлопнулась.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
🍿 ИИ становится более контекстным: пользователям все реже нужны идеальные промпты

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

Еще один тренд — использование ИИ вместе с VR/AR-технологиями. Уже сейчас такие решения улучшают сценарии виртуальной примерки одежды. А в будущем подход может распространиться и на другие категории, например, на «примерку» мебели в интерьере.
Please open Telegram to view this post
VIEW IN TELEGRAM
👎3
🎧 ИИ-музыку почти никто не слушает

В новом исследовании изучили Spotify и выяснили, что 93% нейротреков не набирают даже 1000 прослушиваний.

Авторы называют это music slop. Тысячи композиций заливают пачками в разные жанры, надеясь случайно попасть в рекомендации. Дистрибьюторы почти этому не мешают, а детекторы пока легко обходятся.

А как часто вам попадается в реках нейрохрючево?

Источник
Please open Telegram to view this post
VIEW IN TELEGRAM
😁71
🖱 Экспортёр директорий проекта в читаемые файлы

Dir2txt — инструмент командной строки, который позволяет быстро экспортировать структуру и содержимое директории в файлы форматов .txt или .json.

👉 Главная цель тулзы — помощь в структурировании кода для интеграции с AI-пайплайнами, такими как GPT-агенты и Retrieval-Augmented Generation.


Клик
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
🐍 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.


🔥 — если разгружаешь эндпоинты через фоновые задачи

🤝 — если пользователь честно ждет, пока скрипт отработает до конца