I hate overtime

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

#arch
В связи с громким постом из серии микросервисы нинужны, Сэм Ньюман написал ответочку, где объясняет когда же все-таки они нужны, а когда нет

З.Ы. узнал про закон Бетериджа: если заголовок статьи является вопросом, то ответ на этот вопрос — 100% "нет"

Строгие правила

Если ваша команда больше 2х человек, то без правил игры вам будет очень очень больно. Вам необходимо установить основные правила по процессам и разработке. Если у вас есть команда девопс посоветуйтесь с ними и делегируйте.

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

Включите в процесс CI\CD автоматические проверки линтеров и тестов.
Убедитесь что бы было обозначено когда нужно написать юнит тест, а когда интеграционный.
Внедрите популярную модель ветвления (например от Vincent Driessen) и запретите делать исключения.
Запретите коммиты в ветке develop и master, разрешите мержи туда только тимлидам после прохождения тестов.
Обязуйте делать релизы только с тегами версии в которых есть логи изменений.
Запретите неинформативные коммит мессенджы.

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

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

#sre #alerting
Как-то пропустил статью от Фланта про инцидент менеджмент, а она прекрасна! С одной стороны там описан процесс здорового человека по работе с инцидентами, а с другой, очень грустно от того, что их alerting-поделие не опенсурс, т.к. если для graphite-стека есть восхитительная Moira, то у прома только alertmanager и мерзейший алертинг от графаны

Актуальненько:
https://twitter.com/o_gabsferreira/status/1228291799912996864?s=09

Обнаружил, что мой доклад «Программирование на уровне типов на TypeScript: выжимаем из компилятора все соки» с эпамовского ITSubbotnik еще в начале декабря выложили на YouTube. Если вдруг кто-то хотел послушать, но не получилось быть на митапе вживую, то теперь есть возможность наверстать упущенное 🙂
Ну и напомню, что слайды и примеры доступны в репозитории на Гитхабе: https://github.com/YBogomolov/talk-typelevel-ts

чет я прям очень ору https://youtu.be/9wvEwPLcLcA

#algorithm #scala
Узнал про интересный алгоритм под названием Happy eyeballs.
Представьте, что DNS вернул вам на резолв-запрос ответ состоящий из N IP-адресов, при этом некоторые из них могут быть нерабочими, а некоторые очень долго отвечать. Наша задача, с одной стороны, найти рабочий узел с приемлемым временем отклика, а с другой, не рассылать кучу запросов по всем возможным узлам(ибо дорого).
Что интересно, реализация этого алгоритма является своего рода лакмусовой бумажкой для concurrency фреймворков, и по ссылке можно найти реализацию на scala ZIO и нескольких питонячьих фреймворках. Надеюсь челендж продолжится и можно будет увидеть реализации, например, на гошных горутинах

#patterns
Наткнулся тут на очень интересную мысль о том, что вместо валидаторов надо писать парсеры.
Т.е
void ValidateJson(string s) throws BadJsonError //🤮

User ParseUserFromJson(string s) throws BadJsonError //👌

Причина в том, что при парсинге система типов окажет вам неоценимую помощь, а так же, такой подход сохранит вас от антипаттерна Shotgun parsing.
За подробностями велкам в статью(осторожно, примеры на Хаскеле, но подход актуален и для систем с более слабой системой типов)

Видосы с ZooKeeper митапа в фейсбуке. Много про тюнинг, конфигурацию и рецепты из разных крупных компаний(Facebook, Twitter, Cloudera и т.д.)

https://habr.com/ru/post/487058/
#hadoop #zookeper

#gc #dotnet #go #java
Котики, с работой в последнее время завал, так что не особо получается отыскивать ништяки, но обещаю исправиться. А пока вот вам 3 нетленки про работу GC: раз, два, три.
З.Ы. в первой автор почему-то сильно бомбит от Go, но если блейм пролистать, то статья очень крутая

Тут вот интересное мнение по поводу Alpine: https://pythonspeed.com/articles/alpine-docker-python/ говорят, что для питона его не надо использовать, т.к. образы получаются больше и дольше собираются.
Не буду это комментировать, но мы всегда юзаем alpine, т.к. альтернатив особо и не видим

#sre
Открыл для себя https://www.learningfromincidents.io/ Это каталог материалов и бест-практисов по работе с инцидентами. Очень много крутых материалов и будет еще больше(судя по coming soon-разделам)

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

#db
Интересный подкаст про CDC и Debesium в частности

Впихивание и вынимание

Есть два способа управлять временем команды — через впихивание и через вынимание.

Самый распространённый способ в наших широтах — первый: просто берём все дела, которые нужно сделать, и впихиваем в людей, которые могли бы их сделать. Если плохо впихивается — трамбуем: главное получить обещание, а человек потом сам что-нибудь придумает.

У этого способа есть большая проблема — впихивание невпихуемого приводят к выпихиванию ранее впихнутого: задачи банально проёбываются. То, что вы только что с таким трудом впихнули в сотрудника, выпихивается вашими же руками на следующем сеансе впихивания.

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

Вынимание требует большей ответственности от руководителя: когда люди сами разбирают задачи, гораздо сложнее становится «сменить приоритеты» и отнять у человека задачу в пользу какой-то новой. Приходится думать — а точно ли тебе важна каждая задача, которую ты кладёшь в кучку? Может убрать что-нибудь, пока её случайно не взяли?

Тут такое дело: оказывается у grep'а в этом году юбилей! Старичку аж 45 стукнуло! И вот интересные размышления о том как делать софт, который сможет оставаться юзабельным и через 50 лет

#postgres #db
Оказывается в вики постгреса собраны не только лучшие практики, но и антипатерны. А вот тут сделали тулзу для проверки вашей базенки на предмет этих косяков