Forwarded from Defront — про фронтенд-разработку и не только
Ровно год назад появился Defront. Канал начался с простой идеи — начать читать минимум одну статью каждый день и делать небольшой tldr, чтобы в будущем быстро находить нужные статьи. Но несколько недель спустя стало понятно, что канал несёт пользу не только мне, но и сотням разработчиков, а сейчас уже почти трём тысячам.
Хочу поблагодарить за помощь в развитии канала:
Сергея Рубанова (@juliarderity — очень крутой канал про web-стандарты и новинки web'а от участника TC39)
Олега Ковалёва (@oleg_log — самый лучший канал про бэкенд и go)
И, конечно, передаю привет всем дружественным каналам и сообществам (если кого-то забыл, пишите в лс):
@we_use_js @cyberhermitage
@sysadmin_tools @overtimehate
@odinraznepitonist @ithueti
@UkropsDigest @evodevclub
@lord_alfred @ch_11
@schopenhauer_was_right
@testerinlife @ufostation
@javanoscript_ru @css_ru
@forwebdev @winterview
Спасибо всем за помощь и поддержку! Следующий год будет ещё лучше.
P.S. Если считаете нужным, можете сделать подарок каналу и рассказать про Defront своим друзьям, коллегам и подписчикам.
https://twitter.com/myshov/status/1222444224571899905
Хочу поблагодарить за помощь в развитии канала:
Сергея Рубанова (@juliarderity — очень крутой канал про web-стандарты и новинки web'а от участника TC39)
Олега Ковалёва (@oleg_log — самый лучший канал про бэкенд и go)
И, конечно, передаю привет всем дружественным каналам и сообществам (если кого-то забыл, пишите в лс):
@we_use_js @cyberhermitage
@sysadmin_tools @overtimehate
@odinraznepitonist @ithueti
@UkropsDigest @evodevclub
@lord_alfred @ch_11
@schopenhauer_was_right
@testerinlife @ufostation
@javanoscript_ru @css_ru
@forwebdev @winterview
Спасибо всем за помощь и поддержку! Следующий год будет ещё лучше.
P.S. Если считаете нужным, можете сделать подарок каналу и рассказать про Defront своим друзьям, коллегам и подписчикам.
https://twitter.com/myshov/status/1222444224571899905
Twitter
Alexander Myshov
Сегодня день рождения у Defront! Первый год прошёл очень круто — каждый день выходил минимум один пост (не пропустил ни одного дня) и сейчас у канала почти 3000 подписчиков. Если вы интересуетесь web'ом и фронтендом, welcome! https://t.co/guY6ahL8b7
#k8s
Во-первых, котаны и котанессы, в блоге Фланта очередное пополнение: обзор Calico. Обзор годный, рекомендую. В начале достаточно годное введение в CNI и плагины, потом сабж с ссылками
Во-вторых, из обзора узнал, что оказывается в Azure AKS можно(теперь) CNI плагины приделывать!
Во-первых, котаны и котанессы, в блоге Фланта очередное пополнение: обзор Calico. Обзор годный, рекомендую. В начале достаточно годное введение в CNI и плагины, потом сабж с ссылками
Во-вторых, из обзора узнал, что оказывается в Azure AKS можно(теперь) CNI плагины приделывать!
Хабр
Calico для сети в Kubernetes: знакомство и немного из опыта
Цель статьи — познакомить читателя с основами сетевого взаимодействия и управлением сетевыми политиками в Kubernetes, а также со сторонним плагином Calico, расширяющим стандартные возможности....
#postgres #db
Оказывается в вики постгреса собраны не только лучшие практики, но и антипатерны. А вот тут сделали тулзу для проверки вашей базенки на предмет этих косяков
Оказывается в вики постгреса собраны не только лучшие практики, но и антипатерны. А вот тут сделали тулзу для проверки вашей базенки на предмет этих косяков
Тут такое дело: оказывается у grep'а в этом году юбилей! Старичку аж 45 стукнуло! И вот интересные размышления о том как делать софт, который сможет оставаться юзабельным и через 50 лет
Forwarded from FEDOR BORSHEV
Впихивание и вынимание
Есть два способа управлять временем команды — через впихивание и через вынимание.
Самый распространённый способ в наших широтах — первый: просто берём все дела, которые нужно сделать, и впихиваем в людей, которые могли бы их сделать. Если плохо впихивается — трамбуем: главное получить обещание, а человек потом сам что-нибудь придумает.
У этого способа есть большая проблема — впихивание невпихуемого приводят к выпихиванию ранее впихнутого: задачи банально проёбываются. То, что вы только что с таким трудом впихнули в сотрудника, выпихивается вашими же руками на следующем сеансе впихивания.
Второй способ — вынимание — более доброжелателен. Мы просто раскладываем перед командой кучу со всеми делами, которые у нас есть, а они уже сами вынимают то, что могут сделать. Задача руководителя — фасилитировать процесс так, чтобы у каждого участника оказалось как можно больше дел, подходящих именно ему.
Вынимание требует большей ответственности от руководителя: когда люди сами разбирают задачи, гораздо сложнее становится «сменить приоритеты» и отнять у человека задачу в пользу какой-то новой. Приходится думать — а точно ли тебе важна каждая задача, которую ты кладёшь в кучку? Может убрать что-нибудь, пока её случайно не взяли?
Есть два способа управлять временем команды — через впихивание и через вынимание.
Самый распространённый способ в наших широтах — первый: просто берём все дела, которые нужно сделать, и впихиваем в людей, которые могли бы их сделать. Если плохо впихивается — трамбуем: главное получить обещание, а человек потом сам что-нибудь придумает.
У этого способа есть большая проблема — впихивание невпихуемого приводят к выпихиванию ранее впихнутого: задачи банально проёбываются. То, что вы только что с таким трудом впихнули в сотрудника, выпихивается вашими же руками на следующем сеансе впихивания.
Второй способ — вынимание — более доброжелателен. Мы просто раскладываем перед командой кучу со всеми делами, которые у нас есть, а они уже сами вынимают то, что могут сделать. Задача руководителя — фасилитировать процесс так, чтобы у каждого участника оказалось как можно больше дел, подходящих именно ему.
Вынимание требует большей ответственности от руководителя: когда люди сами разбирают задачи, гораздо сложнее становится «сменить приоритеты» и отнять у человека задачу в пользу какой-то новой. Приходится думать — а точно ли тебе важна каждая задача, которую ты кладёшь в кучку? Может убрать что-нибудь, пока её случайно не взяли?
Все, конечно, слышали про то, что в чистых функциональных языках простое канкаренси из-за чистоты, иммутабельности и т.д.
Вот вам статья, где во всей красе демонстрируется канкаренси Хаскеля. С одной стороны, это действительно выглядит круто и очень...элегантно что-ли. Но с другой стороны, там достаточно много машинерии на теоркате, без которой на вашем любимом ЯП канкаренси все равно останется адом(а самим построить то же самое смогут только тайпкласс-бояре)
Вот вам статья, где во всей красе демонстрируется канкаренси Хаскеля. С одной стороны, это действительно выглядит круто и очень...элегантно что-ли. Но с другой стороны, там достаточно много машинерии на теоркате, без которой на вашем любимом ЯП канкаренси все равно останется адом(а самим построить то же самое смогут только тайпкласс-бояре)
FP Complete
Transformations on Applicative Concurrent Computations
We wrote a data type called Conc, which provides for more efficient concurrent computations. Come read how you can use this in your Haskell code today!
#sre
Открыл для себя https://www.learningfromincidents.io/ Это каталог материалов и бест-практисов по работе с инцидентами. Очень много крутых материалов и будет еще больше(судя по coming soon-разделам)
Открыл для себя https://www.learningfromincidents.io/ Это каталог материалов и бест-практисов по работе с инцидентами. Очень много крутых материалов и будет еще больше(судя по coming soon-разделам)
Тут вот интересное мнение по поводу 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.