Write-ahead logging

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

А что будет, если RabbitMQ будет недоступен в этот момент и сообщение не отправиться ☠️? Можно добавить какой-то retry, можно вообще откатить транзакцию и ответить 500. Можно "потерять" это сообщение, таких случаев ожидается мало, но лучше не "терять", ведь тогда может нарушиться цельность данных в нашей информационной системе.

Есть другое решение — использовать технику write-ahead log. В таком случае, отправка сообщения будет, грубо говоря, состоять из трех шагов:

1. Записываем что нужно отправить в базу данных, в табличку events, ставим статус PENDING
2. Какой-то worker периодически проверяет эту табличку и отправляет сообщения со статусом PENDING
3. Если сообщение отправилось, ставим ему статус SENT
4. Бонус. Время от времени удаляем строки у которых статус SENT

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

Эта же техника используется движками баз данных для обеспечения atomicity и durability из ACID. Только базы данных записывают информацию в файл, а потом в саму базу данных.

⬛️ Еще раз — если вы хотите быть уверенными, что действие будет выполнено, используйте технику write-ahead log. Это делает программу сложнее, но стабильнее.

Реализовывали такое сами? Пишите в комментариях
⁠
#хардскиллы

Техника Pomodoro

Прокрастинация. Мы все страдаем от этого, правда? Я точно да. Думаю каждый Хороший разработчик, иногда, страдает от этого. Нужно сделать столько всего, и это все вроде бы так важно, что не знаешь с чего начать и как к этому подступиться. Поэтому жмешь Cmd + R и проверяешь есть ли что новое на Медузе.

К счастью, наш мозг, можно легко обмануть. И убедить его, что напрягаться придется недолго. С этим помогает техника Pomodoro timer. Название пошло от кухонного таймера

Она простая, уверен, что многие о ней уже слышали:

1. Составьте список задач, над которыми вам надо работать
2. Заведите таймер на 25 минут, в течении этого времени НИ НА ЧТО не отвлекайтесь. Выключите мессенджеры. Работайте над задачей.
3. Поработали? Отдохните пять минут. Можно читать Facebook.
4. Еще раз пункт два. Завели таймер и работаем. Один такой интервал называется — помидорка.
5. После четырех помидорок можно сделать большой перерыв, например 20 минут.

Это точно работает, я проверял. Согласиться поработать 25 минут намного проще, чем согласиться с абстрактным "сделать задачу".

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

Я использую программу Be Focused - Focus Timer на Mac, все еще на бесплатной версии. Ссылка в комментариях. Мне очень помогает тиканье часов + я включаю белый шум в Spotify.

⬛️ Еще раз — если сложно начать работать над задачей, то проще согласиться поработать над ней только 25 минут, а потом вознаградить себя заслуженным отдыхом.

Уже использовали эту технику? Если использовали, напишите, пожалуйста, в комментариях свое любимое приложение.
⁠
#софтскиллы

👋,

Я решил расширить "Хороший разработчик знает" еще одним каналом и завел Instagram-аккаунт.

Планы такие:
1. В Telegram я продолжу писать контент посложнее и подлиннее
2. В Instagram можно больше и чаще показывать, меньше писать
3. Некоторые темы, которые уже встречались здесь, буду пересказывать там, используя другие средства
4. Еще там я буду рассказывать и показывать личное, то что мне интересно — работа, жизнь в 🇩🇪Германии, архитектура Гамбурга, моя жизнь
5. В будущем, я планирую там продавать, но это в будущем. И это будет win-win.

Сейчас там уже теплится первый пост и игра "две правды одна ложь". А вечером расскажу рецепт традиционного немецкого Рождественского напитка 🍹. Кулинарный разработчик, получается.

Подписывайтесь: https://www.instagram.com/gooddevknows/ , будет интересно и про IT.

История о том, как я не получил промоушен

Как-то раз, работал я в компании. Я работал там уже три года и был Хорошим разработчиком (со скидкой). А по должности назывался Expert Software Engineer, потому, что в этой компании так называли Senior.

Выше Expert в иерархии стоял Head. По факту, люди с тайтлом Head лидили команду. Занимались менеджментом и техническим лидерством. Я тоже хотел быть Head. Чтобы расти и денег 💸 больше.

