🥸 про коучинг

наша встречу по наведению порядка в проекте через вопросы (два поста выше ↑) напомнила мне профессиональные коучинговые сессии — недавно я попробывал новый для себя инструмент для пары личных проектов.

роль коуча как раз в безоценочной помощи в наведении порядка в хотелках и стремлениях (= проектах). Получается это такой инструмент для диагностики — прикладываешь его к нужному месту, отвечаешь на его вопросы → профит.

ключевой фактор здесь именно в отсутствии оценки, т.е. коуч убирает себя как личность из процесса; он не оперирует терминами «хорошо» и «плохо» — только задаёт вопросы и пытается вместе с тобой найти твои конечные цели и приложить их к какому-то плану (а потом и к сделанным делам по этому плану)

по себе знаю, насколько это сложно не пытаться давать совет после каждой реплики собеседника (ведь я же ЗНАЮ КАК ЛУЧШЕ!!1)

я занимался с Димой Черненьковым и могу его смело рекомендовать. Дима — мой добрый приятель и по совместительству сертифицированный коуч (а ещё фанат кулинарии, спикер, участник подкастов и жонглёр примерно восьмью способами)

Тем, у кого нет возможности на работе побить об кого-то свои проекты или есть личные проекты где могла бы пригодиться помощь извне — тем может быть полезно познакомиться с Димой.

Начать можно с его канала, где встречаются советы о прокрастинации, заметки из книг и конспекты лекций (отдельный лайк за тематические мемы между)

🖤

Яндекс 🇷🇺 → Klarna 🇸🇪

2 года назад у меня был план

к тому моменту я поработал полгода джуном в Ривьере, потом ещё годик в агентстве Epoch8. Когда пришёл в Яндекс, по прикидкам в такой большой компании можно смело проработать года 2-4, продолжая открывать что-то новое.

помню как смотрел такими О_О глазами на коллег, которые уходили из Яндекса когда я только туда добрался. Смотрел и не понимал что за жизнь такая может быть после.

но потом что-то случилось 🫠

хотя изначальный расчёт был верным — к концу второго года я так и не успел заскучать; считай, только-только освоился и начал примерно понимать как тут что работает, что там по инфраструктуре и какие отделы за что отвечают.

это знание контекста накапливается постепенно и оно действительно стоит, чтобы его накапливать — сверху этого знания можно делать проекты, охватывающие не только твой отдел, но и соседние; плюс эффективно задействовать нужных людей из общей инфраструктуры.

начало получаться складывать кубики в простые башенки

решение вышло сложным. Было бы гораздо проще, если бы тимлид был самодур, денег бы не платили и проекты были скучные, да ещё и на легасной инфре. Но нет, тут они совершенно не «помогали» =)

это было дико интересное приключение и незаменимая школа. Дорогие коллеги на прощание накидали в шапку добрых слов и славно проводили.

ну штош, а теперь попробуем повторить всё то же самое на новой земле и в англоязычном окружении — stay как говорится tuned

✍️ первое задание для новенького

адаптироваться в новой команде сложно: свои обычаи, новая инфра, кодовая база и конвенции. Голова идёт кругом, пока всё вкуришь. И перед тем как начать приносить пользу команде, проходит какое-то время. Есть даже метрика — время до первого коммита в прод.

но у новичков есть одно преимущество — незамутнённый взгляд (и девственно чистое окружение!)

у старичков-то всё просто — когда-то давно они настроили себе окружение и с тех пор всё просто работает. они не имеют счастья пройти с нуля онбордниг и могут не знать что в документации что-то устарело.

И тут на помощь приходит свеженький и полный сил новичок! По ходу прохождения процесса онбординга, он может:
- проверить список доступов (все необходимые и достаточные)
- собрать неработающие ссылки,
- обновить неактуальные инструкции
- дополнить или добавить новые: что было непонятно именно ему

ведь так и так приходится всё это читать и тыкать каждую ссылку; остаётся только не забывать записывать к себе в заметки мысли об улучшении (это помимо обычного конспекта, хехе)

как у бойскаутов — поляна после тебя должна остаться чище, чем была до

а в дополнение к улучшенной документации, это ещё и показывает проактивный настрой — способность и желание брать ответственность за проект.

послушал как принципалы Thoughtworks обсуждают ai-помогаторы для написания кода.

