⭐️ Чистые зависимости с помощью uv

Часто в проектах получается одна из двух крайностей:
🔘огромный requirements.txt, который тащит всё подряд,
🔘боль с поддержкой разных окружений для прода, CI и локалки.

⚡️ Решение - использовать uv и группы зависимостей прямо в pyproject.toml.

✏️ Пример pyproject.toml

[project]
name = "myapp"
version = "0.1.0"
requires-python = ">=3.12"
dependencies = [
  "fastapi",
  "httpx",
]

[tool.uv.group.dev]
dependencies = [
  "ruff",
  "ty",
  "pytest",
  "pytest-cov",
  "ipython",
  "types-requests",
]

[tool.uv.group.test]
dependencies = [
  "pytest",
  "pytest-xdist",
  "pytest-randomly",
]

[tool.uv.group.docs]
dependencies = [
  "mkdocs-material",
  "mkdocstrings[python]",
]

📌Как устанавливать

Prod:

uv sync --frozen

Dev-окружение:

uv sync --group dev

Тесты:

uv sync --group test

Комбинированно (например, dev + доки):

uv sync --group dev --group docs

🙂Паттерны для CI/CD

Prod-образ:

uv sync --frozen ⏩ минимум зависимостей, детерминированная сборка.

Тесты:

uv sync --group test --frozen && pytest -q

Линтеры:

uv sync --group dev --frozen && ruff check . && mypy .

☕️ Бонус: фичи как extras

[project.optional-dependencies]
s3 = ["boto3"]
clickhouse = ["clickhouse-connect"]

Установка:

uv sync --extras s3,clickhouse --group dev

🔥 В итоге: один pyproject.toml ⏩ много сценариев ⏩ чистые окружения ⏩ быстрые билды.

#uv #pipelines #ci #tests

🔥 Создатель Flask о том, как 90% кода ему написала БЯМ:

✍️ Армин Роначер пишет:

В последнем проекте я действительно сгенерировал с помощью ИИ более 90% кода: сервис на Go, SDK на Python и TypeScript, даже SQL и миграции. Но важно - я просматривал каждую строчку, переписывал архитектуру, чистил дубликаты.

ИИ идеально справляется с рутиной, но всё, что касается дизайна и общей целостности системы - пока ещё исключительно на человеке. Без этого код развалится.

Когда-то ты перестал писать ассемблер, сейчас перестаёшь писать рутину.

Звучит как новая ступень эволюции. Но ценность умения видеть систему целиком только растёт.

#ai #llm #dev #coding #agents #бям

🖼️ + 🖼️ без боли в IDE

Часто хочется выжать из Rust скорость, но остаться в Python-экосистеме. Самый удобный путь сейчас:

1️⃣ PyO3: пишешь функции/классы на Rust и экспортируешь их как питонячий модуль.
2️⃣ maturin: собирает и ставит Rust-модуль в venv как обычный wheel.
3️⃣ .pyi-стабы: чтобы PyCharm/VS Code видели автодополнение и типы.

😀 Минимальный проект

myext/
  Cargo.toml
  src/lib.rs
  pyproject.toml

Cargo.toml

[package]
name = "myext"
version = "0.1.0"
edition = "2021"

[lib]
name = "myext"
crate-type = ["cdylib"]

[dependencies]
pyo3 = { version = "0.22", features = ["extension-module"] }

src/lib.rs

use pyo3::prelude::*;

#[pyfunction]
fn add(a: i64, b: i64) -> i64 { a + b }

#[pymodule]
fn myext(m: &Bound<'_, PyModule>) -> PyResult<()> {
    m.add_function(wrap_pyfunction!(add, m)?)?;
    Ok(())
}

pyproject.toml

[build-system]
requires = ["maturin>=1.6"]
build-backend = "maturin"

[project]
name = "myext"
version = "0.1.0"
requires-python = ">=3.9"

Хочешь погонять модерн дата‑стек у себя на ноуте без облачных вычислений и лишней боли?

🔥 Лови Data Forge - аккуратная песочница, где всё уже скручено docker compose’ом.

Что внутри: MinIO+Hive (каталог), Trino и Spark, Kafka+Schema Registry+Debezium, Postgres 🔜 ClickHouse, Airflow, Superset и JupyterLab.

Запуск профилями: core, airflow, explore, datagen.

Есть генератор реалистичных retail‑данных, плюс Learning Path с ноутбуками - можно пройтись end‑to‑end.

Из железа просят ~8+ ГБ RAM и ~20 ГБ диска. Лицензия MIT.

▶️ Репо: https://github.com/fortiql/data-forge