Компания планировала выход на новый рынок (🇲🇽) и нужно было адаптировать продукт под этот рынок. То есть подкрутить фронт-энд, подкрутить бэк-энд, поинтегрироваться с другими командами и связать все это вместе. Закрутилось все это без меня. Но пошло не так активно как планировалось, поэтому, в рамках оптимизации курса, возникла идея привлечь меня, чтобы я этот процесс лидировал.

Я согласился. В моей голове, эта работа была такая же, как и работа других Head. Я думал так — у меня нет опыта в менеджменте команды в Европе, сейчас я научусь, у меня получится и мне тоже дадут Head. В итоге я взялся за дело и мы, вместе с командой, сделали этот проект в срок. Это заняло примерно 6 месяцев. Моя роль в успехе мероприятия была велика, говорю это только потому, что на ретроспективе каждый из членов команды это отметил отдельно, так что это измеримый факт.

По результатам перформанс ревью, меня похлопали по плечу, сказали что я ух как хорошо работаю и это ух как помогает компании. Компенсация немного повысилась. А Head дадут? Спросил я. Мне ответили, что, согласно бюрократическим особенностям нашей компании, “ух как работать” нужно 12 месяцев подряд, чтобы рассчитывать на промоушен.

Окей, я прикусил губу и решил работать еще и подождать, что будет через 6 месяцев. В следующие полгода мне выпала другая команда, которую я тоже лидировал. И другая задача. Перспективная, но менее приоритетная, а к концу полугода уже и неактуальная. Хотя я и команда работали хорошо, но мои заслуги оценили как “хорошо”, а не “ух как хорошо”. Перспективы Head особо не обсуждались. На мой вопрос “почему я делаю тоже что и другие Head, но еще не Head?” мне ответили что-то вроде “сейчас нет необходимости в новом Head".

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

Давайте рассмотрим мои ошибки:
1. Изначально, у себя в голове, я нарисовал какой-то “справедливый” план — работай хорошо, это увидят, тебя по заслугам повысят
2. Я не обсудил этот план с моим менеджером. Я подумал, что он тоже придерживается такого плана
3. Похоже, что моему менеджеру просто было удобно закрыть мной проблему. А о моей “проблеме” ему первые 6 месяцев вообще не было известно.

А вот и вывод — Хороший разработчик не надеется на “справедливость”. Справедливость для него, для его менеджера, для его коллег может быть очень разной, это субъективная оценка. Хороший разработчик проговаривает ожидания, а лучше их прописывает. Необязательно прописывать как контракт, можно просто как e-mail с саммари встречи. Тогда результат можно будет оценить объективно.

Попадали в похожие ситуации? Рассказывайте в комментариях.

#истории

А еще я завел 🌄Instagram, подписывайтесь 🤝

👋, еще одно объявление.

Если вы с каналом давно, то может быть помните, что я ставил цель собрать здесь 2000 подписчиков до Нового Года. Тогда нас было где-то 500. И я только примерно представлял, как я этого буду добиваться. Но вот еще 21-е декабря, а нас уже ~2350.

Это очень здорово, и я доволен аудиторией которая тут собралась. Практически под каждым постом у нас очень продуктивные комментарии. Спасибо за подписку 🤗.

Теперь нужно ставить новые цели. Теперь моя цель сделать "Хороший разработчик знает" sustainable. Я хочу продолжать писать по 3 поста в неделю и еще вести Instagram (там, кстати, вышел новый пост). Что нужно Хорошему разработчику, чтобы продолжать делать то, что он делает? Знать, что то, что он делает, кому-то нужно.

Я запускаю программу поддержки, т.е. Patreon. По ссылке, вы можете стать моим патроном и получить что-то взамен.

Это подойдет вам если:
1. Вам нравится то, что я делаю и вы хотите участвовать
2. Вам нужна моя помощь
3. Вы хотите открытку 🎁

По ссылке https://www.patreon.com/PavloPoliakov, вы можете почитать больше про бонусы. Плюс вас уже ждут два публичных текста. Почитайте.

Спасибо, за то что здесь 🤗

Про RPO и RTO

