Good dev knows

Восьмой день войны 💙💛

Вчера мы дополнительно собрали:
1. 2517.13 EUR на PayPal от 17 человек
2. 434 EUR на IBAN
3. 9000+ UAH на украинскую карту, точной информации нет, друг эвакуировался из Харькова и ответит позже

📝 Сегодня я перевел EUR:
1. 1500 EUR Харьков Волонтер ЕВГЕНИЙ (помощь продуктами)
2. 1000 EUR Tatiana Ivanchenko (помощь раненым)
3. 440 EUR Андрей Белинский (помощь продуктами)

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

Хочу рассказать — я еще собираю в LinkedIn. Очень много переводов от европейцев — немцев, поляков, людей которых я просто не знаю. Поддерживают люди из Египта и Индии. Все поддерживают Украину, наша компания SHARE NOW выделила 10.000 EUR на помощь. Дополнительно собирает непосредственно физическую гуманитарную помощь для беженцев. Всем спасибо, это важно для меня и для Украины 🙏

⚠️ Информация для россиян: Справочник для антивоенных споров в семье и на работе. Это касается вашего будущего и будущего ваших детей. Не оставайтесь в стороне. Каждый делает то, что может.

Спасибо 🤗 Вместе остановим войну 🤝

⚡️ Внеочередное включение

Пришел первый отчет и благодарность ВАМ (хоть я и не просил).

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

Если появилось желание помочь, реквизиты на месте:

IBAN: DE69100110012620227756, Pavlo Poliakov; BIC: NTSBDEB1XXX
PayPal: https://www.paypal.com/paypalme/PavloPoliakov или me@pavelpolyakov.com
Перевод на украинскую карту (UAH): 4441114456919602, Dmitry Yevtushenko

Спасибо 🤗

Седьмой день войны 💙💛

Отчитываюсь про сборы гуманитарную помощь. Я собирал здесь и через свой LinkedIn.

Вчера мы собрали:
1. 2331.59 EUR на PayPal от 25 человек
2. 845 EUR на банковский счет от 8 человек
3. 28.000 UAH на счет в Украине, от я не знаю скольких человек, это ведь не мой счет
4. + 200 EUR от меня

Попыток фишинга моего PayPal: 1.

Я узнал контакты людей в Харькове, которые осуществляют помощь в поле и отправил им переводы.

📝 Отчет:
1. 28.000 UAH ушло брату подписчика этого канала @maxim1am — покупают и развозят продовольствие в городе
2. 1000 EUR ушло Андрей Белинский — помогает с гуманитарными нуждами в поле
3. 1500 EUR ушло Tatiana Ivanchenko — координирует лечение раненых
4. 880 EUR ушло благотворительному фонду Станция Харьков

Пока я это писал мне на PayPal пришло 500 USD. Все деньги которые продолжат поступать будут выводиться местным волонтерам и организациям.

Большое спасибо за помощь! То что вы сделали это очень важно. Важно работать над тем, чтобы война остановилась. Каждый делает то, что может.

Наконец я точно себе доказал, что не зря создал этот канал 🤗

Скрины переводов в комментариях.

Собираем деньги для гуманитарной помощи 💙💛

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

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

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

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

IBAN: DE69100110012620227756, Pavlo Poliakov; BIC: NTSBDEB1XXX
PayPal: https://www.paypal.com/paypalme/PavloPoliakov или me@pavelpolyakov.com
Перевод на украинскую карту (UAH): 4441114456919602, Dmitry Yevtushenko

Такие переводы безопасны, это просто p2p перевод. Каждый доллар важен. Каждый должен помогать тем, чем может. Я удвою первые 100€.

Спасибо 🙏

Пятый день войны 💙💛

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

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

С сегодняшнего дня КАЖДЫЙ россиянин тоже чувствует эффект — рубль обесценивается. Весь прогрессивный мир объединился и стоит на стороне Украины. Благодаря действиям вашего правительства, ваше будущее ставится под сомнение. Не жизнь, а БУДУЩЕЕ и будущее ваших детей.

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

Россия ведет полноценную войну в Украине. "Умные" ракеты и точечные удары закончились в первый день, применяется оружие неизбирательного действия. За время войны на территории Украины уже погибло 16 детей. Гибнут и попадают в плен ваши солдаты. Солдаты не мотивированы воевать, даже они не понимают смысла происходящего.

