متاح الآن! بحث تيليغرام 2025 — أهم رؤى العام 
P(hD)ython
الذهاب إلى القناة على Telegram
О Python, PhD, распределённых системах и не только Автор - Михаил Масягин (@masyagin1998): - Python Lead в NDA HFT; - преподаватель в Бауманке; - эксперт по СУБД System Design World; - любитель PhD и авторегрессии.
إظهار المزيدلم يتم تحديد البلدالفئة غير محددة
233
المشتركون
-124 ساعات
لا توجد بيانات7 أيام
+1930 أيام
جاري تحميل البيانات...
القنوات المماثلة
لا توجد بيانات
هل تواجه مشاكل؟ يرجى تحديث الصفحة أو الاتصال بمدير الدعم الخاص بنا.
سحابة العلامات
لا توجد بيانات
هل تواجه مشاكل؟ يرجى تحديث الصفحة أو الاتصال بمدير الدعم الخاص بنا.
الإشارات الواردة والصادرة
---
---
---
---
---
---
جذب المشتركين
يوليو '26
يوليو '26
+1
في 0 قنوات
يونيو '26
+42
في 0 قنوات
Get PRO
مايو '26
+15
في 1 قنوات
Get PRO
أبريل '260
في 0 قنوات
Get PRO
مارس '26
+12
في 0 قنوات
Get PRO
فبراير '260
في 0 قنوات
Get PRO
يناير '26
+55
في 0 قنوات
Get PRO
ديسمبر '250
في 0 قنوات
Get PRO
نوفمبر '25
+116
في 1 قنوات
| التاريخ | نمو المشتركين | الإشارات | القنوات | |
| 07 يوليو | 0 | |||
| 06 يوليو | 0 | |||
| 05 يوليو | 0 | |||
| 04 يوليو | 0 | |||
| 03 يوليو | 0 | |||
| 02 يوليو | 0 | |||
| 01 يوليو | +1 |
منشورات القناة
«Мама, я в телевизоре x2 😎»
#заметки_с_полей
Попал на камеры Saint HighLoad++ 2026, когда с умным видом обсуждал с докладчиком AI-трансформацию IT-компаний 😅
С уважением,
Михаил Масягин
| 2 |  «AI съел HighLoad 🤖»
#ai_sdlc
Вернулся с Saint HighLoad++ 2026 в СПб.
Конфа была крутой и, что ожидаемо, почти полностью про AI: по ощущениям, процентов 70 докладов так или иначе крутились вокруг LLM, агентов, AI4SDLC, контекста, токенов и eval'ов.
Но среди всех выступлений хотелось бы выделить несколько ключевых.
Самое запоминающееся для меня - доклад Ивана Поддубного, CTO Вебпрактик, про уровни зрелости внедрения AI в разработку.
По мнению спикера есть 5 уровней этого процесса:
🍼 L0 - пишем код без AI
❔ L1 - спрашиваем GPT и копипастим код (ChatGPT)
💻 L2 - используем агентов локально (Claude Code, Codex)
🏎 L3 - человек ставит задачи агентам и валидирует их
🏭 L4 - dark factory: роботы полностью автономны
⚡️ Про L0 и L1 в 2026 году уже и говорить неловко
⚡️ На L2 так или иначе перешли 70% разработчиков
⚡️ L4 пока выглядит скорее как цель
⚡️ А вот в рамках L3 идёт настоящая гонка...
L3 - это не «запустил Cursor/Claude Code в цикле до зелёных тестов», а жёсткий и стандартизованный процесс:
SDD → ADR → TDD
⚡️ SDD - Spec Driven Development. Мы пишем настолько формальную постановку задачи, что спецификация становится новым кодом
⚡️ ADR - Architecture Decision Record. Не просто план агента, а стандартизированное описание вариантов, trade-off'ов, рисков и выбранного решения
⚡️ TDD - Test Driven Development. Сначала тесты, а только потом код. Методология 50-летней давности, но теперь её придерживается не человек, а нейросеть
Чуть в сторонке от этого пайплайна стоят агентские Evals и Observability
⚡️ Evals - тесты не только самого кода, но и агента, порождающего код. Например, «напиши pupa-service с p99 ≤ 100ms». Справился? - супер, нет? - срочно на доработку промптов и обвязок!
⚡️ Observability - отдельный агент-методолог смотрит на спеки, ADR, код, тесты и даже reasoning основного агента, пытаясь сделать выполнение задач оптимальным.
По сути мы повторяем технологическую революцию начала XX века: строим конвейер, а за каждым рабочим ставим своего Фредерика Тэйлора - основоположника научной организации труда (кстати прочитайте биографию - крутой дядька).
Только теперь вместо рабочих - агенты, а вместо конвейера - наш пайплайн на условном Python.
Кстати за лучший вопрос докладчику мне вручили книгу Таненбаума по ОСям. Приятно, что база ещё кому-то нужна 😄
Ещё очень зашли доклады Андрея Неведина, Алексея Гладкова и Александра Иванова про сжатие контекста, harness'ы и базы знаний агентов.
TL;DR у всех примерно один:
⚡️ токены дорогие, контекст маленький, agentic grep малоэффективен, а MD-базы знаний быстро превращаются в свалку
⚡️ поэтому все строят умные индексы проектов, графовые/граф-раговые базы знаний и пытаются как угодно минимизировать число потребляемых & выдаваемых моделью токенов
Отдельно отмечу воркшоп Кирилла Мокевнина «Как сделать проект понятным для AI-агентов».
Главная мысль свежая: надо делать проект под агента, а не агента под проект.
Например, вместо models/, tables/, routers/ в Django-проекте - раскладывать код по фичам: billing/, auth/, notifications/, а внутри каждой держать свои model.py, router.py, schema.py.
Для человека разница небольшая, а для агента - огромная: меньше прыжков по проекту, меньше контекста, меньше токенов.
Saint HighLoad++ получился очень показательным.
Вопрос уже не в том, используете ли Вы AI в разработке или нет.
Вопрос в том, насколько эффективно Вы его используете.
С уважением,
Михаил Масягин | 256 |
| 3 |  «Навигация по P(hD)ython 🧭»
Канал уже заметно разросся, поэтому собрал небольшой рубрикатор, чтобы было проще искать посты по темам. Всё для Вас 😅
🐍 #python - всё о Python: релизы, фичи, тонкости и нюансы
🏗 #system_design - Клеппманн, транзакции, CQRS, DWH, СУБД и прочие распределённые радости
⚙️ #техно_и_хардкор - C, Linux, параллельное программирование, оптимизации, HFT, FPGA, Low Latency и всё то, где идёт борьба за микросекунды
🤖 #ai4sdlc - AI в разработке: агенты, AI-Native IDE, автоматизация кодинга, LLM и всё то, что ведёт нас в светлое (или не очень) будущее
🧭 #карьера_и_собесы - рынок IT, интервью, найм, кандидаты, red flags, офферы и способы не утонуть, когда рынок штормит
🎓 #аспирантские_будни - диссертация, статьи, ВАК, патенты, Бауманка и путь к степени кандидата физ-мат наук
🎤 #заметки_с_полей - конференции, доклады, поездки, встречи и живые репортажи с места событий
🧑💻 #жизнь_айтишника - мемы, розыгрыши, отпуск, Work-Job Balance и прочее околокодовое
Пост буду периодически обновлять.
Если потеряли какой-то материал - пишите в комментариях, попробую достать его из недр канала 🫡
С уважением,
Михаил Масягин | 179 |
| 4 |  «Легенды System Design 😎😂»
#заметки_с_полей
С уважением,
Михаил Масягин
P.S. Завтра твёрдо и чётко напишу пост с TL;DR по Saint HighLoad++ 2026 👍 | 175 |
| 5 |  «Прорекламирую Вашу компанию, дорого 💵»
#заметки_с_полей
С уважением,
Михаил Масягин | 213 |
| 6 | ОывдкжжМшеег20— | 4 |
| 7 |  «Питер, HighLoad++ и предзащита 🎓»
#заметки_с_полей
22–23 июня еду на Saint HighLoad++ 2026 в СПб!
Причём в этот раз в качестве участника: буду помогать @vova_dev из System Design World проводить аналог «Своей игры» по System Design 💪.
Да-да, с вопросами за 300, котом в мешке и необходимостью иметь эрудицию как у Вассермана 😅
Питерские подписчики, знаю, Вы тут точно есть!
Буду рад пересечься, пообщаться и выпить чаю, а может, и чего покрепче 🍷.
Вообще июнь оказался крайне богат на события:
⚡️ съездил во Владимир и Суздаль
⚡️ сходил с семьёй в Большой театр
⚡️ еду на Saint HighLoad++ 2026
⚡️ реализовал несколько крутых фичей по работе
⚡️ а главное... пережил предзащиту диссертации!
TL;DR по предзащите:
📌 было больно
📌 местами очень больно
📌 но я справился 🫡
Если Вам интересно, как вообще проходит предзащита в Бауманке и почему это отдельный жанр на грани фарса и трагедии, ставьте 🔥 - посвящу этому отдельный пост!
С уважением,
Михаил Масягин | 264 |
| 8 | «Питер, HighLoad++ и предзащита 🎓»
#заметки_с_полей
22–23 июня еду на Saint HighLoad++ 2026 в СПб!
Причём в этот раз в качестве участника: буду помогать @vova_dev из System Design World проводить аналог «Своей игры» по System Design 💪.
Да-да, с вопросами за 300, котом в мешке и необходимостью иметь эрудицию как у Вассермана 😅
Питерские подписчики, знаю, Вы тут точно есть!
Буду рад пересечься, пообщаться и выпить чаю, а может, и чего покрепче 🍷.
Вообще июнь оказался крайне богат на события:
⚡️ съездил во Владимир и Суздаль
⚡️ сходил с семьёй в Большой театр
⚡️ еду на Saint HighLoad++ 2026
⚡️ реализовал несколько крутых фичей по работе
⚡️ а главное... пережил предзащиту диссертации!
TL;DR по предзащите:
📌 было больно
📌 местами очень больно
📌 но я справился 🫡
Если Вам интересно, как вообще проходит предзащита в Бауманке и почему это отдельный жанр на грани фарса и трагедии, ставьте 🔥 - посвящу этому отдельный пост!
С уважением,
Михаил Масягин | 1 |
| 9 |  Приветствую Вас на канале P(hD)ython 👋
Меня зовут Михаил Масягин.
Я тимлид, разработчик, аспирант и преподаватель МГТУ им. Н.Э. Баумана.
Сейчас я руковожу backend- и frontend-разработкой в HFT-компании. До этого были Lawful Interception и Bare Metal-проекты, работа с AWS и даже погружение в ML и NLP.
С опытом я понял, что самые ценные знания обычно не попадают в учебники. Они появляются при решении реальных задач - через ошибки, багфиксы и дебаг, и, увы, часто теряются.
Именно поэтому появился этот канал. Здесь я буду делиться тем, что считаю реально полезным:
⚡️ Python и современные практики разработки
⚡️ оптимизация кода и performance engineering
⚡️ C, Linux и немного Bare Metal
⚡️ распределённые системы и архитектура
⚡️ алгоритмы и структуры данных
⚡️ HFT и инженерные решения из индустрии
⚡️ опыт из преподавания, аспирантуры и написания диссертации
Если Вам интересно не просто писать код, а понимать, почему он работает именно так, - добро пожаловать 🤝
С уважением,
Михаил Масягин | 312 |
| 10 | test | 2 |
| 11 |  «Финишная прямая 🎓»
Научный руководитель наконец одобрил текст диссертации, и сегодня я отнёс «кирпич» в 2-х экземплярах на финальную проверку на кафедру 😎!
Думаю, есть шанс, что первая предзащита будет в текущем учебном году (в июне).
С уважением,
Михаил Масягин
P.S. А ещё со следующего учебного года ассистент становится старшим преподавателем 😎 | 2 525 |
| 12 |  «Data Lake: от перестановки мест слагаемых сумма... меняется? 👷»
Недавно проводил лекцию по DWH на курсе System Design от nevzorov.courses.
На лекции разбирали довольно частый практический кейс:
- есть ряд поддерживаемых источников данных (Sources);
- есть множество клиентов (Customers);
- для каждого клиента необходимо сохранять и обрабатывать данные из его источников (Customer Sources);
- вопрос: как лучше спроектировать Data Lake под эту задачу?
Вариант 1: customers/<customer_name>/source=<source_name>
Вариант 2: sources/<source_name>/customer=<customer_name>
Интуитивно рука тянется к 1 варианту... Однако для Data Lake и дальнейшей DWH-инфраструктуры часто лучше именно 2 вариант:
raw/sources/<source_name>/customer=<customer_name>/...
cleaned/sources/<source_name>/customer=<customer_name>/...
...
Например:
...
raw/sources/google_play/customer=rammstein/dt=2026-05-24/*.parquet
raw/sources/google_play/customer=sabaton/dt=2026-05-24/*.parquet
raw/sources/google_play/customer=megadeth/dt=2026-05-24/*.parquet
...
raw/sources/trustpilot/customer=rammstein/dt=2026-05-24/*.parquet
raw/sources/trustpilot/customer=led_zeppelin/dt=2026-05-24/*.parquet
raw/sources/trustpilot/customer=lordi/dt=2026-05-24/*.parquet
...
Почему?
1. Source естественным образом превращается в таблицу.
Для AWS Athena, Apache Trino или Apache Spark - google-play, trustpilot и т.д. - это отдельные логические таблицы, разложенные по Parquet-файлам и партициям в виде Customer'ов:
SELECT
*
FROM
"raw"."google_play"
WHERE
("customer" = 'rammstein') AND ("dt" >= DATE '2026-05-01');
У google-play даже в сыром виде (и уж тем более в очищенном) есть какая-то своя схема данных, ключи, timestamp'ы, правила дедупликации, SLA, логика инкрементальной загрузки и т.д.
У trustpilot и любого другого Source'а - свои.
Если же сделать наоборот:
...
raw/customers/rammstein/source=google_play/dt=2026-05-24/*.parquet
raw/customers/rammstein/source=trustpilot/dt=2026-05-24/*.parquet
...
raw/customers/sabaton/source=google_play/dt=2026-05-24/*.parquet
...
то один логический источник google-play размазывается по разным корням. А дальше начинается адъ 👹:
- отдельные таблицы на каждый Source каждого Customer'а;
- UNION ALL запросы и VIEW-шки;
- бардак с Data Governance.
В общем, Data Lake, а следом за ним и DWH медленно, но неотвратимо превращаются в DataSwamp 😄
2. Data Mesh проще делать именно по Source'ам.
Естественная единица владения - это не «папка клиента» (Customer), а доменный источник (Source).
У каждого такого Source'а есть отдельная команда-владелец, контракты, документация, SLA, data quality checks и правила эволюции схемы.
Команда, отвечающая за google_play, должна владеть одной папкой sources/google_play/customer=<customer_name>/*, а не тысячами подпапок customers/*/source=google_play/*.
- Добавили нового клиента? Добавили новую партицию.
- Поменяли контракт источника? Обновили один data product.
- Поймали баг в ingestion? Чиним одний единственный ETL-pipeline.
3. Pipeline'ы обычно тоже мыслят именно Source'ами:
...
google_play
trustpilot
...
А не:
...
ingest_rammstein_everything
ingest_sabaton_everything
ingest_led_zeppelin_everything
...
Иначе очень быстро появляются «особые клиенты»:
- у этого legacy CSV;
- у этого timezone в строке;
- у этого timestamp иногда null;
- у этого producer шлёт дубликаты;
- у этого «ну вы там руками поправьте, пожалуйста».
Поздравляю, у вас не DWH, а зоопарк с Airflow DAG-ами 🦓
4. Наконец, Source-First Layout упрощает сложную аналитику:
SELECT
"customer", count(*)
FROM
"raw"."google_play"
WHERE
"dt" = DATE '2026-05-24'
GROUP BY
"customer";
Можно с лёгкостью строить Usage-Based Billing по конкретным Source'ам, позволять даже менеджменту без труда копаться в данных и т.д.
Таким образом, проектируя DWH-систему лучше думать не о том, какие у вас будут клиенты, а о том, какие источники данных вы будете для них поддерживать.
С уважением,
Михаил Масягин | 333 |
| 13 |  «Cursor на миллиард 🤑»
В нашей команде мы активно используем множество ИИ-инструментов, в том числе Cursor. Сидим на Teams Plan. И сегодня я нашёл в этом «плане» неприятный сюрприз.
В Teams Plan команда представляет собой одного админа (Admin) и множество обычных пользователей (Member). При этом имеется возможность ограничить расход средств, выставив максимально допустимую месячную сумму, которую команда тратит на токены: превысил лимит - жди следующего месяца.
Но оказалось, что по умолчанию функция выставления лимитов доступна не только админу, но и любому члену команды! Да-да, не админу, не владельцу карты, а обычному Member-у! Имхо, это крайне неочевидное и небезопасное поведение, о котором документация упоминает лишь всколзь.
Заходишь в Settings → Spend Limit → Team Spend Limit, ставишь лимит в миллиард долларов 💵 и уходишь на ночь, запустив 1000 и 1 агента 😎.
Auto-моделька Cursor уверенно говорит, что это не баг, а фича, дабы «упростить онбординг команды» 😁
Чтобы запретить это веселье, нужно отдельно включить тумблер: Settings → Usage-Based Pricing Settings → Admin-only modifications.
После этого вкладка Spend Limit исчезает у обычных пользователей.
Интересная, конечно, помощь в онбординге команды...
С уважением,
Михаил Масягин
P.S. Может, имелся в виду онбординг команды топ-менеджеров Cursor на очередную яхту 🧐? | 282 |
| 14 |  «Python 3.15 beta: что нового 🐍»
7 мая зафризили фичи Python 3.15, и сейчас, в длинные выходные, самое время обсудить ключевые изменения.
Сразу уточню, что полный стабильный релиз будет 1 октября, поэтому пока что катаемся на test- и debug- ENV-ах 🤓.
1. Lazy imports (PEP 810) 🥱
В язык завезли новое ключевое слово lazy. Ленивый модуль загружается только при непосредственном обращении к его коду, что ускоряет старт Python-процесса:
lazy import numpy as np
lazy from pandas import DataFrame
df = DataFrame() # только здесь pandas реально загрузится
Можно включить глобально через флаг -X lazy_imports=all или переменную PYTHON_LAZY_IMPORTS.
2. Распаковка в comprehensions (PEP 798) 📦
Самое долгожданное расширение синтаксиса за годы. Теперь * и ** работают внутри list/set/dict-comprehensions и генераторов:
lists = [[1, 2], [3, 4], [5]]
flat = [*L for L in lists] # [1, 2, 3, 4, 5]
merged = {**d for d in [{'a': 1}, {'b': 2}]} # {'a': 1, 'b': 2}
То, что раньше писалось через itertools.chain.from_iterable или вложенные циклы, теперь - одна строка. Работает и в async for.
Наконец вопрос на собесах «как разжать список списков» получил однозначный и окончательный ответ.
3. frozendict как builtin (PEP 814) 😎
«Замороженный» словарь - теперь встроенный тип. Можно класть в set, использовать ключом другого dict, да ещё и хэш не зависит от порядка вставки!
config = frozendict(host="localhost", port=5432)
cache = {config: "primary"}
hash(frozendict(a=1, b=2)) == hash(frozendict(b=2, a=1)) # True
Также его подружили с copy, json, pickle, pprint.
4. sentinel builtin (реализация PEP 661) 🛡
Все мы писали этот хак: _MISSING = object(), чтобы отличать «не передал» от «передал None». Теперь это часть языка:
MISSING = sentinel("MISSING")
def get(d, key, default=MISSING):
if default is MISSING:
raise KeyError(key)
return d.get(key, default)
Мелочь, а приятно.
5. Tachyon - сэмплирующий профайлер (PEP 799) 🔎
Появился пакет profiling с двумя бэкендами: profiling.tracing (бывший cProfile) и profiling.sampling - статистический профайлер с почти нулевым оверхедом. Самое крутое - сэмплирующий профайлер умеет подключаться к уже работающему процессу по его `PID`у:
python -m profiling.sampling --pid 12345 --format flamegraph -o out.svg
Кто хоть раз профилировал прод - понимает цену вопроса.
6. Очередное ускорение 🚀
Ускорили JIT (да, в CPython есть JIT, хоть и по умолчанию он недоступен!) на 8-9% на x86-64 Linux и на 12-13% на AArch64 macOS.
Таким образом, 3.15 - это пусть и не «революционный», но важный релиз, значительно повышающий качество жизни разработчиков.
Стандартная библиотека продолжает вбирать в себя то, что годами жило в формате рецептов на Stack Overflow. Это ли не говорит о зрелости языка?
С уважением,
Михаил Масягин | 301 |
| 15 | sticker.webp | 288 |
| 16 |  +1«Мама, я в телевизоре 😎»
Ну, может и не в телевизоре, но с первым опытом студийной записи меня 😅
С уважением,
Михаил Масягин | 424 |