Поговорим еще раз про даунтаймы, а именно, про восстановление работы после них. Записывайте себе в конспект, это будет на экзамене (ну если будете сдавать AWS Solution Architect).

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

Когда мы планируем reliability и availability нашего решения, мы хотим, чтобы наш сервис восстанавливался быстро и без потери информации. Чтобы формализовать эти требования, мы можем определить два параметра — RTO (Recovery Time Objective) и RPO (Recovery Point Objective).

RTO. Сколько времени максимально, наше решение должно восстанавливаться после инцидента. Например, ⚡️ ударила прямо в наш сервер, через сколько времени наш сервис должен опять работать и работать нормально? Этот параметр поможет нам определиться с availability стратегией.
Если для восстановления работы нам нужно заказать и настроить новый сервер, то на это может уйти день. А если у нас всегда параллельно работает такой же сервер, и нам нужно только переключить трафик — то минуты.

RPO. Потерю какого количества актуальной информации может “стерпеть” компания? Измеряется во времени. Например, 🦡 перегрыз провода, произошло замыкание и сгорел HD. Данные за последние два часа нельзя восстановить. Это приемлимо? Зная RPO можно определиться со стратегией резервного копирования.

Определение RTO и RPO это бизнес задача, в которой учитывается пользовательский опыт, возможные финансовые потери от даунтайма, репутационные потери. А вот реализация этих требований, это уже задача Хорошего разработчика. Очевидно, что чем строже требования, тем дороже будут ежедневные траты на поддержку этих требований 💸.

⬛️ Еще раз — Хороший разработчик готов к тому, что все сломается. На этот случай у него есть стратегия. Хорошо, когда эта стратегия подготовлена на основе бизнес требований, которые формализованы в RTO и RPO.

У вас в команде определены эти параметры? Пишите в комментариях.

#хардскиллы, 🌄Instagram |🤝Patreon

Про unknown unknown

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

Всю информацию, с которой мы сталкиваемся, можно разделить на четыре категории.

Known known. Мы это твердо знаем и мы знаем, что мы это знаем. Например, мы проектируем REST сервис, который реализует HTTP методы. Мы их все знаем. Существование метода THANOS, о котором мы не догадываемся, стремится к нулю.

Known unknown. Мы знаем что информация существует, если нужно, то мы ее найдем и изучим. Например, как развернуть Rust приложение на Microsoft Azure? Сейчас мы не знаем, но если надо, то узнаем и сделаем.

Unknown known. Мы не знаем эту информацию, но, возможно, ее знают люди которые нас окружают. А мы понимаем, что такое может иметь место. Например, мы хотим развернуть Rust на Microsoft Azure, собираем митинг чтобы провалидировать нашу стратегию. А там опытный Rust разработчик говорит — меньше 64Gb памяти сервер не берите, иначе сборщик мусора взорвет сервер. (это я придумал, если что)

Unknown unknown. Моя любимая область. Мы не знаем об этой информации и никто вокруг не знает о ней. Даже если мы сильно захотим, но ничего не поменяем вокруг, мы о ней не узнаем. Например, с большой долей вероятности можно сказать, что 🦈 не знают о существовании 🐫.

Ну а если на примере для разработчиков, то мы все еще разворачиваем Rust на Microsoft Azure, но бухгалтерия не может оплатить счет, потому что ваш главный инвестор оказался замешан в коррупционном скандале и теперь все активы заморожены 🤷‍♂️.

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

⬛️ Еще раз — как бы мы хорошо не готовились, всегда останется unknown unknown, это нужно принять. А если unknown unknown настал, не стоит расстраиваться и корить себя, нужно просто сделать выводы, а в следующий раз сократить количество возможных unknown unknown.

Сталкивались с unknown unknown? Пишите примеры в комментариях.

#софтскиллы, 🌄Instagram |🤝Patreon

Пришла последняя неделя года, время подводить итоги и строить планы. Я придумал, что хорошо было бы написать пост о том, чему я научился в 2021. Но я быстро понял, что лучше я перечислю то, что учило меня в 2021.

В этом году я проходил курсы и читал книги. Вот что это было.

Книги

