Микроменеджмент

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

Поэтому хотел бы рассказать интересное поведение человеческого тела на примере бега:

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

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

Более того, такая свобода в выборе позволяет создавать новые вариации постановки стопы и перемещения тела в целом, которые будут еще более эффективны.

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

И тогда программисты скопировали беговую модель из реальной жизни, где мозг указывает лишь НАПРАВЛЕНИЕ, куда двигаться, а все остальное (микроменеджмент) - уже имеют свободу в решении и автоматической корректировке благодаря датчикам, располагающимся в нужных местах робота.

PS. Остается лишь надеяться, что сотрудники датчики хорошие :)

Speculative retry

Одной из очень полезных настроек, которую мы часто используем для своих gRPC клиентов - это speculative retries. Суть ее в том, чтобы не дожидаясь ответа от первого запроса - отправлять через какое-то время второй ТОЧНО ТАКОЙ ЖЕ запрос. Какой ответ был получен первым из двух запросов - тот и используется дальше клиентом, второй же запрос просто отменяется.

Особенно ценны speculative retries при использовании в микросервисной архитектуре, когда один из instance сервера медленно обрабатывает запросы, близок к OOM, и т.д. Но ее можно использовать для клиентов разных протоколов, включая привычные нам http и даже запросы к СУБД.

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

Поэтому как минимум очень рекомендую попробовать внедрить speculative retries в своих проектах и посмотреть как поведет себя система в целом, потому что у нас на проектах они показывают статистически значимый прирост производительности!

Заключительный день моего трёхнедельного отпуска

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

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

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

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

Так что теперь буду стараться продлить свою жизнь не только количественно, но и качественно 🙂

IRONMAN - я все-таки на это решился!

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

Буквально в эту среду, совершенно случайно за разговором, я узнал, что мой коллега собирается в августе поехать в город Гдыня (Польша), чтобы участвовать впервые в своей жизни в триатлоне. А именно в олимпийской ее дистанции, которая состоит из:
- 1.5 км плавание
- 40 км вело
- 10 км бег

И потом меня спрашивает:
- А давай со мной за компанию чисто по фану?!

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

Спустя сутки я покупаю слот с совершенно другой мыслью в голове:

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

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

Restart service instances

На этой неделе был интересный инцидент, суть которого заключалась в следующем:

1. есть сервис с tomcat pool = 194
2. этот же сервис обращается к базе с database pool = 10
3. накатывается скрипт, который лочит одну из таблиц (таблица весит больше 100 GB)
4. из-за лока пул базы данных не успевает обрабатывать запросы клиентов, которых почти в 20 раз больше в единицу времени
5. запросы скапливаются в очередь, часть фейлится с таймаутами, что влечел дополнительные ретраи со стороны клиента
6. все ретраи просто вновь становятся в и так переполненную очередь

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

На деле фикс заключался в следующем:

1. прекратить запросы к залоченной таблице, чтобы они не занимали оба пула
2. по очереди рестартовать инстансы сервиса, чтобы очистить переполненные пулы

Почему это помогло?

После рестарта обнулялся tomcat pool и все несколько тысяч запросов от клиентов (большая часть из которых - это retry) просто заново сделали свои запросы. Только в этот раз успешно обрабатывались, т.к. tomcat pool был свободен.

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

PS. Не зря в детстве при любой проблеме с компом - просто рестартовал его 😁

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

#20 Мой путь

В конце ноября 2017 года я пришел на собеседование в IT Academy (так назывался этот образовательный центр от парка высоких технологий), чтобы устроиться на работу в качестве преподавателя, или, как тут было принято называть, “ментора” по языку программирования Java. Прошла всего неделя с того момента, как я позвонил им и мне было назначено собеседование. За эту неделю мне нужно было выбрать любую понравившуюся небольшую тему по Java, подготовить презентацию, и рассказать ее двум основным слушателям: директору и заведующей учебным процессом. Что, собственно, и произошло.

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

В итоге, спустя где-то 30 минут, я стою у доски и рисую как устроены простейшие нейронные сети и как в мозгу человека происходит передача сигналов от каждого нейрона с помощью синапсов. В то время я как раз читал одну из технических книг от Рашида Тарика "Создаем нейронную сеть”, поэтому эти знания у меня были довольно свежи в памяти. После чего меня останавливает директор и говорит: “Я думаю, что можно закончить на сегодня. Прошло 45 минут, т.е. целый академический час, а мы еще очень далеко до объяснения темы нашего сегодняшнего занятия”.

Следующие 45 минут мне давали обратную связь по ошибкам, как нужно вести лекции на самом деле, и что как легко уйти в сторону из-за вопросов студентов, тем более имея довольно большой багаж знаний (все-таки моя цель была достигнута, они это оценили!). Это еще один пример того, на сколько важна обратная связь для человека. Только на своем опыте, получая конструктивную критику со стороны, можно очень быстро расти в любой сфере.

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

