В последнем проекте я действительно сгенерировал с помощью ИИ более 90% кода: сервис на Go, SDK на Python и TypeScript, даже SQL и миграции. Но важно - я просматривал каждую строчку, переписывал архитектуру, чистил дубликаты.
ИИ идеально справляется с рутиной, но всё, что касается дизайна и общей целостности системы - пока ещё исключительно на человеке. Без этого код развалится.
Когда-то ты перестал писать ассемблер, сейчас перестаёшь писать рутину.
Звучит как новая ступень эволюции. Но ценность умения видеть систему целиком только растёт.
#ai #llm #dev #coding #agents #бям
Please open Telegram to view this post
VIEW IN TELEGRAM
Часто хочется выжать из Rust скорость, но остаться в Python-экосистеме. Самый удобный путь сейчас:
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"
Please open Telegram to view this post
VIEW IN TELEGRAM
Хочешь погонять модерн дата‑стек у себя на ноуте без облачных вычислений и лишней боли?
🔥 Лови 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
Что внутри: MinIO+Hive (каталог), Trino и Spark, Kafka+Schema Registry+Debezium, Postgres
Запуск профилями: core, airflow, explore, datagen.
Есть генератор реалистичных retail‑данных, плюс Learning Path с ноутбуками - можно пройтись end‑to‑end.
Из железа просят ~8+ ГБ RAM и ~20 ГБ диска. Лицензия MIT.
#sandbox #de #modenstack #dev
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - fortiql/data-forge: Data Forge — a modern data stack playground to practice flows and best practices, not just tools.…
Data Forge — a modern data stack playground to practice flows and best practices, not just tools. Spark, Trino, Kafka, Iceberg, ClickHouse, Airflow, MinIO, Superset — all wired together locally wit...
Свежий релиз принёс серьёзные улучшения:
• ⚙️ Асинхронный ввод-вывод (AIO) — теперь чтение данных может идти параллельно, ускоряя seq-scan и VACUUM.
• 🔍 Skip-scan в B-tree — индекс по нескольким полям теперь работает даже без фильтра по первому.
• 🔄 pg_upgrade без "холодного старта" — статистика сохраняется при апгрейде.
• 🔐 OAuth 2.0 аутентификация, плюс прощание с MD5.
• 🧮 Мелкие радости: uuidv7(), виртуальные столбцы, подробная статистика в EXPLAIN и включённые по умолчанию checksums.
💡 Если твои базёнки упираются в диск - самое время затестить.
#postgres #db #de #dev #sql
Please open Telegram to view this post
VIEW IN TELEGRAM
PostgreSQL Documentation
E.2. Release 18
E.2. Release 18 # E.2.1. Overview E.2.2. Migration to Version 18 E.2.3. Changes E.2.4. Acknowledgments Release date: 2025-09-25 E.2.1. Overview # PostgreSQL 18 …
Forwarded from Архитектор Данных
Кратко - основные инсайты с круглого стола «Хадуп мертв»
1️⃣ HDFS сам по себе мало кому нужен, если есть S3.
2️⃣ Даже YARN уже не так необходим.
3️⃣ Современная BigData признана начинающейся от 10 Петабайт. Эта планка постепенно растет.
4️⃣ Приходится делать много ухищрений, чтобы получить в он-преме S3. И принимать множество компромиссов.
5️⃣ Hadoop (HDFS) - все еще хороший, надежный, понятный и предсказуемый способ получить скалированное хранилище для бигдаты
6️⃣ Но с нуля Hadoop сейчас мало кто решится разворачивать для GreenField проектов
7️⃣ Apache Ozone - перспективный способ получить S3 (+HDFS) на сегодня - признано 60% участниками дискуссии.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
😁10 4 3 2
DE
Раньше, чтобы быть сильным инженером, достаточно было знать язык, предметную область и свой проект.
Теперь к этому добавилось новое измерение - понимание самой нейросети, с которой ты работаешь.
Ты должен знать:
🧠 как она "думает"
🧩 где у неё слепые зоны
📚 какая у неё внутренняя терминология
⚙️ и как подать задачу так, чтобы она дала не просто ответ, а нужное решение.
Фактически, ты уже не просто пишешь код - ты проектируешь мышление инструмента, который пишет код за тебя.
ИИ стал новым языком программирования. И чем лучше ты его понимаешь, тем мощнее твой код.
Please open Telegram to view this post
VIEW IN TELEGRAM
Автор статьи сравнивает асинхронность и многопоточность в 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 внутри зовёт
⏩ Микротесты ожидания: при 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 конкурентных запросов решающей разницы нет.
Все цифры - из измерений автора статьи, на твоих задачах результаты могут отличаться.
Выводы:
loop.run_in_executor, а Motor (async‑драйвер MongoDB) использует под капотом синхронный PyMongo через thread‑pool; часть Django‑стека вынужденно прыгает между sync/async, добавляя оверхед. Все цифры - из измерений автора статьи, на твоих задачах результаты могут отличаться.
Please open Telegram to view this post
VIEW IN TELEGRAM
Вчера выкатили стабильный Python 3.14.
Коротко: t‑строки (template strings), отложенная оценка аннотаций + annotationlib, подинтерпретаторы в stdlib, удалённая отладка (pdb -p), официальный free‑threaded CPython как вариант сборки, compression.zstd, UUID v6/v7/v8, цветной REPL, экспериментальный JIT в бинарях macOS/Windows, новый Python Install Manager для Windows.
#python #release
Коротко: t‑строки (template strings), отложенная оценка аннотаций + annotationlib, подинтерпретаторы в stdlib, удалённая отладка (pdb -p), официальный free‑threaded CPython как вариант сборки, compression.zstd, UUID v6/v7/v8, цветной REPL, экспериментальный JIT в бинарях macOS/Windows, новый Python Install Manager для Windows.
#python #release
Forwarded from DataEng
Последние года 4 я использовал Apache Airflow исключительно в облаке, преимущественно в Amazon — Amazon Managed Apache Airflow. И как обычно бывает, в облаках всё так или иначе между собой связано. Логи хранятся в Cloud Watch, воркеры запускаются в изолированной среде (Amazon Fargate). С июля месяца я стал активно использовать self-hosted Airflow на своих серверах (для своих личных целей), и в целях экономии храню всё в файлах. Так уж получилось, что задачу с регулярной "чисткой" я постоянно откладывал и вот настал час X, когда всё легко из-за исчерпания inodes в файловой системе. Для этого случая я написал DAG, который каждый день в полночь чистит папки со старыми логами, делюсь с вами вдруг он пригодится:
Здесь учитывается стандартный шаблон именования логов и директорий, включающий дату и время. Я по привычке использую
import os
import shutil
from datetime import datetime, timedelta
import pendulum
import structlog
from airflow.sdk import DAG, task
logger = structlog.get_logger(__name__)
@task
def cleanup_airflow_logs(days_to_keep):
log_base_path = os.environ.get("AIRFLOW_HOME", "/opt/airflow") + "/logs"
cutoff_date = datetime.now() - timedelta(days=days_to_keep)
for root, dirs, files in os.walk(log_base_path):
for dir_name in dirs:
dir_path = os.path.join(root, dir_name)
try:
if os.path.getmtime(dir_path) < cutoff_date.timestamp():
logger.info(f"Deleting old log directory: {dir_path}")
shutil.rmtree(dir_path)
except Exception as e:
logger.error(f"Error deleting directory {dir_path}: {e}")
with DAG(
dag_id="airflow_log_cleanup_dag",
start_date=pendulum.datetime(2025, 10, 1, tz="Asia/Almaty"),
schedule="@daily", # Run daily at midnight
catchup=False,
default_args={
"owner": "airflow",
"retries": 2,
"retry_delay": timedelta(minutes=5),
},
max_active_runs=1,
) as dag:
cleanup_airflow_logs(days_to_keep=14)
Здесь учитывается стандартный шаблон именования логов и директорий, включающий дату и время. Я по привычке использую
structlog для ведения логов.
DataEng
Последние года 4 я использовал Apache Airflow исключительно в облаке, преимущественно в Amazon — Amazon Managed Apache Airflow. И как обычно бывает, в облаках всё так или иначе между собой связано. Логи хранятся в Cloud Watch, воркеры запускаются в изолированной…
Плюс ➕ gist
Please open Telegram to view this post
VIEW IN TELEGRAM
Gist
airflow_logs_cleanup_dag.py
GitHub Gist: instantly share code, notes, and snippets.
Please open Telegram to view this post
VIEW IN TELEGRAM
😁10
Forwarded from FastNews | Никита Пастухов
Кстати, чтобы написать свой простейший MCP сервер очень просто:
FastMCP - это небольшая обертка над библиотекой Starlette, которая позволяет легко создавать MCP серверы - тут вы видите и noscript, и denoscription, и inputSchema каждого метода.
#MCP #протоколы #LLM #AI
from fastmcp import FastMCP
mcp = FastMCP("Demo 🚀")
@mcp.tool
def add(a: int, b: int) -> int:
"""Add two numbers"""
return a + b
FastMCP - это небольшая обертка над библиотекой Starlette, которая позволяет легко создавать MCP серверы - тут вы видите и noscript, и denoscription, и inputSchema каждого метода.
#MCP #протоколы #LLM #AI
FastMCP
Welcome to FastMCP 2.0! - FastMCP
The fast, Pythonic way to build MCP servers and clients.
❤🔥4👏2 1
Forwarded from Уставший техдир
12 Factor Agents - принципы разработки агентов
По следам от 12 Factor Apps, Декстер Хорти собрал ключевые принципы по разработке агентов, делюсь!
1) Преобразование естественного языка в вызовы инструментов. Агент интерпретирует команды в формализованные вызовы функций, а исполняет их — детерминированный код
2) Владей своими промптами (как кодом). Промпт — это артефакт. Его надо хранить, версионировать, тестировать и относиться к нему не как к важной части кода.
3) Управляй контекстом агента. Активно контролируй, что попадает в это окно. Убирай уже не нужное, суммаризируй, оставляй важное, выделяй ограниченные слоты под фичи — внимание модели ограниченно.
4) Вызов тулинга — это просто JSON. LLM генерирует название тула и параметры, остальное должен делать ваш детерминированный вход. Модель решает "что делать", а ваше приложение "как делать"
5) Держи тех.состояние и бизнес состояние вместе. Каждый шаг агента — это и логика, и данные. Всё в одном состоянии, чтобы потом не ковыряться по логам в поисках, где оно сломалось
6) API для управление циклом агента. Агент должен иметь простой API для запуска, приостановки и возобновления работы, уметь вставать на паузу и возвращаться к работе спустя время на каждом этапе жизненного цикла
7) Запрос к человеку — как инструмент. Любое обращение в процессе работы к человеку должно быть представлено агенту, как инструмент
8) Явно контролируйте логику исполнения. Модель лишь "говорит" что, а твой код решает стоит ли выполнять, когда и как.
9) Добавляйте ошибки исполнения инструментов в контекст. Если что-то упало, сократи информацию и добавь это в контекст агента. Пусть модель сама догадается, что дальше: повторить, спросить или изменить стратегию
10) Используйте малых специализированных агентов. Лучше много маленьких агентов, решающих узконаправленные задачи, чем один перегруженный агент всего
11) Доставляй агентов в любые интерфейсы, удобные пользователю. Slack, Telegram, веб, CLI — неважно. Главное — единый API и омниканальность. Пользователь не должен думать, где общаться с агентом. Он просто должен это делать.
12) Агент как Stateless Reducer. На входе — состояние и запрос. На выходе — новое состояние и ответ. Всё как в хорошем Redux. Никакого собственного внутреннего состояния, он должен работать как чистая функция
Бонус:
13) Предзагрузи все необходимое. Агент не должен постоянно дёргать одни и те же данные. Наполняй контекст тем, что почти наверняка пригодится.
Репа: https://github.com/humanlayer/12-factor-agents
Доклад: https://www.youtube.com/watch?v=8kMaTybvDUw
По следам от 12 Factor Apps, Декстер Хорти собрал ключевые принципы по разработке агентов, делюсь!
1) Преобразование естественного языка в вызовы инструментов. Агент интерпретирует команды в формализованные вызовы функций, а исполняет их — детерминированный код
2) Владей своими промптами (как кодом). Промпт — это артефакт. Его надо хранить, версионировать, тестировать и относиться к нему не как к важной части кода.
3) Управляй контекстом агента. Активно контролируй, что попадает в это окно. Убирай уже не нужное, суммаризируй, оставляй важное, выделяй ограниченные слоты под фичи — внимание модели ограниченно.
4) Вызов тулинга — это просто JSON. LLM генерирует название тула и параметры, остальное должен делать ваш детерминированный вход. Модель решает "что делать", а ваше приложение "как делать"
5) Держи тех.состояние и бизнес состояние вместе. Каждый шаг агента — это и логика, и данные. Всё в одном состоянии, чтобы потом не ковыряться по логам в поисках, где оно сломалось
6) API для управление циклом агента. Агент должен иметь простой API для запуска, приостановки и возобновления работы, уметь вставать на паузу и возвращаться к работе спустя время на каждом этапе жизненного цикла
7) Запрос к человеку — как инструмент. Любое обращение в процессе работы к человеку должно быть представлено агенту, как инструмент
requestClarification(message:string)8) Явно контролируйте логику исполнения. Модель лишь "говорит" что, а твой код решает стоит ли выполнять, когда и как.
9) Добавляйте ошибки исполнения инструментов в контекст. Если что-то упало, сократи информацию и добавь это в контекст агента. Пусть модель сама догадается, что дальше: повторить, спросить или изменить стратегию
10) Используйте малых специализированных агентов. Лучше много маленьких агентов, решающих узконаправленные задачи, чем один перегруженный агент всего
11) Доставляй агентов в любые интерфейсы, удобные пользователю. Slack, Telegram, веб, CLI — неважно. Главное — единый API и омниканальность. Пользователь не должен думать, где общаться с агентом. Он просто должен это делать.
12) Агент как Stateless Reducer. На входе — состояние и запрос. На выходе — новое состояние и ответ. Всё как в хорошем Redux. Никакого собственного внутреннего состояния, он должен работать как чистая функция
Бонус:
13) Предзагрузи все необходимое. Агент не должен постоянно дёргать одни и те же данные. Наполняй контекст тем, что почти наверняка пригодится.
Репа: https://github.com/humanlayer/12-factor-agents
Доклад: https://www.youtube.com/watch?v=8kMaTybvDUw
YouTube
12-Factor Agents: Patterns of reliable LLM applications — Dex Horthy, HumanLayer
Hi, I'm Dex. I've been hacking on AI agents for a while.
I've tried every agent framework out there, from the plug-and-play crew/langchains to the "minimalist" smolagents of the world to the "production grade" langraph, griptape, etc.
I've…
I've tried every agent framework out there, from the plug-and-play crew/langchains to the "minimalist" smolagents of the world to the "production grade" langraph, griptape, etc.
I've…