1️⃣ Искусство объяснять. Мне кажется я и раньше неплохо объяснял и делал презентации. Но эта книга не была лишней. Она дает определению слову “объяснение”, основной цели этого процесса (сделать информацию “дешевле” для слушателя). Дальше рассматривается универсальная структура хорошего объяснения. Уверен, что этого навыка не хватает многим разработчикам.

2️⃣ Solution’s Architect’s Handbook.... В этой книге нет ничего уникального, более того, есть логические ошибки в тексте, которые искажают смысл сказанного. Но это хорошая компиляция прямо всего, что относится к теме Solution Architect. Рад, что прочитал.

3️⃣ Пиши, сокращай. Книга в которой методично объясняется, что основная цель текста это — быть полезным читателю. Конечно, рассматриваются и инструменты, с помощью которых этого можно достичь. Помогает мне писать посты в канал. Рекомендую.

4️⃣ Developing Coaching Skills: A Concise Introduction. Я ничего не знал о коучинге, кроме того что есть коучи и это “модно”. Эта небольшая книжка рассказывает что такое коучинг, почему он работает, освещает базовые коучинг фреймворки. Полезно, все это можно применять и с собой, без всяких коучей. А можно так общаться с людьми и помогать им решать проблемы, при этом не будучи экспертом в их предметной области. Мне понравилось.

5️⃣ Leading Great Meetings.... До этого года мне было не комфортно вести митинги. Я это делал и не избегал, но это вызывало у меня стресс. Благодаря этой книге я структурировал свои представления о митингах, узнал о конкретных инструментах, которые помогают достигать результатов.

6️⃣ Переговоры без поражения. Гарвардский метод. Рассказывают, что любые переговоры вести несложно. Метод состоит всего из четырех пунктов. Никакого секретного соуса, все основано на “справедливости”. Было полезно + подтвердило собственные убеждения.

Курсы

1️⃣ AWS Cloud Services and Infrastructure - Cost Optimization Deep Dive. Компиляция информации о том, как заниматься Cost Optimization с AWS. Много информации уже встречалось при подготовке к AWS Solution Architect сертификации. Но есть и новое. Полезно.

2️⃣ Kubernetes Deep Dive. Стал больше понимать k8s, то как он работает и как развивается. Стало проще общаться с platform командой и следить за нашим “доменным” кластером.

3️⃣ The Diamond of Participatory Decision-Making. Короткий “курс” который открыл мне глаза. Это нормально, когда на митинге происходит “не конструктивная” фаза, а тебе кажется что это ничем хорошим не кончится. Для “сложных” митингов это нормально, это просто часть процесса.

Еще я слушал книги и подкасты, смотрел youtube и читал Telegram-каналы, но про это в другой раз.

А что классного прошли или прочли вы в 2021? Поделитесь, нам всем надо составлять список на 2022.

#истории, 🌄Instagram |🤝Patreon

Топ имен

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

Первой задачей было экспортировать участников группы. Оказалось, что эта задача не тривиальная и в Telegram клиенте это так просто не наклацаешь. Нужно использовать API и не какое-нибудь простое REST API, а самое настоящее хардкорное, которое работает напрямую с кастомным Telegram протоколом. Это API, которое используется для написания Telegram-клиентов.

Благо есть Python библиотека Telethon, которая абстрагирует использование протокола. Я нашел готовый скрипт для экспорта участников группы, немного изменил его, чтобы он поддерживал двухфакторную аутентификацию и применил. В результате я получил 2005 записей. Потому что экспортировать всех все еще нельзя 🤷‍♂️. Но я думаю выборка репрезентативная.

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

И вот результаты.

Мужские имена:
1. Александр - 111 🏆
2. Дмитрий - 87
3. Сергей - 80
4. Евгений - 52
5. Андрей - 50

Женские имена:
1. Ольга - 16 🏆
2. Анна - 14
3. Наталья, Анастасия, Елена - по 11

Конечно, уверен что погрешность присутствует, но, думаю что Александры точно победили в общем зачете. Дмитриям стоит постараться и пригласить в канал своих тезок, если они планируют бороться за топ 1. Среди девушек явного фаворита нет, все может измениться в любой момент, мои поздравления Ольгам 👏.

В целом, подумайте над заполнением своего Telegram профиля корректно, каждое имя важно 🙃.