самое простое описание — это продвинутое автодополнение. Как раньше курсор предлагал дописать несколько символов текущего слова, так сейчас предлагает дописать несколько строк.

дополнение пока что хорошо работают на уровне дописания отдельных методов, но не целых приложений. Хотя есть примеры в интернетах как люди генерят небольшие приложения с нуля. Но есть сомнения, что это всё-таки крайне ограниченная выборка среди всех пользователей.

и на качество таких приложений надо ещё посмотреть изнутри. Ведь хороший код должен был читаемым и поддерживаемым нашими белковыми коллегами (включая себя самого в будущем). однако, что работает сейчас хоть как то, через полгода будет работать лучше.

есть ещё подход в TDD — даешь на вход пачку тестов и генеришь к ним код; если проходит, то типа всё ок. Но тут надо смотреть на полноту и качество тестов. А что если и сами тесты тоже генерить?

на сайте подкаста есть транскрипт, возможность послушать и ссылки на iTunes и Spotify. На Overcast ссылку не даю, там чёт шерилка сломалась — пинганите меня в комментах если пользуетесь Overcast (просто любопытно)
https://www.thoughtworks.com/insights/podcasts/technology-podcasts/ai-assisted-coding-experiences-perspectives

Microsoft Excel в 1990 году

https://www.youtube.com/watch?v=kOO31qFmi9A

тв-реклама Экселя из 1990 года — как 30 лет назад люди воспринимали возможность вставить циферки в таблицу и красиво раскрасить.

особенно полезно посмотреть на это в контексте фразы «AI отберёт у людей работу» — ведь сам по себе АИ ничего отобрать не может (пока что, хехе!). Миджорни не знает куда вставлять свои чудесные креативы, а ChaGPT не понимает как использовать этот гениальный контент-план, который он только что нагенерил.

наверное, в 90-х люди тоже смотрели на Эксель с опаской, а кто-то может и вообще первый раз про него услышал лет через 10

но постепенно бухгалтеры, которые умеют пользоваться Экселем, стали цениться больше. Даже в вакансиях начали писать: требуется знание Microsoft Office

При этом ни эксель, ни майкрософт ни у кого работы не отобрали

чтобы делать свою работу хорошо, важно вовремя о себе позаботиться. Не смог пройти мимо — Ася написала годную и актуальную инструкцию как правильно болеть.

Сейчас многие болеют. И мне хочется чтоб все болели правильно

Немного рандомных мыслей
🌿Предсказуемость важнее результативности.
Я понимаю, хочется орать, что компания платит за результат, и в мире кровавого капитализма человек - лишь функция. Но мое мнение иное. В долгосрочной перспективе важнее не то сделана задача сейчас или нет, а то как эта задача встроена в жизненный цикл компании. То есть, надо ли искать ресурс для постобработки вашего труда сейчас или потом. Важно вовремя перераскидать нагрузку на других людей, закрыть другими людьми горящее, отменить/подвинуть негорящее.

🌿 Намного хуже когда человек умирает и из последних сил работает. Во-первых, это неэффективно. Во-вторых, болезнь возьмет свое. Либо в непредсказуемый момент времени все таки кончатся силы работать, либо время низкой эффективности растянется на длительное время

🌿 Резервной копии себя нет. Кажется, что мир рухнет, если ваш отдел не выполнит какие-то сверхважные планы. Но на деле этот мир рухнет только если вы отъедете в мир иной.

🌿 Чтоб себя успокоить вспомните про bus-factor. Если в вашей компании не закрыт риск, что вас(или любого другого участника команды) может сбить автобус, значит таково решение руководства. Надо позволить руководству вкусить последствия решения, а не прекрывать их собой и своим здоровьем.

🌿 Ну и последний аргумент социальный. Хватит делать вид, что это нормально работать на больничном или работать сверхурочно, если вы на это не подписывались. Это всё нормализация какой-то фигни, которая вредит всем, кто за ней наблюдает.
У вас в компании стажер? Он будет уверен, что так и надо делать. Руководитель тоже легко перестанет считать это подвигом и начнет считать нормой, что все должны работать в любом состоянии.
Не надо так с собой. И не надо так с другими.

Ну и будьте здоровы🧡

🦆 Zero ETL?

