#patterns
Наткнулся тут на очень интересную мысль о том, что вместо валидаторов надо писать парсеры.
Т.е
Причина в том, что при парсинге система типов окажет вам неоценимую помощь, а так же, такой подход сохранит вас от антипаттерна Shotgun parsing.
За подробностями велкам в статью(осторожно, примеры на Хаскеле, но подход актуален и для систем с более слабой системой типов)
Наткнулся тут на очень интересную мысль о том, что вместо валидаторов надо писать парсеры.
Т.е
void ValidateJson(string s) throws BadJsonError //🤮
User ParseUserFromJson(string s) throws BadJsonError //👌Причина в том, что при парсинге система типов окажет вам неоценимую помощь, а так же, такой подход сохранит вас от антипаттерна Shotgun parsing.
За подробностями велкам в статью(осторожно, примеры на Хаскеле, но подход актуален и для систем с более слабой системой типов)
#algorithm #scala
Узнал про интересный алгоритм под названием Happy eyeballs.
Представьте, что DNS вернул вам на резолв-запрос ответ состоящий из N IP-адресов, при этом некоторые из них могут быть нерабочими, а некоторые очень долго отвечать. Наша задача, с одной стороны, найти рабочий узел с приемлемым временем отклика, а с другой, не рассылать кучу запросов по всем возможным узлам(ибо дорого).
Что интересно, реализация этого алгоритма является своего рода лакмусовой бумажкой для concurrency фреймворков, и по ссылке можно найти реализацию на scala ZIO и нескольких питонячьих фреймворках. Надеюсь челендж продолжится и можно будет увидеть реализации, например, на гошных горутинах
Узнал про интересный алгоритм под названием Happy eyeballs.
Представьте, что DNS вернул вам на резолв-запрос ответ состоящий из N IP-адресов, при этом некоторые из них могут быть нерабочими, а некоторые очень долго отвечать. Наша задача, с одной стороны, найти рабочий узел с приемлемым временем отклика, а с другой, не рассылать кучу запросов по всем возможным узлам(ибо дорого).
Что интересно, реализация этого алгоритма является своего рода лакмусовой бумажкой для concurrency фреймворков, и по ссылке можно найти реализацию на scala ZIO и нескольких питонячьих фреймворках. Надеюсь челендж продолжится и можно будет увидеть реализации, например, на гошных горутинах
Medium
Happy eyeballs algorithm using ZIO
A great example on how structured concurrency and high-level concurrency libraries help in creating understandable, concurrent code in…
Forwarded from dd if=/dev/stuff of=/dev/tg
Обнаружил, что мой доклад «Программирование на уровне типов на TypeScript: выжимаем из компилятора все соки» с эпамовского ITSubbotnik еще в начале декабря выложили на YouTube. Если вдруг кто-то хотел послушать, но не получилось быть на митапе вживую, то теперь есть возможность наверстать упущенное 🙂
Ну и напомню, что слайды и примеры доступны в репозитории на Гитхабе: https://github.com/YBogomolov/talk-typelevel-ts
Ну и напомню, что слайды и примеры доступны в репозитории на Гитхабе: https://github.com/YBogomolov/talk-typelevel-ts
YouTube
Программирование на уровне типов на TypeScript: выжимаем из компилятора все соки | Юрий Богомолов
Из моего доклада вы узнаете о нюансах системы типов TypeScript, которые позволяют сделать первые шаги в сторону формальной верификации программ.
Первая часть доклада посвящена тому, как можно заставить компилятор делать дополнительные проверки корректности…
Первая часть доклада посвящена тому, как можно заставить компилятор делать дополнительные проверки корректности…
#sre #alerting
Как-то пропустил статью от Фланта про инцидент менеджмент, а она прекрасна! С одной стороны там описан процесс здорового человека по работе с инцидентами, а с другой, очень грустно от того, что их alerting-поделие не опенсурс, т.к. если для graphite-стека есть восхитительная Moira, то у прома только alertmanager и мерзейший алертинг от графаны
Как-то пропустил статью от Фланта про инцидент менеджмент, а она прекрасна! С одной стороны там описан процесс здорового человека по работе с инцидентами, а с другой, очень грустно от того, что их alerting-поделие не опенсурс, т.к. если для graphite-стека есть восхитительная Moira, то у прома только alertmanager и мерзейший алертинг от графаны
Хабр
10 лет on-call. Чему мы научились? (обзор и видео доклада)
Осенью прошлого года на конференции DevOops 2019 прозвучал доклад «10 лет on-call. Чему мы научились?». В нём рассказывается о том, почему мы отказались от внутреннего «акселератора» по развитию...
Forwarded from Подлый апельсинчик
Строгие правила
Если ваша команда больше 2х человек, то без правил игры вам будет очень очень больно. Вам необходимо установить основные правила по процессам и разработке. Если у вас есть команда девопс посоветуйтесь с ними и делегируйте.
Процесс проверки соблюдения этих правил должен быть максимально автоматизированный и прозрачный. Да, да, вам придется поработать чтобы донести до всех как надо делать. Тогда не будет места для споров или пограничных ситуаций, только бездушная машина будет выносить вердикт.
Включите в процесс CI\CD автоматические проверки линтеров и тестов.
Убедитесь что бы было обозначено когда нужно написать юнит тест, а когда интеграционный.
Внедрите популярную модель ветвления (например от Vincent Driessen) и запретите делать исключения.
Запретите коммиты в ветке develop и master, разрешите мержи туда только тимлидам после прохождения тестов.
Обязуйте делать релизы только с тегами версии в которых есть логи изменений.
Запретите неинформативные коммит мессенджы.
Постройте и распишите жизненный цикл разработки фич. Постарайтесь обозначить связь конкретной задачи и фичи. Когда вы наладите эти процессы, вам станет намного легче.
Всегда, без исключений, когда я забивал на эти правила происходило что-то плохое. Сначала вы махнете рукой на одну мелочь, потом так сделают ваши тимлиды. По началу вы ничего не заметите. Возможно вы даже задумаетесь о либеральности, исключительных ситуациях. Что человек существо разумное иногда сам знает как лучше. Но потом пару косяков наложится друг на друга, и вы уже на пути к орбите на жопной тяге.
Если ваша команда больше 2х человек, то без правил игры вам будет очень очень больно. Вам необходимо установить основные правила по процессам и разработке. Если у вас есть команда девопс посоветуйтесь с ними и делегируйте.
Процесс проверки соблюдения этих правил должен быть максимально автоматизированный и прозрачный. Да, да, вам придется поработать чтобы донести до всех как надо делать. Тогда не будет места для споров или пограничных ситуаций, только бездушная машина будет выносить вердикт.
Включите в процесс CI\CD автоматические проверки линтеров и тестов.
Убедитесь что бы было обозначено когда нужно написать юнит тест, а когда интеграционный.
Внедрите популярную модель ветвления (например от Vincent Driessen) и запретите делать исключения.
Запретите коммиты в ветке develop и master, разрешите мержи туда только тимлидам после прохождения тестов.
Обязуйте делать релизы только с тегами версии в которых есть логи изменений.
Запретите неинформативные коммит мессенджы.
Постройте и распишите жизненный цикл разработки фич. Постарайтесь обозначить связь конкретной задачи и фичи. Когда вы наладите эти процессы, вам станет намного легче.
Всегда, без исключений, когда я забивал на эти правила происходило что-то плохое. Сначала вы махнете рукой на одну мелочь, потом так сделают ваши тимлиды. По началу вы ничего не заметите. Возможно вы даже задумаетесь о либеральности, исключительных ситуациях. Что человек существо разумное иногда сам знает как лучше. Но потом пару косяков наложится друг на друга, и вы уже на пути к орбите на жопной тяге.
#arch
В связи с громким постом из серии микросервисы нинужны, Сэм Ньюман написал ответочку, где объясняет когда же все-таки они нужны, а когда нет
З.Ы. узнал про закон Бетериджа: если заголовок статьи является вопросом, то ответ на этот вопрос — 100% "нет"
В связи с громким постом из серии микросервисы нинужны, Сэм Ньюман написал ответочку, где объясняет когда же все-таки они нужны, а когда нет
З.Ы. узнал про закон Бетериджа: если заголовок статьи является вопросом, то ответ на этот вопрос — 100% "нет"
Changelog
Monoliths are the future
Unpopular opinion! Monoliths are the future because the problem people are trying to solve with microservices doesn’t really line up with reality. Just to be honest - and I’ve done this before, gone from microservices to monoliths and back again. Both directions.
Тут вот вышла еще одна заметка про то как лучше всего заставлять девелоперов больше деливерить. В красном углу, как водится, дедлайн и бутылки за его несоблюдение, в синем, сплоченность, командный дух и прочие базворды.
Итог, разумеется, понятен, но я принес это не ради очевидных вещей, а ради шикарных критериев качественно выстроенных процессов в конце лонгрида. Рекомендую прям сравнить со своей галеркой
Итог, разумеется, понятен, но я принес это не ради очевидных вещей, а ради шикарных критериев качественно выстроенных процессов в конце лонгрида. Рекомендую прям сравнить со своей галеркой
#data #arch
Тут вот приехал лонгрид в двух частях про дата платфому LinkedIn'а(это тот который сделал Kafka, Goblin и Voldemort). Очень занимательное чтиво раз и два! Вот вы, например, знали, что Линкедин в Ажур заезжает?
Тут вот приехал лонгрид в двух частях про дата платфому LinkedIn'а(это тот который сделал Kafka, Goblin и Voldemort). Очень занимательное чтиво раз и два! Вот вы, например, знали, что Линкедин в Ажур заезжает?
Software Engineering Daily
LinkedIn Data Infrastructure - Software Engineering Daily
LinkedIn has become a staple for the modern professional, whether it’s used for searching for a new job, reading industry news, or keeping up with professional connections. As a rapidly growing platform that serves more than 675 million users today, LinkedIn…
This media is not supported in your browser
VIEW IN TELEGRAM
И вместо пятничного мема вот вам гифка на случай важных переговоров.
Если что, это Robert Martin, автор Clean Code
Если что, это Robert Martin, автор Clean Code
Forwarded from Инжиниринг Данных
А вот и про Airflow на русском, очень понятно написано, что такое DAG и Airflow. https://khashtamov.com/ru/apache-airflow-introduction/
Khashtamov
Введение в Apache Airflow
Также по теме Airflow:Apache Airflow и XComTaskFlow API в Apache Airflow 2.0Apache Airflow — это продвинутый workflow менеджер и незаменимый инструмент в арсенале современного дата инженера…
#haskell #scala #fp
Видосы с f(by) 2020. Есть прям огненные доклады. Для тех кто любит функциональщину -- маст вотч
Видосы с f(by) 2020. Есть прям огненные доклады. Для тех кто любит функциональщину -- маст вотч
YouTube
f(by) 2020 Conference - YouTube
Forwarded from ∏ρ؃uñçτØρ Øπτµç∑ | 👁🗨››››
ОНЛАЙН КОНФА PROFUNCTOR TALKS
- если тебе есть что рассказать про разработку или околоразработку то ты можешь стать спикером
- онлайн формат: стрим, сотни/тысячи зрителей, никаких билетов и гостиниц, можно из дома сидя в трениках
- дружелюбное коммьюнити, новые знакомства, веселее чем ты ожидаешь
- дата: TO BE ANNOUNCED
- формат: 20 минут на выступление, 10 минут на вопросы
- ПОДАЙ ЗАЯВКУ пока есть свободные слоты
- если тебе есть что рассказать про разработку или околоразработку то ты можешь стать спикером
- онлайн формат: стрим, сотни/тысячи зрителей, никаких билетов и гостиниц, можно из дома сидя в трениках
- дружелюбное коммьюнити, новые знакомства, веселее чем ты ожидаешь
- дата: TO BE ANNOUNCED
- формат: 20 минут на выступление, 10 минут на вопросы
- ПОДАЙ ЗАЯВКУ пока есть свободные слоты
GitHub
GitHub is where people build software. More than 100 million people use GitHub to discover, fork, and contribute to over 330 million projects.
Forwarded from Дашбордец
Полезно, конечно, учиться на своих ошибках, но лучше их избегать вовсе.
Коллекция предостережений проекта data-to-viz:
https://www.data-to-viz.com/caveats.html
P. S. Сам проект интересен в принципе, в нём также:
-обзор всех типов графиков
-дерево решений на основе формата входных данных;
- сюжетные примеры анализа.
Коллекция предостережений проекта data-to-viz:
https://www.data-to-viz.com/caveats.html
P. S. Сам проект интересен в принципе, в нём также:
-обзор всех типов графиков
-дерево решений на основе формата входных данных;
- сюжетные примеры анализа.
Forwarded from Записки админа
🔎 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
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
GitHub
GitHub - google/haskell-trainings: Haskell 101 and 102: slides and codelabs
Haskell 101 and 102: slides and codelabs. Contribute to google/haskell-trainings development by creating an account on GitHub.
#devops
Не так давно(https://news.1rj.ru/str/overtimehate/401 ) постил тред про матчасть контейнеров, а тут вот и инфографика подъехала!
Не так давно(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
Крайне рекомендую посмотреть. Во-первых, любопытно как Стил топит за добавление в Java дженериков (привет, golang) и перегрузки операторов. Во-вторых, сама подача материала - не хочу спойлерить, но форма подчеркивает содержание - программистам всегда нужно строить мелкие абстракции чтобы перебраться на более высокий уровень. И важно сделать это просто.
Ну и отдельный фан увидеть конференцию разработчиков 22 года назад: докладчик в пиджаке, в нагрудном кармане батарея из ручек, слайды на проекторе - обалденно.
https://www.youtube.com/watch?v=_ahvzDzKdB0
P.S. Можете еще почитать о самом Гае Стиле на википедии. Это один из гигантов computer science, и мы стоим на его плечах в том числе
#video
YouTube
Growing a Language, by Guy Steele
Guy Steele's keynote at the 1998 ACM OOPSLA conference on "Growing a Language" discusses the importance of and issues associated with designing a programming language that can be grown by its users.
ACM OOPSLA conference
Speaker: Guy L. Steele Jr.
ACM OOPSLA conference
Speaker: Guy L. Steele Jr.