Вас зовут Александр? Пишите в комментариях, что чувствуете.

#хардскиллы, 🌄Instagram |🤝Patreon

Последний день в году, время подводить итоги и строить планы.

📝 Итоги

Хороший разработчик знает начал свой путь в конце августа. Тогда я планировал стать software engineering TikTok звездой ⭐️, а канал завел в нагрузку, потому что тексты сценариев выглядели как готовый пост в Telegram. С TikTok не сложилось и я сфокусировался на Telegram-канале.

Итоги канала на картинке, которую любезно сгенерировал TGStat. Самая удивительная цифра на этой картинке для меня это 107.924 просмотра. Это очень круто осознавать, что сто тысяч человек, минимум зацепились взглядом, за то, что я написал, а может быть и прочли текст.

В декабре я начал вести Instagram Хороший разработчик знает, где помимо того, что должен знать Хороший разработчик, я публикую и личный контент. Признаюсь, конверсия с Telegram-канала в Instagram подписчики оказалась меньше, чем я ожидал. У вас все еще есть шанс подписаться 🙃

🔮 Планы

Планы, а скорее цели, на 2022 год такие:
* набрать >10.000 подписчиков в Telegram-канале
* набрать >2.000 подписчиков в Instagram
* запустить минимум один продукт для аудитории “Хороший разработчик знает”
* сделать “Хороший разработчик знает” sustainable, т.е. чтобы инвестиции моего времени в проект компенсировались

Почему это цели, а не планы — потому что я, пока, не прописал то, как буду этого добиваться. Но займусь этим в начале 2022.

🗣 К подписчикам

Спасибо за то что подписались и читаете. Спасибо за комментарии и за любой фидбек. Еще большее спасибо патронам, которые поддержали ХРЗ монетой. Желаю, чтобы в 2022 мы все продолжили идти по пути Хорошего разработчика и делали это с удовольствием.

Тем, кто хочет поддержать проект — приглашаю оформить подписку на Patreon до конца года и получить от меня открытку 🎁. Это поможет мне писать полезные посты регулярно.

Вы все клевые, спасибо, что вы здесь 🤗

OneTwo more things

В первую неделю 2022 канал будет в отпуске, до встречи 10го января.

А еще я включил реакции, можно, например 🎉. Отмечаем НГ в комментариях.

🌄Instagram |🤝Patreon

Цена не нашего бага

Начинаем год с истории.

Как-то раз один из наших сервисов начал падать. У нас вроде бы ничего не менялось, а сервис падал, об этом сигнализировали health чеки.

Начали разбираться, увидели что проблемы с базой данных, поизучали еще, увидели что закончились коннекшены в пуле коннекшенов к базе данных. Окей, быстрый фикс — увеличили количество копий сервиса в k8s кластере на 3, он опять начал работать нормально.

Быстрый фикс это хорошо, но нужно нормально разобраться и починить. Сначала выяснили, что к сервису вырос трафик. Мы ничего не делали, маркетинг ничего не делал, мы не знали кто делал, но кто-то ведь сделал 🤷‍♂️. Трафик вырос к эндпоинту, который делал 1 или 2 запроса к базе данных и больше ничего особенного. Но из-за роста количества запросов и текущей конфигурации этого было достаточно, чтобы все коннекшены кончились.

Окей, разбираемся дальше, почему вырос трафик? Оказалось, что в недавнем релизе приложения завелся баг 🐞. Приложение делало запрос к эндпоинту. Если эндпоинт отвечал 404 (что согласно нашей бизнес логике было возможным), то приложение думало, что это ошибка, и начинало повторять запрос. Распостранение приложения по телефонам занимает время, поэтому трафик рос постепенно, пока не вырос значительно.

Договорились с командой, что приложение починят. Это займет примерно месяц (включая новый цикл распостранения приложения). А мы решили, что должны оптимизировать наш сервис сейчас, чтобы было по уму, чтобы он справлялся с новым трафиком. В итоге мы добавили кэш, и теперь, если сервис возвращал 404, то он и следующие 5 минут возвращал 404. Зарелизили, посмотрели на метрики — все улеглось.

