1851
Авторский блог Карена Товмасяна. Идеи, слова поддержки и критики отправляйте мне - @ThomasStorm. С предложениями рекламы не обращайтесь. I do not speak on behalf of my employer.
#пятничное
AWS CodeDeploy научился цеплять несколько балансировщиков к EC2 машинам. Это вызвало у меня радость, поскольку я мог вычистить кодовую базу от нескольких хаков, которые пришлось применить, чтобы подружить машину с двумя балансировщиками.
Зайдя в доку, я обнаружил что нововведение не появилось в провайдере (хотя 3 месяца прошло, могли бы и завести). Беглый поиск показал открытый запрос на поддержку, висящий в очереди, потому что HashiCorp расставляет приоритеты на основе... лайков!
Удивительно, что Хаши раньше добавляли новые фичи и сервисы быстрее команды CloudFormation.
#машины_aws
При настройке доступа через IAM велик соблазн использовать сгенерированные самим AWS'ом политики, в которых нужная часть доступа уже предоставлена.
Так, например, в AmazonEC2ReadOnlyAccess добавили ec2:Get*. Все бы хорошо, но действие ec2:GetPasswordData дает администраторский пароль от Windows машины, что, скажем так, уже не совсем read-only 🙂
Изменение довольно шустро откатили. Лишний раз напомню, что лучше дополнительные пару часов потратить на дизайн доступа по Least Privilege Principle, чем потом быть на первой полосе новостей из-за взлома.
#машины_aws
У нас с командой AWS CloudFormation есть славная традиция: как только я отправляю новое издание по Mastering AWS CloudFormation в печать, команда тут же выпускает новые фичи, про которые мне обязательно хотелось бы рассказать в книге.
Сначала это был Fn::ForEach, который добавляет поддержку циклов (долгожданный конкурент Terraform'овского count и for_each), вышедший в релиз как только вторая глава со словами "Вот AWS уже делает нам циклы в клавдформейшоне" была сдана, сверстана и проиндексирована, ну а теперь, как вы наверное догадались - IaC generator.
Генератор - это AWS-managed аналог Terraformer. Сканируем весь аккаунт (если надо, с фильтрами) и добавляем ресурсы для будущего стека.
На выходе получаем сгенерированный код с импортированным состоянием. Этакий OneClick переезд с ClickOps на Infrastructure-as-Code. А любители высокоуровневых языков программирования могут сходу занести стек в CDK и забыть про ужасы правки длиннющих YAML'ов.
Из очевидных недостатков: поддерживаются только "родные" ресурсы из CloudFormation Registry, что логично - оно не побежит в DataDog сканировать дашборды. Второй недостаток вытекает из первого - если вы накликали себе ресурсов из свежего мегасервиса, который не поддерживается CloudFormation, то никакой генерации не будет.
P.S. Мне такими темпами скоро придется третье издание писать, пощадите.
P.P.S. В комментарии приглашаются YAML-фобы, потому что я так и не понял разницу между поддержкой кодовой базы на тысячу строк и аналогичным шаблоном CloudFormation.
#машины_разное
Null Pointer Exception одна из самых ублюдских проблем, с которой мне приходится сталкиваться с тех пор, как я перешел в бекенд. Особенно противно работать с вложенными структурами, когда приходится делать такие проверки:
s := someStruct{}
if s.Nested != nil || s.Nested.MoreNested != nil || s.Nested.MoreNested.EvenMoreNested != nil {
// ...
}
#машины_разное
Мое пятничное чтиво - история load average (LA), которое, как выяснилось, существует аж с 70х годов прошлого века, и претерпело значительные изменения в 93-ем.
Для тех, кому LA в новинку, рекомендую мой источник. Там и пояснения, и увлекательное детективное расследование.
Но что интересно, так это то, что LA сначала мерило ожидания только CPU. По мере добавления других компонентов в компьютеры, как сетевые и дисковые устройства, причин задержек стало больше, поэтому их тоже понадобилось включать в формулу.
Иными словами, если раньше LA показывало количество процессов "ждущих" процессор, то сейчас оно показывает количество процессов ожидающих любой ресурс.
P.S. Вы наверняка столкнетесь с кадрами, которые считаю LA какой-то бесполезной фигней, например, разработчики Linux.
#машины_разное #люди
Вне зависимости от срока жизни предприятия или организации, специалист всегда можно подчерпнуть вдохновение из, возможно устаревшей, архивной документации и рабочих предложений.
Во-первых, история циклична, и то, что использовалось 30 лет или 3 года назад, вполне может быть переиспользовано сейчас под давлением новых обстоятельств.
Во-вторых, архивные рабочие предложения могли быть закрыты из-за нехватки ресурсов или более приоритетного проекта. Что не значит, что проект нельзя реанимировать - не зря же его пытались запустить.
В-третьих, полезные знакомства в лице локальных дедов помогут усилить рабочее предложение, убрав из него очевидные недостатки и сгладив углы. Вы получите мудрого и влиятельного советника, а дед получит возможность тряхнуть стариной.
Вооружившись историей и дедами, как начинающий карьерист, так и опытный специалист, можно найти хорошую отправную точку для причинения пользы предприятию.
#машины_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 learned, мать его, the hard way.
#анонсы #машины_разное
Согласованный кеш на базе Redis Cluster, Highload Serbia.
https://youtu.be/Sqxsm2oQDsw
Приятного просмотра!
#машины_разное
Усилия по ускорения Python продолжаются! Теперь Гвидо при поддержке инженеров из Меты намерен выкинуть из него GIL.
Нелюбовь к GIL сама по себе не новость. Из-за него для эффективной параллелизации приходится использовать multiprocessing, что неэффективно по памяти, хотя multithreading vs multiprocessing - отдельная дискуссия в сообществе.
Толчком к движению PEP-a вперед стало желание фейсбушников помочь, выделив на этот проект 3 человеко-года.
#машины_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, но вот генерация и регенерация кода - мое увожение, я был приятно удивлен.
#машины_aws
А если без шуток, то c us-east-1 часто творится какая-то хрень, потому что это старейший и крупнейший регион, причем не только у AWS, но и в целом в Северной Виргинии очень много ЦОД. Автор помнит мемы, когда какой-то реднек хотел "сломать интернет" взорвав серверные интернет провайдеров в этом штате.
С USE1 ситуация усложняется еще тем, что раньше этот регион ставился по умолчанию всем, кто заходил в облако впервые. Молодым же стартаперам невдомек были особенности регионального развертывания, да и запустить свежий продукт поскорее хотелось больше, чем думать о том, где именно его запускать. Чего уж добавлять, что AWS тестирует новые сервисы в Вирджинии и Ирландии (eu-west-1).
В итоге USE1 перегрузился, AWS сделал регионом по умолчанию Орегон (us-west-2), но дело это не сильно спасло, ибо вчерашние стартапы уже стали единорогами.
Собственно хозяйке на заметку: держитесь от USE1 подальше. А про мульти-региональные приложения вы и без меня знаете.
#машины_aws
Для CloudFormation был разработан линтер cfn-lint, который на базе разных правил проверял шаблон на вшивость. Одной из моих любимых фишек этого линтера была возможность написать свое правило на том же языке, что и сам линтер, т.е. на Python.
А раз для написания правила используется верхнеуровневый язык программирования, то положить в это правило можно буквально все что угодно. Автор помнит времена, когда он злоупотреблял Boto3, чтобы в рамках правила делать вызовы на AWS API и делать более точечные проверки, например, если hardcoded ARN ссылается на существующий ресурс.
У таких свистоплясок есть очевидный недостаток. Например, если линт проходит в рамках CI, то у сборочного агента должен быть доступ в AWS, не говоря уже о том, что мы нагружаем линтер функциональностью, для которой он никогда не предназначался.
И вот я в очередном туре по кишкам CFN, изучая расширения, нашел расширение Hooks. Hooks проверяют разные типы ресурсов на соответствие определенным правилам, но в этот раз правила проверяются на стороне самого CloudFormation. Может показаться, что это бесполезное дело, ресурс дешевле проверить до развертывания, а не во время развертывания.
С другой стороны можно застраховаться от тех, кто катит CFN вручную и не применяет линтер, или если приходящие изменения в вашу инфраструктуру не под вашим контролем. Hooks это такой способ защититься от неприемлемых изменений, поскольку они не допускают абьюза со стороны ленивых девопсов.
Но для этого нужно побороть сначала свою лень и написать много правил на все случаи жизни. 🙂
#машины_разное
В пользу, извините за тавтологию, противников всего нового и современного говорит необходимость обслуживания старой системы на период миграции, а иногда и на более долгий срок, если миграция затянулась или вовсе отменилась.
Один из законов Лемана гласит, что ПО либо эволюционирует, либо становится несопровождаемым и бесполезным. Это может привести к тому, что экономия человеческих ресурсов от новой красивой системы нивелируется при условии, что старая система все еще существует, но в нее уже не инвестируют.
Это не отменяет того факта, что рефакторинг существующей системы, особенно при большой текучке кадров, становится непосильной задачей, из-за чего команда принимает решение бросить все и написать новую с нуля. Это является не ликвидацией технического долга, а скорее объявлением дефолта, что, честно скажу, рабочий вариант при условии, что технический долг уходит на свалку вместе с legacy. Иначе остаемся в долговой яме надолго.
Поэтому я с пониманием и уважением отношусь к тем, кто продолжительно инвестирует и обслуживает старую скучную тусклую систему, за доработки которой не светит никакого повышения.
#анонсы
4-ого июля буду выступать на HighLoad в Сербии, рассказывая о том, как можно сделать Redis строго-консистентным в кластерном режиме.
Буду рад встретиться очно с коллегами, кто окажется там же в те же дни. 🙂
#машины_aws
К слову о интересных темах - смахнем пыль со старого срача о системах управления облаками, т.е. Infrastructure-as-Code. Так получилось, что я снова изучаю возможности CloudFormation и нарвался на нововведение под названием Language Extensions.
Language Extensions это Template Macros, разработанные AWS. Сами макросы представляют собой блоки шаблона, которые “трансформируются” на лету, делая шаблон динамическим и позволяя с ним химичить, как душе угодно.
Например, AWS SAM это самый, что ни на есть, макрос-сахарок, который абстрагирует под собой неудобства описания serverless ресурсов.
На момент этой записи Language Extensions умеет конвертировать YAML ключи-значения в JSON-строки, включает поддержку Intrinsic Functions в - наконец-то - Update/DeletionPolicy, и с какой-то целью добавляет новую функцию Fn::Length.
Что привлекло мое внимание, так это обсуждение новых фишек этой разработки, а именно вот эта ветка. Да, вам не показалось, мои дорогие ненавистники многострочных шаблонов. В CFN собираются внедрить циклы. Возможно, затем и придумали Fn::Length.
При чем здесь срач, скажете вы? При том, что львиная доля холиваров CloudFormation vs Terraform vs CDK vs Pulumi нередко сводились к тому, что последние 3 инструмента могут использовать цикличность для описания ресурса один раз, а создания многажды, а мой любимый целофан - нет. Поэтому, создавая VPC с 6 подсетями, 3 публичными и 3 приватными, вы 6 раз описывали подсеть, 6 раз описывали ассоциацию таблицу маршрузитации с подсетью, и неизвестно сколько еще дубликаций вам пришлось бы сделать позднее. Шаблон становился огромным набором копированного дублированного кода, который не хочется ни читать, ни тем более обслуживать.
Наконец-то за эту проблему взялись сами владельцы сервиса. Это создает надежду, что сервис живет и не станет полумертвым backend’ом для CDK. А может и станет, кто ж его знает.
#машины_разное
Рик Хулихан, известный политтехнолог NoSQL в свое время разработал стандарт Single Table Design, который подразумевает хранить все поля сущностей в одной, как следует из названия, таблице.
Про STD есть превосходная презентация, которая раскрывает суть, детали и имплементацию. Честно скажу, что это моя самая любимая презентация.
Однако, индустрия делает очередной виток, и снова начинаются гонения на, вроде бы, принятые подходы. Создателя паттерна это, можно сказать, задело, и он разразился большой ответкой в Твитере.
Настоятельно советую прочитать ответ. Без апелляции к авторитету, можно снова сказать, что был потерян контекст. STD никогда не подразумевал складывать вообще все в одной таблице. Паттерн подразумевает, что атрибуты одной сущности должны храниться в одном месте, а не в разных. Но определение этих атрибутов идет в первую очередь с помощью определения паттернов доступа - какие данные мы читаем и для каких целей.
От себя замечу, что пока мы, как индустрия, продолжаем терять контекст, мы обречены использовать инструменты и подходы не по назначению, а потом героически их переизобретать.
#машины_разное
Если вам вдруг надоело флексить CAP теоремой, значит пришло самое время расчехлять "новый" "тренд" под названием PACELCA
И если вы сейчас подумали о зумерах, которые переизобрели распределенные системы, спешу вас расстроить - с критикой теоремы зашли пресловутые деды.
В первую очередь, CAP теорема обманывает тем, что мы можем выбрать 2 из трех, в то время как выбрать мы можем одно из двух - А или С. Выкинуть из системы Р нереалистично, да и более того - кто такой этот ваш партишн толеранс? В каком-то случае, пропавший интернет в туннеле уже себе Network Partition, попробуйте предусмотреть это в своей системе.
Вернемся к PACELCA (кто-нибудь, отберите у итшников нейминг, пожалуйста).
Сама по себе эта, даже не теорема, а скорее алгоритм анализа компромисов звучит так: Если нам нужна терпимость к сетевым партициям (P), то мы выбираем между доступностью (А) и согласованностью (С). В противном случае (Else - E), компромис между задержкой (Latency - L) и выбором в сторону согласованности (С) или доступности (А).
Сложно? Сложно. Сначала академики придумали нам устойчивую договоренность, а потом пришли деды из индустрии и из этой договоренности сделала пес знает что. Потому что edge cases. 🤷♂️
P.S. В индустрии в принципе есть тренд то на усложнение, то на упрощение. См. прыжки из монолита в микросервисы, из микросервисов в макросервисы, из макросервисов обратно в монолит. В гибкости - сила!
#пятничное #новогоднее
Многим из вас знаком закон Конвея, который гласит, что организационная структура и коммуникация между командами отражается на итоговой архитектуре систем.
Существует и обратный закон Конвея, предлагающий растить и развивать структуру предприятия в соответствии с архитектурой системы.
К чему я это все? К тому, что и в первом, и во втором случае наблюдается натягивание одного на другое. Это не хорошо и не плохо, это данность за которой придется следовать. В конце концов мы субъекты вечно меняющихся обстоятельств, в которых нам надо существовать и оперировать.
В 2024 году я хочу пожелать вам, дорогие друзья, крепости и силы для внешних обстоятельств и гармонии и покоя для внутренних.
С наступающим Новым годом! 🎉
#машины_aws
AWS будет строить "суверенные" регионы в Еврозоне.
Ставлю, что это нужно для:
1. GDPR/PSD2/других европейских стандартов
2. GovCloud для ЕС
#анонсы #машины_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 за то, что заставили меня вылизывать все почти до мельчайшего знака препинания!
#машины_разное #люди
В индустрии есть распространённое предубеждение против найма так называемых олимпиадников, и оно, должен признать, небеспочвенно.
Как-то раз мне дали одну задачу на собеседование. Задача про пиццу, она же Lazy caterer's sequence, была крутая. Так и не смог понять, как к ней подойти, но я и математику не знаю, что с меня взять. А коллега, давший мне задачу, намекнул, что решение задачи не должно превышать 40 символов, чем вызвал желание написать этот пост.
Зная формулу, решить эту задачу можно в одну строку, а олимпиадники их так наверняка и решают. Однако такое решение имеет мало шансов обеспечить кандидату найм, ведь интервьюер смотрит не только на такие характеристики как эрудицию, отладку и прочее, но и читаемость кода. А все потому что в индустрии код пишется не для машин - компилируемый код машина и так пожрет - но для людей. Если кандидат не в состоянии внятно объяснить свой ход мыслей словами через рот и невербально через код, то о командной работе и сопровождаемости и речи быть не может.
Поэтому читаемый код, пусть и превышающий мнимый лимит в количество символов, гораздо важнее быстрого наброска, который не поймет даже сам автор, не говоря уже о его коллегах.
Хорошо про читаемость кода написал один из адвокатов оного в Google. Да, вы работаете не в Google и не решаете задач Google, но изучать опыт других никто не запрещает, верно?
#машины_aws
Крайне неприятным и премерзейшим образом открыл для себя, что подключиться к Aurora Serverless DataAPI из другого AWS аккаунта нельзя. Даже если есть IAM роль с cross-account доступом и этим самым.
Спекулирую, что причиной тому вероятно отсутствие доступа к KMS ключам для дешифровки в Secrets Manager, опять же, другого аккаунта, и решается это путем создания того же секрета у себя, но такой возможности у меня нет.
Отвратительное открытие стоило мне несколько дней по проекту, дедлайны которого неумолимо надвигаются. Хорошо, что в запасе был план Б в виде прямого подключения из интернета к самой базе.
Причем хотелось переключиться на RDS Proxy, чтобы безопасно, так эта зараза тоже хочет в Secrets Manager логины пароли держать.
Как проект будет завершен и отправлен на золото, раскрою подробности. А пока разрешить позлиться.
#машины_разное
Дизайн документ нередко предшествует абстракт - пару-страничник, задача которого ответить на вопрос “Зачем?” и “Почему то, что есть сейчас, не работает?”. Ответить на “Что?” тоже можно, буквально одним абзацем. Но “Зачем/Почему” куда важнее.
“Зачем” в первую очередь помогает посмотреть на проблему с нетехнической точки зрения. Технарей же хлебом не корми, дай пописать или поделать что-то прикольное, а вот нетехнарский анализ направит энергию в правильное коммерческое русло. В эту секцию складывают либо бизнес проблему, либо расчеты полученной прибыли / сокращенных расходов, либо оба два. Математика дубовая - если на проект тратим 10 баксов, а зарабатываем 100, то это хорошо и проект надо пускать вперед.
“Почему то, что есть сейчас, не работает?” вопрос наименее важный, но куда более интересный с философской и прагматичной точки зрения. Подробное описание существующих систем и компонентов, окружений и ограничений даст хорошую перспективу на историю. А история объяснит и обоснует условия, которые привели к недостаткам.
И вот эта самая история нужна, чтобы ее не повторить в новом дизайне.
#пятничное #воскресное
"Он понял из этого отрывочного бормотания, что Сомс - отвергнутый, нелюбимый муж - восстановил свои права на жену путем величайшего, наивысшего акта собственности."
Какой интересный способ выбрал Джон Голсуорси чтобы в "Саге о Форсайтах" описать обыкновенное домашнее насилие!
#машины_разное #люди
Попался на глаза прикольный блог про “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 случаев звучит: “Зарабатывать деньги.”
#пятничное
Уморительно, оказывается есть игра, где участнику надо угадать, кто по ту сторону чата - человек или машина.
https://www.humanornot.ai/
Один сеанс игры занимает всего 2 минуты, долго переписываться не получиться. Для себя нашел выигрышную стратегию, задавать вопросы о политике.
Не чтобы позлить лишний раз, а потому что о политоте у каждого человека мнение есть. 🙂
#жиза
В Амстердаме стоит Королевский музей, габаритами и наполнением словно Пушкинский в Москве. Внутри он разделен на несколько эпох нидерландской культуры и искусства, от деревянных церковных статуэток святых до легендарного автопортрета, тогда еще “двуухого”, Ван Гога и знаменитого “Ночного дозора” Рембрандта, вокруг которого построили стеклянный саркофаг.
Организация музея, честно скажу, сделана добротно. Вооружившись аудиогидом за деньги или бесплатно на собственном мобильнике, можно пройти тур как общего плана, т.е. от и до, так и тематический с глубоким уклоном в конкретную эпоху или работы.
Моя любимая картина там - "Испуганный лебедь" Яна Асселина, про работу которого я узнал из нидерландского мистического триллера “Арес”. Лебедь олицетворяет Яна де Витта, защищающего тогда еще Голландию от “сущего зла”, которое изобразили в виде собаки сутулой.
Но что вызвало больший интерес, так это средневековые картины религиозного толка. Прикладываю фотографию, сделанную моей любимой супругой, к этому посту и прошу обратить внимание именно на нее. Сюжет, как это было популярно в те времена, повествует о распятии Христа, которое, как мы знаем, произошло в эпоху римлян. Что это за странные одежды и, простите, графы и герцогини, я ума не приложу, да и на кой ляд фоном рисовать замок, которого в те времена точно не было, мне совсем непонятно.
Была мысль, что автор тогда испытывал те же трудности, что и художники, которые рисовали зверей по рассказам и на слух, из-за чего вы часто можете посмеяться над максимально всратыми львами, тиграми и птицами, но я не рискну взять ее как основную гипотезу.
В комментарии приглашаются - ха-ха! - искусствоведы или знатоки, кто желает мне помочь пролить свет на эту тайну. Уже неделю с этим живу и не могу понять, что к чему.
#люди
Питер Друкер, известный экономист и автор множества произведений в области управления, в своем труде The Effective Executive дает следующий карьерный совет: “Build on strengths, not weaknesses.”
На первый взгляд такая рекомендация кажется чем-то странным, да и конфликтует с идеей T-shape, но это далеко не так. Тот же T-shape подразумевает наличие основного навыка, в которую специалист постоянно инвестирует. Помимо этого навыка у специалиста есть общее понимание смежных областей - достаточное, чтобы сделать простейшую оценку или поддержать диалог.
Что же касается самого совета, то он полезен не дебютантам индустрии, но опытным кадрам, которые спустя Х лет решили сменить свой карьерный курс. Рекомендую не выбрасывать за борт накопленный багаж знаний и опыта.
К моменту моего трудоустройства в Убер, я поставил себе задачу перестать опираться на AWS, потому что чувствовал, что некий порог уже достигнут. В какой-то мере это удалось - теперь я занимаюсь бекендом, но сказать, что теперь бекенд стал моим основным навыком будет как минимум наивно. Мозгом я все еще сисадмин инфраструктурщик, который проектирует системы из расчета, где и как могут отстрелить компоненты или как тяжело их обслуживать. Опыт работы с AWS дал мне этот и много других поднавыков, которые и стали столпом моей экспертизы: анализ откупов и выбор наименее худшего сценария; умение договариваться; коммуникативные навыки и навыки презентаций; техническое письмо, и так далее. На этих качествах я и строю свою карьеру дальше, потому что в них я силен и могу конкурировать.
При этом я прекрасно осведомлен, что не владею теми же языками программирования на том же уровне, что и мои коллеги. Я осознанно принимаю решение не инвестировать в свои слабости слишком много, ведь эффективнее делегировать задачу тому, кто с ней справится куда лучше чем я.
Если же вами движет жажда знаний, и вы хотите покрыть все больше и больше предметных областей - это похвально и ничего плохого в этом нет. Раз у вас есть силы искать себя, то это может говорить только о том, что вы просто еще не заебались. 🙂
#люди
Я привык разделять карьерный трек инженера на "до" и "после", где "после" наступает после обретения так называемой "сеньорской мудрости". Дальше рост идет только в вертикальном направлении (лидерские и управленческие качества), либо горизонтальном (охват областей и технологий). И то чаще всего идет вертикальный рост.
Пресловутая “мудрость” появляется, как ни странно, вместе с “сеньорской заебанностью”, когда молодой энергичный заряд постепенно ослабевает, и инженер становится… медленнее. Меньше отправляет pull request’ов в день по сравнению с коллегами, меньше производит дизайн документов, тише ведет себя на встречах и так далее. Это вовсе не значит, что инженер потерял в производительности! Скорее инженер понимает, что здоровье у него одно, опыта у него о-го-го, а 25-летних людей по скорости переплюнуть просто невозможно.
Но причинять пользу предприятию надо, и инженер начинает работать эффективно. Находит дешевые и быстрые имплементации или вообще избегает их - ведь лучше всего работает тот код, который не написали! Делегирует задачи, опираясь на сильные стороны своих коллег (про это расскажу отдельно), доверяет им принятие решений в определенных областях и этапах; выбивает у своего руководителя человеческие ресурсы, чтобы не тянуть проект в одиночку; и начинает все чаще задавать нелюбимый всеми вопрос “А зачем?”. Инженер уже не следит за бесконечным потоком новых фронтенд фремворков и очередных витков эволюции в индустрии, потому что он уже опоздал их изучать, да и они все равно каждую неделю новые.
Вместо этого инженер прекрасно понимает, что его польза проявляется не в оперативных, а стратегических задачах. Какие проекты принесут большую пользу, какие же, наоборот, будут пустой тратой времени. Какую работу взять самому, чтобы не ржаветь, а что поручить перспективным коллегам с потенциалом.
Если вы поймали себя на мысли, что работаете и думаете не так - не беда. Вероятнее всего вы просто еще не заебались.
#жиза
Я увлекаюсь письмом и, заветами умных людей, работаю над качеством своих трудов. Чтобы становиться лучше как, простите за пошлость, контент-мейкер, я читаю много литературы - профессиональной и художественной - и изучаю тонкости писательского дела.
Раньше мне казалось, что письмо требует обязательного аттрибута "муза", но этот миф был быстро развеян. К моему удивлению, письмо это самая настоящая работа, и относиться к письму надо как к работе.
Первое подтверждение этому я это увидел в книге Карлоса Руиза Сафона "Игра Ангела", где главный герой, неудачливый писатель, поймавший большой куш и приобретя патрона, говорит своей ассистентке: "Утром садишься и не встаешь, пока не напишешь."
Несколько лет спустя, я читаю похожие правила от Стивена Кинга в его автобиографическом мануале о писательстве On writing. В самом труде много полезных советов и упражнений, очевидных и внезапных, но правило то же - не ждешь музу, просто садишься и пишешь. Будешь писать редко - стухнешь и просрешь идею.
К техническому тексту такой совет слабо применим, но я немало интересных тем для канала бездарно просрал, потому что поленился и не написал. Надо исправляться. :)
