#messaging #arch
CAP vs exactly once
Как-то так получается, что на каждой галере приходится объяснять коллегам почему ни один message broker не умеет в exactly once и что не стоит ждать чуда от магической очереди, которая придет и подарит все те же гарантии, что и in-proc, при этом размазав нагрузку и сделав всё остальное, что мы там ждем от мессаджинга. Оставлю кэп-пост тут, если кому пригодится -- велкам
Ок, поехали, если нет exactly once, то что есть? Есть at most once, когда нам ок потерять сообщеньку, но дубли не допустимы и at least once, когда, наоборот, ок задублировать, но не ок потерять.
Как это работает: есть 2 стула push и pull, при первом сообщенька заталкивается консьюмеру и консьюмер рапортует, что он ее получил. На втором стуле консьюмер сам читает батчами и иногда говорит, что вот до сюда я отработал. Суть на самом деле в том, что брокер всегда ждет от консьюмера(ов) отмашки о том, запроцессил ли он сообщения или нет, и если нет, то принимается решение на основании установленной at * once политики.
Вернемся к exactly once. Какие же брокеры мы любим? Правильно, персистентные! Поэтому систему брокер-консьюмер можно представить в виде 2 хранилищ, которые надо держать строго консистентными при политике exactly once. А вот тут и всплывает CAP, который говорит, что в распределенных системах мы можем всегда расчитывать либо на доступность, либо на строгую консистентность. Недоступный брокер нам вряд-ли подходит(очередь останавливается, если какая-то сообщенька не обработана консьюмером), так что останавливаемся на AP-схеме. Что это значит применительно к гарантиям доставки: пусть сообщенька была успешно обработана подписчиком, но, по какой-то причине, сообщение о успешной обработке не было получено брокером. Что в этом случае будет делать брокер? Можно либо понадеяться, что сообщение доставлено, либо перепослать. Если перепослали, то нарушаем exactly once и получаем at least once, если оставляем, то теряем сообщение на аналогичном кейсе, где консьюмер все-таки не смог обработать сообщение, но получаем at most once.
На закуску, увлекательное чтиво про разные типы консистентности на примере бейсбола(правила знать не надо, там объяснят)

Как использовать стендбай в PostgreSQL

Константин Евтеев рассказывает в нашем англоязычном блоге на Медиуме о различных вариантах использования и конфигурации standby сервера.

В статье:

1️⃣ горизонтальное масштабирование с помощью репликации;
2️⃣ как использовать реплику для чтения и избежать stale reads;
3️⃣ возможные проблемы и решения при использовании стендбая с большим количеством запросов, применение DDL, отправка большого количества WAL-файлов в архив и восстановление из архива;
4️⃣ использование пула стендбаев и переключения запросов между ними;
5️⃣ восстановление после аварий с приведением в согласованное состояние мастера, стендбаев и архива.

Почитайте, если интересуетесь темой: http://bit.ly/2JO2sGW

#testing
Нашел тут очень сочный, но, походу, мертвый блог царя тестирования. И сразу же статья про unit vs integration testing: http://barancev.github.io/why-unit-tests-dont-catch-bugs/

Приседания с Terraform: рассказы бывалых.

#terraform #hashicorp

