Перевел для Хабра статью Как разработчику применять принципы лидерства Amazon.

Один мой друг, который сначала переехал из 🇺🇦 в 🇩🇪, а потом из 🇩🇪 в 🇨🇦 Amazon, рассказывал, что у них там все действительно сводится к исповедованию этих принципов. И твой промоушен напрямую зависит от того, что ты сможешь доказать, как хорошо ты ими руководствуешься.

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

Поддержите апвоутом ⬆️ плз 🤗

Defensive programming

Часто, когда мы разрабатываем программное обеспечение, мы фокусируемся на таком сценарии, где все идет как надо — happy path. С опытом, приходит понимание, что даже если обычно все идет как надо, то 100% будут случаи, когда что-то пойдет не так. Хороший разработчик старается учитывать наиболее важные ситуации, когда что-то идет не так.

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

Например, у нас есть uuid пользователя, мы знаем, что пользователь существует и наш сервис делает запрос к другому сервису /users/{uuid}. Но вдруг мы получаем 404, что делать? Мы ведь уверены, что пользователь существует. Возможно пользователь просто не успел создаться, потому что операция создания пользователя асинхронная.

Применив defensive programming, мы можем запрограммировать повтор запроса (лучше с экспоненциальной задержкой и ограничением количества повторов). В таком случае мы еще раз попробуем получить данные про пользователя через 1, 2, 3 секунд ⏳. Если после пятой попытки все еще возвращается 404, то можно и упасть — записать сообщение в лог и ответить 500 клиенту.

Defensive programming хорошо подходит там, где мы не контролируем входные данные. Например, при обработке форм, куда пользователи вводят данные, мы можем санитизировать данные (делать их безопасными) или нормализировать данные (приводить их к тому формату, который нам нужен). И только потом — валидировать. Never trust user input.

⬛️ Еще раз — здорово, когда программы не падают из-за любой ошибки. Чтобы этого достичь, Хороший разработчик, предусматривает обработку нестандартных ситуаций, чтобы программа продолжила свою работу. Это способствует high availability.

Вы используете defensive programming? Пишите в комментариях. В следующую среду поговорим про offensive programming 🤺.

#хардскиллы, 🌄Instagram |🤝Patreon

Новости

Оказывается, что в ноябре 2021 Redis зарелизили клиентскую библиотеку Redis OM, где OM это object mapping. Библиотеки доступны для .NET, Python, Node.js (TypeScript) и Spring.

Узнал я об этом из этого видео, где за 13 минут показывают как сделать CRUD (только create) + поиск на Redis. Использование библиотеки выглядит простым и понятным.

Мы Redis особо не используем, но я делал демо проект на нем. Для работы я использовал Spring Data Redis, нашел баг в документации и теперь даже являюсь контрибьютором в этот проект.

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

Кто-то уже использует Redis для чего-то большего чем кэш? Пишите в комментариях.

#новости, 🌄Instagram |🤝Patreon

Про проклятье знания

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

Это когнитивное искажение называется — проклятье знания (Сurse of knowledge). Нам сложно представить, что другие люди не знают то, что кажется нам очевидным. Это можно наблюдать везде.

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

Другой пример, эксперт, при составлении презентации часто “боится” вставлять туда информацию, которая является базовой для этой области. Он думает, что все уже и так знают это и слушателям будет скучно. Я испытываю эти чувства практически перед каждым постом. Например, думаю, что все уже и так знают что такое Метод помидора, стоит ли писать про это пост?

Однако этот “страх” довольно просто победить. Потому что, даже если люди уже знают информацию, о которой идет речь, то у большинства это повторение вызовет положительные эмоции. Потому, что мы получаем удовольствие, когда получаем подтверждение того, что мы что-то знаем 🏆.

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

⬛️ Еще раз — не факт, что другие люди знают то, что знаете вы. Чтобы добиться того, что у всех одинаковый контекст, нужно оверкоммуницировать. Это безопасно и не повлияет на вашу репутацию. Полезно рефлексировать, не находитесь ли вы сейчас под “проклятьем знания”?

Замечали за собой такое поведение? Пишите в комментариях.

#софтскиллы, 🌄Instagram |🤝Patreon

Про типизированные языки

Как-то раз к нам в компанию вышел новый СТО. И через примерно месяц своего присутствия он начал рубить с плеча. Сказал, что теперь новые бэк-энд сервисы мы можем писать только на Java или Go.