Россияне, тут нет второго варианта, вы НЕ ХОТИТЕ войны, потому что вы хотите будущего. Хороший разработчик не хочет войны, потому что он хочет развития. Каждый должен делать что-то, что в его силах, чтобы остановить войну. Вы не хотели этой войны, но теперь эта война и ВАША ответственность. Распространяйте информацию, это минимум. Посмотрите как мирные жители встречают ваших солдат.

Все, для кого это безопасно, могут помочь армии Украины.

Комментарии под этим постом оставляю открытыми. Мир уже изменился, нет никаких "других" площадок. Все площадки должны говорить о войне и о том как ее остановить!

Украина будет свободной!

Работа с тревожностью

Разработчики много переживают. Особенно сейчас 💙💛. Тревожность (anxiety) сковывает, мешает делать свою работу, кидает тебя в объятья думскроллинга. Именно так я провел вчерашний день.

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

Хочу порекомендовать апп Sayana. Я узнал о нем около месяца назад, на фоне новостей о том, что Headspace купили его. В приложении простая механика - вы делаете чекин, отмечаете как себя чувствуете (тревожно, спокойно, счастлив, устал и т.п.), можете сделать заметку из-за чего. А после этого, апп рассказывает вам что-то полезное. Например, о простой практике с фокусом на когнитивно-поведенческую терапию или что-то про когнитивные искажения или просто историю.

Например, упражнение Breathing daisy 🌸. Если дышать в темпе вдох 4 секунды и выход 4 секунды, то тело подумает, что вам спокойно и вы тоже успокоитесь.

Еще мне понравилась притча оттуда:

Когда-то давно старый индеец открыл своему внуку одну жизненную истину.
— В каждом человеке идет борьба, очень похожая на борьбу двух волков. Один волк представляет зло — зависть, ревность, сожаление, эгоизм, амбиции, ложь... Другой волк представляет добро — мир, любовь, надежду, истину, доброту, верность...
Маленький индеец, тронутый до глубины души словами деда, на несколько мгновений задумался, а потом спросил:
— А какой волк в конце побеждает?
Старый индеец едва заметно улыбнулся и ответил:
— Всегда побеждает тот волк, которого ты кормишь.

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

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

#софтскиллы

Моя страна атакована, мой город атакован, не хочу делать вид, что этот канал вне политики.

Сегодня Путин объявил войну Украине, мотивируя свои действия идеями "денацификации". Это полная чушь и не имеет ничего общего с реальностью. Когда я жил в Украине я ездил в Донецк и отлично проводил там время. Я ездил во Львов, говорил там по-русски, и отлично проводит там время. Народ Украины и власть, которую украинцы выбрали в ходе демократических выборов, хочет одного — жить мирно и счастливо.

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

Я знаю, что в этом канале много россиян. Посмотрите обращение президента Зеленского к россиянам (на русском с 02:03).

Всех призываю помочь фонду "Повернись живим". Это можно сделать тут:
* https://www.patreon.com/savelife_in_ua
* https://savelife.in.ua/donate/

Переживаю, но верю в будущее 🇺🇦

Mutation testing

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

Мы можем тестировать компоненты отдельно с помощью unit тестов, мы можем тестировать как все работает вместе, с помощью интеграционных тестов. Но сколько тестов нужно? Чем сложнее приложение, тем больше сценариев, как оно может работать — тем больше тестов можно написать. Все сценарии покрыть невозможно. Но можно усилить свой quality assurance процесс дополнительно. Один из таких вариантов — применять mutation testing 🧟‍♂️.

Суть этого подхода проста. Специальная библиотека делает в вашем коде изменение (мутант) и запускаются тесты. Если ваши тесты упали, значит они убили мутанта ☠️. Если ваши тесты не упали, значит он выжил и нанес ущерб. Это что-то значит. Хотя бы следующее — либо изменение было сделано в мертвом коде, либо этот кусок кода не тестируется, либо ваши тесты плохо работают. Из этого уже можно сделать какие-то выводы и принять решения.

Какие изменения вносятся в код? Например, у вас в коде есть if(myValue == 50), мутант может выглядеть так if(myValue != 50). Мутант ведет себя как обычный баг.

Качество ваших тестов можно будет измерить ориентируясь на mutation score. mutation score = number of mutants killed / total number of mutants. Если mutation score низкий — нужно менять ваши тесты.

Что можно использовать:
* Stryker — для JavaScript, C#, Scala
* Pitest — для JVM языков
* Mull — для C или C++
* mutmut — для Python

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

#хардскиллы

