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

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

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

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

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

#dmdev_top_books

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

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

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

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

#20 Мой путь

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

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

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

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

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

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

#my_little_story

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