К тому времени нас было, наверное, около 15 фулстэк Node.js + JavaScript разработчиков. Наш основной стэк был Hapi (кто-то помнит такой фреймворк?), Angular, новый проект был на React. Сказать что мы “удивились” это ничего не сказать. Мы пытались войти в аргументированную конфронтацию, объяснить что хорошая архитектура на Node.js тоже возможна, предлагали сойтись на том, что добавим в список TypeScript. Но CTO был непреклонен, он аргументировал это тем, что для энтерпрайза важнее не скорость разработки, а возможность поддержки ПО в дальнейшем.

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

Сейчас я понимаю две вещи — 1. у СТО были большие проблемы с коммуникацией, 2. он был прав.

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

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

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

Затраты на хорошую архитектуру JavaScript приложения будут выше, чем скорость, которая “потеряется” из-за использования типизированного языка. Тестами это тоже не исправишь, потому что тестировать приходится значительно больше, по сравнению с типизированными языками. К счастью, сейчас экосистема JavaScript движется в сторону TypeScript.

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

Приходилось поддерживать большие проекты на JavaScript? Пишите в комментариях.

#истории, 🌄Instagram |🤝Patreon

Обновление в Patreon

Решил писать 5-15 минутки для патронов. Суть этого формата, что я трачу 15 минут на текст, который можно потом прочитать за 5 минут. Обычно это используется для улучшения коммуникации на работе. Я буду писать про свою прошлую неделю и инсайты которые я получил в течение нее. В итоге это полезно и мне — лог своих мыслей в будущем и патронам — узнавать все раньше. Еще там можно общаться.

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

В первом выпуске два топика:
* про обратную совместимость API и вендора с оценкой во много миллионов 💰
* про то, что нужно знать Junior разработчику, по моему мнению

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

Всем кто уже патрон — спасибо 🤗

Offensive programming

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

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

Offensive programming это вариант дизайна ПО, когда мы обрабатываем исключения и ошибки так, что программа прекращает выполнение бизнес логики, при любой неожиданной ситуации. Т.е. fail fast.

Например, у нас есть кусок кода, который работает со state и логикой подразумевается, что когда наш кусок кода будет вызван, то state будет заполнен, и не будет null. Но вдруг! Мы понимаем что в переменной все такие null. Наши действия?

При Defensive programming мы бы могли подстелить соломки, и еще раз попробовать “наполнить” state, может быть узнать его у какого-то сервиса. Но при Offensive programming мы сразу же бросаем исключение. Мы не пишем дополнительный код, который обрабатывает и старается исправить исключительные ситуации.

В некоторых технологиях уже присутствуют методы, которые помогают писать код в таком стиле. Например, assert в Node.js. А в Kotlin их даже больше — require, check, assert, requireNotNull.

Вы можете написать:

val state = checkNotNull(someState) { "State must be set beforehand" }

И быть уверенными, что со state все отлично.

Основное преимущество Offensive programming — вы пишете меньше кода. Меньше кода — в меньшем количестве мест что-то может пойти не так. А значит, это требует меньше поддержки. Из минусов — если вы не обрабатываете эту ситуацию, то она должна быть обработана в другом месте, возможно другой командой или другой компанией. Где-то новый код все равно объявится.

⬛️ Еще раз — когда команды не падают из-за любой ошибки это хорошо, но это требует разработки более сложных программ. А сложные программы это плохо. Поэтому, если ситуация позволяет, можно использовать offensive programming и следить за тем, чтобы работал только happy path.

Используете Offensive programming? Пишите в комментариях.

#хардскиллы, 🌄Instagram |🤝Patreon

Про Developer Experience

Когда мы разрабатываем программное обеспечение мы думаем о многих его характеристиках — будет ли оно быстрым (efficiency)? будет ли оно надежным (reliability)? будет ли пользователю удобно его использовать (user experience)? Но одна из характеристик практически всегда остается неназванной вслух — будет ли удобно разрабатывать это ПО? Это свойство ПО можно назвать Developer Experience.

