Good dev knows

2022-02-11 11:42:38 Кто такой фасилитатор

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

Но есть проблема, если группа большая или у участников еще не установилось доверие, то договориться сложно. А еще к группе приставили какого-то странного магического персонажа — фасилитатора. Он(а) вообще норовит превратить весь митинг в детскую игру с какими-то упражнениями. Нет бы просто хорошо поговорить и принять уже решение?

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

Теперь по другому — у фасилитатора нет задачи помочь принять какое-то конкретное решение, фасилитатор не находится на чьей-то стороне. Он(а) просто помогают группе проходить процесс принятия хорошего решения. Сам, обычно, процесс состоит из нескольких частей — divergent zone, groan zone, convergent zone, closure zone. Сначала группа придумывает разные варианты решения проблемы; потом плотно их обсуждает, чтобы убедиться, что все понимают о чем идет речь; потом появляются лидирующие варианты, группа дорабатывает их и принимает решение.

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

Еще раз — простые решения (business as usual) хорошо принимаются и без фасилитатора. Сложные решения тоже можно принять самостоятельно. А можно использовать роль фасилитатора, если кто-то выполняет эту роль, то он(а) помогает члену группы эффективно участвовать в решении проблемы. Фасилитатор, это не обязательно отдельный человек, член команды тоже может фасилитировать принятие решения.

Вы любите митинги с фасилитаторами?

#софтскиллы Открыть/Комментировать

2022-02-09 11:49:31 Application Performance Monitoring

Мы написали новый классный сервис. Что обязательно нужно сделать, перед тем как выкладывать его на продакшен? Много чего. У сервиса должны быть тесты, у сервиса должны быть логи, у сервиса должны измеряться бизнес метрики, + что-то еще, что нужно именно этому сервису. Но есть вещь, которую нужно интегрировать прямо везде. Это Application performance monitoring или APM.

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

Самое классное с APM — для того чтобы внедрить их сбор, как правило, нужно подключить лишь одну библиотеку. Например, можно сделать это с помощью NewRelic (платно ), их клиент поддерживает большинство языков (Go, Java, .NET, Node.js, PHP, Python, Ruby, C SDK). В Node.js буквально:

if (process.env.NEWRELIC_LC) {
// eslint-disable-next-line global-require
require('newrelic');
}

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

Есть и бесплатные решения, например, OpenTelemetry. Это решение с открытым исходным кодом, за него не надо платить кому-то, но нужно устанавливать его на свою инфраструктуру и потом рисовать дэшборды, в какой-нибудь Grafana. Зато тоже есть библиотеки для разных языков программирования.

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

Какие вы используете библиотеки для APM?

#хардскиллы Открыть/Комментировать

2022-02-08 11:10:57 Про меня

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

Меня зовут Павел, в профессиональной (той, что приносит мне ) разработке я уже около 18 лет. Сначала я работал фрилансером на PHP. Потом на компанию в Харькове, делал магазины на Magento. Потом на компанию в Харькове, делал финпродукт на PHP. А потом я и вовсе переехал в Германию, продолжал работать на ту же компанию, но уже на Node.js. 4 года назад я присоединился к SHARE NOW, сначала с Node.js, а потом конвертировался в Java/Kotlin. Но разве языки программирования что-то обо мне говорят? Я думаю мало.

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

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

Истории
* Как я не получил промоушен
* Как я получил промоушен: часть 1, часть 2
* Как хакер украл 10.000€

Хард скиллы
* Что такое ADR
* Что такое Technology Radar от ThoughtWorks
* Что такое Levels of maturity

Софт скиллы
* of participatory decision making
* Техника Fist to Five
* Матрица Эйзенхауэра

Есть еще пара лонгридов
* Как я завел экспертный TikTok и потерпел неудачу
* Как практики из IT помогают растить детей

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

Спасибо, что присоединились И спасибо старожилам, что еще здесь . Открыть/Комментировать

2022-02-07 12:54:13 Про разные форматы данных

Как-то раз, недавно, к нам в команду поступил баг . Наш BI сказал, что от нас приходят таймстампы в разных временных поясах, то как в Берлине, а то как в Гринвиче. Я стал разбираться.

Чуть-чуть разобрался, и оказалось, что наша логика простая — взять то, что возвращает вендор (многомиллионная компания ) и отправить дальше. Стал проверять, а что же возвращает вендор? Сделал разные запросы и — ухты, иногда, он возвращает 2022-04-30T00:00:00+01:00 а иногда 2022-04-29T23:00:00Z. В одном формате есть часовой пояс, а в другом просто UTC.

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

