подкаст Data Heroes о релокейте и переезде в другую страну

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

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

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

Цены на жильё подскочили из-за возвросшего спроса (где-то звучат оценки типа в 3-5 раз).

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

Жителям Москвы тяжело привыкать к тому, что нельзя заказать продукты с доставкой за 15 минут или ждать такси больше трёх минут.

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

ссылки на подкаст-платформы в канале Left Join:
https://news.1rj.ru/str/leftjoin/617
https://news.1rj.ru/str/leftjoin/662

#послушано

Английский в вакууме не котируется

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

Поработав какое-то время, понял, что за всё время никто меня так и не попросил поговорить по английски или прочитать что-то. Так это не работает.

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

То есть я думал, что связь прямая:
английский → больше зарплата

А на самом деле она косвенная:
английский → изучаешь новое в первоисточниках → применяешь на практике → прокачиваешь навыки → больше зарплата

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

Есть ли смысл переезжать?
— Senior Software Vlogger

Посмотрел ёмкий ролик про релокацию айтишника в другую страну. Записал себе такие пункты:
• Для переезда нужно большая сумма: 5-10К $
• Снять жилье — как неместного попросят предоплату за 1-3 месяца
• Экономить не получится — местные-то знают где что и как, а вы — пока нет
• Две средних зарплаты — больше чем одна синьорская. Сколько членов вашей семьи будет работать? Если на текущем месте работают двое, а будет только один — это точно будет даунгрейд
• Внимательно выбирать страну по набору критериев (учитывая их динамичность)


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

Это был «нулевой» урок из курса «Вы приняты», который Дима делает совместно с Фёдором Брощёвым и Марьяной Онысько (под видео в первом комменте есть промокод)

Каюты с муми-троллями

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

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

Пока плыли, пришёл к тому что фичу с тематической каютой неправильно зарелизили в прод!

Допустим, на корабле обычных кают такого класса 1000, из них 10 с муми-троллями. При этом заполняемость парома не 100% (в непиковые дни по ощущениям ниже 50%), то есть «обычные» каюты вполне можно ротировать: заселять пассажиров в разные каюты при каждом рейсе.

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

Это как «горячая нода» в распределённых системах, когда данные между узлами распределены неравномерно и общая эффективность системы снижается.

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

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

🥸 короткий и дельный совет от Игоря Мосягина — добавлять эмоджи в отладочные логи, чтобы было заметнее

это из доклада на конференции SmartData — там сегодня community day, можно посмотреть доклады бесплатно 👀

Выпуск Data Coffee про собеседования

Три лида́ обсуджают как они проводят собеседования для инженеров данных:

⁃ Сколько по времени должно быть собеседование — нормально ли заканчивать их досрочно, если по кандидату точно «да» или точно «нет».

⁃ Сколько вообще может быть этапов у процесса найма.

⁃ Чем отличаются задачи для джунов, мидлов и синьоров. С какого-то уровня помимо основных инструментов (SQL+Python/Scala) требуется понимать и общую архитектуру (и альтернативные варианты с их плюсами и минусами).

⁃ Зачем сотруднику присоединятся к клубу собеседующих — прокачивает техническую насмотренность и помогает точнее сориентировать свой уровень относительно других.

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


Слушать в iTunes и Overcast
Ещё ссылки в канале подкаста

Очереди сообщений

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

До сих пор не сталкивался ни с Kafka, ни RabbitMQ, поэтому мне было интересно послушать. Что-то из выпуска записал (как мог):

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

⌘

В целом, чем-то похоже на базы данных: тоже запись и чтение. Иногда даже отдельные бд используют как очередь — в Яндекс GO используют Mongo в сервисе репликации данных от источников в DWH.

Отличие от баз данных: чтение — модифицируащая операция. Получатель сообщения подтверждает факт получения и брокер удаляет это сообщения у себя.

⌘

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

⌘

За чем следить во время работы:
⁃ работа под нагрузкой. При тестах всё может «летать», а под нагрузкой иногда появляются рекурсивные самозапросы и система сама себя дидосит.
⁃ длина очереди — она должна быть во вненяемых пределах. Очередь по определению ограничена (в конечном счёте — ресурсами системы).