Представьте, что вы выходите на работу в новый перспективный стартап. В такой, где есть личный бариста ☕️. Бариста есть, а вот онбординга толком нет. Вам дали доступ в git, вы нашли там пять вроде бы нужных репозиториев. Что-то на Java, где-то React , а этим вы разобрались, а вот как все это запустить вместе — нет. В итоге вы ловите коллег и просите их помочь. Чтобы запустить проект локально вам понадобилась неделя. Это плохой DX.

Чтобы улучшить DX можно сделать следующее:

* README.md с описанием того как запустить проект локально, как настроить среду, как запустить тесты

* документация о технических процессах в команде — какая конвенция работы с git; как работаем с merge request — кто проверяет, какой врем ожидания проверки; как происходит релиз на продакшен

* в самом коде проекта минимальное количество неочевидных вещей. Время разработчика стоит дороже чем облачные вычисления. Оптимизировать DX, а не скорость.

* использование распостраненных стандартов, технологий и зависимостей, а не своих “велосипедов”. Здесь дополнительный плюс — документацию на эти модули за вас пишут люди в интернете.

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

⬛️ Еще раз — чем проще работать с вашим проектом, тем большая вероятность, что вам кто-то поможет. А когда кто-то помогает, это прекрасно, потому что это значит, что вам надо работать меньше. Хороший разработчик любит работать меньше, т.е. эффективно.

Как еще можно улучшить DX? Пишите в комментариях.

#софтскиллы, 🌄Instagram |🤝Patreon

Перевел для Хабра статью "как НЕ надо учить TypeScript".

ИМХО лучше подойдет тем, кто лишь начинает становиться на TypeScript рельсы. Кстати у автора статьи есть книга TypeScript in 50 lessons, которую я читал, там в конце начинается такая жесть (сложные примеры conditional types), что было страшно читать. Но приятно понимать какой уникальный микс получается если взять JavaScript и добавить гибкую типизацию. Такое невозможно в других языках программирования.

Всем новым (и старым) подписчикам с Хабра привет 👋

Статья

Про fast thinkers

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

В этой иерархии было два трэка — Expert и Management. И, в частности, рассказывали про их особенности. И вот когда речь зашла о менеджерском треке, то девушка, которая рассказывала про характеристики абстрактного, но нужного компании менеджера, обронила, что если вы fast thinker то не факт, что вам это подойдет.

Никто особо не обратил внимание на это, но я обратил и у меня была волна внутреннего возмущения. Я ведь себя отношу к fast thinker-ам и не хочу, чтобы мне что-то не подходило. Но, спустя время и годы, я больше об этом думал и пришел к новым выводам.

Наверное многие разработчики относят себя к fast thinker-ам. Но, чтобы согласовать ожидания, я вижу эту характеристику такой — ты быстро понимаешь о чем говорят другие, быстро проматываешь историю вперед и вот у тебя уже есть решение, ты учел какие-то риски и даже их поборол, теперь тебе скучно слушать и хочется всех перебить и говорить “о сути”. Какие-то ментальные шахматы. Я часто нахожу себя в такой ситуации.

Наверное, может показаться, что это хорошо — такие люди могут сэкономить время решения проблемы. Но у такого подхода есть и минусы. Проблема в том, что fast thinker-ы исключают из решения других людей. Если люди исключены из решения, то они не будут его искренне поддерживать и участвовать в нем. Кроме того, не факт что они полностью понимают предложенное решение, смог ли fast thinker хорошо передать контекст, который он создал у себя в голове? Не факт. Групповые решения приносят разные перспективы в решение проблемы.

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

Быть fast thinker-ом однозначно не плохо, просто нужно осознавать, что есть вещи важнее скорости и работать с этим — следить чтобы все понимали контекст, критически относиться к своим идеям, быть готовым отказаться от нее, если есть лучшая альтернатива.

Что думаете? Пишите в комментариях.

#истории, 🌄Instagram |🤝Patreon

Вакансия

Мой друг Дима работает CTO в небольшой (инженеринг <20 человек) и перспективной компании в 🇩🇪Гамбурге - CONDO.

Компания занимается тем, что совмещает машинное обучение и рынок недвижимости, а именно - они вычисляют какие объекты недвижимости покупать, что надо в них изменить (отремонтировать), чтобы их потом выгодно продать. На вечно растущем рынке Германии это заходит очень хорошо 🚀.

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

Сейчас ищет Full-Stack Engineer. Стэк отличный - TypeScript, Kotlin, React и Vue.js. Разрабатывать начали буквально пару лет назад, поэтому все свежее, а не legacy. Деплоят в Google Cloud Platform.

Из интересного:
* 🚜 перевозят людей в Германию, помогают с визой, дают подъемные ~2.500€
* достаточно знать английский ~B1
* 30 дней отпуска
* офис с видом на Эльбу (тоже зднание что и SHARE NOW) до лета 2022, потом с видом на центр Гамбруга
* для Senior ЗП до 90.000€
* бизнес связан с реальностью, квартиры реально покупаются, ремонтируются и продаются дороже

Еще есть вакансии Data Scientist и Data Engineer, если вы больше по data science и ML.

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

#вакансия

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

Вастрик это клуб по подписке, участие стоит 15$ в год, зато такая небольшая сумма + небольшая проверка при вступлении является фильтром и внутри там все друг другу рады и продуктивно общаются. Так сложилось, что там много разработчиков и экспатов. Но вообще там всем рады.

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

Почитайте, если тоже думаете над созданием Telegram-канала (он вам нужен) или просто так: Как я завел Telegram-канал для разработчиков, набрал 3000 подписчиков и что я получил.

Роль SRE

Современная разработка уже подразумевает интеграцию DevOps в цикл разработки программного обеспечения. Хороший разработчик уже не только разрабатывает программу, а еще и думает как она будет доставляться в продакшен; работать там; что мы будем мониторить, чтобы понимать, что наш сервис в порядке.

Это здорово. Но может быть еще лучше. Как выглядит цикл разработки у большинства команд? Он может выглядеть так:

1. Обдумали новую фичу
2. Запрограммировали ее
3. Обложили метриками
4. Зарелизили
5. Мониторим
6. Потом вернуться к пункту 1

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

Для решения этой, и не только этой проблемы, сейчас выделяют роль Site Reliability Engineer (SRE).

Основная ответственность человека, который исполняет эту роль, в том, чтобы ваша система оперировала, была resilient и по-умному redundant. Этот инженер, как правило, напрямую не связан с разработкой сервисов, но он(а) знает как ими оперировать, как их мониторить, что делать когда что-то идет нет так. Так же этот человек участвует в on-call и исправляет проблемы.

Важной частью SRE практик является автоматизация (operations as code). Конечно что-то пойдет не так, это точно произойдет. Но важно, чтобы из этого были сделаны выводы и больше это бы не повторилось. SRE, вместе с командой анализирует инциденты, делает выводы и вносит изменения в инфраструктуру, чтобы проблемы не повторились.

⬛️ Еще раз — хорошо когда есть кто-то, кто постоянно следит за тем, что система хорошо работает в продакшене. Лучше, когда это еще и постоянно оптимизируется. Для этого кто-то должен выполнять SRE роль. В небольших и средних компаниях, это общая роль и за нее ответственна вся команда, но лучше, когда это отдельная позиция или даже команда.

У вас в компании есть SRE? Пишите в комментариях

#хардскиллы

Приоритизация технического долга

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

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

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

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

1. Собираем митинг и рисуем матрицу. По горизонтали — какие усилия нужно приложить (effort), по вертикали — какой эффект это даст для проекта (impact).

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

3. Когда все обсудили и визуализировали, решаем, что мы готовы взять в ближайшую итерацию. А high impact + high effort проекты лучше разбить на меньшие задачи.

4. Теперь мы готовы обслуживать технический долг. Вы великолепны ⭐️.

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

⬛️ Еще раз — технический долг это не плохо, это просто данность разработки программного обеспечения. Дальше может оказаться, что ваш долг вовсе и не долг, а “особенность” и никому не мешает. Чтобы понять, что именно нужно обслуживать, нужно регулярно приоритизировать технический долг.

Как вы работаете с техническим долгом? Делитесь в комментариях.

#софтскиллы

Поговорим про 1-1 митинги

На всякий случай, вот определение, которое предлагает Google:

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

Перед постом будет два опроса.

Про 1-1

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

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

Иногда такие митинги проходили совсем скупо:
— У меня все хорошо
— Ну и у меня вопросов нет
— Тогда до следующего раза?
— Хорошо

Часто такие митинги хотелось пропускать. И я знаю других людей, которые не любят свои 1-1 митинги.

