Bieg Konstytucji, 5k, 18:28

Начинаю рассказывать как все было...

Сделал я разминочку за 10 минут до старта, буквально 6 минут потрусил с 5-6 ускорениями. И начал пробираться к старту. В этот раз я уже научен был, поэтому когда не смог пролезть ближе, чем на 5 метров к пейсерам на 20 минут, то я просто перелез через забор и побежал к самой стартовой линии. Нужно было действовать быстро, ибо оставалось буквально 3 минуты до начала. Как раз пока все гимн польский пели - я все равно его не знаю. Там я опять перелез через забор на виду у ребят в майках Security, но они решили не останавливать меня)

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

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

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

На 4км я чувствовал, как расплавляюсь. Но ноги, кстати, бежали нормально. Поэтому последние 300 метров я смог сделать финишное ускорение по 3:10 мин/км в среднем. Правда, пульс был 191. Но я как-то не особо это ощущал.

Я тут еще раз почитал, что +10-12℃ - это идельная температура для бега. Если на термометре выше или ниже этой отметки, результаты финишёров снижались примерно на 0,3-0,4% с каждым градусом. Так что я думаю, что время прям вообще огонь с учетом средней температуры в 24-25 градусов сегодня во время забега)

https://www.strava.com/activities/11321347708

Самое длинное Code Review уже на YouTube

В этот раз Code Review был сделан для довольно большого проекта. Поэтому вместо использования стандартного инструмента пул реквестов в GitHub - было решено выкачать код локально и сделать Code Review через среду разработки IntelliJ IDEA.

Причем сам процесс начался с уровня контроллеров, т.е. сверху вниз. Хотя обычно, если пул реквесты небольшие (как и должны быть на практике!), то лучше выполнять Code Review снизу вверх, начиная с анализа базы данных, сущностей, и поднимаясь все выше по n-tier архитектуре.

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

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

Приятного просмотра 🤗

#18 Мой путь

Осень 2017 года - моя первая командировка в Лондон. Не то, чтобы я был фанатом этого города или страны, но это была моя первая командировка в жизни, да еще и в страну с носителями английского языка. Поэтому все свободное время я гулял и осматривал достопримечательности, включая конечно же знаменитый Биг-Бен. Одно я понял точно: мне не нравится ездить куда-то по работе, потому что нарушается мой распорядок дня. Я не мог ходить в тренажерный зал, не мог кушать в то время, которое привык, и в том количестве, которое было необходимо, например, для набора мышечной массы. Но галочку себе можно уже было поставить, все-таки маленькое, но достижение есть.

Неделя в Лондоне прошла весьма быстро, и по возвращению назад в Минск я решил поговорить с менеджером о смене проекта, потому что теперь меня не сдерживала гипотетическая командировка или еще что-то. Я хотел нормально программировать на Java, а не писать хранимые процедуры 90% своего рабочего времени. Но, к сожалению, так и не дождавшись ответа и слышав очередное “скоро все будет, подожди” - начал ходить по собеседованиям.

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

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

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

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

#my_little_story

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

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

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

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

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

#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