⌘⌘⌘

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

в iTunes и Overcast

#послушано

Ещё из новостей подкастов: у Самата Галимова вышли два интересных выпуска в подкасте «Запуск завтра»:

1. про российский StackOverflow — как студент сделал сайд-проект в универе, получилось хорошо и это стало основной работой. А потом продал его основателю «основного» StackOverflow — легендарному Джоелю Спольски.
2. про язык Kotlin, который был признан Google основным языком для разработки на Android. Как(и зачем!) в 2010 году в JetBrains захотели сделать свой язык программирования на замену стагнирующей в то время Java. И причём тут Андроид.

Оба выпуска слушаются как аудио-книга — невероятная история с поворотами и техническими деталями. Тут вроде нечего конспектировать, надо слушать)

Закрывая тему подкастов: оказывается, у Max Beauchemin (Бьюшемин?) тоже есть «свой» подкаст. Макс — автор Airflow и Superset, а подкаст они делают от имени Preset (платная версия их опенсорсного Superset).

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

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

Если кто-то коллекционирует тематические подкасты, добавляйте к себе. А пока продолжаем наблюдение.

https://podcasts.apple.com/us/podcast/the-analytics-everywhere-podcast/id1612532253

Год в Яндексе

Тут в октябре случилась первая годовщина.

Из этого времени:
⁃ посидеть полгода в другом офисе от всей команды >_>
⁃ три месяца поработать удалённо из другого города
⁃ зайти на экскурсию в три офиса Яндекса в Москве
⁃ проехать мимо трёх офисов в других городах (жаль, не сложилось зайти — но бейджик был наготове!)
⁃ пройти два перфоманс ревью (пока вроде не выгнали)

Поначалу голова шла кругом от обилия внутренних инструментов, но вроде основные успел изучить (более-менее).

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

Потихоньку обкладываюсь мерчем: супруга даже шутит, что Яндекс Музей — теперь мой любимый магазин.

План дальше выглядит как-то так:
⁃ записаться в ШАД;
⁃ дорасти до собеседующего;
⁃ поработать из офиса в другом городе.

про Data Contracts в подкасте dbt

Chad Sanderson из Convoy (heavy modern data staсk users 🥸) делится своим кейсом: занимаются бизнесом, который truly ML driven, т.е. эм-эль не просто где-то сбоку, а без него не было бы самого бизнеса.

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

И так из других отделов тоже, общий тренд такой, что «мы не доверяем данным». Так начали развивать Data Quality (и до сих пор в этом процессе).

⌘⌘⌘

Ещё раз звучала аналогия, что датасеты (по крайне мере те которые «свои») — это как API. Подразумевается, что нельзя просто так вносить изменения без обратной совместимости.

С другой стороны, разработчики — не демоны. У них нет цели сломать процессы, нижестоящие по пайплайну данных. Они могут быть просто не в курсе, что ИХ ДАННЫМИ пользуется кто-то ещё.

С источниками надо коммуницировать. Причём делать это лучше заранее, а не так чтобы прибегать к ним с криками «ВЫ ЛОМАЕТЕ НАМ ДЕШИ!», когда уже всё сломалось. На это они могут резонно ответить, что типа с чего это вы вешаете продакшен-критичные зависимости без предупреждения, мы не подписывались на это.

Ещё обсуждали, что дата-контракты могут «подписывать» только со стороны источника. Это в ответ на реплику в дбт-шном Слаке, что бывают producer-side и consumer-side контракты. Участники подкаста сходятся в том, что пользователи могут только обвешать входные данные чеками и алертами, но влиять на них не могут.

Ссылки на послушать на сайте подкаста:
https://roundup.getdbt.com/p/ep-34-why-youll-need-data-contracts

#послушано

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

Опытом делились Семён Осипов из Gett, Ксения Томак из Dodo Brands и Сергей Бойцов; их и приглашаю послушать, получилось разносторонне, у всех свой опыт и итоговые советы получились довольно уникальными.

Ссылки где послушать в канале Left Join:
https://news.1rj.ru/str/leftjoin/841

«Бэкенд» бэкенда

