I hate overtime – Telegram
I hate overtime
867 subscribers
129 photos
4 videos
54 files
961 links
Some DevOps, SRE and IT development stuff
Download Telegram
#patterns
Наткнулся тут на очень интересную мысль о том, что вместо валидаторов надо писать парсеры.
Т.е
void ValidateJson(string s) throws BadJsonError //🤮

User ParseUserFromJson(string s) throws BadJsonError //👌


Причина в том, что при парсинге система типов окажет вам неоценимую помощь, а так же, такой подход сохранит вас от антипаттерна Shotgun parsing.
За подробностями велкам в статью(осторожно, примеры на Хаскеле, но подход актуален и для систем с более слабой системой типов)
#algorithm #scala
Узнал про интересный алгоритм под названием Happy eyeballs.
Представьте, что DNS вернул вам на резолв-запрос ответ состоящий из N IP-адресов, при этом некоторые из них могут быть нерабочими, а некоторые очень долго отвечать. Наша задача, с одной стороны, найти рабочий узел с приемлемым временем отклика, а с другой, не рассылать кучу запросов по всем возможным узлам(ибо дорого).
Что интересно, реализация этого алгоритма является своего рода лакмусовой бумажкой для concurrency фреймворков, и по ссылке можно найти реализацию на scala ZIO и нескольких питонячьих фреймворках. Надеюсь челендж продолжится и можно будет увидеть реализации, например, на гошных горутинах
Обнаружил, что мой доклад «Программирование на уровне типов на TypeScript: выжимаем из компилятора все соки» с эпамовского ITSubbotnik еще в начале декабря выложили на YouTube. Если вдруг кто-то хотел послушать, но не получилось быть на митапе вживую, то теперь есть возможность наверстать упущенное 🙂
Ну и напомню, что слайды и примеры доступны в репозитории на Гитхабе: https://github.com/YBogomolov/talk-typelevel-ts
#sre #alerting
Как-то пропустил статью от Фланта про инцидент менеджмент, а она прекрасна! С одной стороны там описан процесс здорового человека по работе с инцидентами, а с другой, очень грустно от того, что их alerting-поделие не опенсурс, т.к. если для graphite-стека есть восхитительная Moira, то у прома только alertmanager и мерзейший алертинг от графаны
Строгие правила

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

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

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

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

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

З.Ы. узнал про закон Бетериджа: если заголовок статьи является вопросом, то ответ на этот вопрос — 100% "нет"
Тут вот вышла еще одна заметка про то как лучше всего заставлять девелоперов больше деливерить. В красном углу, как водится, дедлайн и бутылки за его несоблюдение, в синем, сплоченность, командный дух и прочие базворды.
Итог, разумеется, понятен, но я принес это не ради очевидных вещей, а ради шикарных критериев качественно выстроенных процессов в конце лонгрида. Рекомендую прям сравнить со своей галеркой
#data #arch
Тут вот приехал лонгрид в двух частях про дата платфому LinkedIn'а(это тот который сделал Kafka, Goblin и Voldemort). Очень занимательное чтиво раз и два! Вот вы, например, знали, что Линкедин в Ажур заезжает?
This media is not supported in your browser
VIEW IN TELEGRAM
И вместо пятничного мема вот вам гифка на случай важных переговоров.
Если что, это Robert Martin, автор Clean Code
#haskell #scala #fp
Видосы с f(by) 2020. Есть прям огненные доклады. Для тех кто любит функциональщину -- маст вотч
ОНЛАЙН КОНФА PROFUNCTOR TALKS

- если тебе есть что рассказать про разработку или околоразработку то ты можешь стать спикером
- онлайн формат: стрим, сотни/тысячи зрителей, никаких билетов и гостиниц, можно из дома сидя в трениках
- дружелюбное коммьюнити, новые знакомства, веселее чем ты ожидаешь
- дата: TO BE ANNOUNCED
- формат: 20 минут на выступление, 10 минут на вопросы
- ПОДАЙ ЗАЯВКУ пока есть свободные слоты
Forwarded from Дашбордец
Полезно, конечно, учиться на своих ошибках, но лучше их избегать вовсе.

Коллекция предостережений проекта data-to-viz:
https://www.data-to-viz.com/caveats.html
P. S. Сам проект интересен в принципе, в нём также:
-обзор всех типов графиков
-дерево решений на основе формата входных данных;
- сюжетные примеры анализа.
🔎 https://ihateregex.io/ - пачка примеров регэкспов, с объяснением того, как они работают. #линк #regexp
Forwarded from oleg_log (Oleg Kovalov)
Гугловцы опубликовали слайды по Хаскеллу.

Haskell is not one of the internally "blessed" languages, but a dedicated team of volunteers is making use of 20% time to try to make Haskell at Google possible.
(что правильно)

https://github.com/google/haskell-trainings

Собственно 2 пдф (92 и 182 слайда соотв)
https://github.com/google/haskell-trainings/releases/download/v1.0/haskell_101.pdf
https://github.com/google/haskell-trainings/releases/download/v1.0/haskell_102.pdf
#devops
Не так давно(https://news.1rj.ru/str/overtimehate/401 ) постил тред про матчасть контейнеров, а тут вот и инфографика подъехала!
Forwarded from Evo Dev Club
📼 И сразу добью шикарным докладом 1998 (!!!) года Гая Стила про развитие языков программирования.

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

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

https://www.youtube.com/watch?v=_ahvzDzKdB0

P.S. Можете еще почитать о самом Гае Стиле на википедии. Это один из гигантов computer science, и мы стоим на его плечах в том числе

#video
Однажды Хемингуея попросили написать самый короткий печальный рассказ: