Тут вот интересное мнение по поводу Alpine: https://pythonspeed.com/articles/alpine-docker-python/ говорят, что для питона его не надо использовать, т.к. образы получаются больше и дольше собираются.
Не буду это комментировать, но мы всегда юзаем alpine, т.к. альтернатив особо и не видим
Не буду это комментировать, но мы всегда юзаем alpine, т.к. альтернатив особо и не видим
Python⇒Speed
Using Alpine can make Python Docker builds 50× slower
Alpine Linux is often recommended as a smaller, faster Docker base image. But if you’re using Python, it will slow down your build and make your image larger.
#gc #dotnet #go #java
Котики, с работой в последнее время завал, так что не особо получается отыскивать ништяки, но обещаю исправиться. А пока вот вам 3 нетленки про работу GC: раз, два, три.
З.Ы. в первой автор почему-то сильно бомбит от Go, но если блейм пролистать, то статья очень крутая
Котики, с работой в последнее время завал, так что не особо получается отыскивать ништяки, но обещаю исправиться. А пока вот вам 3 нетленки про работу GC: раз, два, три.
З.Ы. в первой автор почему-то сильно бомбит от Go, но если блейм пролистать, то статья очень крутая
Medium
Modern garbage collection
A look at the Go GC strategy
Forwarded from Пятничный деплой
Хабр
«Hadoop. ZooKeeper» из серии Технострима Mail.Ru Group «Методы распределенной обработки больших объемов данных в Hadoop»
Предлагаю ознакомиться с расшифровкой лекции "Hadoop. ZooKeeper" из серии "Методы распределенной обработки больших объемов данных в Hadoop" Что такое ZooKeeper, его место в...
Видосы с ZooKeeper митапа в фейсбуке. Много про тюнинг, конфигурацию и рецепты из разных крупных компаний(Facebook, Twitter, Cloudera и т.д.)
Engineering at Meta
ZooKeeper Meetup@Facebook: Advancing the state of distributed coordination
The annual ZooKeeper Meetup@Facebook covered new performance, scalability, and security features implemented at large-scale companies.
#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