DMdev talks

#18 Мой путь

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

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

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

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

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

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

#my_little_story

Всем привет!

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

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

Напоминаю условия участия:
✅Проект опубликован на github

✅Весь код в виде одного пул реквеста или коммита (скидывать можно прямо здесь в комментариях)

✅Чем больше кода - тем больше добавить описания о нем в README файле (чтобы я понимал о чем проект)

✅Не удалять пул реквест или коммит после code review

✅Согласие на то, что ваш разбор попадет в мои соц сети

✅Ссылки жду до 26 апреля включительно

62% людей, опрошенных выше, используют Docker поверхностно, выполняя лишь несколько распространенных команд.

Я уже более 10 лет являюсь Java разработчиком, и начиная с 2017 года активно использую его в каждой компании (кроме гугла, здесь используется его аналог - Boq nodes).

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

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

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

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

Присоединяйся и погружайся в мир Docker вместе с DMdev 🚀

#17 Мой путь

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

Со времен моего первого тестирования на курсы в EPAM Systems, мои улучшения в английском за 4 года работы программистом заканчивались только на беглом чтении книг и документации. Разговорный и аудирование как были на низком уровне, так на нем и остались. Что очевидно дало о себе знать спустя время в очередной раз.

Второй неприятный момент: так как на предыдущем месте работы мне приходилось писать различные хранимые процедуры на PL/SQL, то мой опыт показался релевантным для проекта на компанию Ford. Здесь использовалась Java и T-SQL. Причем, на практике оказалось, что Java я занимался в лучшем случае 10% времени, в то время как остальные задачи были исключительно связаны с написанием хранимых процедур и оптимизации SQL запросов. Хотя на собеседовании конечно же озвучивались совсем противоположные цифры. На тот момент я был, мягко говоря, недоволен сложившейся ситуацией. Но спустя время я осознал, как здорово, на протяжении всей моей карьеры backend разработчика, меня выручали глубокие знания в SQL.

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

Третий момент: офис располагался не в 5 минутной ходьбы от дома как раньше, и теперь приходилось использовать общественный транспорт, что было для меня совсем неудобно и непривычно. Поэтому я все-таки решился выделить часть из суммы, что копил на квартиру, на покупку своей первой новой машины Volkswagen Polo. К ней я относился исключительно как к средству для передвижения. Особенно был доволен тем, что не нужно было с пересадками добираться к своим родным в Мстиславль. Теперь путь был более комфортным и занимал около трех часов времени.

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

#my_little_story

Production данные испорчены. Что делать?
Часть 2

3️⃣ Запускать только тот код, что прошел code review

Jobs, что вы планируете запустить для исправления production данных, обязательно должны пройти через core review. Для этого достаточно просто создать pull request и иметь ограничения на merge в main ветку без получения хотя бы одного approve (что обычно уже и есть в компаниях). Чаще всего этот approve будет получен от напарника из пункта 2, ибо он в первую очередь должен просмотреть и утвердить любые вносимые в код изменения.

Также нужно отгонять мысли подобного плана: "Ну, эти изменения не должны принести какого-то негативного эффекта". Все потому, что это очень сложно продумать все возможные варианты развития событий. Особенно когда production в огне. И нет человека, который не допускает ошибки. Поэтому всегда нужно держать в голове пункт 1 "Не надо спешить"

4️⃣ Планируйте, как будет происходить revert изменений

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

В первую очередь вам понадобится backup данных.

Он должен быть достаточно свежим, а не недельной давности. Также было бы очень неплохо делать пометки (log) о любых выполненных вами изменениях production данных и времени, когда именно они были сделаны. Эти пометки должны включать состояние «до» и «после». Это сильно поможет, если вы обнаружите, что вам нужно отменить некоторые из ваших изменений, а также сделать postmortem, чтобы воспроизвести события в прошлом в любой момент.

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

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

Production данные испорчены. Что делать?
Часть 1

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

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

1️⃣ Не надо спешить
Очень часто, когда вы оказываетесь в такой ситуации и нашли поврежденные данные - в таком состоянии эти данные были уже довольно долгое время. Дни, недели, или даже месяцы. Поэтому очень маловероятно, что ситуация станет еще хуже, если вы потратите на подготовку дополнительные 2-3 часа. Поэтому нужно позволить себе не торопиться, успокоиться, подготовиться морально и сделать все правильно.

2️⃣ Найти напарника
Попросите другого инженера стать вашим "вторым пилотом", чтобы:
- он ревьювал твой код
- он контролировал, что предпринимаемые шаги решения проблемы и их очередность верна
- делал double check всех выполняемых тобой команд в prod cli
- разительно уменьшить появление всяких "описок" и случайных неверных действий
- использовать его как "Метод утёнка"