Есть профессии, которые прямо можно оценить по вносимому вкладу — особенно ближе к сезону перфоманс ревью поднимаются вопросы тип «вот сколько Вася принёс денег компании?».

Как ни старайся, DWH таким аршином не измеришь. Только если вешать «счётчик входящих» и высчитывать % от оклада у всех кто пользуется нашими сущностями.

Получается, наша работа в другом — мы подносим патроны. Причём подносим патроны тем, кто сам подносит патроны. Мы в глубоком тылу. В чём же наша польза? Как её измерить?

Один из вариантов ответов, который мне больше всего нравится, — мы повышаем стабильность и скорость общей работы. Мы поддерживаем документацию, чтобы менеджеры могли быстрее найти как поджойнить зоны с тарифами. Мы сокращаем количество джойнов, которые нужно сделать аналитикам для ответов на свои вопросы (говорят, Женя Козлов предлагал такую метрику в Яндекс Такси).

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

Перекликается с тем, как Ваня-инженер писал про отсутствие провалов в противовес бешенному достигаторству.

И по совокупности всех этих показателяй мы должны выделяться на фоне «теневого DWH» (иначе, зачем нужен «официальный», да?)

Кто в прошлом году вёл себя плохо, тот в следующем будет писать SQL на кириллице 😈

картинка из чатика Data Coffee

О развитии как разработчика баз данных

Алексей Махоткин известен среди меня тем, что продвигает фреймворк проектирования (?) Minimal Modeling. В посте Алексей рассуждает о развитии как разработчика баз данных.

Интересно, что он не уходит в список необходимых утилит и фреймворков, а сосредотачивается на понимании бизнеса:

⁃ First, learn to speak the language of the business side. [..] also need to have a common language with stakeholders, such as data analysts and researchers, and especially with marketing [..]
⁃ Second, think about removing the organizational bottlenecks around data processes [..]
⁃ There are also some other activities that could help with reducing friction, such as establishing data provenance. [..]

Понравился тезис, что хранение данных, должно «оплачивать свою аренду» =)

Another thing I'd suggest keeping in mind: how much does the data cost? When your company stores values for a certain attribute (anything, say "the day of birth of the user"): how much does it cost to store all those days of birth, in dollars? Next question is of course: does this data pay the rent?

Кажется, у дата инженеров принят обратный подход: надо собрать с источника все доступные данные, желательно с сохранением истории изменений. И потом ещё у себя всё собранное разложить на две реплики в двух кластерах ^_^

Но это всё в «сырых» слоях. А вот дальше по слоям уже действительно протаскивается только нужное и скурпулёзно документированное.

https://minimalmodeling.substack.com/p/how-to-grow-as-a-database-developer

Необязательные код-ревью

Интересный подход применяют в компании Raycast — они решили отказаться от обязательных код-ревью и коммитить сразу в дев ветку. Ежедневно автоматика собирает внутренний релиз из этой ветки, чтобы проявить возможные нестыковки.

Приводят следующие доводы:
⁃ Ревью подрывает доверие, типа твоему решению не доверяют и за тобой приходятся проверять код
⁃ Баги случаются и после код-ревью, то есть это не 100% гарантия
⁃ Ревью отнимает время, а значит тормозит разработку

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

https://www.raycast.com/blog/no-code-reviews-by-default

И к заметке есть отдельные комментарии, где радуются за авторов и потом рассказывают почему так делать нельзя, и почему всё сломается.

https://news.ycombinator.com/item?id=27606066

И в комментариях приводят ссылку на ментальную модель про забор Честертона. Мол, не спеши удалять то, что сделано до тебя, пока не разобрался зачем оно нужно. «Не нужно» или «не знаю зачем нужно» — недостаточные аргументы. Если предположить, что делали не полные дураки, то надо для начала разузнать истинную причину зачем делали и уже судить по ней.

https://fs.blog/chestertons-fence/

Максимизация скорости разработки через ZDD©

К предыдущему посту Игорь Мосягин прислал релевантную ссылку — как Илья Лебедев 2 года назад внедрял в BestDoctor нечто под названием Zaeb*s Driven Development.

