#люди

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

Пресловутая “мудрость” появляется, как ни странно, вместе с “сеньорской заебанностью”, когда молодой энергичный заряд постепенно ослабевает, и инженер становится… медленнее. Меньше отправляет pull request’ов в день по сравнению с коллегами, меньше производит дизайн документов, тише ведет себя на встречах и так далее. Это вовсе не значит, что инженер потерял в производительности! Скорее инженер понимает, что здоровье у него одно, опыта у него о-го-го, а 25-летних людей по скорости переплюнуть просто невозможно.

Но причинять пользу предприятию надо, и инженер начинает работать эффективно. Находит дешевые и быстрые имплементации или вообще избегает их - ведь лучше всего работает тот код, который не написали! Делегирует задачи, опираясь на сильные стороны своих коллег (про это расскажу отдельно), доверяет им принятие решений в определенных областях и этапах; выбивает у своего руководителя человеческие ресурсы, чтобы не тянуть проект в одиночку; и начинает все чаще задавать нелюбимый всеми вопрос “А зачем?”. Инженер уже не следит за бесконечным потоком новых фронтенд фремворков и очередных витков эволюции в индустрии, потому что он уже опоздал их изучать, да и они все равно каждую неделю новые.

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

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

#анонсы

4-ого июля буду выступать на HighLoad в Сербии, рассказывая о том, как можно сделать Redis строго-консистентным в кластерном режиме.

Буду рад встретиться очно с коллегами, кто окажется там же в те же дни. 🙂

#люди

Питер Друкер, известный экономист и автор множества произведений в области управления, в своем труде The Effective Executive дает следующий карьерный совет: “Build on strengths, not weaknesses.”

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

Что же касается самого совета, то он полезен не дебютантам индустрии, но опытным кадрам, которые спустя Х лет решили сменить свой карьерный курс. Рекомендую не выбрасывать за борт накопленный багаж знаний и опыта.

К моменту моего трудоустройства в Убер, я поставил себе задачу перестать опираться на AWS, потому что чувствовал, что некий порог уже достигнут. В какой-то мере это удалось - теперь я занимаюсь бекендом, но сказать, что теперь бекенд стал моим основным навыком будет как минимум наивно. Мозгом я все еще сисадмин инфраструктурщик, который проектирует системы из расчета, где и как могут отстрелить компоненты или как тяжело их обслуживать. Опыт работы с AWS дал мне этот и много других поднавыков, которые и стали столпом моей экспертизы: анализ откупов и выбор наименее худшего сценария; умение договариваться; коммуникативные навыки и навыки презентаций; техническое письмо, и так далее. На этих качествах я и строю свою карьеру дальше, потому что в них я силен и могу конкурировать.

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

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

#машины_разное

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

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

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

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

​​#жиза

В Амстердаме стоит Королевский музей, габаритами и наполнением словно Пушкинский в Москве. Внутри он разделен на несколько эпох нидерландской культуры и искусства, от деревянных церковных статуэток святых до легендарного автопортрета, тогда еще “двуухого”, Ван Гога и знаменитого “Ночного дозора” Рембрандта, вокруг которого построили стеклянный саркофаг.

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

Моя любимая картина там - "Испуганный лебедь" Яна Асселина, про работу которого я узнал из нидерландского мистического триллера “Арес”. Лебедь олицетворяет Яна де Витта, защищающего тогда еще Голландию от “сущего зла”, которое изобразили в виде собаки сутулой.

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

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

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

#машины_aws

Для CloudFormation был разработан линтер cfn-lint, который на базе разных правил проверял шаблон на вшивость. Одной из моих любимых фишек этого линтера была возможность написать свое правило на том же языке, что и сам линтер, т.е. на Python.

А раз для написания правила используется верхнеуровневый язык программирования, то положить в это правило можно буквально все что угодно. Автор помнит времена, когда он злоупотреблял Boto3, чтобы в рамках правила делать вызовы на AWS API и делать более точечные проверки, например, если hardcoded ARN ссылается на существующий ресурс.

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

И вот я в очередном туре по кишкам CFN, изучая расширения, нашел расширение Hooks. Hooks проверяют разные типы ресурсов на соответствие определенным правилам, но в этот раз правила проверяются на стороне самого CloudFormation. Может показаться, что это бесполезное дело, ресурс дешевле проверить до развертывания, а не во время развертывания.

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

Но для этого нужно побороть сначала свою лень и написать много правил на все случаи жизни. 🙂

#пятничное

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

https://www.humanornot.ai/

Один сеанс игры занимает всего 2 минуты, долго переписываться не получиться. Для себя нашел выигрышную стратегию, задавать вопросы о политике.

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

#машины_aws