Я написал вендору с примерами и попросил разобраться. Их ответ меня удивил. Они написали, что действительно, буквально месяц назад они выпустили обновление. И теперь, когда ты сохраняешь время через UI, то возвращаться оно будет в UTC. А вот те значения, что были созданы раньше, будут, как и раньше, возвращаться с часовым поясом. Если вы хотите, чтобы формат был одинаковый, стоит лишь сохранить все еще раз через UI (для нас это более 100 раз). А в конце дружелюбно добавили — а почему вы вообще спрашиваете? Ведь мы возвращаем одно и то же время.

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

В итоге прошла еще пара дней. Они исследовали как бы это обновить, а я исследовал, что мы будем делать, если они не обновят. Я реализовал свое решение, а они сообщили, что теперь все данные консистентны. Happy end!

Бонус знание, если вы видите время и в конце стоит Z, то это всегда UTC. When “Z” (Zulu) is tacked on the end of a time, it indicates that that time is UTC, so really the literal Z is part of the time.

Какие выводы мы можем сделать?

1. На самом деле не важно сколько стоит вендор, это я забавы ради написал. IT процессы не зависят напрямую от стоимости компании.
2. При обновлениях нужно следить за обратной совместимостью
3. Ошибаться не страшно, но нужно признавать свои ошибки

Что думаете?

#истории Открыть/Комментировать

2022-02-05 12:07:49 Для всех, кто интерсуется Go, хочу предложить обратить внимание на канал Go Дайджест. Его ведет Сергей, Go разработчик в компании Ring (те которые умный звонок, в фильмах вы, наверное, видели).

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

Подписывайтесь и следите: https://t.me/golangdigest

#промо Открыть/Комментировать

2022-02-04 17:26:53 Не переживайте, сообщение выше это не прогрев на покупку NFT или какого-то -коина.

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

Перевел статью для Хабра, где, с картинками и постепенно, объясняется как работает биткоин.

https://habr.com/ru/post/649597/ Открыть/Комментировать

2022-02-04 17:22:42 Открыть/Комментировать

2022-02-04 11:13:25 Мозг уже все решил

Мы, как Хорошие разработчики и как люди, просто постоянно принимаем решения. Какие-то решения не слишком важны (посмотреть это видео на youtube или поработать?), какие-то более важные (принять оффер от этой компании?). Порой мы долго думаем, взвешиваем все за и против, и это делает нашу жизнь менее приятной.

А что если все это бессмысленно, что если мы уже приняли решение? Этот пост вдохновлен воспоминаниями о прочтении книги "Иллюзия Я, или игры, в которые играет с нами мозг".

В книге описан такой эксперимент. В 1980-х годах психолог Бенджамин Либет посадил людей перед кнопкой и просил их нажимать на нее тогда, когда им самим взбредет в голову. Параллельно, он наблюдал за активностью их мозга. Он заметил, что перед тем, как люди нажмут на кнопку происходит всплеск активности нейронов. Но, что было интересно, всплеск активности происходит раньше, чем человек ощущал сознательное намерение нажать на кнопку. Разница колебалась от 1/5 секунды до 7 секунд.

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

Я часто использую этот “хак” при решении проблем, которые затягивают и затягивают меня. Как поступить лучше? Продолжать хайринг процесс с этой компанией? Какой вариант рефакторинга выбрать? Когда я замечаю, что воронка принятия решения меня затягивает, то я спрашиваю себя — какое решение УЖЕ выбрано? И часто я знаю, какое это решение. Окружать себя вопросами становиться бессмысленно.

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

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

Еще раз — если вы долго не можете принять решение, то спросите себя — какое решение я УЖЕ принял? Как правило, оно уже есть. Теперь у нас есть свободное время, чтобы тревожиться о чем-то другом.

Напишите, пожалуйста, интересны ли такие, более далекие от IT, темы.

#софтскиллы Открыть/Комментировать

2022-02-03 12:16:03 ,

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

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

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

#дайджест Открыть/Комментировать

2022-02-02 12:34:32 Обновление зависимостей

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

С одной стороны это хорошо — мы можем делать что-то, что относится к нашей экспертизе, например, как в случае с 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.

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

#хардскиллы Открыть/Комментировать