На следующий день — сообщения от саппорта, у некоторых пользователей проблемы. Стали разбираться — действительно, у нас может быть такое, что сначала возвращается 404, потом пользователь делает действие и должна возвращаться уже 200, но благодаря нашему “фиксу” мы возвращаем 404 еще 5 минут и пользователь видит странности в UI. Мы откатили “фикс”, все стало опять хорошо.

А теперь плот твист. Почему мы хотели внедрить кэш? Чтобы все было “правильно”, чтобы не платить за лишние инстансы сервиса. Потом я посчитал, что за лишние “инстансы” сервиса за месяц мы заплатим всего 60$. Т.е. 0, в масштабах компании. Сколько мы “потратили” на наш “фикс”, проблемы пользователей и т.п.? Однозначно больше. Мы оставили все как есть, подождали полтора месяца и уменьшили количество инстансов.

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

Есть примеры, когда вы заливали пожар деньгами? Пишите в комментарии.

#истории, 🌄Instagram |🤝Patreon

Перевел для Хабра статью Как разработчику применять принципы лидерства Amazon.

Один мой друг, который сначала переехал из 🇺🇦 в 🇩🇪, а потом из 🇩🇪 в 🇨🇦 Amazon, рассказывал, что у них там все действительно сводится к исповедованию этих принципов. И твой промоушен напрямую зависит от того, что ты сможешь доказать, как хорошо ты ими руководствуешься.

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

Поддержите апвоутом ⬆️ плз 🤗

Defensive programming

Часто, когда мы разрабатываем программное обеспечение, мы фокусируемся на таком сценарии, где все идет как надо — happy path. С опытом, приходит понимание, что даже если обычно все идет как надо, то 100% будут случаи, когда что-то пойдет не так. Хороший разработчик старается учитывать наиболее важные ситуации, когда что-то идет не так.

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

Например, у нас есть uuid пользователя, мы знаем, что пользователь существует и наш сервис делает запрос к другому сервису /users/{uuid}. Но вдруг мы получаем 404, что делать? Мы ведь уверены, что пользователь существует. Возможно пользователь просто не успел создаться, потому что операция создания пользователя асинхронная.

Применив defensive programming, мы можем запрограммировать повтор запроса (лучше с экспоненциальной задержкой и ограничением количества повторов). В таком случае мы еще раз попробуем получить данные про пользователя через 1, 2, 3 секунд ⏳. Если после пятой попытки все еще возвращается 404, то можно и упасть — записать сообщение в лог и ответить 500 клиенту.

Defensive programming хорошо подходит там, где мы не контролируем входные данные. Например, при обработке форм, куда пользователи вводят данные, мы можем санитизировать данные (делать их безопасными) или нормализировать данные (приводить их к тому формату, который нам нужен). И только потом — валидировать. Never trust user input.

⬛️ Еще раз — здорово, когда программы не падают из-за любой ошибки. Чтобы этого достичь, Хороший разработчик, предусматривает обработку нестандартных ситуаций, чтобы программа продолжила свою работу. Это способствует high availability.

Вы используете defensive programming? Пишите в комментариях. В следующую среду поговорим про offensive programming 🤺.

#хардскиллы, 🌄Instagram |🤝Patreon

Новости

Оказывается, что в ноябре 2021 Redis зарелизили клиентскую библиотеку Redis OM, где OM это object mapping. Библиотеки доступны для .NET, Python, Node.js (TypeScript) и Spring.

Узнал я об этом из этого видео, где за 13 минут показывают как сделать CRUD (только create) + поиск на Redis. Использование библиотеки выглядит простым и понятным.

Мы Redis особо не используем, но я делал демо проект на нем. Для работы я использовал Spring Data Redis, нашел баг в документации и теперь даже являюсь контрибьютором в этот проект.

Все знают, что Redis это хорошее решение для кэша, потому что данные хранятся в памяти, но при этом они не эфемерные. По развитию проекта, очевидно, что они хотят быть больше чем кэшем.

Кто-то уже использует Redis для чего-то большего чем кэш? Пишите в комментариях.

#новости, 🌄Instagram |🤝Patreon

Про проклятье знания

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

Это когнитивное искажение называется — проклятье знания (Сurse of knowledge). Нам сложно представить, что другие люди не знают то, что кажется нам очевидным. Это можно наблюдать везде.

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