#sandbox #de #modenstack #dev

🖼️ PostgreSQL 18 релизнули в конце сентября.

Свежий релиз принёс серьёзные улучшения:

• ⚙️ Асинхронный ввод-вывод (AIO) — теперь чтение данных может идти параллельно, ускоряя seq-scan и VACUUM.
• 🔍 Skip-scan в B-tree — индекс по нескольким полям теперь работает даже без фильтра по первому.
• 🔄 pg_upgrade без "холодного старта" — статистика сохраняется при апгрейде.
• 🔐 OAuth 2.0 аутентификация, плюс прощание с MD5.
• 🧮 Мелкие радости: uuidv7(), виртуальные столбцы, подробная статистика в EXPLAIN и включённые по умолчанию checksums.

💡 Если твои базёнки упираются в диск - самое время затестить.

#postgres #db #de #dev #sql

Кратко - основные инсайты с круглого стола «Хадуп мертв»

1️⃣ HDFS сам по себе мало кому нужен, если есть S3.
2️⃣ Даже YARN уже не так необходим.
3️⃣ Современная BigData признана начинающейся от 10 Петабайт. Эта планка постепенно растет.
4️⃣ Приходится делать много ухищрений, чтобы получить в он-преме S3. И принимать множество компромиссов.
5️⃣ Hadoop (HDFS) - все еще хороший, надежный, понятный и предсказуемый способ получить скалированное хранилище для бигдаты
6️⃣ Но с нуля Hadoop сейчас мало кто решится разворачивать для GreenField проектов
7️⃣ Apache Ozone - перспективный способ получить S3 (+HDFS) на сегодня - признано 60% участниками дискуссии.

Печалька, но факт опровергнуть невозможно 🙃☹️

#meme #dev #ai #llm #stackoverflow #notmeme

🔥 ИИ-разработка - это уже мета-программирование

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

Ты должен знать:
🧠 как она "думает"
🧩 где у неё слепые зоны
📚 какая у неё внутренняя терминология
⚙️ и как подать задачу так, чтобы она дала не просто ответ, а нужное решение.

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

Автор статьи сравнивает асинхронность и многопоточность в Python на фоне свободнопоточности (No GIL) в Python 3.13.

Выводы:
🔘 при IO‑bound до ≈1000 одновременных задач скорости близки
🔘 асинхронность выигрывает по ресурсам и масштабируемости (10k+ соединений)
🔘 с No GIL классическая многопоточность начинает догонять и местами обгонять async на смешанных нагрузках (есть заметная доля CPU)

✏️ Что важно из статьи:

⏩ Для CPU‑bound задач по‑прежнему уместен multiprocessing; для IO‑bound многопоточность и асинхронность дают схожие времена, разница - в механике переключений (OS‑scheduler vs await) и сложности разработки: асинхронный код труднее писать и отлаживать.

⏩ Async нередко маскирует пулы потоков: aiofiles внутри зовёт loop.run_in_executor, а Motor (async‑драйвер MongoDB) использует под капотом синхронный PyMongo через thread‑pool; часть Django‑стека вынужденно прыгает между sync/async, добавляя оверхед.

⏩ Микротесты ожидания: при 100–1000 задач разницы почти нет; при 10 000 - у threading "can’t start new thread". Память: ~4 МБ на поток против ~4 КБ на async‑задачу, поэтому на больших кардинальностях async существенно экономнее; у множества потоков растёт стоимость переключений и нагрузка на планировщик.

⏩ В реальных библиотеках возможен крупный выигрыш: у psycopg 3 асинхронный путь даёт ≈2200–2500 RPS против ≈700–800 RPS у синхронного.

⏩ Эксперимент с FastAPI: многопоточность с GIL - ~2800 RPS, async - ~3500 RPS. С No GIL: async остаётся примерно на том же уровне, а многопоточность поднимается до ~3540 RPS, местами обгоняя async. Итог автора: апгрейд на No GIL даёт прирост, сопоставимый с полной перепиской на async.

⚡️ Итог:

🟢 асинхронность - про экономию железа и экстремальную конкурентность (10k+)
🟢 No GIL усиливает многопоточность там, где в запросе есть заметная доля CPU (условно 20–40% и выше)
🟢При чистом IO (например, LLM‑агенты 5/95) разумнее оставаться на async; при типичных нагрузках <1000 конкурентных запросов решающей разницы нет.


Все цифры - из измерений автора статьи, на твоих задачах результаты могут отличаться.

Плюс ➕ gist

Глаз да глаз нужен за этими затейниками 🙂