на той неделе почти случайно попал на митап от Couchbase, где они рассказывали насколько их решение быстро, надёжно и экономит косты на скейле. Показывали насколько легко и быстро данные перекидываются между операционными и запасным кластерами в разных зонах.

Помимо репликации в бекап, данные так же могут около рейалтайм заливаться в «аналитический кластер». Типа рядом с OLTP кластером разворачиваешь такой же OLAP и пускаешь туда орду аналитиков, чтобы они делали свои SELECT * за всю историю. Заверяют, что это работает ого-го.

Плюс к тому, если я правильно понял спикера, то в репликацию между кластерами можно вставить кастомную js-функцию, которая будет налету преобразовывать схему из операционной в аналитическую (сразу делать тебе дата-волт, а?)

типа одна база to rule them all. С одной стороны у вас приложеньки и АПИ, а с другой — МПП и аналитика. Звучит как магия.

Кажется, что-то типа этого https://docs.couchbase.com/server/current/learn/architecture-overview.html

> The Analytics Service helps analyze JSON data in Couchbase in real time, without the need to extract, transform, and load (ETL) the underlying operational data into a separate system.

⌘⌘⌘

Помню как я залипал на график в мониторинге Кликхауса, где было видно как на три машины в кластере в параллель заливалось N топиков и всё это под капотом одинаково реплицировалось на все машины. Мне казалось магией, что оно как-то под капотом само обкашливало наши ежедневные дата-инженерские вопросики: а-ля оперативно захватить последний инкремент, идемпотентно его записав.

⌘⌘⌘

И сегодня вижу анонс от AWS, где они бьют в то же место:

> Within seconds of transactional data being written into Amazon Aurora, zero-ETL seamlessly makes the data available in Amazon Redshift, eliminating the need to build and maintain complex data pipelines that perform extract, transform, and load (ETL) operations.

https://aws.amazon.com/rds/aurora/zero-etl/

типа мы вам сам переложим ваши данные из вашего (нашего) MySQL/PostreSQL в замечательный Redshift.

Получается, можно будет из коробки селектить данные в операционных моделях как есть, зато в около реалатайме. Звучит неплохо для каких-то кейсов.

🤔 Чего не хватает в Zero ETL?

разминаю мозги, пытаясь понять для чего этот их zero-etl ↑ будет хорош, а для чего не очень.

+

из позитивного: я бы не отказался, если бы автоматика взяла на себя базовый сценарий «сделай мне данные как в источнике, но в двх». В компании всегда найдутся потребители и задачи, для которых этого будет достаточно (тем более с секундными задержками-то!).

либо на ранней стадии, когда двх ещё нет, но селектить прод-данные в операционной бд уже больно — клик-клик в админке! — и рядом развёрнут отдельный кластерочек для полутора аналитиков.

в целом, похоже на ещё один инструмент в ящике дата-инженера.


-

Старший коллега, которому я с горящими глазами рассказывал как эта автоматика заменит всё двх, смотрит на это всё крайне скептически — мол, проблема таких магических подкапотных систем, оно всё работает пока работает; а когда перестанет работать будет непонятно как его чинить.

Плюс остаётся вопрос моделирования данных. В тех немногих проектах, где я успел поработать, модель данных в хранилище отличалась от операционной. Что логично: их в принципе дизайнили под разные задачи и разное окружение.

И что там с изменением схемы данных? что будет с этой хвалёной магической репликацией, когда на бэке решат удалить-добавить-поменять полюшко?

Ещё в голову приходит бекфил: вдруг настолько повезло, что захочется перезалить данные с источника ещё раз. Эт как тут?

Ну и данные из стороннего АПИ эта штука тоже не затащит конечно. В любом случае придётся рядом поднимать дополнительно ещё что-то, чтобы покрыть весь спектр задач.

в общем, с дивана ничего не понятно — надо пробовать (желательно сначала на чужой системе!)

Телеграм — настоящая соцсеть

в чём главная проблема канала в телеге? дорогу туда найдёт лишь тот, кто там уже был, хе-хе

просто в отличие от фейсбуков и тиктоков, в телеге не было механизма дискавери новых каналов; чтобы новый читатель узнал про канал, он доложен был его сам найти, либо ему кто-то его прислал — пошерил в другом или прислал лично

соответственно, чтобы канал рос, нужно чтобы его репостили

