data будни
Open in Telegram
работаю инженером данных и пишу в основном про это. Профильные ссылки с коротким резюме (статьи, доклады, подкасты), иногда «софтовое» — например, про поиск работы.
Show more973
Subscribers
+124 hours
+47 days
+5330 days
Data loading in progress...
Similar Channels
Tags Cloud
No data
Any problems? Please refresh the page or contact our support manager.
Incoming and Outgoing Mentions
---
---
---
---
---
---
Attracting Subscribers
December '24
December '24
+49
in 1 channels
November '240
in 2 channels
Get PRO
October '240
in 0 channels
Get PRO
September '24
+29
in 0 channels
Get PRO
August '24
+164
in 1 channels
Get PRO
July '240
in 1 channels
Get PRO
June '240
in 1 channels
Get PRO
May '24
+10
in 1 channels
Get PRO
April '24
+33
in 1 channels
Get PRO
March '24
+17
in 0 channels
Get PRO
February '24
+49
in 1 channels
Get PRO
January '24
+77
in 1 channels
Get PRO
December '23
+78
in 1 channels
Get PRO
November '230
in 0 channels
Get PRO
October '230
in 0 channels
Get PRO
September '23
+11
in 0 channels
Get PRO
August '23
+20
in 0 channels
Get PRO
July '23
+20
in 0 channels
Get PRO
June '23
+15
in 0 channels
Get PRO
May '23
+21
in 0 channels
Get PRO
April '23
+19
in 0 channels
Get PRO
March '23
+17
in 0 channels
Get PRO
February '23
+16
in 0 channels
Get PRO
January '23
+26
in 0 channels
Get PRO
December '22
+15
in 0 channels
Get PRO
November '22
+33
in 0 channels
Get PRO
October '22
+27
in 0 channels
Get PRO
September '22
+16
in 0 channels
Get PRO
August '22
+20
in 0 channels
Get PRO
July '22
+17
in 0 channels
Get PRO
June '22
+26
in 0 channels
Get PRO
May '22
+24
in 0 channels
Get PRO
April '22
+28
in 0 channels
Get PRO
March '22
+37
in 0 channels
Get PRO
February '22
+12
in 0 channels
Get PRO
January '22
+133
in 0 channels
Get PRO
December '21
+117
in 0 channels
Get PRO
November '21
+89
in 0 channels
Get PRO
October '21
+42
in 0 channels
Get PRO
September '21
+17
in 0 channels
Get PRO
August '21
+53
in 0 channels
Get PRO
July '21
+107
in 0 channels
Get PRO
June '21
+10
in 0 channels
Get PRO
May '21
+270
in 0 channels
| Date | Subscriber Growth | Mentions | Channels | |
| 21 December | +3 | |||
| 20 December | 0 | |||
| 19 December | +3 | |||
| 18 December | 0 | |||
| 17 December | 0 | |||
| 16 December | 0 | |||
| 15 December | +2 | |||
| 14 December | 0 | |||
| 13 December | 0 | |||
| 12 December | 0 | |||
| 11 December | 0 | |||
| 10 December | 0 |
Channel Posts
🥸 про коучинг
наша встречу по наведению порядка в проекте через вопросы (два поста выше ↑) напомнила мне профессиональные коучинговые сессии — недавно я попробывал новый для себя инструмент для пары личных проектов.
роль коуча как раз в безоценочной помощи в наведении порядка в хотелках и стремлениях (= проектах). Получается это такой инструмент для диагностики — прикладываешь его к нужному месту, отвечаешь на его вопросы → профит.
ключевой фактор здесь именно в отсутствии оценки, т.е. коуч убирает себя как личность из процесса; он не оперирует терминами «хорошо» и «плохо» — только задаёт вопросы и пытается вместе с тобой найти твои конечные цели и приложить их к какому-то плану (а потом и к сделанным делам по этому плану)
по себе знаю, насколько это сложно не пытаться давать совет после каждой реплики собеседника (ведь я же ЗНАЮ КАК ЛУЧШЕ!!1)
я занимался с Димой Черненьковым и могу его смело рекомендовать. Дима — мой добрый приятель и по совместительству сертифицированный коуч (а ещё фанат кулинарии, спикер, участник подкастов и жонглёр примерно восьмью способами)
Тем, у кого нет возможности на работе побить об кого-то свои проекты или есть личные проекты где могла бы пригодиться помощь извне — тем может быть полезно познакомиться с Димой.
Начать можно с его канала, где встречаются советы о прокрастинации, заметки из книг и конспекты лекций (отдельный лайк за тематические мемы между)
🖤
| 2 | О приоритетизации задач
Дорогой читатель Алексей Махоткин @squadette в коментах к прошлому посту прислал релевантную заметку (спасибо большое! люблю такое, шлите ещё).
Мой ограниченный опыт подтверждается богатым (подозреваю) опытом автора из ЖЖ — ошибка довольно распространённая.
https://gaperton.livejournal.com/36144.html
⁃ неопределённость в проектах есть всегда; ей можно управлять (хотя бы наблюдать и иметь в виду).
⁃ неопределённость к концу проекта должна снижаться
⁃ мутные задачи делать сложно и неохотно, поэтому есть склонность откладывать их на конец проекта.
⁃ вместе с тем, в сложных задачах скрыто куча потенциальной неопределённости — и лучше бы узнать о них пораньше
⁃ иначе неопределённость проявится на 90% готовности проекта (тот случай когда внезапно появляются «вторые 90% проекта»).
👆 | 379 |
| 3 | Польза вопросов
Последние пару месяцев активно копаю в сторону стриминга. Последний проект — перевод одной отдельновзятой поставки данных на Flink.
В какой-то момент настолько увлёкся и закопался, что потерял общий ориентир; ви́дение стало слишком узким и застал себя за тем, что «искал ключи где светло, а не там где их мог потерять»
Благо дело было перед регулярной встрече 1-1 и на помощь пришёл наш бравый лид (привет, Саша!). Через ряд последовательных вопросов у него получилось упорядочить хаос в моей голове: вспомнить о цели проекта, предстоящих этапах и когда это должно быть сделано.
прошли от обратного:
дедлайн условно 1 сентября — значит, 31 августа должен быть релиз? нет, релиз нужен минимум за неделю до этого, чтобы посмотреть как работает на продовых данных и отловить возможные косяки
окей, значит релиз нужен за неделю до этого. Что должно быть в релизе? парсинг входящих джейсонов по схеме и пара джойнов со стейтом (плюс сопутствующий обвес из Графины, настроенных доступов, алертов и пр.)
я был сосредоточен на парсинге, потому что это самое простое 🤡
в то время как часть с джойнами была сложной (и я её оставил на потом). Мы проговорили, что логичнее начинать как раз с реализации джойнов, чтобы раньше узнать о всех сложностях и начать их решать.
в результате беседы был готов расписанный план со всеми промежуточными этапами от сейчас и до дедлайна
интересно, что Саша мог вообще быть не в курсе проекта — все технические и проектные вводные были от меня как участника процесса; он просто задавал нужные вопросы в правильном порядке | 573 |
| 4 | Нет правильных решений
в школе было просто: тебе дают пример, ты что-то там решаешь на листочке и выдаёшь ответ — «42!». И сссразу получаешь обратную связь «правильно / неправильно».
дальше всё получается сложнее.
возьмём кластер Кликхауса, которому плоховато от нагрузки. Что с этим можно сделать? можно добавить ещё хостов, можно апнуть текущие хосты, можно добавить шардирование.
с другой стороны можно проверить нагрузку; что больше грузит систему — запись или чтение? может мы пишем что-то лишнее, т.е. оптимизировать запись. Или у нас Даталенс с Графаной спамят по стопицот одинаковых запросов в секунду?
здесь нет «правильного» ответа. По-хорошему надо бы зарыться в логи и разобраться что происходит, составить план и его придерживаться. Скорее всего придём не к одному решению, а к комбинации из нескольких.
в любом случае, технический расклад по текущей нагрузке пригодится потом, когда придётся защищать запрос на дополнительное железо. А если даже нет, то всегда полезно самому понимать как оно устроено под капотом.
и даже после того, как сделан анализ текущей нагрузки, проработы альтернативные варианты, сделала приоритезация и первые изменения пошли в прод, не придёт никакая технофея и не скажет «молодец! всё правильно сделал» — ничего подобного!
просто продолжаешь наблюдать растущую нагрузку и как предыдущие решения на неё влияют. Оп! — один хост ушёл в maintenance, как система держится? CPU на живых машинах ушло в полочку на 100%, но лаг по данным не растёт. Уже неплохо! Если бы не предыдущие оптимизациия, было бы точно хуже.
нет «правильных» решений — есть только более оптимальные в текущем контексте. | 333 |
| 5 | #послушано
🎧 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 |
| 6 | 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 |
| 7 | 🤓️️Практикум: английский для разработчика
Спустя 6 месяцев закончил курс, куда записался на панике сразу после мобилизации. На самом деле записался сразу на два английских от Практикума: общий и для разработчиков.
Общий порадовал короткими кусочками — в любое свободное время за 15 минут проходишь теорию и после неё записываешься на практику на через-5-минут. Можно не держать в голове расписание, а заниматься по свободности.
Но в итоге продолжил только с курсом английский для разработчиков. Там подкупила релевантность тем — всё связаны с ежедневной работой: стендапы и ретро, парное программирование и код-ревью, вопросы в интернете и публичная презентация; и конечно поиск работы и тренировка технических и бихейв интервью.
⌘ Процесс
В самом начале был небольшой скрининг, проверяли мой английский (видимо, что я смогу общаться с преподом без русского)
А дальше занятия 1-1 по зуму. Преподаватель шарит экран с уроками из Ноушена и мы вместе проходим. Там на понимание, на чтение и много на пересказ и прочие болталки.
После занятия идут домашки (препод ещё спрашивал в начале нужны ли они, буду ли я их делать)). Домашки на той же платформе, где и занятия по обычному английскому.
Каждое 8-е занятие идёт с носителем. За время обучения у меня были разные ребята из Милана, Австралии, Турции, США и Сингапура. У них был разный уровень английского — двое точно не нейтивы. Но в целом норм, они типа те самые айтишники, об которых можно потренироваться: отработать поведенческие и технические интервью.
Ещё мне очень повезло с преподом. Хоть её и зовут Елена, но английский у неё на уровне нейтива — кажется это из-за того, что она долго жила где-то заграницей. Прям приятно её слушать и подмечать разные интересные фразы. Если вдруг у вас будет возможность выбора, рекомендую спросить можно ли заниматься с Elena Shoshkina
полгода назад было два курса: для разработчиков и аналитиков. Сейчас вижу добавили третий (и расширили старые):
1. для разработчиков и QA
2. для продактов и прожектов
3. для аналитиков и DS
https://practicum.yandex.ru/english/english_for_career-1/ | 400 |
| 8 | там завтра наши хэды из платформы данных будут рассказывать как ворочать петабайтами в YTsaurus (он же Ыть, он же а-ля Хадуп)
https://t.me/ytsaurus_ru/2869 | 364 |
| 9 | 👆 Минутка кибербезопасности
Регулярно появляются новости, что взломали очередную компанию, поэтому тема актуальная. Кажется, что проблема где-то на другом уровне, но часто взломы начинаются с отдельного человека, который решил, что qwerty — сильный и надёжный пароль.
В подкаст «Запуск завтра» пришёл хакер-предприниматель, компания которого проводит аудит безопасности: за деньги пытаются сломать компании с последующим отчётом и предложениями по улучшению.
кулстори: для одной компании делали аудит, сделали скан и нашли забытый всеми почтовый сервис, торчащий наружу. Спарсили с Линкедина сотрудников, сгенерерили почтовые адреса и по всем прошлись проверкой на базовые пароли — нашёлся один с условным qwerty. Зашли внутрь и пошли гулять там по внутренней сети по соседним сервисам, наткнулись на незашифрованный бекап хранилища паролей. Редкий случай, но довольно показательный.
векторов атаки много: можно скупать логи ботнетов и ищут там целенаправленно что-то про конкретную компанию, чтобы целенаправленно пытаться её сломать; либо искать по логам кто (ещё) использует технологию нужной версии, где недавно нашли критичный баг.
фанфакт: если сделать облачную виртуальную машину, открытую наружу и с простым паролем, через несколько минут там будет работать чей-то майнинг крипты. Сканирование бубличного интернета и взломы такого уровня уже автоматизированы.
вторая половина подкаста была про то как это всё работает в мире блокчейна и крипты — там полный дикий запад, поэтому особенно интересно послушать.
https://t.me/ctodaily/1684 | 466 |
| 10 | 🤓 data-архитектуры: Lamda vs Kappa
по рабочей необходимости въезжаю в тему стриминга данных, пытаюсь вникнуть в тамошние концепции, основные проблемы и методы их решения. Первая тема на пути — базовые отличия обработки данных батчами и на непрерывном потоке.
батчинг — это просто и надёжно: тащишь все данные за какой-то период (для надёжности — с нахлёстом) и пересчитываешь спокойно произвольный период в прошлое по мере доезда всех данных. Получается консистентно, но вчера.
стриминг — это быстро, но сложно: данные льются потоком, их надо успевать читать и записывать. Если воркер упал, что происходит с данными? если для трансформации нужен стейт или джойн, то сколько держать событие в памяти? поначалу решения были неконсистентными by design
но всем хотелось сейчас и сразу, поэтому придумали как совместить эти два подхода
🔵 Lambda-архитектура
идея простая: когда хочется стриминг, но он ещё ненадёжный, делаем два потока данных:
1. текущий инкремент бежит через стриминг
2. а потом по старинке сверху накатываем батч
получается и быстро (но не надёжно), и eventually надёжно — после того как накатился следующий батч.
проблема в том, что код трансформаций теперь лежит в двух разных местах — и стриминг, и батчинг считают по-своему; приходится поддерживать две кодовые базы и следить за консистентностью.
http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html
🟡 Kappa-архитектура
тогда другие умные люди подумали и предложили альтернативный подход: давайте держать единую версию трансформаций и пускай главным будет стриминг-реализация.
А если (когда!) надо будет пересчитать историю, то мы просто будем держать в памяти данные за нужный период и запускать новые версию джобов поверх них. Автор приводит пример что они в Линкедине таким образом держат в памяти 30 дней и для отдельных сущностей это может быть «терабайты».
http://radar.oreilly.com/2014/07/questioning-the-lambda-architecture.html
Звучит интересно, но пока не понял, как при каппа-архитектуре работают бекфилы? что делать, если надо пересчитать не 30 дней, а все данные за всю историю? | 324 |
| 11 | #послушано
🎈 Алексей Миловидов в «Запуск завтра» рассказал про то как начинал ClickHouse и к чему это всё привело
в 2008 это был просто конструктор отчётов для Яндекс Метрики, просто какие-то базовые отчёты на основе неагрегированных логов тогдашнего рунета. Потом была пауза в развитии и вернулся к разработке в 2011, чтобы в следующем году уже на основе Кликхауса вышла Метрика 2.0
Постепенно соседние отделы тоже интересовались возможностью быстро обрабатывать тонны логов и Кликхаус распространялся внутри Яндекса.
В 2016 решили выложить КХ в опенсорс — были опасения про безопасность, но плюсы этого решения оказались существеннее. А недавно КХ отделился совсем и стал стартапом с завидной оценкой и хорошими инвесторами. Развивают облачную версию и за несколько дней до подкаста запустили поддержку managed ClickHouse в GCP.
Понравился тезис Алексея что они стараются держать кодовую базу максимально простой — сейчас она порядка 800К строк против 2 млн у Postgres или MySQL. С определённого порога сложности вся структура перестаёт влезать в голову и скорость введения новых фич сильно замедляется. Чтобы в коде не оставалось непонятных костылей сбоку они регулярно переписывают или выпиливают совсем старые куски кода.
ссылки на послушать в канале подкаста
⌘⌘⌘
🎈 Антон Жирнов просветил «Подлодку» про SQL
интересная беседа на два часа про SQL — будет полезно как начинающим, так и «продолжающим». Прошлись по всем кажется основным темам, соблюдая баланс между широтой охвата тем и глубиной погружения в каждую.
Для себя повторил индексы, транзакции и узнал про безопасность. Понравилось тема с документно-ориентированными базами данных: сначала все побежали в nosql, а потом в Постгрес добавили поддержку json (не без помощи этого nosql хайпа), и теперь те же документы эффективнее делать в старом обычном SQL.
Антон сделал подробные таймкода в своём канале, не буду переписывать оттуда темы)
⌘⌘⌘
🎈 Иван Ямщиков и Григорий Бакунов обсудили что там с генеративными нейросетями и куда всё идёт
работа над кодом вместе с ChatGPT напоминает работу с джуном: ты ему говоришь что-то сделать, он приносит результат и потом ты это переделываешь «как правильно»
в будущем будет профессия «оператор Copilot» — можно будет не писать код, а писать инструкции для LLM-моделей, чтобы те уже дали нужный код. Это чем-то напоминает чернокнижников прошлого, когда те пытались заклинаниями вызвать демона для определённой работы.
такие операторы не заменят программистов полностью, но могут взять на себя часть каких-то (простых?) задач. При этом это и не джун программист — программисты останутся в соседней ветке развития.
по статистике порядка ~30% новых браков заключаются между людьми, познакомившихся в соцсетях. А поскольку используемые модели представляют собой черный ящик без возможности интерпретации результатов, то нельзя с уверенностью сказать, что нейросети уже сейчас не занимаются селекцией человеков, более склонных к залипанию в соцсетях 🌚
В канале подкаста есть ссылка на Ютуб, Apple Podcasts
#подкаст | 415 |
| 12 | Книжный клуб + Кабанчик = 🖤
Два года назад как начинающий и ответственный дата-инженер заказал оригинал книги Мартина Клеппманна Designing Data-Intensive Applications с Амазона. Но книга так и лежала у меня с тех пор, не смотря на рейтинг 5.0 и рекомендации со всех сторон.
И вот в рабочей флудилке заговорили про книжные клубы, я решил что это хороший повод и закинул идею совместно прочитать этот технический бестселлер.
План был максимальной простой: одна глава = одна неделя. Встречаемся каждый четверг, обсуждаем прочитанное, вспоминаем байки из опыта (если есть), находим аналоги в нашей инфраструктуре. И вот спустя 12 недель Кабанчик прочитан, книга исчёркана карандашными заметками, в заметках осталось 12 относительно структурированных конспектов.
В общем идею можно признать успешной: паблик комитент работает плюс в компании единомышленников читать веселее. Сами обсуждения тоже были полезными: приносил темы что остались непонятными, а коллеги подсказывали что упустил — профит!
Заметки на будущее: сложность материала возрастает к последним главам. В первых Мартин описывает базовые концепции и повествование в следующих главах строит уже поверх них. Последние несколько глав можно смело делить на два захода, потому как 50-60 страниц технического текста за неделю осилить уже сложновато.
Отдельно стоит отметить примечания к каждой главе. Мартин скрупулёзно собирал источники для каждого тезиса. В заметках можно найти научные работы, датированные начиная с 1960-х и до 2018 (года публикации книги). Для желающих копнуть глубже можно всегда обратиться к оригиналам. | 476 |
| 13 |  потрёпанный жизнью книжным клубом Кабанчик | 439 |
| 14 | Промпт-инженеры
Зацепила фраза Григория Бакунова (bobuk) про промт для GitHub Copilot (работает на ChatGPT):
> Для тех кто не программирует, посмотрите на картинку — вот так выглядит будущее программирование искусственного интеллекта.
Действительно эти ~25 предложений можно представить как ~25 абзацев кода для какого-то приложения.
Продолжая аналогию с программированием, можно вспомнить с чего начинается почти каждый урок — тот самый Hello world! И то же самое происходит с тем, кто впервые сталкивается с гот-моделями — их промты простые и односложные.
А вот продвинутые юзеры гпт-моделей через пробы и ошибки учатся улучшают свои промты и некоторые уже даже не помещаются на страницу. Чем не продвинутая программа уже?
Получается, придумали весь этот МЛ, чтобы не писать кучу IF’ов — и теперь пишем эти же ифы, только теперь на естественном языке. | 348 |
| 15 | студенты есть? там открыли конкурс на стажировки, где за деньги можно поконтрибьютить в разный опенсорс: CatBoost, YDB и наш любимый YTsaurus
https://foss.kruzhok.org/code-for-all | 470 |
| 16 | #послушано
доклад Ивана Ямщикова на TechTrain про практические применения МЛ — от банальных до продвинутых. Медицина, легал и прочие отрасли. В конце общее (позитивное!) напутствие.
> Какие сейчас перед нами сценарии развития искусственного интеллекта? Ждет ли нас еще одна «зима»? Как машинное обучение меняет рынки, общества и планету?
iTunes, YouTube
⌘⌘⌘
В яндексовый подкаст позвали двух директоров Такси (и одного таксиста-блогера). Поговорили об актуальном: распределение загрузки сервиса по часам и месяцам, цены на поездки, как внедряют новые фичи. Ещё из подкаста можно узнать, что СЕО Яндекс Такси регулярно таксует в Саратове (до чего работа довела человека!)
iTunes, YouTube
⌘⌘⌘
Спотифай делает аккуратный шажочек в голосовые помощники. Там взяли крутого диджея, заперлись с ним в студии и сделали персонального диджея для каждого пользователя Спотифай. МЛ-диджей объявляет следующие треки и иногда делает вставки с фан-фактами об исполнителе. Примечательно, что диджей интегрирован с рекомендательной системой и может комментировать почему та или иная песня попала именно в твой плейлист.
iTunes | 420 |
| 17 | деньги-денежки-деньжата
так-так-так, что тут у нас? это же зарплаты дата-профессий в Европе!
что может быть интереснее, чем залезть в карман к брату-инженеру и узнать сколько туда капает каждый месяц.
ребята собрали статистику по 500 вакансиям, сконвертили всё в доллары и сделали разрезы по синьорности, стране и компаниям.
⌘ что интересного увидели:
1. по синьорности: зп есть прямая корреляция на первых 6 лет карьеры, дальше всё по-разному
2. по локациям: в Берлина в среднем зп ниже, объясняют наличием там офисов Delivery Hero и Zalando, где зп чуть ниже рынка. А вот в Дублине, кажется, собрались сеньёристые ребята и там явный перекос зп в сторону высоких грейдов.
3. по компаниям: Delivery Hero и Zalando находятся где-то слева на распределении зп (см. п2 про них). А вот в Мете, Амазоне и Букинге есть выбросы по зп даже для мидлов — вот кому хорошо)
⌘ для нашего рынка раньше такое делали Хабр в 2021 и New.HR в 2019
за ссылку спасибо подборке от дата-кофе | 400 |
| 18 | короткой строкой про дата-инженерские вакансии в Яндексе:
1. открыта вакансия в Практикум. Судя по описанию, всё довольно стандартно: там собрать, сюда положить, сверху витрины; ждут кандидатов с 3+ годами опыта. Если я ничего не путаю, Практикум работает удалённо, а ещё там супер душевная команда ❤️
2. а ещё случайно узнал, что 4-5 марта (это уже ЗАВТРА!) можно получить фаст оффер в DWH Яндекс Маркета. Про требования к кандидатам всё написано общо́. Маркет использует подходы к двх-строению как у нас в Go, поэтому там должно быть круто. Я б сходил чисто по фану — часто перетереть за данные с умными людьми без каких-то обязательств 😉
3. ну и к нам в Доставку тоже ищут инженера. У нас YT (Hadoop) + Greenplum, свой etl-фрейморк, работающий data mesh и свой анкор-моделинг для дата-ценителей. Тут уже могу рассказать всё в деталях, если будет интересно. | 550 |
| 19 |  в каждом меме есть доля шутки — в далёком 2020 я присматривался куда пойти… и не пошёл в ML 🙃 типа ща я тут по-быстрому с аналитикой сперва разберусь, а там до мл уже шапкой докинуть! | 404 |
| 20 | Легенды базостроительства в подкасте от dbt
Mike Stonebraker занимается базами данных с 1970-х. Тогда он написал реляционную БД Ingress, за три года до того как Ларри Эллисон выпустил Oracle. После этого Майкл приложил руку к Postgres (название отсылает к Ingres).
Рассказал, как в 1990-х обратили внимание на колоночный тип хранения. Строчное хранение оптимизирует запись, в то время как данных скопилось много и начались проблемы со скоростью чтения — появилась необходимость в том, что стало называться DWH.
В 2005 они выпустили Вертику. Понравилась байка как они пришли показывать Вертику в большой тогдашний е-ком. Там был инстанс Оракла за миллион долларов, который обрабатывал аналитический запрос сутки. Команда Майка установила им Вертику, закачала туда их данные и тот же запрос отработал уже за секунды. Вот она вся прелесть DWH.
Ещё Майк очень сожалеет, что не выложили тогда Вертику в опенсорс — он уверен, что сегодня это было бы дефолтное решение для многих проектов.
Вообще, судя по Википедии, дядьке 79 лет! Он уже как полвека что-то делает полезное, написал несколько популярных движков бд и кажется не планирует останавливаться. Вот сейчас мутит очередной дата-стартап. Говорит, что ему скучно просто лежать на пляже =)
https://roundup.getdbt.com/p/ep38-a-romp-through-database-history | 367 |