Другой пример, эксперт, при составлении презентации часто “боится” вставлять туда информацию, которая является базовой для этой области. Он думает, что все уже и так знают это и слушателям будет скучно. Я испытываю эти чувства практически перед каждым постом. Например, думаю, что все уже и так знают что такое Метод помидора, стоит ли писать про это пост?

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

Проклятье знания нужно разбивать. Хороший разработчик не боится повторить то, что ему кажется очевидным. Это никого не травмирует, способствует распространению информации и ликвидации knowledge silos (ситуации, когда знания сконцентрированы только у определенных людей). Все это способствует продуктивной работе.

⬛️ Еще раз — не факт, что другие люди знают то, что знаете вы. Чтобы добиться того, что у всех одинаковый контекст, нужно оверкоммуницировать. Это безопасно и не повлияет на вашу репутацию. Полезно рефлексировать, не находитесь ли вы сейчас под “проклятьем знания”?

Замечали за собой такое поведение? Пишите в комментариях.

#софтскиллы, 🌄Instagram |🤝Patreon

Про типизированные языки

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

К тому времени нас было, наверное, около 15 фулстэк Node.js + JavaScript разработчиков. Наш основной стэк был Hapi (кто-то помнит такой фреймворк?), Angular, новый проект был на React. Сказать что мы “удивились” это ничего не сказать. Мы пытались войти в аргументированную конфронтацию, объяснить что хорошая архитектура на Node.js тоже возможна, предлагали сойтись на том, что добавим в список TypeScript. Но CTO был непреклонен, он аргументировал это тем, что для энтерпрайза важнее не скорость разработки, а возможность поддержки ПО в дальнейшем.

Я был фрустрирован. Но рычаги влияния закончились. В итоге я даже успел написать одну интеграцию с платежной системой на Go и мне это вполне понравилось.

Сейчас я понимаю две вещи — 1. у СТО были большие проблемы с коммуникацией, 2. он был прав.

Половина моей карьеры связана с не типизированными языками — PHP, потом JavaScript. И сейчас я понимаю, что все то, что написал в то время, невозможно было бы поддерживать. Потому, что когда ты открываешь код и не имеешь возможность “прокликать” методы и переменные, то когнитивная сложность растет экспоненциально.

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

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

Затраты на хорошую архитектуру JavaScript приложения будут выше, чем скорость, которая “потеряется” из-за использования типизированного языка. Тестами это тоже не исправишь, потому что тестировать приходится значительно больше, по сравнению с типизированными языками. К счастью, сейчас экосистема JavaScript движется в сторону TypeScript.

Не типизированные языки отлично подходят для одноразовых скриптов. А для всего что будет жить больше года и над чем будет работать команда нужно выбирать типизированные языки.

Приходилось поддерживать большие проекты на JavaScript? Пишите в комментариях.

#истории, 🌄Instagram |🤝Patreon

Обновление в Patreon

Решил писать 5-15 минутки для патронов. Суть этого формата, что я трачу 15 минут на текст, который можно потом прочитать за 5 минут. Обычно это используется для улучшения коммуникации на работе. Я буду писать про свою прошлую неделю и инсайты которые я получил в течение нее. В итоге это полезно и мне — лог своих мыслей в будущем и патронам — узнавать все раньше. Еще там можно общаться.

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

В первом выпуске два топика:
* про обратную совместимость API и вендора с оценкой во много миллионов 💰
* про то, что нужно знать Junior разработчику, по моему мнению

Подписывайтесь 🤝, чтобы узнавать все первыми и поддержать проект. Писать буду по понедельникам.

Всем кто уже патрон — спасибо 🤗

Offensive programming

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

Продолжим разговор про методики обработки нестандартных ситуаций. В прошлый раз мы рассматривали технику Defensive programming, когда наша программа старается продолжить работать, несмотря на проблемы. А сегодня поговорим про технику offensive programming.

Offensive programming это вариант дизайна ПО, когда мы обрабатываем исключения и ошибки так, что программа прекращает выполнение бизнес логики, при любой неожиданной ситуации. Т.е. fail fast.