А если без шуток, то c us-east-1 часто творится какая-то хрень, потому что это старейший и крупнейший регион, причем не только у AWS, но и в целом в Северной Виргинии очень много ЦОД. Автор помнит мемы, когда какой-то реднек хотел "сломать интернет" взорвав серверные интернет провайдеров в этом штате.

С USE1 ситуация усложняется еще тем, что раньше этот регион ставился по умолчанию всем, кто заходил в облако впервые. Молодым же стартаперам невдомек были особенности регионального развертывания, да и запустить свежий продукт поскорее хотелось больше, чем думать о том, где именно его запускать. Чего уж добавлять, что AWS тестирует новые сервисы в Вирджинии и Ирландии (eu-west-1).

В итоге USE1 перегрузился, AWS сделал регионом по умолчанию Орегон (us-west-2), но дело это не сильно спасло, ибо вчерашние стартапы уже стали единорогами.

Собственно хозяйке на заметку: держитесь от USE1 подальше. А про мульти-региональные приложения вы и без меня знаете.

#машины_разное #люди

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

Хочу подчеркнуть 3 основных закона, которые мне аукнулись.

“A technology that was built for good will eventually be also used for bad.”

Я бы сократил это до “A technology will eventually be also used for bad.”, причем так можно говорить не только про новые блестяшки, как (де-)генеративный ИИ, но и про внутренние системы, которыми неизбежно будут злоупотреблять или использовать не по назначению. Соответственно, я, как разработчик-владелец, должен не допустить такого поведения.

“The most painful, and least useful projects are migration projects, yet companies will replace technologies every 4 years.”

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

“A highly communicative and collaborative team of average engineers, is going to outperform an uncommunicative and non-collaborative team of great engineers.”, и за ним же: “Left alone, a product team will optimize to the closest and easiest goal.”

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

Прекрасно понимаю коллег, которые в индустрии ради того, чтобы приносить пользу, занимаясь любимым делом и постоянно развиваясь. Неприятная реальность такова, что такие мотивы должны соответствовать миссии коммерческой организации, которая в 9 из 10 случаев звучит: “Зарабатывать деньги.”

#машины_aws

Разработчикам CloudFormation Extensions, да и в целом команде CFN - мое почтение, такого удобства как человек, который хочет писать бизнес-логику и только, я с сервисами AWS не испытывал примерно никогда.

Собственно, в чем цимес. Разработчики CFN придумали расширения, в которые входят Modules (по аналогии с Terraform), Hooks (валидация изменений, но теперь на лету) и Resource Types - та самая мякотка, которая позволяет выкинуть в окно и сжечь Custom Resource со всеми его Lambda’ми.

От разработчикам расширения требуется строгое следование спецификации. Оно и понятно, ведь ресурс управляется бекендом CFN, а значит входящий тип должен спокойно перевариваться. В помощь разработчику дается cloudformation-cli с набором плагинов, в который оборачивается логика жизненного цикла ресурса.

Чтобы сгенерировать стартовый скелет, нужно просто напечатать cfn init и пройти интерактивный опрос. Обертка подготовит структуру проекта, сгенерирует модель, хендлеры, скелеты тестов, и даже набросает схему.

Посмотрев на результат работы init-скрипта, я поймал сильный вайб от SAM. Предположив, что мне нужно будет руками поправить сначала схему, потом переписать приблизительно все. Однако, открыв models.py, я увидел подозрительную строчку: # DO NOT modify this file by hand, changes will be overwritten

Пройдясь бегло по мануалу, я обнаружил волшебную команду cfn generate, которая на основе схемы генерирует весь шаблонный код, с (де-)сериализацией, валидаторами и прочим. От меня нужно только CRUDL нашлепать, да в сгенерированные тесты какие-то данные сложить.

Весь остальной опыт +- такой же как у SAM CLI, но вот генерация и регенерация кода - мое увожение, я был приятно удивлен.

#пятничное #воскресное

"Он понял из этого отрывочного бормотания, что Сомс - отвергнутый, нелюбимый муж - восстановил свои права на жену путем величайшего, наивысшего акта собственности."

Какой интересный способ выбрал Джон Голсуорси чтобы в "Саге о Форсайтах" описать обыкновенное домашнее насилие!

#машины_разное

Усилия по ускорения Python продолжаются! Теперь Гвидо при поддержке инженеров из Меты намерен выкинуть из него GIL.

Нелюбовь к GIL сама по себе не новость. Из-за него для эффективной параллелизации приходится использовать multiprocessing, что неэффективно по памяти, хотя multithreading vs multiprocessing - отдельная дискуссия в сообществе.

Толчком к движению PEP-a вперед стало желание фейсбушников помочь, выделив на этот проект 3 человеко-года.

#машины_разное