вокруг выросла целая индустрия «давайте включим ваш канал в подборку» или более креативные и интересные стратегии типа «перестрелки»

авторы каналов в надежде выдавить ещё пару капель конверсии ставят в конце каждого поста ссылку на канал (@data_days !), ведь иначе при репосте невнимательный читатель может не отличить репост от оригинального контента (и не подпишется на исходный канал!)

и вот теперь тёмное время окончено и да начнётся перекрёстное опыление релевантных каналов — для каждого канала Телеграм сделал сториз подборку похожих

я посмотрел для @data_days и надо сказать, что с компанией мне крайне повезло — все замечательные как на подбор. Сначала подумал, с нашей темой всё было довольно просто: достаточно пройтись регуляркой по названию и выделить всё со словом data 🤣 но судя по каналам других тематик, там под капотом всё-таки что-то сложнее

осталось только достать эту функцию поближе к пользователям, а не прятать за три клика (почему про это не пишут из всех каналов как было с релизом сторис??)

призываю затестить на всех своих каналах и поискать похожие

ну вы поняли, @data_days

оставлю тут гифку из официального блога телеграма как найти эти Similar Channels

(в комментах подсказывают, что на Андроид и в веб версии пока не раскатили)

Kafka is dead, long live Kafka

https://www.warpstream.com/blog/kafka-is-dead-long-live-kafka

два выходца из Datadog накидывают на Кафку. Ну, точнее не на саму Кафку, а на окружение, в котором крутятся современные инсталляции.

дисклеймер: сам я Кафку не варил, шарды не перебалансировал и патриции не восстанавливал; но кажется я понимаю спектр проблем, на которые указывают авторы, и мне в целом нравится что они ставят под вопрос дефолтное решение. И было интересно для общего кругозора прочитать что там их не устраивает и как же сделать лучше (по законам жанра в конце статьи [коммерческое] предложение).

авторы пишут, что сама по себе Кафка всем хороша и с момента релиза зарекомендовала себя как дефолтный способ реалтаймового перекладывания байтов. А заметка про техническую базу распределённого бревна лога стала культовой

Базовых проблем две:
- большие потоки данных между внутренними узлами
- много ручного труда для поддержки и развития

Изначально Кафка крутилась в датацентрах Линкедина, где внутренний трафик не тарифицировался. Текущие реализации работают в основном в облаках, где это стоит денег. Помимо прямого трафика, есть ещё внутренняя репликация в целях отказоустойчивости.

понравился кусочек про Accidental SRE; мол, вот в чём приходится разбираться, если решил завести себе Кафку:

1. Kafka (brokers, coordinators, watermarks, etc)
2. ZooKeeper (or KRaft)
3. Leader elections
4. Partitions (how many partitions do I need? Unclear, but better get it right because you can never change it!)
5. Consumer groups
6. Rebalancing
7. Broker tuning
8. Client tuning
9. etc

🏦 Klarna — куда я попал

если коротко, то Klarna — это сервис отложенных платежей, т.н. BNPL — buy now, pay later (or never lol). Самоидентифицируют себя как банк, что ведёт за собой дополнительное регулирование. Начинали из Швеции, постепенно вышли в некоторые страны Европы и потом ещё в Штаты.


📍команда

из Штатов, кстати, наши тимлид и архитектор. Поэтому дейлики у нас в середине дня (но при этом Уэса всегда можно приветствовать «доброе утро!» :-)

остальная команда тоже довольно мультинациональная и распределённая: Германия, Румыния, Италия и, собственно, Швеция.

компания себя позиционирует как международная, поэтому вся документация и коммуникация внутри — на английском, включая все массовые встречи.


📍спектр задач

тут самое интересное — я как-то не догадался об этом спросить на этапе собесов (сейчас понимаю, что у меня в голове были другие дефолтные предположения)

после нескольких онбордингов, под конец второй недели я обнаружил себя в команде разработки одного из микросервисов — ребята пилят серивис на TypeScript для управления аффилированными ссылками и их дальнейшее отслеживание.

ну штош, не зря читал про Data Mesh — буду пробовать себя как выделенный инженер данных в отдельно взятом дата-продукте

я не так часто собеседуюсь и ещё реже меняю работы, поэтому ещё не накачал умение задавать правильные вопросы на этапе знакомства и выбора команды; иначе бы я вряд ли решился пойти в команду разработки микросервиса единственным дата-инженером :-D