Я несколько раз отрепетировав перед зеркалом “Примитивные типы данных в Java”, сделал презентацию еще лучше, и со второй попытке меня наконец-то приняли. Осталось лишь стать индивидуальным предпринимателем (именно так было комфортнее всего сотрудничать с IT Academy, когда у тебя было основное место работы), ознакомиться с примерной программой для обучения, и подготовить материал для первых 6-8 занятий. На все это у меня было около полутора месяцев, потому что моя первая группа стартовала как раз после Нового Года.

#my_little_story

Денис, у тебя мб есть обзор твоего рабочего места дома? Если нет, есть планы снять подобное видео?

Почему у меня двое часов?

Не секрет, что невозможно создать инструмент, который бы отлично подходил для всего, что-то вроде швейцарского ножа. Да и в программировании есть такое заимствованное понятие one-size-fits-all, которое говорит все о том же.

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

Поэтому и я ношу двое часов, чтобы лучше удовлетворить свои нужды:

1️⃣ Garmin
Лучшие умные часы для занятия спортом. Причем покрывают практически все циклические виды, тренажерный зал, фитнес, воркауты и т.д. Без них я не представляю как делал бы все свои тренировки по бегу, потому что я ленив, чтобы ездить чуть дальше, чем подъезд твоего дома.

2️⃣ Fitbit
Как хороши бы ни были Garmin для спорта, но мне не очень нравится качество/точность, с которым они трэкают мои health metrics: HR, RHR, HRV, sleep, stress, etc. Именно поэтому я отдаю предпочтение Fitbit. Тем более я работаю над ПО для этих часов, что тоже помогает в тестировании написанного функционала.
____________
И да, мне весьма комфортно носить двое часов.
У меня есть лишь одно требование -> зарядка должна держать не менее 5-7 дней.

🚂 Для любителей последнего вагона...
...осталось ОДНО место на 1 и 2 ступень менторства DMdev

Отправляется в путь ровно через две недели - 2 сентября!

Условия учатстия:
Первая ступень менторства
Вторая ступень менторства

Кто забирает и присоединяется к нам?
✍️Пиши @karina_matveyenka

Искандер прям как будто сорвал с языка - подписываюсь под каждым словом 😅

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

Чем проще, тем лучше

Я много раз на практике встречал довольно сложные решения. Даже тогда, когда сама задача была достаточно простой. Люди пытаются использовать сложные механизмы, такие как Reflection API, Generics, пишут даже кастомную сериализацию.

Но искусство программирования в другом - в простоте

Чем проще решение, тем проще его изменять, поддерживать, оно понятно менее опытным разработчикам, оно меньше подвержено багам (ведь чем проще механизм - тем меньше причин для его поломки).

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

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

#21 Мой путь

15 января 2018 года - я стою в аудитории напротив 20 человек. Сбылось то, к чему я шел 2 месяца. Лучшее место и время не придумать, чтобы начать прокачивать свою социальную сферу жизнедеятельности. И, хочу сказать, на практике это оказалось гораздо сложнее, чем я даже предполагал. Очень сложно что-то говорить на публику людей, когда они все молча смотрят на тебя и пытаются понять твои объяснения. Все-таки, это также разные вещи: что-то “объяснять” или просто “рассказывать”.

Я помню, что от волнения мне было очень жарко, я сильно краснел, и у меня так дыхание перехватывало, что даже сложно было говорить - как будто воздуха не хватало. Поэтому приходилось останавливаться как после пробежки и переводить дыхание. И то чувство постоянной жажды я помню до сих пор. Во рту очень сильно пересыхало от долгого говорения, ведь занятие было довольно длинным и включало в себя 4 академических часа с перерывом в 10 минут между парами.

Вообще, обучение было интенсивным. Мы встречались 3 раза в неделю по 4 часа на протяжении 3 месяцев, чтобы выучить весь Java Core, SQL, JDBC, и Servlets. И тогда не было записанных лекций, которые можно было бы пересмотреть. Что усвоил, то усвоил - повтора не будет. Это сейчас на своем менторстве я увеличил и время обучения на месяц, и пересматривай мои лекции в записи столько, сколько пожелаешь. Все познается в сравнении!

Каждый вечер перед каждым занятием я сидел готовился. Т.е. это еще 3 дня в неделю для меня. И плюс проверка домашнего задания по воскресеньям, которая занимала в среднем по 4 часа (18-20 человек по 10-15 минут на проверку каждого). Поэтому мое волнение на лекциях довольно быстро прошло, и уже на второй-третьей неделе я чувствовал себя очень комфортно и уверенно. И это было конечно же заметно студентам, ведь человек быстро подмечает на интуитивном уровне вот такие вещи.

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

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

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