#messaging #arch
CAP vs exactly once 2
Что же делать если нельзя, но очень хочется? Good news everyone! Exactly once можно получить, если немного поколдовать с консьюмером!
Вернемся к предыдущим примерам: допустим мы настроили брокер как at least once и при попытке отправки ответа об успешном получении сломалась сеть и уведомление не дошло до брокера. Брокер отправит сообщеньку еще раз, а вот тут консьюмер может уже решить стоит ли ее обрабатывать. Варианта как добиться нужного поведения аж два:
Первый -- это использовать идемподентные сообщения. Т.е. такие, которые ничего не меняют в состоянии при применении несколько раз подряд. Тут можно вспомнить всеми любимый пример с остатком на банковском счете: сообщение "снять 10$" не идемподентно т.к. при применении несколько раз подряд ваш баланс может уйти в минус, а вот сообщение "теперь баланс равен 90$" уже вполне себе. Ок, допустим мы сделали сообщения идемподентными, но что делать с порядком? Вдруг из-за повторных попыток произойдет ситуация, что баланс клиента выставится в 90, но подтверждение до брокера не дойдет, потом мы получим сообщение о изменении баланса до 80, а уже после этого перепошлется сообщенька с 90? Ну некоторые брокеры гарантируют порядок, но даже если нет, то и эту ситуацию можно порешать 2м способом, а именно operationId.
Допустим, что каждая сообщенька имеет свой уникальный идентификатор(в большинстве брокеров это зашито, а если нет, то логику легко имплементировать самому). В этом случае можно завести на клиенте некое подобие лога транзакций, куда сохранять уже обработанные сообщеньки(транзакционно, конечно) и если сообщенька была прислана повторно, но уже обработана, то просто пропустить ее, отправив брокеру ответ об успешной обработке.
Ну и для особо стойких видос, где аж 3 часа вещают про мессаджинг: https://youtu.be/_3nKjCjt2uU

💬 Если у тебя, камрад, выходные оказались свободны, а за окном поливает дождь, попробуй пройти вот по этой ссылке https://www.usenix.org/conference/atc19/technical-sessions - там неприличное количество разных докладов и материалов с USENIX конференции.

#usenix

Тут лента выплюнула, что на 74 % порносайтов обнаружены трекеры Google. Удивляет даже не то, что корпорации следят за нами(это вроде ни для кого уже не секрет), а то что это гугл, а не баду, пьюр или тиндер. Хмм #идеядлястартапа

#design #java #patterns
Каталог с конским кол-вом паттернов всех сортов и расцветок: https://github.com/iluwatar/java-design-patterns имхо, не самый удобный каталог, но для каждого есть пример на java

Anomaly Detection for Dummies

This tutorial explores unsupervised anomaly detection for univariate and multivariate data. Covers a variety of detection strategies with python code snippets and screenshots.

Jupyter notebook: http://bit.ly/2O2PFp9

http://bit.ly/2O7unaa

Крис Койер на CSS-Tricks написал небольшую статью про работу с псевдоэлементами — «A Little Reminder That Pseudo Elements are Children, Kinda».

Вот основная мысль статьи. Псевдоэлементы ведут себя в родительских элементах точно так же как и обычные потомки. Например, если сделать грид на контейнере с пседоэлементом, то псевдоэлемент станет ячейкой этого грида. Это же справедливо и для флекс-контейнеров — внутри них псевдоэлемент становится флекс-элементом.

Взял на заметку, как получить стили псевдоэлемента из JavaScript. Для этого нужно использовать getConputedStyle с двумя аргументами:

const styles = window.getComputedStyle(
document.querySelector('.container'),
'::before'
);


Статья хорошая. Рекомендую почитать, чтобы разобраться в нюансах работы с псевдоэлементами.

#css #layout

https://css-tricks.com/a-little-reminder-that-pseudo-elements-are-children-kinda/

Отличное дополнение к Typeclassopedia:
https://github.com/thma/LtuPatternFactory

Kubernetes Failure Stories, or: How to Crash Your Cluster

Классный доклад от компании Zalando про то, с какими проблемами им пришлось столкнуться в процессе менеджмента 130ти кластеров Kubernetes.

https://youtu.be/LpFApeaGv7A

Build your own React

How does React really work? In this talk, you'll find out. You'll write a simplified version of React from scratch, based on the real source code, including: jsx, fibers, reconciliation, hooks, and more.

нашел тут bullshit bingo на все случаи жизни: https://www.bullshitbingo.net/cards/bullshit/ Спасибо https://news.1rj.ru/str/hexlet_ru/1228 за вдохновение!