📍 техностек

в основном всё работает на AWS — данные с источников заливаются в S3, откуда их можно селектить через Athena. Или заливать дальше в Redshift.

С последним знакомые проблемы — на вход большая очередь, в которой таски могут простоять день или больше; плюс встречаются жалобы «всё тормозит, невозможно работать!!11» — кластер-то коммунальный.

узнал новую для себя фишку: Redshift умеет селектить «внешние» схемы напрямую из S3. Тогда можно обойти узкое место в виде переливки данных, но и скорость чтения будет ниже.

DataHub в качестве дата-каталога.

на оркестрации централизованный Airflow. Даги генерятся из ямликов через воркеры на Jenkins. Из коробки умеет делать SQL в тех же Athena и Redshift, плюс джобы на AWS Glue.

видел записи докладов других команд, где народ настраивает себе стриминг через Flink и Firehose. Видимо локально в командах тут может встречаться всякое.


📍 дата-архитектура

за первые 8 недель успел только погрузить в дела команды и немного мониторю чаты поддержки избранных команд, поэтому сложно экстраполировать на всю компанию

я кажется упоминал тут «теневой двх» — это когда рядом с «официальным» красивым двх с дк-чеками, документацией, конвенцией и т.д. аналитики собирают «на коленке» свои пайплайны. Каждый делает как умеет, поэтому рядом могут лежать почти одинаковые таблицы из одних источников, но при этом данные в них будут разные.

у нас в команде есть только «теневой» двх :-D чисто собрали витринки на своих таблицах. У каждого аналитика — свои. При этом свежесть данных по некоторым источникам — до пяти дней. Что-то неладное в датском королевстве. Будем разбираться.

пока что не видел признаков какой-то централизованной конвенции по неймингу или рекомендации по раскладыванию данных по слоям. Может ещё не докопал, или существуют только локальные внутри команд.

с одной стороны без единой архитектуры почти всё пишешь с нуля, а с другой — много свободы и, соответственно, большой потенциал для роста и реализации.

Data Modeling is Dead! Long Live Data Modeling!

https://youtu.be/OCClTPOEe5s

увидел у Семёна ссылку на рассылку про моделирование данных от Joe Reis, автора Fundamentals of Data Engineering — книги, которая вроде как пробилась в топы Амазона сразу по нескольким категориям.

помимо книги и рассылки, нашёл небольшой доклад от Джо на тему того же моделирования.

В целом, от доклада сложилось впечатление «дед ворчит на облако», но кажется смысл сводиться, что мы стали забывать что такое модели данных и в принципе забивать на этот этап. Остаётся только поверить его обширному кругу общения — у него своё консалтинговое агентство, он много катается по миру с докладами, поэтому повидал и услышал всякое там; и даже сам Andrew Ng пригласил делать его делать курс вместе.

Автор приводит две книги по моделированию данных, с которыми стоит познакомиться. Мне тема близка и актуальна по работе, поэтому вторую книгу я уже заказал — посмотрим что там к чему (правда, тот же Кабанчик у меня лежал года полтора прежде чем я его прочитал с книжным клубом >_> )

В конце автор призывает вернуться к моделированию данных: ведь когда, если не сейчас — все эти ваши ллм-ки поломаются без красивых данных на входе.

🎧 Father of «DataWarehouse»

продолжая копать под этого Joe Ries, нашёл у него подкаст. Полистая прошлые эпизоды, нашёл там никого иного как Билла наше-всё Инмона. Оказывается Билл его менторит (вот это размах!).

эпизод слушается как смесь баек из склепа и триллера: всё на одном дыхании — хотя уже заранее знаешь кто убийца, но до самого конца было непонятно как оно всё придёт к этому.

первую программу Билл написал в 1965, за свою карьеру успел пописать на ассемблере, паскале и коболе. Застал программирование на перфокартах; когда несёшь стопку таких карт к «компьютеру», то главное их не рассыпать — иначе придётся вручную восстанавливать и проверять их порядок >_<

сейчас мы (по крайней мере мы в нашем уютном инфопузыре) рассматриваем хранилище данных как нечто само собой разумеющиеся. Однако, в 80-х всё было далеко не так радужно. В начале было слово OLTP и только транзакционные базы данных.

