ru
Feedback
P(hD)ython

P(hD)ython

Открыть в Telegram

О Python, PhD, распределённых системах и не только Автор - Михаил Масягин (@masyagin1998): - Python Lead в NDA HFT; - преподаватель в Бауманке; - эксперт по СУБД System Design World; - любитель PhD и авторегрессии.

Больше
Страна не указанаКатегория не указана
214
Подписчики
Нет данных24 часа
Нет данных7 дней
Нет данных30 день

Загрузка данных...

Похожие каналы
Нет данных
Возникли проблемы? Пожалуйста, обновите страницу или обратитесь к нашему support-менеджеру .
Облако тегов
Нет данных
Возникли проблемы? Пожалуйста, обновите страницу или обратитесь к нашему support-менеджеру .
Входящие и исходящие упоминания
---
---
---
---
---
---
Привлечение подписчиков
июнь '26
июнь '26
+18
в 0 каналах
май '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 каналах
Дата
Привлечение подписчиков
Упоминания
Каналы
12 июня0
11 июня+1
10 июня+1
09 июня0
08 июня0
07 июня0
06 июня0
05 июня0
Посты канала
Приветствую Вас на канале P(hD)ython 👋 Меня зовут Михаил Масягин. Я тимлид, разработчик, аспирант и преподаватель МГТУ им. Н
Приветствую Вас на канале P(hD)ython 👋 Меня зовут Михаил Масягин. Я тимлид, разработчик, аспирант и преподаватель МГТУ им. Н.Э. Баумана. Сейчас я руковожу backend- и frontend-разработкой в HFT-компании. До этого были Lawful Interception и Bare Metal-проекты, работа с AWS и даже погружение в ML и NLP. С опытом я понял, что самые ценные знания обычно не попадают в учебники. Они появляются при решении реальных задач - через ошибки, багфиксы и дебаг, и, увы, часто теряются. Именно поэтому появился этот канал. Здесь я буду делиться тем, что считаю реально полезным: ⚡️ Python и современные практики разработки ⚡️ оптимизация кода и performance engineering ⚡️ C, Linux и немного Bare Metal ⚡️ распределённые системы и архитектура ⚡️ алгоритмы и структуры данных ⚡️ HFT и инженерные решения из индустрии ⚡️ опыт из преподавания, аспирантуры и написания диссертации Если Вам интересно не просто писать код, а понимать, почему он работает именно так, - добро пожаловать 🤝 С уважением, Михаил Масягин

2
test
2
3
«Финишная прямая 🎓» Научный руководитель наконец одобрил текст диссертации, и сегодня я отнёс «кирпич» в 2-х экземплярах на
«Финишная прямая 🎓» Научный руководитель наконец одобрил текст диссертации, и сегодня я отнёс «кирпич» в 2-х экземплярах на финальную проверку на кафедру 😎! Думаю, есть шанс, что первая предзащита будет в текущем учебном году (в июне). С уважением, Михаил Масягин P.S. А ещё со следующего учебного года ассистент становится старшим преподавателем 😎
2 202
4
«Data Lake: от перестановки мест слагаемых сумма... меняется? 👷» Недавно проводил лекцию по DWH на курсе System Design от ne
«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-систему лучше думать не о том, какие у вас будут клиенты, а о том, какие источники данных вы будете для них поддерживать. С уважением, Михаил Масягин
264
5
«Cursor на миллиард 🤑» В нашей команде мы активно используем множество ИИ-инструментов, в том числе Cursor. Сидим на Teams P
«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 на очередную яхту 🧐?
280
6
«Python 3.15 beta: что нового 🐍» 7 мая зафризили фичи Python 3.15, и сейчас, в длинные выходные, самое время обсудить ключев
«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
7
sticker.webp
288
8
«Мама, я в телевизоре 😎» Ну, может и не в телевизоре, но с первым опытом студийной записи меня 😅 С уважением, Михаил Масяги+1
«Мама, я в телевизоре 😎» Ну, может и не в телевизоре, но с первым опытом студийной записи меня 😅 С уважением, Михаил Масягин
424
9
«Айтишники 💻 и металлурги 🛠» Последние пару месяцев активно провожу собесы Python-разработчиков: отвечаю за алгоритмическую
«Айтишники 💻 и металлурги 🛠» Последние пару месяцев активно провожу собесы Python-разработчиков: отвечаю за алгоритмическую секцию, где кандидатам предлагается решить несколько задач уровня LeetCode Easy/Medium и пообщаться о внутрянке Python. К сожалению, списывание и использование GPT на интервью лишь набирает обороты. Обычно это заметно довольно быстро: - либо человек не может объяснить «своё же» решение; - либо сыпется на каверзных вопросах про асимптотику, дополнительные ограничения и прочие нюансы. Недавно узнал, что в бигтехах 🏙 во время интервью кандидату могут задать пару случайных дурацких вопросов: - если человек честно говорит, что не знает - всё ок ✅; - а вот если отвечает, то, как модно сегодня говорить, это редфлаг ❌. И буквально час назад у меня случилась идеальная иллюстрация этого подхода. Кандидат ⭐️: - шикарный опыт; - почти 1 в 1 попадает в наш стэк; - решает задачи раза в полтора быстрее всех прошлых кандидатов; - знает абсолютно всё об asyncio; - strong hire! Но в какой-то момент в голове рождается мысль: а чем я хуже интервьюеров из бигтеха 😎? И звучит вопрос: - А расскажи мне, пожалуйста, про эвтектику в СУБД. (эвтектику, если что, мне подсказал GPT - как что-то максимально умное, солидное и при этом абсолютно не к месту) Кандидат без запинки отвечает, что проходил это ещё в вузе, и выдаёт какой-то поток несвязного бреда. Чувствую, что на подходе материал для поста (всё ради вас, подписчики ❤️), и решаю дожать: - Супер. А откуда это вообще пошло? Что такое эвтектика в исходном смысле? И тут человек снова без малейшей паузы выдаёт: - Эвтектика - это смесь двух или более веществ, которая плавится или затвердевает при фиксированной, самой низкой температуре для данной системы, действуя как чистое вещество. За пару минут собеседование Python-разработчика превратилось в устный экзамен по металлургии! Похоже, дурацкие вопросы работают! Иногда даже слишком хорошо 🤓 P.S. Эвтектика - это вполне реальный термин из металлургии и неорганической химии. P.P.S. До сих пор не исключаю, что у человека первое образование было металлургическое 👀 С уважением, Михаил Масягин
574
10
«Мам, сфоткай типо я кант-трейдор 🥴» С уважением, Михаил Масягин
«Мам, сфоткай типо я кант-трейдор 🥴» С уважением, Михаил Масягин
433