Например, у нас есть кусок кода, который работает со state и логикой подразумевается, что когда наш кусок кода будет вызван, то state будет заполнен, и не будет null. Но вдруг! Мы понимаем что в переменной все такие null. Наши действия?

При Defensive programming мы бы могли подстелить соломки, и еще раз попробовать “наполнить” state, может быть узнать его у какого-то сервиса. Но при Offensive programming мы сразу же бросаем исключение. Мы не пишем дополнительный код, который обрабатывает и старается исправить исключительные ситуации.

В некоторых технологиях уже присутствуют методы, которые помогают писать код в таком стиле. Например, assert в Node.js. А в Kotlin их даже больше — require, check, assert, requireNotNull.

Вы можете написать:

val state = checkNotNull(someState) { "State must be set beforehand" }

И быть уверенными, что со state все отлично.

Основное преимущество Offensive programming — вы пишете меньше кода. Меньше кода — в меньшем количестве мест что-то может пойти не так. А значит, это требует меньше поддержки. Из минусов — если вы не обрабатываете эту ситуацию, то она должна быть обработана в другом месте, возможно другой командой или другой компанией. Где-то новый код все равно объявится.

⬛️ Еще раз — когда команды не падают из-за любой ошибки это хорошо, но это требует разработки более сложных программ. А сложные программы это плохо. Поэтому, если ситуация позволяет, можно использовать offensive programming и следить за тем, чтобы работал только happy path.

Используете Offensive programming? Пишите в комментариях.

#хардскиллы, 🌄Instagram |🤝Patreon

Про Developer Experience

Когда мы разрабатываем программное обеспечение мы думаем о многих его характеристиках — будет ли оно быстрым (efficiency)? будет ли оно надежным (reliability)? будет ли пользователю удобно его использовать (user experience)? Но одна из характеристик практически всегда остается неназванной вслух — будет ли удобно разрабатывать это ПО? Это свойство ПО можно назвать Developer Experience.

Представьте, что вы выходите на работу в новый перспективный стартап. В такой, где есть личный бариста ☕️. Бариста есть, а вот онбординга толком нет. Вам дали доступ в git, вы нашли там пять вроде бы нужных репозиториев. Что-то на Java, где-то React , а этим вы разобрались, а вот как все это запустить вместе — нет. В итоге вы ловите коллег и просите их помочь. Чтобы запустить проект локально вам понадобилась неделя. Это плохой DX.

Чтобы улучшить DX можно сделать следующее:

* README.md с описанием того как запустить проект локально, как настроить среду, как запустить тесты

* документация о технических процессах в команде — какая конвенция работы с git; как работаем с merge request — кто проверяет, какой врем ожидания проверки; как происходит релиз на продакшен

* в самом коде проекта минимальное количество неочевидных вещей. Время разработчика стоит дороже чем облачные вычисления. Оптимизировать DX, а не скорость.

* использование распостраненных стандартов, технологий и зависимостей, а не своих “велосипедов”. Здесь дополнительный плюс — документацию на эти модули за вас пишут люди в интернете.

Чем проще начать работать с вашим проектом, тем больше вероятность что кто-то захочет его улучшить. Даже если ваш проект проприетарный, вы можете относиться к нему как к open-source проекту, представьте, что с ним будут работать случайные люди в интернете.

⬛️ Еще раз — чем проще работать с вашим проектом, тем большая вероятность, что вам кто-то поможет. А когда кто-то помогает, это прекрасно, потому что это значит, что вам надо работать меньше. Хороший разработчик любит работать меньше, т.е. эффективно.

Как еще можно улучшить DX? Пишите в комментариях.

#софтскиллы, 🌄Instagram |🤝Patreon

Перевел для Хабра статью "как НЕ надо учить TypeScript".

ИМХО лучше подойдет тем, кто лишь начинает становиться на TypeScript рельсы. Кстати у автора статьи есть книга TypeScript in 50 lessons, которую я читал, там в конце начинается такая жесть (сложные примеры conditional types), что было страшно читать. Но приятно понимать какой уникальный микс получается если взять JavaScript и добавить гибкую типизацию. Такое невозможно в других языках программирования.

Всем новым (и старым) подписчикам с Хабра привет 👋

Статья