Когда Билл читал свои первые лекции про «новый инструмент для аналитики — DWH», первые 3-4 года его слушателями были исключительно маркетологи, и никого из технических профессий.

После докладов на конференциях ему даже приходили гневные письма, чтобы он заканчивал со всей этой ересью про OLAP и «хватит тянуть отрасль назад»

тогда топовой компанией была IBM (которая продавала свои мейнфреймы по 2-3 миллиона при себестоимости в $165), и они там были настолько против этого вашего OLAP, что просили не упоминать в одном предложении OLAP и IBM.

типичная проблема больших корпораций тогда — понять сколько именно они зарабатывают. Когда у тебя 10 000 программистов и практически бесконечные бюджеты, то даже такие ресурсы не способны приблизить к ответу; потому что данные размазаны по всем отделам равномерно и нет одного места, где можно было бы всё свести в единый отчёт.

и вот когда первая компания сделала у себя DWH, это дало такой прирост эффективности их аналитиков, что по отрасли пошли слухи о «новом секретном инструменте — DWH»; и сразу все захотели к себе такое же и на лекциях Билла стали появляться технари.


#подкаст в Apple Podcasts и Overcast

первая неделя с CoPilot

тут в нашей Кларне держат фокус на AI. Может где-то и перегибают в горячке, но тем не менее всем разработчикам оплатили лицензию на CoPilot и неустанно напоминают её активировать и установить плагин свой IDE.

последнюю неделю дорвался наконец до питонячего кода и таки активировал-установил копайлот в свою Идею. Делюсь ощущениями по итогам первой недели с аи-помошником. Наверняка тут есть прожженные промпт-инженеры и гпт-мастера — не судите строго (а лучше приходите в комменты!)


+++

мне понравилось как копайлот справляется с питоном и конфигами терраформа: предлагает дополнения исходя из контекста файла и непосредственного окружения.

в одном месте писал функцию для дебага и нужно было создать словарик с мок-данными на вход; и вот тут копайлот мне предложил готовый вариант ровно с теми полями, которые ожидает функция ниже. Топчик!

можно дополнять строки или генерировать целые функции. На функциях при этом получается такой микро-паттерн: пишешь в комменте что должна делать функций, копайлот тебе её генерит, а изначальный коммент-промт идеально подходит на роль докстринга к этой новой функции

в VSCode функциональность ещё шире: можно просить пояснить за целый файл или кусок кода; плюс есть отдельный или инлайн- чат, где можно отдельно поговорить с ботом по душам. Тут спасибо Майкрософту.

− − −

не получилось помощи с ридми — видимо, не хватает контекста для релевантных подсказок. Пока писал короткий ридми с основными моментами нового проекта кажется ни один промт не подошёл — всё как-то мимо. Но я писал больше по-программистски: короткие сухие предложения с примерами кода и ссылками на папки-файлы.


⌘⌘⌘

ещё тут у нас проводят еженедельные встречи любителей помучать чатжпт. на одном ребята показывали как с нуля можно написать простой скрипт с помощью копайлота.

в итоге у них получилось чисто через промты и автодополнения написать скрипт на полторы страницы, который парсил рядом лежащий .csv и выводил агрегат по заданному вопросу

вывод:
- можно писать код на незнакомом языке (мама, я — фулстек!)

- в среднем код с копайлотом получается лучше документированным: комменты с промтами можно оставлять как просто комменты и в целом просить его написать первую версию докстринга

- копайлот можно использовать как резиновую уточку, которой будешь объяснять свои проблемы: может повезёт и найдёшь пробел в рассуждениях в процессе. В любом случае иногда полезно явно формулировать свои мысли где-то помимо своей головы


⌘⌘⌘

на другой такой аи-встрече аналитик показывал как с помощью чат-гпт и копайлота написал пайтон скрипт, который парсит расшифровки после встреч, выводит ключевые идеи и экшен-поинты, плюс формирует элементы для графа связей в общую базу знаний

при этом аналитик говорит что «не знает питон»


⌘⌘⌘

товарищ рядом со мной тоже с помощью гпт написал («скомпилировал»?) в ноутбуке код, который берёт гугл-таблицу, что-то там трансформирует, генерирует пдф и отправляет результат в нужный слак-канал.

