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

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

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

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

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

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

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

#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

Готовность: 99.9%

Docker на финишной прямой.
Как и обещал к 14 апреля - весь контент заснят, смонтирован, и залит на платформу GetCourse (теперь доступен для всех стран ❗️)

Осталось лишь расставить таймкоды и описания для последних 5 видео.

Как я изначально и планировал, весь курс уложился в рамках 40-50 видео. Люблю, когда предварительные оценки подтверждаются в будущем. Жаль, так бывает не всегда :)

В итоге весь курс занял:
📌 45 видео
📌 ~6.5 часов контента
📌 ~3.5 месяцев создания (с перерывом в почти год)

Всем приятного просмотра 🚀

PS. На картинке план, по которому было создано финальное практическое занятие

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

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

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

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

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

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

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

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