Смотрите видео с выступления Сергея Долганова на #ДАМП с докладом про то, как типы и функциональный подход могут вдохнуть новую жизнь в создание контрактов для API:

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

И контракты и апи схемы и чуть-чуть Хаскеля! Прям все как мы любим! Наслаждайтесь!

📝 Коротко о том, что такое path юниты, и как с помощью systemd можно мониторить файлы в системе. https://www.redhat.com/sysadmin/introduction-path-units

#systemd #будничное #напочитать

⚙️ Любители sed'а, тут для вас интересное принесли - sed дебаггер - https://aurelio.net/projects/sedsed/ Занятная штука, попробуйте надосуге. 🙂

#bash #sed #фидбечат

Есть что-то в программировании красивое и завораживающее. Особенно, когда это круто визуализировано.

50+ алгоритмов сортировки за полчаса: https://youtu.be/FZ8FaztJGEo

Анкита Масанд написала статью про использование API для интернационализации приложений в JS — "New Intl APIs in JavaScript".

API интернационализации живёт в глобальном объекте Intl. В статье рассматривается несколько кейсов, где оно может быть полезно. Например, можно использовать Intl.RelativeTimeFormat для форматирования относительных дат ("минуту назад", "день назад", "через 10 дней" и т.п.). Intl.ListFormat для форматирования списков (можно использовать списки с конъюнкцией, дизъюнкцией или с обычным перечислением через запятую). Intl.NumberFormat используется для форматирования больших целых чисел (между разрядами числа в русскоязычном формате добавляются пробелы, в англоязычном — запятые). Для форматирования времени и дат используется Intl.DateTimeFormat.

Intl доступен во всех актуальных браузерах, но полнота имплементации от браузера к браузеру отличается. Например, Intl.RelativeTimeFormat не поддерживается в IE11 и Edge.

Не могу сказать, что в статье содержится исчерпывающая информация по Intl, тем не менее в ней есть хорошие кейсы его использования.

#js #i18n

https://blog.bitsrc.io/new-intl-apis-in-javanoscript-c50dc89d2cf3

Elements of Programming by Alexander Stepanov and Paul McJones is now free.

Книга чуток математичная, но вдруг кому-то надо. Кстати 2019, то есть самая новенькая.

http://elementsofprogramming.com/

Ох, люблю я такие блеймы: https://m.habr.com/ru/post/459992/ и все вроде бы по делу и правильно(хоть и не очень своевременно, все уже "сотку" сто лет как обхаяли), но чет все равно смешно

Если кто не в курсе, то предистория такая:
во времена позднего палеолита дяденьки задумались как бы описать ландшафт сложных IT систем, что бы понимать что от чего зависит, какие данные откуда куда текут, что где развернуто и т.д. Было много попыток, но щас канонической считается модель Кручтена(ну и куча других, построенных на ее основе). Упомянутый на хабре ISO — адаптация трудов Кручтена, а пресловутая "сотка" — вольный перевод этой адаптации.
ИМХО, сложно было ожидать качества от такого глухого телефона, но тем не менее.

#azure
У Azure в Azure SQL Database есть такая неприятная вещь как DTU: это некий попугай, измеряющий нагрузку на базу. Самое неприятное, что при прайс-модели в DTU(есть еще нормальный vCore, но за конский ценник) при привышении DTU-лимита ваши запросы к базе просто не будут обрабатываться.
Что такое DTU и как это посчитать\сконвертировать в обычные mcpu\iops'ы инфы тащем-то нету, но опытным путем было установлено, что огибающая DTU-графика совпадает с наиболее загруженной подсистемой базы. Т.е. если вы насилуете CPU, то DTU будет вести себя как CPU, а если диски в полке, то в полке будет и DTU.
Замониторить этот ад можно только ажуровскими средствами(как ажуровский мониторнг подружить с промом мы чет так и не разобрались)
Вобщем боль, ужас и бесперспективняк.
И вот тут дядя, наконец-то более-менее адекватно описал что и как с Azure'вским, прости господи, DBaaS'ом

Тут Nginx вебинар замутили про их ингрес в честь выхода 1.5

#database
Для тех кто как и я долго пытается найти тулзы для рисования схем базенок, расскажу про свой топ тулзов:
1. Очень долго пользовался штукой, которая называется vertabelo Из плюсов: красивые диаграмки, генерит норм скуль. Из минусов: коооонский ценник и небольшие проблемы с экспортом уже имеющихся базенок
2. Новая штука, которую еще не успел толком попробовать, но первые впечатления хорошие! Умеет все что и предыдущая, но есть Free-план и нормальный экспорт(правда не всех диалектов, но ребята работают над этим)
3. SSMS(великий и ужастный). Из плюсов: очень тесно связан с базой, так что все отрисованное моментально отображается на схему и обратно. Из минусов: жуткий UX и только SQLServer

ℹ️ Очень крутой, и регулярно обновляемый FAQ по Fedora. Всех, кто с этим дистрибутивом начинает знакомиться, можно смело отправлять по ссылке: https://russianfedora.github.io/FAQ/

#fedora #будничное #линк

Финальная компиляция #monadicmonday за июль на dev.to:
https://dev.to/ybogomolov/monadicmonday-compilation-july-4pal

Очередной доклад нашего техдира про Kubernetes, а если точнее — про управление ресурсами и автомасштабирование — в нашем блоге (https://habr.com/ru/company/flant/blog/459326) и на YouTube (https://www.youtube.com/watch?v=10ZR-fbyuSY).

#ux
Очень полезная штука https://m.habr.com/ru/post/459054/ при анализе UX(разумеется, если все детские проблемы уже порешали)

#frontend
Как-то пропустил очередной пост от Фаулера про микрофронтенд(фронтендовые микросервисы) https://martinfowler.com/articles/micro-frontends.html#TheExampleInDetail

Как по мне очень не однозначная идея. Ваще не понятно в чем бенефит по сравнению с feature slices + atomic design, зато вопрос "как это интегрировать" встает очень остро. Да, там предложены несколько вариантов, но что-то ни один не впечатлил

Стали доступны видео с SREcon19 Asia/Pacific 🎉
http://amp.gs/rlc5

И саммари по конференции в трех частях
http://amp.gs/rl6I http://amp.gs/rl6z http://amp.gs/rl6Y

P.S. А еще появились видео с ContainerDays 2019 🐳 http://amp.gs/rlc6
#srecon #videos

Что такое Zero Bug Policy и зачем эту политику стоит внедрять у себя?

Короткий ответ — в нашем видео. Подробнее о Zero Bug Policy — в нашем блоге на Хабре: bit.ly/z0bpc

#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.
На закуску, увлекательное чтиво про разные типы консистентности на примере бейсбола(правила знать не надо, там объяснят)