при это товарищ тоже аналитик и не шарит за всякие там апи, функции и вызовы — но при этом благодаря гпт скриптик у него работает и приносит свою пользу.


⌘⌘⌘

в Яндекс Доставке тоже аналитик рассказывал как писал с помощью жпт скрипт для бутстрапа сплит-тестов и потом ещё итеративно оптимизировал его производительность, чтобы полностью утилизировать все ядра данной виртуалки.


⌘⌘⌘

в целом, выглядит как ещё один инструмент в наборе: python, sql, chatgpt …

а чо у вас по копайлотам по работе? применяете? полезно?

🤓 испытательный срок — тю!

прошло полгода в Кларне, объявили что я молодец и мой временный контракт превращается в тыкву настоящий бессрочный взрослый трудовой договор. Внутренний самозванец громко и глубоко выдохнул.

понял, насколько спокойно было в России — кажется, чтобы тебя уволили надо очень сильно постараться. Особенно в нашей уютной айтишечке.

хочется немного порадоваться, потому что было всякое за эти шесть месяцев: расскажу ниже. я так и не научился вести прямой репортаж, поэтому ниже краткий пересказ.

⌘ на второй неделе моего пребывания местный профсоюз предупредил компанию о забастовке — они хотели подписать коллективный трудовой договор. Последний раз про забастовки я слышал из телевизора ещё при Ельцине. А тут это как бы обычный инструмент профсоюзов.

⌘ через месяц НЕ полетел в Лондон на офсайт сходку нашего департамента — не успели сделать вовремя визы, хотя билеты и отель был уже заказан. Почувствовал (виртуально) размах активностей компании. Ну и виза осталась >_>

⌘ перед новым годом наш департамент расформировали (не говорите супруге!) — помню как прямо на встрече после объявления кинулся смотреть внутренние вакансии. Нашему отделу повезло, мы целиком перешли в другой департамент. Хорошо когда отдел напрямую генерирует прибыль (я говорил, что попал в команду аффилированного трафика?) Другие коллеги отправились во внутренний competence pool в поисках подходящих вакансий в других департаментах компании.

⌘ где-то в этот же момент в Спотифае буквально через дорогу сократили 1500 человек. Поэтому было довольно тревожно. С одной стороны, в Кларне «прямых» сокращений не было (в этот раз), но с другой — меня-то и сокращать не надо было, можно было бы просто не продлить рабочий контракт.

⌘ чтобы записать сына в детский сад, спарсил емейлы ректоров с сайта коммуны, чтобы сделать холодную рассылку с вопросом можно ли получить у них место и сколько людей в очереди к ним прямо сейчас. яжпрограммист! Чтобы отранжировать сады, добавил расчёт расстояния по гео-координатам до нашего дома. 13 писем отправлено, 4 ответа получено, одно место предложено.

⌘ сходил на митап Coachbasе в местном офисе Google. Послушал про базы два-в-одном — как они с одной стороны держат транзакционную нагрузку, а с другой не боятся сотен аналитиков с их select *

⌘ слетали семьей в Милан за €100 на человека (спасибо Ryanair). И город посмотрел, и поработал там из местного офиса. Развиртуализировался с коллегой. Плюсы большой компании и распределённой команды. На очереди Берлин и Бухарест.

⌘ помимо отменённых самолётов в Россию ещё закрыли сухопутную границу между Питером и Хельсинки, так что и без того весёлый трёх-сегментный маршрут домой превратился в четырёх-сегментный: Стокгольм → Хельсинки → Таллин → Питер → Москва. Удивлял коллег на стендапах вступлением «из какой страны выхожу на связь в этот раз».

⌘ залетел перед работой на дата-завтрак от Snowflake с участием dbt labs. Я думал, что и те, и другие дальше штатов не заглядывают, а оказывается у них тут есть офис и люди. Правда, судя по вакансиям, только сейлзы =) Послушал как Эриксон строит универсальный датамеш (уже как год). Мне конечно до таких масштабов далеко, поэтому просто довольствуюсь кружкой и блокнотом со снежинкой ❄️

📓 Infrastructure as a Code

будучи начинающим дата-инженером в Эпохе довелось первый раз сетапить дата-инфру с нуля для нового проекта

я тогда уже чуток представлял из каких «кубиков» должна получиться система: где-то должны быть пайплайны, где-то храниться данные и в итоге желательно из всего этого сделать дашборды.

