Беседы с Богом

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

Особенно эта фраза:

Слова могут помочь тебе понять что-либо. Опыт позволяет тебе знать это.

Ничего не напоминает, если переносить на программирование? 🙂

#dmdev_top_books

Мое первое интервью

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

Думаю, это будет отличный повод посмотреть душевное видео, где я не вещаю умные речи про Java и где можно будет обойтись чашечкой горячего чая вместо IntelliJ IDEA.

Надеюсь, вам понравится 😎
https://t.iss.one/iamdilettante/257

Как понять время раз и навсегда?

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

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

Именно поэтому я хотел бы раз и навсегда рассказать про самые основы дат и времени, что такое Physical TIme c его Instants и Durations, что такое Civil Time с его Datetime и Periods, а также что такое Time zones, которые помогают соединить все предыдущее вместе.

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

Желаю приятного просмотра 🚀

#1 Backwards compatibility

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

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

И тут есть два пути:
1️⃣ либо вносить правки в тот же самый API (/v1/users)
2️⃣ либо создать новую версию того же самого API (например, /v1/users -> /v2/users)

В каждом из вариантов есть свои плюсы ➕ минусы ➖

Очевидные минусы первого:
- велик шанс поломать что-то на стороне клиента

Очевидные минусы второго:
- клиентам нужно мигрировать на новый API
- новый API влечет за собой дополнительные расходы на его создание/тестирование/release
- backend нужно сравнительно долгое время поддерживать обе версии API

❓Какой вариант выбираешь ты (пиши в комментариях)?

#2 Backwards compatibility

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

Более того, для клиентов переход на новый API становится огромной незапланированной проблемой, ведь обычно работы и так очень много, и совсем не хочется еще думать о том, что какой-то backend принудительно заставляет смигрировать (исключением, пожалуй, является тот случай, когда и backend и клиент разрабатывает одна и те же команда). И на практике этот переход для всех клиентов может занимать несколько лет!

❗️Но есть одно важное правило:

при создании и дальнейшем изменении API, нужно всегда думать об Backwards compatibility (обратной совсестимости). Другими словами говоря, клиенты должны без каких-либо ошибок работать как с новой, так и старой версией API

Есть 3 основных вида "совместимости" после правок в API:

1️⃣ Source compatibility - когда код клиента продолжает компилироваться. Особенно важно для протоколов вроде thrift, gRPC, где общая модель часто шарится между клиентом и сервером, хотя и для HTTP тоже вполне встречается.

2️⃣ Wire compatibility - когда передача данных между клиентом и сервером (сериализация и десериализация), продолжает корректно работать

3️⃣ Semantic compatibility - когда семантика (смысл новой версии API, его полей, структуры модели) - вполне понятна и очевидна разработчикам на стороне клиента.

❓А теперь вопрос (пиши в комментариях):
- какие именно изменения в API можно делать, чтобы соблюдалась обратная совместимость?

#3 Backwards compatibility

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

Backwards compatible changes:
- Добавление новых полей, методов, интерфейсов, enums.

Но есть пару нюансов:
1️⃣ Нельзя добавлять новых required полей (поэтому в принципе best practice - это все поля optional за редким исключением)

2️⃣ Все поля должны заполняться точно также, как и в старой версии API. Даже если это поле уже redundant в новой версии.

3️⃣ В случае, если enums используются в качестве response - то тут следует быть аккуратным уже на стороне клиента, т.к. можно написать какой-нибудь неправильно работающий switch. В случае изменения enums в request - тут нет таких проблем.

4️⃣ Не стоит создавать на стороне клиента свои mock/proxy классы на основании интерфейсов API, т.к. в этом случае добавление нового метода в этот интерфейс вызовет ошибку компиляции

Backwards incompatible changes:
1️⃣ Удаление или переименование полей. Потому что переименование - это то же самое, что добавить новое поле (backwards compatible change) и удаление старое (backwards incompatible change)

2️⃣ Изменение типа уже существующего поля.

3️⃣ Добавление пагинации в API, которое возвращает список чего-то (поэтому пагинацию лучше добавлять сразу же).

4️⃣ Изменять default значения полей, особенно enums.

5️⃣ Перемещение
компонентов/классов между файлами и пакетами (потому что пакет - это часть полного имени)

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

PS. Если никак не избежать backwards incompatible changes, то придется создавать новую версию API /v1/users -> /v2/users, потому что ломать клиентов ни в коем случае нельзя!

#19 Мой путь

Спустя 4 месяца, закончился второй проект, и нас перевезли в новый офис около станции метро “Молодежная” в Минске. Я решил подыскать квартиру получше, побольше и поближе к новому офису. Что, собственно, и сделал. У меня снова появилось свободное время, которое я решил посвятить самореализации и чтению книг по саморазвитию. Я читал их просто запоем, начиная от “Самый богатый человек Вавилона“ и заканчивая “7 навыков высокоэффективных людей”.

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

Как программист, большую часть времени я проводил наедине с компьютером. Я себя представить не мог на публике или, например, как читаю какие-нибудь лекции на большую аудиторию человек. И тут я начал думать, как это можно исправить…

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

Точно также и с машинами было: как только я купил себе Volkswagen Polo, то тут же начал замечать их повсюду на дорогах! Та же история повторялась и с другими машинами, что я покупал или хотел приобрести. В последующим я понял, что эта “фича” с твоим вниманием работает во всем, стоит только начать думать в каком-то направлении. Без этого - все проходит сквозь тебя как белый шум (и это правильно, это хорошо, так работает наш мозг!).

Добравшись до своего рабочего компьютера, я сразу начал гуглить, что там за здание такое и как там обучают IT. Сразу нашел их веб сайт, где довольно подробно было расписано, по каким языкам программирования идет обучение и по каким профессиям/специальностям человек может после окончания искать работу. А чуть ниже увидел номера телефонов и надпись: "Ищем менторов по следующим дисциплинам: Java, C#, JavaScript…”.

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

#my_little_story

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

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

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

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

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

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

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

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

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. Все-таки инциденты довольно полезны для твоего качественного развития - когда все хорошо, то думать не приходится. Именно проблемы ты начинаешь анализировать, чтобы не повторить их вновь!