И только потом, с другим менеджером, я понял что у меня до этого не было “настоящих” 1-1 митингов. А “настоящий” 1-1 может быть полезным.

📝 Вот список характеристик “настоящего” 1-1 для меня:

* У митинга есть агенда, вы и менеджер вносите что бы вы хотите обсудить.
* На митинге не обсуждается обычная работа, для этого есть все остальные дни в неделю. Чтобы обсудить работу не нужен специальный митинг.
* Фокус митинга в том, чтобы помочь сотрудники расти и убрать препятствия, которые мешают ему расти. Т.е. необходимость совершенствовать свой скилл, один из факторов влияющих на мотивацию.
* У митинга есть какие-то результаты. Например, сейчас, на каждом митинге, я отвечаю на вопрос “Что ты вынесешь из этого митинга?”. И каждый раз мне есть что ответить, даже если это мелочь.

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

Какой у вас опыт с 1-1? Пишите в комментариях.

#истории

Новости

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

На прошлой неделе, они выпустили фильм про Kubernetes, две части: раз, два. Фильм состоит из интервью людей, которые были связаны с созданием Kubernetes, выводом его в open source, построением сообщества вокруг продукта.

Рассказывают истории о том:
* почему контейнеры были и до Docker, но Docker сделал их доступными
* что спровоцировало появление Kubernetes как платформы
* как в Google спорили стоит ли ее делать открытым продуктом
* как Kelsey Hightower стал голосом Kubernetes
* и про многое другое

В общем отличное видео, чтобы посмотреть его пока вы едите. Более того, его можно смотреть и не техническим людям.

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

Всего у них семь документальных видео — Ember.js, elexir, GraphQL, про инвесторов, Vue.js и про Kubernetes.

#новости

Обновление зависимостей

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

С одной стороны это хорошо — мы можем делать что-то, что относится к нашей экспертизе, например, как в случае с SHARE NOW, сдавать машинки в аренду, а не тратить время на низкоуровневое программирование про то, как положить данные в PostgreSQL. С другой стороны — зависимости постоянно обновляются, в них находят критические (log4j) уязвимости, зависимости не всегда следуют правилам semantic versioning. И следить за ними большая боль.

Если что-то боль, то лучше это что-то автоматизировать. И в случае с зависимостями, решение тоже есть. Это проект Renovate.

Эту штуку можно сконфигурировать с платформой где лежит ваш код (gitlab, github и другие) и с вашим CI. В итоге будет следующее:

1. Renovate видит, что доступна новая версия какой-то зависимости
2. Он создает merge request, где обновлена только эта зависимость
3. Ваш CI прогоняет pipeline, где запускаются unit и integration тесты (у вас ведь есть?)
4. Если все зеленое, то можно смело мерджить в основную ветку. Еще лучше, если вы настолько доверяете сетапу своего проекта, что MR будет мерджиться автоматически.

Проект поддерживает множество языков и платформ — Java, Node.js, JavaScript и даже Docker и terraform.
Интеграция таких решений как Renovate косвенно заставляет вас писать лучшие тесты, вы ведь хотите, чтобы CI сам проверял все сценарии и мерджил обновления?

⬛️ Еще раз — использовать зависимости это хорошо, другие люди делают за нас работу. Еще лучше, когда вы тоже вносите свой вклад в open source. Но даже если нет, то зависимости надо регулярно обновлять, иначе точно будет беда. Обновление зависимостей можно автоматизировать с помощью Renovate.

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

#хардскиллы

👋,

Расскажу про сгенерированный мною контент, про который я еще не писал в канале.

Для всех
1. Перевод "Как писать условия в JSX". Не сложные рецепты про то как не стрелять себе в ногу, когда пишешь шаблоны.
2. Перевод "Возможности TypeScript, которых нужно избегать". TLDR, не нужно использовать ничего, чего нет в JavaScript. Статья стремительно улетает в минуса, но ее читают и комментируют. Если вы поставите ⬆️, то будет вообще супер.

Для патронов
В своем 🤝Patreon я каждую неделю пишу эксклюзивные заметки для патронов. В январе писал про:
* что такое обратная совместимость и что я ожидаю от Junior разработчика.
* внедрение инноваций в компаниях и проблемы с этим. backstage.
* про работу офтальмолога в Германии; внедрение backstage, стратегия; про то, что важно ясно выражать свои потребности, на примере.

#дайджест