Написал лонгрид для VC о том, как я в 2019 изобрел тесты в Instagram.

Будет интересно почитать всем любителям пет-проектов. У вас есть какие-то? Расскажите в комментариях.

Еще есть кросс-пост на Хабре, для ваших апвоутов 🤗.

Как я промоутил без фактов

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

Тогда процесс был такой — тимлиды заполняют документы на членов команд, собирают с них фидбэк, дают свой и делают вывод — как проявил себя человек в этом полугодии. Вариантов было три — below expectation, meets expectation, overachieved expectations. Если человек overachieved, то ему выплачивался бонус 💰, согласно контракту. Потом был митинг среди всех хэдов, где производилась калибровка, утрясались детали и утверждались результаты.

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

С этой информацией я, собственно, и подошел к калибрационному митингу. Это был первый подобный опыт для меня. На митинге мы быстро прошлись по below и meets — вопросов не было. Потом начали обсуждать overachieved. И тут меня спросили — а почему этот разработчик overachieved? Я рассказал про то же, что написал выше. Тогда меня спросили — а что конкретно сделал этот разработчик, как можно это измерить?

И тут я понял, что я в беде 📉. У меня не было ответа на этот вопрос. Для меня было очевидно, что он работает отлично. Я думал, что и для других очевидно, а если не очевидно, то они поверят моим словам. К сожалению, у меня не было подготовлено конкретных примеров (а лучше еще и слегка преувеличенных). Я попытался что-то быстро вспомнить, но это был провал. При этом я наблюдал, как другие хэды предметно нахваливали своих подопечных, тех, кого я бы не оценил, как Хороших разработчиков.

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

⬛️ Какой вывод можно сделать? Я делаю такой — нужно не забывать, что мы живем в информационном пузыре. Если что-то очевидно мне, это не значит, что это очевидно и другим. Если хочешь в чем-то убедить других, легче всего это делать, используя что-то, что можно измерить. Например, я мог сказать — разработчик N сделал рефакторинг пайплайна, теперь мы билдим проект за 5 минут, это сэкономило нам 20 часов в прошлом месяце. А его об этом даже никто не просил. Все нужно измерять, это пригодится.

#истории

VAPID цели

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

Если мы хотим что-то сделать, то нужно поставить цель. А когда мы слышим про постановку цели в голову приходит одна аббревиатура — SMART. Цель должна быть Specific, Measurable, Attainable, Relevant, Time-Bound. Тогда шансы на успех повышаются.

Хорошо, мы теперь знаем (знали) как ставить хорошие цели, а что есть что-то наоборот? Как проверить, не поставили ли мы перед собой “плохую” цель? Решение есть. Недавно я узнал еще одну аббревиатуру — VAPID.

VAPID это:

Vague – Цель не ясна, шаги, которые нужно предпринять непонятны

Amorphous – Непонятно, что будет считаться достижением цели

Pie in the sky – Она очень амбициозна

Irrelevant – Цель сложно отнести к чему-то, что действительно важно для нас

Delayed – Не ясно когда планируется осуществлять намерение, это может произойти в любой момент

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

Пример VAPID цели — “давайте избавимся от технического долга”, “надо найти новую работу”.

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

#софтскиллы

Новости

В начале этой недели стали доступны результаты IT Salary Survey December 2021. Особенность конкретно этого опроса в том, что его участники, преимущественно русскоговорящие экспаты.

🔭 Наблюдения следующие:

* Большинство экспатов переезжают в Берлин. Определенно там и вакансий больше и ЗП повыше.

* Зарплаты растут, сейчас медианная ЗП составляет 75.000€, когда я переезжал была 60.000€.

* Total compensation практически никогда не отличается от базовой зарплаты больше чем на 10%. В Германии по-прежнему не распространено давать стоки. Обычно бонус это какой-то ежегодный процент от ЗП.

* Большинство ответов из Берлина, 20% из всех ответов питонисты. Они что там все переезжают data science делать в Берлин?

* Фрилансеры зарабатывают прям много, но у них и рабочих часов в году больше, чем у обычных работников. 2000 vs ~1800.

Остальное посмотрите сами, интересные наблюдения велком в комментарии.

Спасибо организаторам за проведение опроса 🤗.

#новости

CIDR