Сегодня флейм немножко не про разработку, а про, прости госпаде, Агиле.
Так уж получилось, что довелось поработать на многих галерах и, что показательно, самые плохие результаты стабильно демонстрировали те, кто пытались натянуть кота на кактус, а именно, привозили BDSM, ретро и груминг в свой ватерфол и считали, что теперь у них всем Scrum'ам Scrum и вот теперь-то заживем.
Прикол в том, что Lean и Agile это не просто итеративный ватерфол + несколько митингов, а совершенно другая система ценностей на всем цикле разработки и всех уровнях кампании. Если разработчик все еще работает исключительно по детальной спеке, и не готов взаимодействовать с коллегами, учавствовать в проработке требований и пытаться всеми силами выпустить MVP что бы проверить продуктовую гипотезу, то у вас, простите, Срам, а не Скрам. Если тестирование не вовлечено в процесс и включается в процесс после разработки, то у вас тоже явно не агиле.
Процесс перехода очень сложный, трудоемкий и тернистый именно из-за перестройки системы ценностей, и перед внедрением м.б. стоит сначала задуматься, а подходит ли вам эта самая "гибкая" система? Может быть у вас это не работает(и это нормально), и не стоит гнаться за хайпом что бы потом присоедениться к толпе Agile-хейтеров?
Более того, мое личное мнение, что Agile в России построить невозможно куда сложнее чем в загнивающей из-за нашего менталитета. Почему-то на просторах СНГ гораздо меньше коммандных игроков, и больше индивидуалистов. Опять же, это не плохо(индивидуалисты, обычно, профессионально сильнее из-за постоянного стремления быть лучше соседа), но это еще один челендж по внедрению Аджайла(причем очень серьезный). Не зря ведь манифест Кокберна начинается с телеги про "самоорганизованные замотивированные комманды"

Мой коллега — Александр Воронянский — сегодня на хабре опубликовал статью про то, как наша команда Яндекс.Маркета доставляет фичи до пользователей — "От идеи до релиза. Детальный опыт фронтенда Маркета".

У нас работает более 40 фронтенд-разработчиков. В нашей ответственности находятся клиентская часть и Node.js BFF (Backend For Frontend). Мы работаем в контурах-командах, состоящих из разных специалистов: фронтендеры, бэкендеры, дизайнеры и продакт менеджеры. Любой человек из команды может предложить свою идею для улучшения сервиса, которая проходит оценку по системе GIST. Если идея хорошая, то команда начинает над ней работать. После того как написан код, пройдено ревью, тесты и другие проверки, фича попадает в релиз. Релизят у нас ребята из QA. Во время релиза проходит большое количество проверок: E2E-тесты, нагрузочные тесты, скриншот-тесты и т.п. Если всё ок, релиз попадает в престейбл (стейджинг). Там тоже проводятся проверки. После этого этапа свежий код релиза раскатывается по датацентрам.

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

#ci #process #yandex

https://habr.com/ru/company/yandex/blog/459960/

📺 По ссылке плейлист с видео, в которых Brendan Burns (один из создателей Kubernetes) про облака, и непосредственно про работу с Kubernetes рассказывает.

#видео #фидбечат #kubernetes

Очень крутой доклад про внутренности AWS Aurora.

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

На сторедж постгри давно ругались, но все же он работает. Вот только не cloud ready™.

Кстати, фича с fast clone заслуживает отдельно внимания. Ты прост жмешь клон и получаешь копию прода (по времени старт инстанции в авс). Мечта для стейджинга и CI.

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

слайды, если лень смотреть, большая часть показана https://www.slideshare.net/GrantMcAlister/dat305-deep-dive-on-amazon-aurora-postgresql?from_action=save

Тут недавно помогал джуниору разобраться с кодировками текста и после удивленного взгляда и лекции про разные кодировки и зачем это нужно созрела мысль, что очень много современных инженеров не очень сильны в основах computer science. Да, возможно, с современными инструментами и высокоуровневыми ЯП не нужно досконально знать спецификацию TCP/IP, но какой-то минимум, кмк, все-таки должен быть.
Более того, с одной стороны, спрашивать на собесе чувака про такое грешновато(из общих знаний щас на собесах выжили только алгоритмы и структуры, и то масса холиваров), а с другой стороны, можно ведь так и нанять синиора, который не в курсе про кеширование, буферизацию и считает, что биты в воздухе невидимые гномики друг-другу передают.

#books #computerscience
Вот, кстати, крутая книжка по сабжу. Не профессор Фортран, конечно, но тоже интересно)