P.S. Планирую написать продолжение, где будет около 10 таких же полезных принципов в последующих постах.
Так что ставь🔥 если хочешь продолжения

Как я случайно попал в Google: правда о везении или труде? 🍀🚀🤔

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

Но как обычно это и бывает - правда где-то по середине.

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

1️⃣ В 2009 году на первом курсе я не сделал вовремя отработки для общежития. Из-за чего меня выселяют в "пристройку", где я познакомился с такими же "залетными" ребятами. И от одного из них, Игоря, я узнал про язык программирования Java, увидев на полке и прочитав книгу Хорстманна. В настоящий момент - вся моя рабочая жизнь вертится вокруг Java.

2️⃣ В 2017 году я прочитываю книгу "7 навыков высокоэффективных людей" и загараюсь желанием "подтянуть" свою социальную сферу жизнедеятельности. В тот же момент мой проект в компании Godel переселяют в другой офис около станции метро "Молодежная" в Минске, где находится центр обучения от парка высоких технологий. Каждый будний день, проезжая мимо него на работу, меня посещает мысль пройти там собеседование и начать преподавать Java. Спустя 3 года - я открываю свой канал DMdev на YouTube, ну а дальше - вы уже знаете и видите сейчас, читая этот пост.

3️⃣ В 2019 году меня пригласили на собеседование в компанию Fitbit. Собеседование должно было занимать почти 4 часа (4 секции с 8 разными людьми). Я за рулем, стою на светофоре и все сомневаюсь: стоит ли ехать ПРЯМО к офису Fitbit на собедование - ведь это сложно, долго, у меня рабочий день, а текущая работа меня полностью устраивает. Или свернуть НАЛЕВО в мой офис Synesis. И в последний момент просто вдавил газ в пол и поехал прямо. Спустя полтора года - Google завершает сделку о покупке Fitbit и я автоматически попадаю в одну из лучших компаний по разработке ПО.

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

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

2️⃣ Я до сих пор помню свои первые лекции - это был просто какой-то ужас и позор. Мне, как интроверту и программисту, было очень сложно что-то говорить на аудиторию из 20 человек. Воздуха не хватало, я запыхивался просто от того, что говорю. Да еще и с красным лицом от стыда. Но это пол беды - ведь все это тоже нужно совмещать с работой, спортом и личной жизнью. Ведь преподование - это 3 дня в неделю по 4 часа после работы + 3 вечера подготовки перед каждой лекцией + 1 вечер на проверку домашнего задания.

3️⃣ Вдавить газ в пол - это не сложно. Но пройти одно из самых сложных собеседований в моей жизни в Fitbit - это просто так не прокатит. Мне пригодились годы опыта, больше полусотни прочитанных книг, преподование и многое другое. А сама миграция в другую страну с семьей, где не говорят даже на тебе понятном языке, потом адаптация (которая, кстати, идет до сих пор) - тоже ничего приятного не приносит кроме уймы очередных трудностей.

Пожалуй, можно честно ответить на следующие вопросы:

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

Поэтому мой план таков:

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

Не отправляй stale notifications пользователю

На практике довольно часто приходится отправлять различные уведомления пользователю (email, in-app notifications), когда происходит какое-то событие. Например:
- у пользователя заканчивается срок действия подписки
- он пробежал свой первый марафон и нужно вручить особенный badge
- необходимо поставить электронную подпись на только что отправленные документы
- пришел счет на оплату электроэнергии
- и т.д.

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

Поэтому их часто складывают в какую-нибудь очередь в базе данных, или в Message Brokers вроде Kafka.

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

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

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

Только благодаря таким double checks получится избежать отправки stale notifications и не вводить пользователя в заблуждение!

#dmdev_best_practices

DOCKER УЖЕ НА GETCOURSE ✅
(актуально для тех, кто с РФ)

Рад сообщить, что подходит к завершению очередная и предпоследняя часть по курсу Docker - создание своих собственных образов, где я постарался акцентировать внимание на действительно важных вещах!

Конечно же, закрепив все на практическом видео, где мы начнем с голого alpine образа, установим все необходимое ПО, выкачаем Spring Boot приложение с GitHub, соберем его с помощью Gradle Wrapper, запустим и подключимся к базе данных PostgreSQL по user-defined bridge network.

Остался заключительный этап - Docker Compose, где мы разберем еще более удобную работу с Docker контейнерами, когда их становится все больше и больше, и особенно - когда они еще и взаимосвязаны друг с другом!

Текущая готовность курса: 80%
Полная готовность курса: ~14 апреля

Приобрести и начать просмотр можно уже сейчас:
- на GetCourse (для РФ пользователей)
- на YouTube (весь остальной мир 🌍 )