Хороший разработчик работает с инфраструктурой. Кто-то чаще, кто-то реже, но все сталкиваются с этим. Часть инфраструктурных задач связана с сетью. Например, мы хотим создать новую VPC (Virtual Private Cloud) на AWS и разместить там наши виртуальные сервера. Когда мы создаем VPC, нужно указать пул IP адресов, которые могут участвовать в этой сети, для этого нас просят указать CIDR блок.

CIDR (Classless inter-domain routing) нотация позволяет нам компактно указать какие IP адреса мы выделяем. Например 10.10.10.10/24 говорит нам, что можно выделять IP с 10.10.10.0 по 10.10.10.255, то есть 256. Но почему так? Я постоянно забываю принцип, по которому из строки можно получить пул IP. Давайте разберемся, может после этого и я запомню.

💡Дисклеймер — я не сетевой инженер, а практикующий разработчик. Это мой рекап данного топика. В комментариях укажут нестыковки, спасибо за это. Уверен, что информации в этом посте достаточно для понимания общей картины.

Теперь про сам IP — IP это четыре байта байт.байт.байт.байт , каждый байт состоит из восьми бит, их можно представить как десятичное число. Байт=11000000 это 192. Таким образом, мы понимаем, что IP это четыре раза по 8 бит, то есть 32 бита.

10.10.10.10 = 00001010.00001010.00001010.00001010.

Теперь возьмемся за /24 , 24 в этом случае это количество бит, начиная слева, которые НЕЛЬЗЯ менять, когда мы хотим получить новый IP. Эти биты являются адресом подсети. Т.е. когда мы выделяем новый IP из этого блока, то мы работаем с такой схемой: 00001010.00001010.00001010.*. У нас осталось 8 бит, чтобы выделять новые IP. В эти 8 бит поместится ровно 256 разных значений.

Теперь другой пример, мы хотим, чтобы наша сеть была маленькой, чтобы в ней было максимум 8 IP. Как мы это сделаем? Зафиксируем больше битов! 10.10.10.10/29. Тогда мы можем выделать IP с 10.10.10.8 по 10.10.10.15.

⬛️ Еще раз — когда нужно указать подсеть, мы используем CIDR. Если вы вдруг (опять) забыли, как это работает, то используйте онлайн калькулятор https://cidr.xyz .

#хардскиллы

Все стремится к энтропии

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

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

Существует даже физический закон “Закон неубывания энтропии” (беспорядка) — в изолированной системе энтропия не уменьшается. Информационную систему с внешними зависимостями сложно назвать стабильной. Поэтому, если перенести этот физический закон в наш абстрактный IT мир, то можно сделать вывод — если жизнь в нашей системе не поддерживать, то она точно сломается.

Проблема в том, что нельзя точно расписать все процессы, которые поддерживают в системе жизнь. Можно постараться, но все расписать точно нельзя. Если представить, что на каждое действие должен быть таск, то можно умереть ☠️ в бюрократии.

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

Примеры:
1. Заметил(а), что в README.md что-то уже не актуально? — удали
2. Заметил(а), что не хватает какой-то документации — добавь
3. Какой-то процесс не задокументирован? — напиши документацию
4. В Slack вашу команду о чем-то спросили? — ответь
5. Кто-то болел и потерял контекст? — созвонитесь и расскажите ему что произошло

Есть идиома "это последняя соломинка, которая сломает спину верблюду”. Одна из задач Хорошего разработчика это убирать эти соломинки, тогда спина нашего верблюда никогда не сломается.

Какие еще примеры приходят вам в голову?

#истории

👋,

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

Сегодня хочу порекомендовать еще один канал, на который подписан сам — Нестыдная фасилитация. Канал ведут три Agile-эксперта — Саша, Женя и Оксана, они же — партнеры в проекте co-actors.

Я узнал об этом канале после подкаста 🎧 Podlodka #217 — Фасилитация, который, в принципе, обязателен к прослушиванию.

В канале девушки регулярно пишут обо всем, что связано с принятием решений и эффективной работе в команде. Эти темы актуальны не только для Agile-коучей, но и если вы разработчик или тимлид. Например:
* Как создать базовые договоренности в команде
* Когда у команды нет идей, что это может значить?

Хороший разработчик не индивидуалист, он работает в команде, и нам важно знать, как работать в команде эффективно.

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

Кто такой фасилитатор

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

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

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

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

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

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

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

#софтскиллы

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?

#хардскиллы

Про меня

С начала года в канал добавилось около 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, где я выкладываю истории про свою работу, жизнь и Гамбург.

Спасибо, что присоединились 🤗 И спасибо старожилам, что еще здесь 🤝.