Дизайн документ нередко предшествует абстракт - пару-страничник, задача которого ответить на вопрос “Зачем?” и “Почему то, что есть сейчас, не работает?”. Ответить на “Что?” тоже можно, буквально одним абзацем. Но “Зачем/Почему” куда важнее.

“Зачем” в первую очередь помогает посмотреть на проблему с нетехнической точки зрения. Технарей же хлебом не корми, дай пописать или поделать что-то прикольное, а вот нетехнарский анализ направит энергию в правильное коммерческое русло. В эту секцию складывают либо бизнес проблему, либо расчеты полученной прибыли / сокращенных расходов, либо оба два. Математика дубовая - если на проект тратим 10 баксов, а зарабатываем 100, то это хорошо и проект надо пускать вперед.

“Почему то, что есть сейчас, не работает?” вопрос наименее важный, но куда более интересный с философской и прагматичной точки зрения. Подробное описание существующих систем и компонентов, окружений и ограничений даст хорошую перспективу на историю. А история объяснит и обоснует условия, которые привели к недостаткам.

И вот эта самая история нужна, чтобы ее не повторить в новом дизайне.

#анонсы #машины_разное

Согласованный кеш на базе Redis Cluster, Highload Serbia.

https://youtu.be/Sqxsm2oQDsw

Приятного просмотра!

#машины_aws

Крайне неприятным и премерзейшим образом открыл для себя, что подключиться к Aurora Serverless DataAPI из другого AWS аккаунта нельзя. Даже если есть IAM роль с cross-account доступом и этим самым.

Спекулирую, что причиной тому вероятно отсутствие доступа к KMS ключам для дешифровки в Secrets Manager, опять же, другого аккаунта, и решается это путем создания того же секрета у себя, но такой возможности у меня нет.

Отвратительное открытие стоило мне несколько дней по проекту, дедлайны которого неумолимо надвигаются. Хорошо, что в запасе был план Б в виде прямого подключения из интернета к самой базе.

Причем хотелось переключиться на RDS Proxy, чтобы безопасно, так эта зараза тоже хочет в Secrets Manager логины пароли держать.

Как проект будет завершен и отправлен на золото, раскрою подробности. А пока разрешить позлиться.

#машины_aws

А давайте еще неприятное про AWS. На этот раз про непредсказуемое и блокируещее поведение DynamoDB Global Tables, Billing Mode и лимитов.

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

Теперь представим, что реплики работают в режиме primary/secondary, т.е. мы сначала обращаемся к реплике в регионе А, а если что-то идет не так, то в регионе Б.

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

Далее, мы совершим небольшую шалость, и переведем таблицу из режима provisioned в режим pay-per-request, а затем обратно. Вопрос: как поведет себя DynamoDB?

Она, конечно же, не сможет вернуться в режим provisioned!

Следите за руками:
1. Если режим provisioned был с включенным автоскейлингом, при переводе из pay-per-request в provisioned автоскейлинг включен по умолчанию с предустановленными параметрами. "Не включать" его нельзя.
2. DynamoDB принимает решение поставить максимальное значение для глобальной таблицы, а значит и реплик в обоих регионах - в нашем случае 100 тысяч запросов в секунду, как настроено в регионе А.
3. При попытке настроить схожим образом реплику в регионе Б, DynamoDB упадет с ошибкой в связи превышением регионального лимита.
4. Изменения откатятся, обе реплики будут работать в режиме pay-per-request.

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

Lessons learnt, мать его, the hard way.

#машины_разное #люди

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

Как-то раз мне дали одну задачу на собеседование. Задача про пиццу, она же Lazy caterer's sequence, была крутая. Так и не смог понять, как к ней подойти, но я и математику не знаю, что с меня взять. А коллега, давший мне задачу, намекнул, что решение задачи не должно превышать 40 символов, чем вызвал желание написать этот пост.

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

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

Хорошо про читаемость кода написал один из адвокатов оного в Google. Да, вы работаете не в Google и не решаете задач Google, но изучать опыт других никто не запрещает, верно?

#машины_разное #люди

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

Во-первых, история циклична, и то, что использовалось 30 лет или 3 года назад, вполне может быть переиспользовано сейчас под давлением новых обстоятельств.

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

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

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

#анонсы #машины_aws

Лучшая книга по AWS CloudFormation получила второе издание!

В новой версии:
1. Переработаны почти все главы в соответствии с изменениями у самого AWS'а, обновлен весь код, и мне за него даже почти не стыдно
2. В главе Advanced Template Development добавлена секция по работе с Language Extensions
3. Глава про Macros была переписана полностью и теперь включает в себя Nested Stacks и Modules
4. Новая глава, посвященная работе с CloudFormation Registry
5. В главе по CDK используется CDK v2

Отдельная благодарность @VasilyPantyukhin и @patrick239 за то, что заставили меня вылизывать все почти до мельчайшего знака препинания!