https://youtube.com/watch?v=8lSG028Z2Vg

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

Как было:
1. Фича-бранч у каждого разраба
2. Мерж-реквест, который ревьюился (сколько-то кем-то)
3. Все фичи спринта мерджились в релиз-ветку
4. Всё «регрессилось»
5. Мерж в мастер → прод

Как хочется:
⁃ очень частые интеграции кода
⁃ частые релизы
⁃ много тестов
⁃ автоматизировать что можно
⁃ not break things much

К чему пришли:
⁃ фигачить в мастер, к чёрту бранч
⁃ релизы по расписанию на кроне (неотвратимы как рассвет!)
⁃ тесты не блокируют релиз (хе-хе)
⁃ код-ревью не блокирует релиз (хе-хе-хе!)
⁃ боты говорят людям, что делать (посмотреть такой-то пр до HH:MM сегодня)
⁃ обвешали процесс метриками, которые прорастают в OKR
- по ночам на простаивающем железе гонялись времязатратные тесты

Общие подходы:
⁃ убираем ручной труд
⁃ сокращаем ментальную сложность — что можно перекладываем на машины
- много общаемся с коллегами, объясняя свои подходы =)

Мета ДВХ: ДВХ для ДВХ

Посмотрел доклад Жени Ермакова двухлетней давности о том как они делали МетаДВХ в Яндекс Такси. Отдельное удовольствие сначала поработать годик внутри, а потом посмотреть такое вводное видео как пришли к такому решению.

Суть доклада сводиться к тому, что логи использования ДВХ засунули в ДВХ как отдельный источник. Смоделировав опрятные модели, это позволило посчитать метрики и отслеживать насколько хорошо команды ДВХ справляются со своими задачами.

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

https://youtube.com/watch?v=EHmf0tTxd6A

Netflix Chaos Monkey

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

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

даже когда есть чёткие инструкции по восстановлению, только практика может отточить навык, а чтобы такая практика происходила регулярно, в Нетфликсе в инфру запускают МАРТЫШКУ ХАОСА (лайк за нейминг!).

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

в конце приходит рейд-босс — Chaos Gorilla — и вырубает целую зону в облачной инфре.

https://netflixtechblog.com/the-netflix-simian-army-16e57fbab116

DWH → Data Mesh

Рассказ Жени Ермакова как переводили DWH Яндекс GO на рельсы Data Mesh. Женя там явно ссылается на предыдущий рассказ ↑ о метриках ДВХ, поэтому лучше начать с предыдущего.

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

В мире разработки в таких случаях принято распиливать монолит на микросервисы, а на просторах DWH консалтеры из Thoughtworks в лице Zhamak Dehghani придумали парадигму Data Mesh. Это когда в DWH есть условно независимые архитектурные кванты с единой платформой и под общим федеративно-архитектурным присмотром.

На практике это выглядело как выделение команд в отдельные ДВХ. Мы съехали со своими етл-пайплайнами на отдельный «етл-сервис» с независимым циклом релиза. А потом постепенно забрали все свои сущности в отдельные схемы-домены.

Получается, раньше аналитики и менеджера Доставки носили свои хотелки в DWH Такси, а после разъезда им стало ходить ближе — появилось «своё» DWH, плотно погруженное в доменную область.

из недостатков:
⁃ пришлось перетащить кажется все сущности в другие папки-схемы. Некоторые по несколько раз >_< Не обошлось без сопутствующих проблем: очевидцы вспоминают процесс не иначе как «демонизация» (вместо официального «доменизация»)
⁃ при делении техническая экспертиза распределилась неравномерно между командами

в вопросах после доклада кто-то «из зала» обратил внимание на схожесть описанного Женей процесса на внедрение аджайла — поверим ему на слово =)

https://youtube.com/watch?v=XCnHS_lXHAA&si=EnSIkaIECMiOmarE

иллюстрация «как должен выглядеть Data Mesh» из той самой статьи от Zhamak Dehghani из 2020 года

https://martinfowler.com/articles/data-mesh-principles.html

сверху купол федеративного арх-надзора с документами-инструкциями

в центре слои-домены с выделенными командами

в основании — общая платформа для того, чтобы всё работало