с хранением всё понятно — был GCP и значит всё льём в BigQuery, там будут жить наши таблицы, аккуратно разложенные по слоям.

осталось поднять Airflow, который, собственно, и будет всё раскладывать по слоям, а ещё Metabase, где будут жить все дашборды.

я долго смотрел на этот космолёт приборную панель управления облачными ресурсами: столько там всяких разделов что сложно понять с чего начинать. В итоге как-то нашёл docker registry с понял куда пихать ссылки на docker hub из соответствующих туториалов.

где-то там же осознал, что Airflow и Metabase надо где-то хранить свои данные типа юзеров и истории, а значит помимо общего хранилища им ещё понадобится и своя отдельная постгря

в итоге я что-то там накликал и оно даже заработало (через стопицот итераций, естественно!) — открывался интерфейс Метабейза, там можно было зарегаться и накликать себе деш с данными из BQ

я был дико горд собой. не иначе как «Ты девопс, Гарри!». Всё-таки первый проект в облаке, это вам не в тапки это самое

показываю Андрею — нашему основателю и по совместительству техдиру. Он посмотрел так скептически. Допустим, говорит, красивый урл для админки вместо циферок айпи мы настроим, ок. Но вот зачем тебе три медиум инстанса ЕС2 для одного метабейза с полутора пользователями? но ладно, можно скейлнуть вниз — не проблема. В целом годиться для начала! Показывай теперь, говорит, свои Helm чарты, посмотрим что там как.

Так я узнал про подход infrastructure as a code.

всё, что я тогда тыкал мышкой через облачную админку, правильные ребята делают через код — в специальных конфигах (чартах) расписывают желаемый результат и потом одной командой раскатывают это на сколько угодно машин.

ведь натыканное через админку неудобно поддерживать — можно быстро получить результат, но сложно его повторить или перенести на другой проект; так же сложно проверить новую правки или откатить последнее обновление — как теперь вспомнить что там было натыкано.

с кодом же всё чётко: каждое обновление — пулл реквест. Явно видно предлагаемые изменения. Легко встраивается в CI/CD пайплайны. Раскатывается на одну или тысячи машин — неважно.

🐭 постоянство в достижениях

взять, например, шефа в ресторане. недостаточно один раз приготовить божественный рататуй, а всё остальное время подавать посредственную яичницу.

должно пройти какое-то время, чтобы «слава закрепилась»; нужно, чтобы люди приходили, восхищались твоим рататуем, приходили снова и снова, а потом всем рассказывали, что лучший рататуй — только у вас.

если приготовить вкусно только один раз, то такого эффекта не получится. Первый раз кому-то попадётся божественный рататуй, а на следующий — будут только яичницы. Земля не остановится, конечно, но и звезду мишлена за яичницы не дадут.

вспомнил об этом, когда задумался о перфоманс наших ревью. Раньше мне казалось, что если я один раз затащил, то меня можно смело повышать до синьора! но теперь понимаю, что синьор — тот, кто планомерно перфомит на должном уровне.

При этом для него просто поднимается дефолтная планка качества работы — он не выжимает из себя 146% эффективности, он просто «бежит в комфортном для себя темпе» и дыхание не сбивается.

Для него приготовить божественный рататуй — это ежедневная рутина, а не достижение.

открываю для себя семейство продуктов Kinesis от AWS. Всё вместе оно решает дата-стриминговые задачи, но чисто по названиям не понять чем Streams отличаются от Analytics и зачем там ещё Firehose.

посмотрев три обзора на ютубе, ответственно заявляю вот что я узнал:

🟣 Kinesis Streams — типа топиков Кафки. Можно несколько консьюмеров на топик, есть ретеншен полиси для записей внутри — т.е. чтение на консьюмере управляется офсетом.

🟣 Kinesis Firehose — по сути коннектор, можно туда паблишить евенты и оно из коробки может писать во все основные тулзы AWS. Нельзя много консьюмеров.

🟣 Kinesis Analytics — под капотом это Managed Flink (почему нельзя было так назвать сразу?). Умеет в разные стрим-трансформации: джойнить потоки, анализировать налету, работать с разными окнами.

к Streams и Firehose можно присобачить Лямбду на обработку входящих событий — на каждое событие или батч будет инициироваться инстанс функции и выполняться её код.