data будни
Відкрити в Telegram
работаю инженером данных и пишу в основном про это. Профильные ссылки с коротким резюме (статьи, доклады, подкасты), иногда «софтовое» — например, про поиск работы.
Показати більше1 464
Підписники
Немає даних24 години
-27 днів
-530 днів
Завантажуємо дані
Схожі канали
Хмара тегів
Немає даних
Виникли проблеми? Будь ласка, оновіть сторінку або зверніться до нашого support-менеджера.
Вхідні та вихідні згадування
---
---
---
---
---
---
Залучення підписників
жовтень '26жовт '26
жовтень '26
+39
в 0 каналах
вересень '260
в 0 каналах
Get PRO
серпень '260
в 0 каналах
Get PRO
липень '260
в 0 каналах
Get PRO
червень '260
в 0 каналах
Get PRO
травень '260
в 0 каналах
Get PRO
квітень '260
в 0 каналах
Get PRO
березень '260
в 0 каналах
Get PRO
лютий '260
в 0 каналах
Get PRO
січень '260
в 0 каналах
Get PRO
грудень '250
в 0 каналах
Get PRO
листопад '250
в 0 каналах
Get PRO
жовтень '250
в 0 каналах
Get PRO
вересень '250
в 0 каналах
Get PRO
серпень '250
в 0 каналах
Get PRO
липень '250
в 0 каналах
Get PRO
червень '250
в 0 каналах
Get PRO
травень '250
в 0 каналах
Get PRO
квітень '250
в 0 каналах
Get PRO
березень '250
в 0 каналах
Get PRO
лютий '250
в 0 каналах
Get PRO
січень '250
в 0 каналах
Get PRO
грудень '24
+49
в 1 каналах
Get PRO
листопад '240
в 2 каналах
Get PRO
жовтень '240
в 0 каналах
Get PRO
вересень '24
+29
в 0 каналах
Get PRO
серпень '24
+164
в 1 каналах
Get PRO
липень '240
в 1 каналах
Get PRO
червень '240
в 1 каналах
Get PRO
травень '24
+10
в 1 каналах
Get PRO
квітень '24
+33
в 1 каналах
Get PRO
березень '24
+17
в 0 каналах
Get PRO
лютий '24
+49
в 1 каналах
Get PRO
січень '24
+77
в 1 каналах
Get PRO
грудень '23
+78
в 1 каналах
Get PRO
листопад '230
в 0 каналах
Get PRO
жовтень '230
в 0 каналах
Get PRO
вересень '23
+11
в 0 каналах
Get PRO
серпень '23
+20
в 0 каналах
Get PRO
липень '23
+20
в 0 каналах
Get PRO
червень '23
+15
в 0 каналах
Get PRO
травень '23
+21
в 0 каналах
Get PRO
квітень '23
+19
в 0 каналах
Get PRO
березень '23
+17
в 0 каналах
Get PRO
лютий '23
+16
в 0 каналах
Get PRO
січень '23
+26
в 0 каналах
Get PRO
грудень '22
+15
в 0 каналах
Get PRO
листопад '22
+33
в 0 каналах
Get PRO
жовтень '22
+27
в 0 каналах
Get PRO
вересень '22
+16
в 0 каналах
Get PRO
серпень '22
+20
в 0 каналах
Get PRO
липень '22
+17
в 0 каналах
Get PRO
червень '22
+26
в 0 каналах
Get PRO
травень '22
+24
в 0 каналах
Get PRO
квітень '22
+28
в 0 каналах
Get PRO
березень '22
+37
в 0 каналах
Get PRO
лютий '22
+12
в 0 каналах
Get PRO
січень '22
+133
в 0 каналах
Get PRO
грудень '21
+117
в 0 каналах
Get PRO
листопад '21
+89
в 0 каналах
Get PRO
жовтень '21
+42
в 0 каналах
Get PRO
вересень '21
+17
в 0 каналах
Get PRO
серпень '21
+53
в 0 каналах
Get PRO
липень '21
+107
в 0 каналах
Get PRO
червень '21
+10
в 0 каналах
Get PRO
травень '21
+270
в 0 каналах
| Дата | Залучення підписників | Згадування | Канали | |
| 26 жовтня | 0 | |||
| 25 жовтня | 0 | |||
| 24 жовтня | 0 | |||
| 23 жовтня | 0 | |||
| 22 жовтня | 0 | |||
| 21 жовтня | 0 | |||
| 20 жовтня | 0 | |||
| 19 жовтня | 0 | |||
| 18 жовтня | 0 | |||
| 17 жовтня | 0 | |||
| 16 жовтня | 0 | |||
| 15 жовтня | 0 | |||
| 14 жовтня | 0 | |||
| 13 жовтня | 0 | |||
| 12 жовтня | 0 | |||
| 11 жовтня | 0 | |||
| 10 жовтня | 0 | |||
| 09 жовтня | 0 |
Дописи каналу
🤩 delirious dhh
итак, прослушал ~5ч одного небезызвестного программиста с сильными взглядами; ушло у меня на это всего где-то неделя: пара походов в спортзал и комьютов.
чем примечательно это интервью?
во-первых, dhh известен своими взглядами за чистоту кода; это тот ещё художник и скульптор, который «вручную вытачивал» каждый кусочек своих программ. за свою карьеру с 90х он успел понабраться и опыта, и мнений
во-вторых, не далее чем год назад, тот же самый dhh приходил в тот же подскаст и уверял, что этим вашим агентам ещё довольно далеко до настоящего года: так — автокомплит, не более!
получается такой идеальный маркер для 2025-26 годов - даже самые сильные программисты стали признавать возросшие возможности и качество кода от агентов.
There are decades where nothing happens and weeks where decades happenи вот с ноября 2025 dhh ведёт отсчёт, когда он впервые поймал себя на том, что выхлоп агента _достаточно_ похож на то, что он бы сам написал отметил тезис, что по мнению dhh большинство белковых программистов тоже пишут довольно посредственный код; не говоря уже о том, что им зачастую лень уделять много времени архитектуре или тестам. поэтому нет особого смысла гнать на «нейрослоп» — агенты хотя бы не будут отпираться и готовы пройти стопицот итераций, чтобы его исправить. а ещё написать сколько угодно тестов и обложить всё понятной и актуальной документацией. ⌘ в проектах dhh есть места, где он даже не смотрит на итоговой код — типа если оно работает по заданным спекам, то детали не важны. при этом в ядро проектов он внимательно ревьюит каждую строку (хоть и не пишет сам теперь) и чтобы понимать масштаб его текущих амбиций — он теперь пишет не очередной веб-фреймворк, а прям собственную ос, пускай и осованную на линуксе. это агентно-центричная система: её пишут агенты (под надзором dhh) для удобства использования другими агентами ⌘ спросите вашего агента про детали интервью — dhh у лекса фридмана от августа 2026
| 2 | мне кажется последние два интервью отлично смотрятся вместе и дополняют друг друга >_>
и отдельно мысль, которая где-то проговаривалась в этих интервью: токены — новый вид бенефита для сотрудников.
большие компании готовы вливать миллионы в токены для своих разработчиков.
а сами поставщики фундаментальных моделей в принципе ограничены только внутренними мощностями для своих сотрудников.
в подкастах Кирилла Мокевнина @orgprog упоминали, что в долине у каждого второго безлимит на модели OpenAI / Anthropic по тем или иным каналам | 950 |
| 3 | 🥷 DHH об agent-first подходе
DHH — известный ии-скептик и сторонник написания кода вручную; в своём сетапе он не использует IDE с их подсказками и навигацией по коду — всё набивает ручками (и радуется)
ещё DHH известен своими сильным мнением и радикальными взглядами — он говорит что думает, не взирая на мнения большинства или отдельных авторитетов
недавно зашёл к Pragmatic Engineer на интервью
https://youtu.be/JiWgKRgdgpI
и вот наступил действительно переломный момент:
⁃ июль 2025 — DHH не верит и не использует агентов
⁃ январь 2026 — DHH переходит на agent-first разработку
что поменялось? вышли модели, которые выдают достаточно хороший результат, которые при минимальных доработках можно шипать в прод.
если уже DHH «распробовал» агентский подход — значит, результаты работы становятся действительно достаточно хорошими
⌘⌘⌘
DHH делится историей, как агент помогает ему разбирать ишью в его проекте на Гитхабе: из 250 открытых пулл-реквестов агент за пару часов разобрал 100.
какие-то единицы можно было мержить «как есть» — они уже были достаточно хорошего качества; другую часть агент провалидировал как «правильно опознанный баг, но реализация не идеальная» — такие он адаптировал/переписал согласно принятому стилю репо; и ещё часть агент смог аргументированно зареджектить.
при этом сам DHH потратил бы на эту работу несколько дней (и не получил бы большого удовольствия от неё). | 861 |
| 4 | 🦄 руководитель Claude Code об AI в разработке
послушал интервью Бориса Чёрного в подкасте Ленни. Борис написал первую версию Claude Code и теперь руководит этим направлением в Anthropic.
https://youtu.be/We7BZVKbCVw
по их данным сейчас уже 4% всех коммитов в Гитхаб создаются через Claude Code (ожидают 20% к концу года)
интересно, что первую версию Claude Code Борис сделал прошлой весной и это не был сиюминутный успех; популярность инструмента росла постепенно и взрывной рост случился после выхода модели осенью (Опус 4.5 кажется)
и с ноября 2025 Борис не написал ни строчки кода вручную — всё через Клода; так же приводит в пример «лучших программистов Spotify», мол, они тоже больше не пишут код руками.
Борис видит, что в будущем профессии будут теснее переплетены: не будет программистов или дизайнеров, все будут builder («создатель»?) — задавать ви́дение, раздавать задачи аи-агентам и принимать результат их работы.
этот сдвиг парадигмы ставят в один ряд с изобретением печатного станка и освобождением пицсцов от монотонной работы; и с переходом от программирования на перфокартах к следующему уровню. | 878 |
| 5 | 📁 про культуру ведения тикетов
продолжаю рассказывать про внутрянку нашей команды, привлекая ваше внимание к активным вакансиям >_>
> важный дисклеймер: это не я, это всё наш техлид Кирилл (я тут только документирую и выношу)
думаю, все видели тикеты, прочитав которые, осталось непонятным что́ надо сделать; или задачи, где ты вроде сделал что было написано, но оказалось, что нужно было не то и не так ¯\_(ツ)_/¯
мы в команде стараемся придерживаться культуры ведения задач — попробую описать как я это вижу
⌘⌘⌘
начнём с того, что создать хороший тикет - это отдельная работа; чтобы понятно описать что надо сделать, надо как минимум представлять проблему и целевое решение
есть базовый паттерн, которого мы придерживаемся:
⁃ контекст
⁃ проблема
⁃ что сделать
⁃ допматериалы
небольшие тикеты могут пропускать 1-2 пункта; а большие эпики будут наоборот побольше
⌘⌘⌘
«хорошие» задачи формулируются через глаголы:
сделать …, добавить …, исправить …, пересчитать …
однозначно указан объект изменения: таблица, таск, модуль и пр.
есть перечень связанных действий: в конце …сделать миграцию, …пересчитать историю, и пр.
⌘⌘⌘
задачи на имплементацию проходят через общее техревью на входе, чтобы вместе посмотреть и проверить:
⁃ проверить, что мы в принципе хотим это делать
(тут бинарно; пока без приоритетов)
⁃ задача описана понятно
⁃ ожидаемый результат считывается однозначно
⁃ (опционально) докапывается технических деталей
цель такого пре-ревью проверить, что автор достаточно подумал про задачу и потенциальный исполнитель прочитает её ожидаемо
паттерны задач помогают консистентно формулировать задачи внутри команды, а так же уменьшают количество догадок и уточнений на этапе разработки
⌘⌘⌘
если задача занимает больше нескольких дней, то внутри ожидаются отбивки по текущему статусы; размер отбивок пропорционален масштабу задачи
причём не абстрактный статус «продолжаю работать», а короткий апдейт по фактам: сделано Х / осталось сделать У / открытые вопросы и блокеры …
⌘⌘⌘
в конце каждого тикет исполнитель оставляет резюме о проделанной работе
«сделал таск, пересчитал историю, вот ссылка на итоговый объект» — всё что нужно знать о задаче, осознанно принять результат (и при необходимости вспомнить через полгода что тут было вообще)
статусы и резюмешки повышают прозрачность работы для сторонних наблюдателей: заказчиков, тимлидов, а так же для себя из будущего
прозрачность ведения задач особенно важна при ведении инцидентов — для них помимо резюме дополнительно надо сразу заполнить пост-морфем
(инцидент-менеджемент у нас тоже есть — про него в другой раз)
⌘⌘⌘
лайк-шер-репост
👉 https://t.me/data_days/400 | 1 109 |
| 6 | 🦀 Clawdbot / Moltbot / OpenClaw
там похоже намечается очередной качественный скачок аи-строения: австрийский программист написал автономного (?) ии-агента… и понеслось
формат горячих новостей не мой любимый жанр, но это залетело в моё инфополе с трёх разных сторон:
+ Самат Галимов накидал ссылок для понимания контекста
https://t.me/ctodaily/1995
+ Pragmatic Engineer выпустил интервью с автором
https://youtu.be/8lF7HmQ_RgY
+ ребята из Шмит16 собрались вместе где-то на Бали и скупают все доступные мак-мини, чтобы устроить ферму из таких аи-агентов
сам автор бота не случайный мамкин вайбкодер — он начинал ещё с веб-приложений в начале 2000-х и потом перешёл на приложения айос для первого айфона.
потом запилил как побочный продукт PSPDFKit — низкоуровневый парсер и рендере пдф-ок; продукт быстро стал приносить денег больше, чем основная работа и он переключился на него фултайм. потихоньку стартап разросся до 70 человек.
продукт оказался достаточно востребованным, чтобы его покупали большие компании, и при этом достаточно сложным, чтобы они не могли его просто сделать внутри
отсюда у автора большой опыт в построении сложных технических продуктов с большим количеством разношёрстных пользователей — надо успевать развивать продукт, ничего не поломав.
⌘⌘⌘
потом он (традиционно) выгорел и ушёл с радаров на три года, ничего не делал, ничем не занимался; и всё, чтобы «вернуться в интернет» в 2025-м —прямо на рассвете ии-агентов
тут он офигел от новой технологии и по первым ощущениям от продукта он вспомнил все хорошие впечатления от программирования
в итоге к осени он врубился в технологию настолько, что она стала для него «запойной»: работает на десятью пет-проектами сразу и 10 разных агентах / терминалах
⌘⌘⌘
поинты автора про подход к агентам:
⌘ замкнуть цикл обратной связи: задача → план → исполнение → отладка → тестирование → сверка с исходной задачей — всё это агент делает сам в бесконечной итерации, пока результат не достигнут
⌘ «новое» программирование — это верхнеуровневый дизайн, а не написание кода
⌘ из аи-агенты можно собирать локальные мини-команды (и не отдельные тулзы)
⌘ а синьорные инженеры — это теперь аи-менеджеры таких локальных команд для разработки
⌘⌘⌘
сам Moltbot / OpenClaw выглядит как проект на стыке аи- и арт-перфоманса
автономный агент, которому явно дают доступ к локальной системе — это что-то за гранью привычного
причём не каждый догадывается или может позволить себе отдельный мак-мини для инстанса бота — и они грузят их прям на своей основной тачке
с другой стороны, эти эмерджентный и удивительные свойства агента проявляются как раз на богатой почве развитого локального окружения; на стерильной системе у него не будет истории переписки в мессенджер и почте, не на что смотреть)
⌘⌘⌘
агент имеет доступ к своим настройкам и исходному коду
может менять свою конфигурацию, дописывать новые модули
так, у бота не было модуля работы с голосовыми сообщениями, но, получив однажды голосяшку от автора, он через какое-то время дал релевантный ответ (оказалось, он прочитал хедер сообщения, нашёл нужный модуль, установил его и смог декдодировать пришедшее ранее сообщение)
🤯 | 905 |
| 7 | 📝 о код-ревью (часть 2)
вижу тема ↑ код-ревью хорошо зашла — продолжаю накидывать
⌘ разные авторы — разные вопросы на ревью
+ во время онбордина на первые ревью обычно приходит тьма комментариев; чтобы проверить, что автор достаточно погрузился в новый проект, приходится спрашивать с самых банальностей: «почему тут за Т-2», «почему тут снепшото, а не апсёрт?» и т.д.
+ со временем у авторов набирается «репутация» — вопросы переходят на следующий уровень абстракций (или вовсе пропадают с типовых решений)
⌘ размер имеет значение
− гигантский ПР на 500+ строк кода, затрагивающий множество модулей, имеет шанс погрязнуть в процессе ревью (не говоря уже про увеличенную вероятность пропустить багульку в прод)
+ а вот маленький атомарный ПР легко читать и требует адекватного количества когнитивной энергии ревьюера — а значит не вызывает сопротивления и обычно сходится предсказуемо быстро
⌘ не всегда есть «правильный» ответ
+ иногда вопрос — это предложение к дискуссии или просто любопытство почему выбран именно такой подход
+ хочется проверить, что автор продумал основные кейсы в предлагаемом решении
⌘ проблемы код-ревью
− неконсистентность от ревью к ревью: даже один ревьюер может спросить разное, не говоря уже о нескольких
− код-ревью не случается само — оно занимает время и тратит когнитивную энергию; это буквально конвейер и его надо явно планировать в своём календаре (получается всем в команде)
− ну и в целом — растёт тайм-ту-маркет, в задачу надо закладывать время на схождение код-ревью
⌘ ожидания от код-ревью
+ код-ревью не должно быть узким горлышком — положительные эффекты складываются, когда вся команда ревьюит друг-друга (не только один тимлид по ночам и выходным)
+ LGTM — это тоже ответственность; если код падает прям сразу после релиза — вопросики будут как к автору, так и к ревьюеру;
+ всем в команде (включая ревьюера) потом поддерживать этот код — в общих интересах поддерживать кодовую базу в хорошем виде
⌘ пускай потеет машина
+ проверять синтаксис и опечатки должны машины, а не белковые мешки; поэтому эффективнее настроить линтеры, тесты, вот это всё
+ если команда уже сформировала код-стайл и обсудила архитектурные подходы, то будет проще формализовать и базовые проверки
+ а дальше пускай уже и аи-шные агенты ревьюят код помимо базовых линтеров и тестов — эти уже не только формально, но и по смыслу смогут накидать на вентилятор
---
тем временем мы продолжаем искать дата-коллег — ваши репосты нам очень помогут | 813 |
| 8 | 📢 ищем дата-коллег к себе в Яндекс Финтех
→ дата инженеры
https://yandex.ru/jobs/vacancies/inzhener-dannih-v-finteh-36637
→ дата-партнёры (они же системные аналитики двх)
https://yandex.ru/jobs/vacancies/analitik-dwh-v-finteh-27815
это прям в нашу команду, то есть будем работать вместе)
наша команда свежая — начали строить наш двх осенью 2024; поэтому не успели пока обрасти легаси и техдолгами, зато смогли заработать репутацию и кредит доверия за свой первый полный год работы.
хотим и дальше нести свет в массы, поэтому активно ищем новых коллег
что у нас есть интересного:
→ есть полная документация — наши объекты не идут в прод без описания каждого атрибута
→ на нанейминг полей и объектов — есть конвенция
→ на YQL — есть линтеры
→ на пулл-реквесты — тесты в си-сд (и 4 глаза ревьюеров)
из технологии — почти всё яндексовое:
+ YTsaurus как основная система хранения
+ смотрим в сторону ClickHouse рядом
+ придерживаемся подхода инфра-как-код через Terraform
+ логброкер как шина данных для стриминга и дата-трансфер как коннектор (если вам это о чём-то говорит)
любим процессы (но без карго культов)
→ есть дежурство и инцидент-менеджмент с пост-мортемами
→ есть удобный процесс мониторинга и алертов
→ подробный онбординг и прочие документы о процессах команды
чем предстоит заниматься:
§ перекладывать джейсоны ысоны слева направо — разобраться где найти, откуда они там появляются, почему в таком формате, и как лучше их разложить, чтобы дорогим пользователям было удобнее их селектить;
$ работать над доступностью сервиса и данных: как валидировать данные и мониторить корректность на потоке, чтобы не пробивать общие сла;
$ выяснять, спрашивать, изучать у источников почему данных не было, почему поздние долёты, почему внутри полная шляпа, и вообще где ещё три нужных поля;
$ спорить с дорогими коллегами как оптимальнее перелопатить теробайты в секунду, как лучше описать новый домен, какой кусок вынести в общую либу, голосовать какие фичи больше всего нужны в общей платформе
и делать это всё в максимально подготовленной и комфортной среде, внутри Яндекса развитая культура внутренних инструментов: доступы к основным аи-моделям, рабочие места с Курсором, внутренние вебинар и обучалки на любые темы
понимаю, что процесс найма долгий, поэтому планирую постепенно накидывать заметок о буднях команды; ссылки буду появляться ниже
→ о код ревью
→ ещё о код ревью
→ про культуру ведения тикетов
→ …
можно откликаться на вакансия выше или присылать CV с кратким интро мне в личку @SashaMikhailov
буду рад ответить на вопросы в комментах или так же в личке | 1 370 |
| 9 | ✍️ о код-ревью
у нас в команде в прод только через пулл-реквесты и каждый пулл-реквест должно посмотреть двое коллег. моя личная статистика за 2025 год показывает 430 проведённых код-ревью. сложились какие-то мысли по этому поводу, ниже пытаюсь собрать их вместе.
⌘ зачем вообще нужно код-ревью
+ это вторая пара глаз с иным контекстом и уровнем погружения: автор и ревьюер смотрят на код в разных когнитивных режимах → ловятся разные ошибки
+ передача знаний в рамках команды: «применяем вот такие паттерны, а вот так не делаем» → в среднем качестве кода постепенно улучшается
+ барьер против энтропии и деградации кодовой базы: без должного присмотра любой проект постепенно превращается в трудно поддерживаемое болото
⌘ как бывает без код ревью
когда команда небольшая, да ещё и допустим без большого опыта, то большой соблазн поспешить с реализацией или смалодушничать при проектировании → в результате получается нагромождение модулей, которые через время проще сжечь, чем исправить
⌘ как задавать вопросы на код-ревью
+ открытые вопросы лучше чётких предложений — во-первых, ревьюер сам можем не осознать что здесь происходит, а, во-вторых,
+ любой код может быть написан множеством способов — прежде чем предложить что-то поправить, надо понять а точно ли оно будет объективно лучше? или просто «ревьюер привык писать по-другому»
+ спорные места должны быть выведены в общие архитектурные соглашения на команду (какие линтеры используем, как ставим отступы и пр.)
⌘ эффект от код ревью
− растёт время на разработку: уходит время на найти ревьюеров и иногда пройти несколько итераций над кодом
+ твои типичные вопросы на код-ревью возвращаются в твои пулл-реквесты — нарабатывается паттерны и начинаешь думать про типовые кейсы заранее
+ повышение качества среднего пулл-реквеста — на ревью не поступает откровенно плохих пулл-реквестов, где какой-то треш или забыли подумать | 1 024 |
| 10 | 🤓 Martin Fowler в гостях Pragmatic Engineer
https://youtu.be/CQmI4XKTa0U
Мартину уже за 60 лет, из которых он 40 с лишним считает себя инженером; когда опыт исчисляется десятками, то накапливается тот уровень насмотренности, когда можно сравнивать эпохи и видеть глобальные тенденции
⌘⌘⌘
по своему масштабу Мартин сравнивает нынешний скачок с переходом программистов с ассемблера на языки более высокого уровня
сам Мартин не имеет ничего против вайбкодинга как такового (тут он понимает «вайбкодинга» именно как безоглядное принятие любого результата ллм-ки без глубокого осознания написанного), однако чётко ограничивает зону его возможностей: небольшие проекты, прототипы на выброс и т.д.
главный недостаток слепого вайбкодинга — отсутствие цикла обратной связи. не пропуская через себя этот код, нет процесса обучения. новые знания не налипают и не копятся
получается вайбкодер через год останется ровно с таким же уровнем и потом его сменит просто другой вайбкодер (помоложе); или просто следующее поколение агентов, которым не нужна будет «простилка» между клавиатурой и креслом
⌘⌘⌘
при этом в прототипировании аи-помощник показывает небывалые приросты в продуктивности. приводят пример инженера из Антропика, который за 2 дня собрал 20 прототипов, итеративно проверяя и валидируя их об команду.
здесь быстрый цикл обратной связи помог им сразу на практике осознать простанство потенциальных вариантов и найти подходящие векторы для развития, отбросив остальные
⌘⌘⌘
ещё одна проблема ллм-ок — полная неспособность решить задачу «переименования класса»; по своему дизайну она скорее перепишет половину кодовой базы, чем поправит в трёх местах нужное название
при этом современные иде уже давно научились это делать, правда со своей подкапотной магией (которой, видимо, и не хватает ллм-кам)
⌘⌘⌘
общий подход к результатам работы моделей — ничему не верить, всё проверять; вдумчиво читать, внимательно вникать, нещадно тестировать, чтобы добавить чуток детерменированности их безудержной креативности.
и тогда действительно можно получать какой-то профит от совместной работы | 1 239 |
| 11 | 🎧 Data Platform T-Bank
послушал подкаст с СТО платформы данных Т-Банка
https://t.me/book_cube/3766
для понимания масштаба
→ 15К MAU пользователей платформы (при условных 18К всех сотрудниках инхаус — это довольно большое проникновение)
→ всю платформу поддерживает ~230 человек
→ сторадж — около 15–20 петабайт;
→ компьют — порядка 100К ядер
→ внутри ~20 тысяч объектов
основная аналитическая СУБД — Greenplum: около 10 кластеров от 30 до 72 нод в каждом
проблемы с текущей архитектурой
⌘ Greenplum имеет ограничение на количество параллельных запросов, которые он может обработать эффективно; считается, что это около ста запросов.
⌘ система требует постоянного мониторинга и ручного управления распределением нагрузки между кластерами. это включает решение «задачки рюкзака», когда необходимо определить, сколько нагрузки можно распределить на каждый кластер с учётом их мощности и возраста оборудования
⌘ архитектура с Greenplum оказалась сложной и нестабильной; даже небольшие сбои могут привести к необходимости переключения пользователей на резервные кластеры, что не всегда проходит гладко и может вызывать негативный опыт
⌘ несмотря на то, что данные распределяются по сегментам, возникают проблемы с их равномерным распределением и обработкой, особенно при больших объёмах и высокой нагрузке
планы дальше
со временем стало понятно, что текущая архитектура не выдерживает всё возрастающий масштаб платформы
теперь задача — рядом с уже летящим самолётом построить ещё один, новый; и как-то аккуратно пересадить «пассажиров» с одного борта на другой
в качестве новой целевой архитектуры выбрали стандартный набор:
iceberg + s3 + spark + trino
по отзывам пользователей где-то новая архитектура отрабатывает дольше, чем старая; но по наблюдениям, она в целом надёжнее и готова к дальнейшему масштабированию в принципе
@data_days | 1 860 |
| 12 | 🥸 про коучинг
наша встречу по наведению порядка в проекте через вопросы (два поста выше ↑) напомнила мне профессиональные коучинговые сессии — недавно я попробывал новый для себя инструмент для пары личных проектов.
роль коуча как раз в безоценочной помощи в наведении порядка в хотелках и стремлениях (= проектах). Получается это такой инструмент для диагностики — прикладываешь его к нужному месту, отвечаешь на его вопросы → профит.
ключевой фактор здесь именно в отсутствии оценки, т.е. коуч убирает себя как личность из процесса; он не оперирует терминами «хорошо» и «плохо» — только задаёт вопросы и пытается вместе с тобой найти твои конечные цели и приложить их к какому-то плану (а потом и к сделанным делам по этому плану)
по себе знаю, насколько это сложно не пытаться давать совет после каждой реплики собеседника (ведь я же ЗНАЮ КАК ЛУЧШЕ!!1)
я занимался с Димой Черненьковым и могу его смело рекомендовать. Дима — мой добрый приятель и по совместительству сертифицированный коуч (а ещё фанат кулинарии, спикер, участник подкастов и жонглёр примерно восьмью способами)
Тем, у кого нет возможности на работе побить об кого-то свои проекты или есть личные проекты где могла бы пригодиться помощь извне — тем может быть полезно познакомиться с Димой.
Начать можно с его канала, где встречаются советы о прокрастинации, заметки из книг и конспекты лекций (отдельный лайк за тематические мемы между)
🖤 | 347 |
| 13 | О приоритетизации задач
Дорогой читатель Алексей Махоткин @squadette в коментах к прошлому посту прислал релевантную заметку (спасибо большое! люблю такое, шлите ещё).
Мой ограниченный опыт подтверждается богатым (подозреваю) опытом автора из ЖЖ — ошибка довольно распространённая.
https://gaperton.livejournal.com/36144.html
⁃ неопределённость в проектах есть всегда; ей можно управлять (хотя бы наблюдать и иметь в виду).
⁃ неопределённость к концу проекта должна снижаться
⁃ мутные задачи делать сложно и неохотно, поэтому есть склонность откладывать их на конец проекта.
⁃ вместе с тем, в сложных задачах скрыто куча потенциальной неопределённости — и лучше бы узнать о них пораньше
⁃ иначе неопределённость проявится на 90% готовности проекта (тот случай когда внезапно появляются «вторые 90% проекта»).
👆 | 379 |
| 14 | Польза вопросов
Последние пару месяцев активно копаю в сторону стриминга. Последний проект — перевод одной отдельновзятой поставки данных на Flink.
В какой-то момент настолько увлёкся и закопался, что потерял общий ориентир; ви́дение стало слишком узким и застал себя за тем, что «искал ключи где светло, а не там где их мог потерять»
Благо дело было перед регулярной встрече 1-1 и на помощь пришёл наш бравый лид (привет, Саша!). Через ряд последовательных вопросов у него получилось упорядочить хаос в моей голове: вспомнить о цели проекта, предстоящих этапах и когда это должно быть сделано.
прошли от обратного:
дедлайн условно 1 сентября — значит, 31 августа должен быть релиз? нет, релиз нужен минимум за неделю до этого, чтобы посмотреть как работает на продовых данных и отловить возможные косяки
окей, значит релиз нужен за неделю до этого. Что должно быть в релизе? парсинг входящих джейсонов по схеме и пара джойнов со стейтом (плюс сопутствующий обвес из Графины, настроенных доступов, алертов и пр.)
я был сосредоточен на парсинге, потому что это самое простое 🤡
в то время как часть с джойнами была сложной (и я её оставил на потом). Мы проговорили, что логичнее начинать как раз с реализации джойнов, чтобы раньше узнать о всех сложностях и начать их решать.
в результате беседы был готов расписанный план со всеми промежуточными этапами от сейчас и до дедлайна
интересно, что Саша мог вообще быть не в курсе проекта — все технические и проектные вводные были от меня как участника процесса; он просто задавал нужные вопросы в правильном порядке | 573 |
| 15 | Нет правильных решений
в школе было просто: тебе дают пример, ты что-то там решаешь на листочке и выдаёшь ответ — «42!». И сссразу получаешь обратную связь «правильно / неправильно».
дальше всё получается сложнее.
возьмём кластер Кликхауса, которому плоховато от нагрузки. Что с этим можно сделать? можно добавить ещё хостов, можно апнуть текущие хосты, можно добавить шардирование.
с другой стороны можно проверить нагрузку; что больше грузит систему — запись или чтение? может мы пишем что-то лишнее, т.е. оптимизировать запись. Или у нас Даталенс с Графаной спамят по стопицот одинаковых запросов в секунду?
здесь нет «правильного» ответа. По-хорошему надо бы зарыться в логи и разобраться что происходит, составить план и его придерживаться. Скорее всего придём не к одному решению, а к комбинации из нескольких.
в любом случае, технический расклад по текущей нагрузке пригодится потом, когда придётся защищать запрос на дополнительное железо. А если даже нет, то всегда полезно самому понимать как оно устроено под капотом.
и даже после того, как сделан анализ текущей нагрузки, проработы альтернативные варианты, сделала приоритезация и первые изменения пошли в прод, не придёт никакая технофея и не скажет «молодец! всё правильно сделал» — ничего подобного!
просто продолжаешь наблюдать растущую нагрузку и как предыдущие решения на неё влияют. Оп! — один хост ушёл в maintenance, как система держится? CPU на живых машинах ушло в полочку на 100%, но лаг по данным не растёт. Уже неплохо! Если бы не предыдущие оптимизациия, было бы точно хуже.
нет «правильных» решений — есть только более оптимальные в текущем контексте. | 333 |
| 16 | #послушано
🎧 Rework: AI! GPT! What a time to be alive!
речи фаундеров 37 Signals просто как бальзам на мою fomo-душу!
Для тех, кто переживает, что «поезд AI ушёл» и его уже не догнать, ребята предлагают взглянуть с другой стороны: в этой отрасли настолько быстро всё меняется, что период полураспада навыков — 48 часов!
Если вы были мастером по MidJourney версии 3, то в пятой версии уже всё поменялось и буквально надо вкатываться заново. Поэтому можно смело начинать вкатываться с версии 5 (или 10!) — и все будут примерно на том же уровне.
Главный совет от ребят — Have fun!
Apple Podcasts
🎧 Moscow Python: Пайтон в мире анализа данных
Мой бывший СТО из агентства Epoch8 — Андрей Татаринов — заглянул в подкаст Moscow Python рассказать про использование Python для анализа данных и ML.
Андрей рассказал что там под капотом у Pandas и чем он отличается от Polars, который активно пиариться за счёт своей скорости.
Интересно было про ускорение работы Python за счёт переноса куска вычислений на Rust. Получилось быстро и удивительно мало итераций до работающего прототипа.
Общий совет — в начале писать наивную реализацию на Пайтон как быстрый прототип. И потом когда какие-то места упираются в производительность (problems nice to have) — точечно оптимизировать. А не наоборот =)
Всегда приятно послушать хорошо структурированные рассуждения Андрея и анекдоты из его опыта.
Apple Podcasts
YouTube (c таймингами!)
🎧 Проветримся: Системное мышление (из 2020)
к следующая книга в нашем книжном клубе будет «Системное мышление» Левенчука; в качестве подготовки переслушал эпизод подкаста с автором из 2020. Делюсь заметками:
- Удачный полёт на Марс с первой попытки как результат науки «системная инженерии».
- pretrain + finetune: чтобы поставить обучение танцам, можно прокачать «танцевальное мышление», понять куда смотреть — и тогда новый танец можно будет выучить за 2 часа, а не за дни-недели.
- «машинка с типами» — уметь мыслить абстракциями и моделями. Проверка через простой вопрос «Лидер — это роль. Какие роли у лидера?»
- утверждение, что «у стада коров есть хвост» валидно с точки зрения математики (через вхождение в подмножество), но невалидно с точки зрения систем, потому что оперирует разными уровнями систем.
- эмерджентные свойства — в группе объектов появляются новые свойства, которых не было у отдельных элементов.
- программирование как подобласть системной инженерии (утверждено NASA в 1968)
- «наши требования это их потребности» — наш конченый продукт куда-то вставляется (в следующую систему) и, чтобы оно там работало, надо понимать как его будут применять. Нет смысла делать шестерёнки для часов полностью под размер, но из пластмассы.
ссылки на платформы и сам файл с записью в канале подкаста
https://t.me/progulka/128 | 355 |
| 17 | ClickHouse: стриминг для бедных
достался в поддержку проект по реалтайм обработке данных на основе КХ — чем больше в него погружаюсь, тем больше он нравится!
смысл простой: из брокера сообщений инсёртим данные в КХ и там через материализованные представления раскладываем их в одну широкую денормализованную витрину.
на выходе получаем основные данные для аналитики бизнеса с задержкой в единицы секунд для основных атрибутов и доезд остальных по мере поступления.
вообще Кликхаус мне представляется как кладезь интересных технических решений. По мере погружения проект отметил два пункта, почему такой проект в принципе работает:
1. колоночное хранение
2. движки таблиц семейства MergeTree
3. матвьюхи, работающие по принципу стриминга
1/ колоночное хранение
данные в таблицах базы — это файлы на диске (довольно очевидно, но до меня это дошло только когда читал Кабанчика)
Когда в одном файле лежат полные строки, то в них могут быть нуллы, т.е. лишняя информация. Если хранение повернуть на 90° и хранить в файлах колонки, то там ничего лишнего не будет; а дополнительно получаешь плюшки в виде более эффективного сжатия и аналитических запросов.
И тогда мы можем инсёртить в нашу широкую витрину на 100+ атрибутов из разных загрузчиков — каждый загрузчик наполняет только своё подмножество атрибутов. При такой вставке в остальных атрибутах не прорастают лишние нуллы.
Чем-то похоже на принцип загрузки в анкор-датаволт: у нас есть «хаб» с первичным ключом и набор отдельных атрибутов-сателлитов; только не на уровне таблиц в базе, а на уровне файлов на диске.
2/ таблицы MergeTree
ещё в Кабанчике читал про разницу между разными методами хранения данных в базе данных: B-Tree и LSM Tree.
B-Tree хранит данные в дереве — это очень удобно для чтения, потому что можно до любой ячейки дойти за пару шагов по этому дереву. Но записывать такое дерево сложно — перед записью надо найти конкретное место, куда положить твои байтики. А если лист дерева переполнен, нужно создать новый.
Log-Structered Merge (LSM) Tree же наоборот оптимизирует запись. Все входящий байтики пишутся тупо в конец последнего файла. Это очень быстро для записи.
Но читать такое сложно — при доступе по ключу записи надо проверить все файлы от последнего к первому (самые плохие кейсы, когда такого ключа нет).
В ClickHouse есть целое семейство из движков таблиц — MergeTree, поэтому туда можно быстро и много инсёртить. А под капотом уже происходит merge — наваленные в порядке записи файлики раскладываются в сортированном порядке, удаляя лишние данные. Что позволяет читать ваши терабайты за секунды.
3/ «стриминг» матвью
интересная особенность матвьюх в КХ — они «присоединяются» к таблице-источник и их логика трансформации применяется к каждому входящему в эту таблицу куску данных.
благодаря этой особенности можно налету «парсить» прилетающие из брокера сообщений инсёрты и раскладывать в нужные колонки нашей широкой витрины.
напоминает триггеры из других баз — типа на каждый инсерт в таблицу Т1 делаем набор действий с таблицами Т2..Т99.
И тут история делает полный круг — на первом своём проекте по дох-строению я сделал условный ЕТЛ на триггерах внутри Постгрес (про Эйрфлоу я тогда ещё не знал =). Как прототип это работало, но развивать и поддерживать это было сложно.
В самом КХ это поддерживать тоже трудновато, надо запросы и DDL выносить куда-то во вне. Но по крайней мере оно всё работает на продавшен объёмах и не загибается; подозреваю, что благодаря пунктам 1. и 2. (и техническому гению Алексея Миловидова и команды КХ) | 372 |
| 18 | 🤓️️Практикум: английский для разработчика
Спустя 6 месяцев закончил курс, куда записался на панике сразу после мобилизации. На самом деле записался сразу на два английских от Практикума: общий и для разработчиков.
Общий порадовал короткими кусочками — в любое свободное время за 15 минут проходишь теорию и после неё записываешься на практику на через-5-минут. Можно не держать в голове расписание, а заниматься по свободности.
Но в итоге продолжил только с курсом английский для разработчиков. Там подкупила релевантность тем — всё связаны с ежедневной работой: стендапы и ретро, парное программирование и код-ревью, вопросы в интернете и публичная презентация; и конечно поиск работы и тренировка технических и бихейв интервью.
⌘ Процесс
В самом начале был небольшой скрининг, проверяли мой английский (видимо, что я смогу общаться с преподом без русского)
А дальше занятия 1-1 по зуму. Преподаватель шарит экран с уроками из Ноушена и мы вместе проходим. Там на понимание, на чтение и много на пересказ и прочие болталки.
После занятия идут домашки (препод ещё спрашивал в начале нужны ли они, буду ли я их делать)). Домашки на той же платформе, где и занятия по обычному английскому.
Каждое 8-е занятие идёт с носителем. За время обучения у меня были разные ребята из Милана, Австралии, Турции, США и Сингапура. У них был разный уровень английского — двое точно не нейтивы. Но в целом норм, они типа те самые айтишники, об которых можно потренироваться: отработать поведенческие и технические интервью.
Ещё мне очень повезло с преподом. Хоть её и зовут Елена, но английский у неё на уровне нейтива — кажется это из-за того, что она долго жила где-то заграницей. Прям приятно её слушать и подмечать разные интересные фразы. Если вдруг у вас будет возможность выбора, рекомендую спросить можно ли заниматься с Elena Shoshkina
полгода назад было два курса: для разработчиков и аналитиков. Сейчас вижу добавили третий (и расширили старые):
1. для разработчиков и QA
2. для продактов и прожектов
3. для аналитиков и DS
https://practicum.yandex.ru/english/english_for_career-1/ | 400 |
| 19 | там завтра наши хэды из платформы данных будут рассказывать как ворочать петабайтами в YTsaurus (он же Ыть, он же а-ля Хадуп)
https://t.me/ytsaurus_ru/2869 | 364 |
| 20 | 👆 Минутка кибербезопасности
Регулярно появляются новости, что взломали очередную компанию, поэтому тема актуальная. Кажется, что проблема где-то на другом уровне, но часто взломы начинаются с отдельного человека, который решил, что qwerty — сильный и надёжный пароль.
В подкаст «Запуск завтра» пришёл хакер-предприниматель, компания которого проводит аудит безопасности: за деньги пытаются сломать компании с последующим отчётом и предложениями по улучшению.
кулстори: для одной компании делали аудит, сделали скан и нашли забытый всеми почтовый сервис, торчащий наружу. Спарсили с Линкедина сотрудников, сгенерерили почтовые адреса и по всем прошлись проверкой на базовые пароли — нашёлся один с условным qwerty. Зашли внутрь и пошли гулять там по внутренней сети по соседним сервисам, наткнулись на незашифрованный бекап хранилища паролей. Редкий случай, но довольно показательный.
векторов атаки много: можно скупать логи ботнетов и ищут там целенаправленно что-то про конкретную компанию, чтобы целенаправленно пытаться её сломать; либо искать по логам кто (ещё) использует технологию нужной версии, где недавно нашли критичный баг.
фанфакт: если сделать облачную виртуальную машину, открытую наружу и с простым паролем, через несколько минут там будет работать чей-то майнинг крипты. Сканирование бубличного интернета и взломы такого уровня уже автоматизированы.
вторая половина подкаста была про то как это всё работает в мире блокчейна и крипты — там полный дикий запад, поэтому особенно интересно послушать.
https://t.me/ctodaily/1684 | 466 |