Эти 3 месяца пролетели очень быстро для меня. Уже пора было сдавать экзамен, который заключался в том, чтобы презентовать свой финальный проект - полноценное веб приложение на Java Core. Все, кто успешно его сдал - могли идти на следующую ступень, которая длилось 2.5 месяца и представляла собой написание такого же самого приложения, но с использованием самых распространенных Java инструментов и фреймворков: Maven, JUnit, Hibernate и Spring. И конечно же мы все вместе пошли в тот вечер в кафе, чтобы отметить такое значимое событие как для меня, так и для моих студентов!

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

PS. Напоминаю, что мой путь с самого начала можно почитать под хэштегом #my_little_story

#my_little_story

Mono vs multi repository

Я помню, что лет 8-10 назад, когда в моду вступала микросорвисная архитектура, мы на проекте создавали под каждый сервис отдельный git репозиторий. А почему бы и нет, ведь так все делали? Да и это казалось логичным - ведь и раньше тоже создавали репозитории под каждый проект.

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

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

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

Теперь все знают, что нет ничего лучше моно-репозитория в git, где каждый сервис представляет собой лишь отдельный модуль в Maven/Gradle. А обновление версии не стоит тебе никаких накладных расходов.

Сейчас это кажется обычным, но до этого тоже нужно было дойти через кровь и боль сотен и тысяч программистов! Ведь когда-то и числа 0 тоже не было, и вряд ли о его изобретении сейчас задумывается обычный человек :)

Logs vs Metrics

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

Это две разные концепции, которые часто путают начинающие разработчики:

1. Логи

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

2. Метрики

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

Если еще более простым языком: метрики нам нужны, чтобы убедиться, что система работает исправно и уведомить разработчиков, если это не так. А логи уже используем, чтобы понять что именно не так. Сначала 2, потом 1!

PS. А как определить и когда алертить разработчиков в случае "не здорового поведения приложения" - это уже тема другого поста :)

11.11.2024, Bieg Niepodległości, 10k, 37:13

3 разряд по бегу взят с итоговым временем 37:13!

Все-таки удалось достичь своей цели, что ставил еще год назад 😎

Разложился вообще отлично, с запасом. Как сделали последнюю тренировку в среду по 3:45-50, так я и бежал всю дистанцию (на скрине смотри как ровно темп держал).

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

И конечно же как положено отработал финишное ускорение. Заключительные 100 метров шел по 2:41 мин/км.

Сейчас прикидываю, что если бы знал, что так подведет тренер меня к старту круто и так легко будет бежаться мне, то можно было не перестраховываться и чуть быстрее идти хотя бы на 2-3 сек на км, тогда бы из 37 минут точно бы вышел!

Когда завершал прошлогодний сезон, то результат был 39:49. Получается, 2:36 мин снял.

Что в переводе на метры выходит около 650. Т.е. на полтора круга на стадионе обошел бы себя самого в прошлом году - это прям очень сильно мотивирует!!!

Во многом тут заслуга тренера. Под четким руководством выполнял все тренировки. Так что спасибо ей большое!

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

Сегодня ровно 2 года, как мы с тренером начали сотрудничать. Так что ровно 2 года мне потребовалось для достижения 3 разряда. Надеюсь, что к следующем году мы если и не возьмем 2 разряд, то будем очень близки к нему!

https://www.strava.com/activities/12874608741/overview

Почему постоянство (consistency) важнее других правил?

Здорово, когда на проекте во всем соблюдаются best practices. Но, во-первых, это не панацея, а во-вторых, не всегда это возможно по многим причинам.

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

Простейший пример
Если ни в одном из проектов/модулей нет lombok, то не нужно его подключать во время реализации вашей задачи, чтобы не генерировать boilerplate code самому. В таком случае только ваш модуль и только ваша часть кода будет его использовать. Других разработчиков это введет в заблуждение при написании кода в других модулях, а также возникновении потенциальных багов и ошибок с тем же equals, hashCode, etc.

Еще один пример из моей практики
У меня как-то раз тестовый flyway скрипт накатился на prod базу данных. А все потому, что именно в этом проекте не работал стандартный шаблон именования скриптов, которые накатываются только на тестовое окружение и больше нигде. Во всех остальных проектах работало именно так. Т.е. не было consistency между всеми модулями, тем самым разработчик сделал предположение, что должно работать именно так.

И это было правильное предположение разработчика, потому что большинство вещей мы делаем на автомате, полагаясь на некий шаблон - это экономит очень много времени и энергии. Только представьте, как застопорилась бы работа, если бы человек думал над каждой строчкой кода, потому что не было бы уверенности без consistency: а точно ли я правильно пишу или нет?