В крупных или микросервисных архитектурах самый важный сервис не всегда самый производительный и бывает не предназначен для хайлоада. Обычно это бэкенд: он теряет время на обработке данных и ожидании ответа между ним и СУБД. Даже если само приложение масштабируется легко, это узкое место не масштабируется совсем. Как эту проблему решить и обеспечить высокую производительность, расскажет Олег Нижников. https://habr.com/ru/company/oleg-bunin/blog/466295/

Ладно, время возвращаться к программированию и инженерие.

Недавно открыл для себя просто потрясающую книгу по системному мышлению от Анатолия Левенчука: https://ridero.ru/books/sistemnoe_myshlenie/
Она же в виде курса на Курсере: https://ru.coursera.org/learn/system-thinking

По моему убеждению, инженер-программист (акцент на слове «инженер») просто обязан обладать рациональным, логичным, последовательным мышлением для того, чтобы моделировать окружающий мир и выражать эти модели и их взаимосвязи в своей работе. Вещи, о которых говорит Анатолий в своих трудах, как раз позволяют выработать навыки системного мышления. Эти навыки будут только усиливаться, если параллельно заниматься изучением теории типов и теории категорий. Их тоже можно рассматривать как инструменты моделирования реальности, а чем больше таких инструментов будет в вашем арсенале, тем точнее вы сможете доносить свои идеи.

P.S. Кстати, у Анатолия очень крутой блог в ЖЖ: https://ailev.livejournal.com, советую внести в закладки, как минимум.

#books
Как вы, наверное, уже заметили, у меня есть нездоровая любовь к литературе из серии "для чайников" и вот на днях я наткнулся на такое про...deep learning! Кароч я прямо в восторге. На пальцах(и питоне) обрисован весь минимальный мат. аппарат для сетей. Из либ только NumPy. В результате прочтения появляется представление что такое DL, зачем он нужен и как работает. Ошибки присутствуют, но не много, перевод годный. Кароч 10 байесов из 10!
P.S. в серии есть еще книжка про алгоритмы и структуры, тоже годная

Фред Шот — автор библиотеки pika — опубликовал статью с рекомендациями по настройке bundler-free окружения для разработки современных web-приложений — "Building without bundling: How to do more with less".

Может возникнуть резонный вопрос: "Зачем избавляться от бандлера?". В начале статьи Фред подсчитывает количество времени, которое отнимает у разработчиков сборка проекта. Для больших проектов, которые запускаются за 42 секунды и пересобираются за 11 секунд, время ожидания может занимать более часа (для 40-часовой рабочей недели).

Если вы используете у себя в проекте модульную систему из ES2015, сборка проекта необязательна, так как все современные браузеры уже поддерживают модульность в JS. Проблема остаётся с node_modules, которые могут содержать спецификаторы, которые браузер не сможет разрезолвить, или с node-специфичным кодом, например, process.env.NODE_ENV. Для решения этих проблем Фред предлагает использовать его библиотеку pika, которая преобразует код из node_modules в esm-бандлы. По сравнению с традиционными бандлерами у такого подхода есть преимущество — это преобразование надо запустить только один раз после npm install. Для работы с JSX предлагается использовать библиотеку htm.

Описанный в статье подход — это возврат к той простоте, с которого начинался web. Очень рекомендую прочитать статью, если у вас большое приложение, которое собирается долго и вы хотите что-то с этим сделать.

#bundler #web #dx

https://blog.logrocket.com/building-without-bundling/

Вот это прямо очень-очень! Как-то так уж получается, что с современными микросервисными реалиями сборка бекенд(ов) происходит быстро, а вот фронтенд, по крайней мере, у нас собирается конское количество времени. И вот, похоже, мучениям приходит конец! Да и сама pika выглядит перспективненько

#frontend
Вот тут сделали тулзу для поддержки микрофронтендов: https://blog.nrwl.io/monorepos-and-react-microfrontends-a-perfect-match-d49dca64489a
Вроде бы первая не велосипедная

Написали новость про очередной service mesh для Kubernetes: https://habr.com/ru/company/flant/news/t/466627/

Гоферы на фестивале стрит-арта в Одинцово. Кстати, москвичам очень советую сгонять!

#sre
Тут Олег(@oleg_log) принес интересную пдфку про то как надо проектировать сервисы чтобы нипадало. Можно рассматривать как краткую выжимку из Нейгарда/sreBook или как еще один чек-лист готовности к проду. В любом случае годно

#ml
Как готовить линейную регрессию(вдруг у вас она что-то нормальное напредсказывает😂) В статье чутка теории про МНК, QR, градиентный спуск, если в универе прогуляли или забыли)

​Издательство Wiley, которое выпускает серию «Для чайников» часто под этим же брендом публикует совместные издания с разными компаниями. В этой подборке три книги по теме мониторинга.

Alert Correlation for Dummies (совместно с BigPanda)

AIOps for Dummies (совместно с FixStream)

Network Monitoring for Dummies (совместно с Solarwinds)

# source map

https://teletype.in/@opendevcast/SyYaunCHB

#js #security
@aspirin_pp

Нашел тут видос 2хлетней давности про то как устроен Slack. Кароч, парни, как-то вот у них все и без ваших кафок-кубернетесов-микросервисов работает.
Более того, судя по стек-шаре они и до сих пор так работают и отлично себя чувствуют

#fp #books
Ой, котаны, че откопал! Ловите знаменитый курс по ФП из Кембриджа от Харрисона с переводом. Достаточно академизма, достаточно примеров, все прям шикарно.
Готовая пдфка в релизах репы, собрать из сорцов у меня не получилось(возможно плохо собирал)

Из разговора с коллегой:
"Основная проблема индустрии в том, что 90% кода пишется либо джунами, которые еще не читали Макконела, либо мидлами, которые уже читали Эриха Гамму"(с). Чет в голосину

Котаны, я тут давно одну мысль вынашиваю, вот решил поделиться. Речь пойдет о DRY и инкапсуляции в ООП.
Все 100 раз слышали мантру, что дублировать код грешновато и надо инкапсулировать дублирующуюся функциональность, используя все имеющиеся для этого средства вашего любимого ЯП(наследование, композицию, все чудеса GoF и т.п.). Обычно тут аппелируют к расширяемости, поддерживаемости и т.д.
В теории все шоколадно конечно, но в постоянно меняющейся среде все эти замечательные абстракции могут превратиться в тыкву протекающие, коллеги начнут путаться в этих бесконечных "фабриках сервисов стратегий" и в один прекрасный день кто-то все это снесет, построив на руинах еще одну такую же башню из слоновой кости. Знакомо?
Более того, в модных нынче микросервисах дублирование считается нормальным(ну по-крайней мере меньшим грехом чем связность сервисов как в классическом SOA). Оттуда же растет популярность сервисных каркасов(шаблонов проектов типа create-react-app или dotnet new), где через cli создается костяк проекта, который можно менять как душе угодно.
Кароч вот такая мысль, что думаете?
Мое мнение, что тут отлично работает правило 3х: 3 раза задублировал, значит надо инкапсулировать, а до этого нинада.
UPD: речь тут не про выделение кода в методы, а скорее, про ООП головного мозга с абстрактными классами, хелперами и всякими мутными стратегиями на каждый чих

Новый перевод как прекрасная иллюстрация важности понимания тонкостей Kubernetes для обеспечения должного уровня безопасности: https://habr.com/ru/company/flant/blog/466625/