Немного капитана очевидности.

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

Ни для кого не секрет, что для закрепления навыка его надо регулярно использовать. И причем использовать для чего-то, должна быть какая-то цель, а не просто “ну, надо поизучать” или “все это делают и мне надо делать”. Для достижения этой цели, возможно придется, не побоюсь этой фразы, “выйти из зоны комфорта” — специально делать что-то не в привычном русле и не с помощью регулярно применяемого и освоенного навыка, а с использованием нового.

Но при этом не стоит забывать о балансе и хоть немного использовать справочный материал, чужой опыт и т.п., а не проламывать стену методом тыка:) Слишком большой упор на практику может отрезать пути к глубокому пониманию процессов.

Хотелось бы конечно иметь бесконечный кластер, но, увы, за расходами все равно следить надо.

kubectl get nodes --no-headers | cut -f1 -d\  | xargs -I {} sh -c 'echo {} ; kubectl describe node {} | grep Allocated -A 5 | grep -ve percent -ve -- ; echo '

Выведет потребление в формате

ip-1-2-3-4.some.host.cluster
  Resource                    Requests      Limits
  cpu                         1610m (83%)   3450m (178%)
  memory                      2566Mi (35%)  5478Mi (76%)

Занятный доклад Мартина (aka Uncle Bob, автор кучи книг по ООП, в т.ч. “Чистый код”) про то, как надо делить код на компоненты.

TLDR:

1. Чем сложнее проект, тем больше вероятность, что он провалится.
2. Coupling (связанность) — это плохо, O(n^2), с его возрастанием снижается продуктивность, найм новых людей не работает, т.к. они не знают всех нюансов “так исторически сложилось”, делают ошибки и все становится еще хуже.
3. Минимально число однонаправленных связей = N-1, и это дерево. Но если добавить только 1 связь, получится цикл, и будет циклическая зависимость, и все может сломаться, как цепная реакция.
4. Компонент — это бинарный модуль, который может быть задеплоен независимо — dll, exe, jar. Неймспейсы/пакеты — не компоненты, но могут им соответствовать. (Хотя лично я считаю, что ничего этому не мешает). Компоненты обязательно должны содержать классы (вроде умный чел, но слышал ли он, что есть программирование без классов?)
5. Система компонентов, удобная для использования, неудобна для разработки и наоборот, она зависит от потребителей. На ранних стадиях она может быть удобной для разработки, на поздних — для пользователя.
6. Три первых принципа находятся в противоречии друг с другом, надо искать баланс.
7. Не надо упаковывать ни по фичам, ни по пакетам, потому что у разных компонентов разные причины для изменения.
8. Множественное наследование не реализовали не для защиты пользователей, а потому что сложно написать компилятор, который его поддерживает:))

Собственно принципы:

1. Release Equivalency Principle — есть процесс релиза с версиями. Самый маленький компонент — это самый маленький кусок кода, который вы хотите переиспользовать.
2. Common Closure Principle — SRP для компонента. Новая фича должна затрагивать ровной один компонент. Т.е. классы, которые изменяются по одной причине, должны быть в одном компоненте. “Все классы для работы с БД должны быть в одном компоненте” (sic!).
3. Component Reuse Principle — Первый компонент зависит от второго, во втором поменялась какая-то мелочь, и первый пришлось обновлять/он сломался, хотя он и не зависел от этой мелочи. Такого быть не должно: если можно использовать только часть компонента, то надо его выделять в отдельный.
4. Acyclic Dependencies Principle — зависимости компонентов между собой не должны создавать цикла.
5. Stable Dependencies Principle — лучше зависеть от того, что тяжело изменить. Забавная аналогия: есть “взрослые компоненты”, которые не зависят от других, но от которых зависят многие, и “детские”, которые “безответственны”, но зависят от многих. И более нестабильный компонент должен зависеть от менее нестабильного, иначе легкий для изменения компонент перестанет быть таковым.
6. Stable Abstractions Principle — на верхних уровнях все должны быть максимально конкретны, на нижних, от которых все зависят — максимально абстрактны. Но это касается только тех компонентов, которые активно развиваются и не касается всяких библиотечных классов, от которых все зависят, но при этом они очень конкретны.

Я может чего-то не понимаю, но под все эти принципы идеально подходит is-even/left-pad, и я не думаю, что экосистема npm — это эталон. В целом вроде доклад “умный”, но 1, 4 и 5 — очевидны, 2 и 3 противоречивы, 6 так вообще с непонятными исключениями. Конкретных приемов, как все это подружить, Мартин, увы, не приводит, поэтому практическая польза не очень высокая, но как затравка для холивара — неплохая тема.

Часто можно услышать разговоры, что вот раньше-то ПО было оптимизированным, а сейчас все жрет ресурсы как не в себя, особенно память. Но на это часто следует ответ, что сейчас больше абстракций, функции и т.п. и на самом деле это нормально.

Прошлогоднее исследование зависимостей java-проектов показало, что с 2011 по 2021 среднее число неиспользованных транзитивных зависимостей возросло с 20 до 60, и оно растет для большинства проектов. Т.е. бесполезный мусор на самом деле есть, и его размер растет.

Для чистки зависимостей рекомендуют использовать плагин DepClean, разработанный, разумеется, авторами статьи. Но, что иронично, с собственными зависимостями у этого плагина все не очень гладко, потому что там внутри две CVE :)

Вообще на первый взгляд развернуть в облаке сервис звучит как неплохая идея — зачем тратить время на трахание с железом или с настройкой какой-то базы, когда можно “потыкать пару кнопочек” и все будет работать “само”. Тем более, что в облаке сейчас уже есть почти все: базы на любой вкус, куберы всякие, CDN, OAuth, метрики, аналитики, сертификаты, хранилища секретов и т.д., даже бэкенд целиком можно себе накликать (см. Firebase или AWS Amplify). Все это с интеграцией между собой и кучей плюшек из коробки.

Однако “all magic comes with a price”:

1. Трахание с железом и сервисами на самом деле заменяется на трахание с настройками и нюансами облачного провайдера. Причем если опыт с сервисами и железом плюс-минус переносимый, то у каждого провайдера свои приколы, разумеется.
2. Отдельно выделю вопросы распределения ролей, настроек доступов и прочих аспектов связанных с ИБ. Про свой опыт с гуглом уже рассказывал. Во всем это зрелый DevOps может на неделю сгинуть для простой задачи, а разраб — вообще умереть.
3. Облачные версии сервисов часто представляются собой форк опенсорсных со своими “расширениями” (например, амазоновский OpenSearch — это форк ElasticSearch), обычно от старой версии. Иногда присутствует EEE во всей красе. Причем расширения обычно нужны для интеграции в облачную экосистему и хреново поддерживаются, а решение для опенсорсного варианта может не подойти для облачного.
4. Поскольку сервисом управляете не вы, то может не получится его тонко настроить или поставить какие-нибудь плагины.
5. Как следствие, возникает привязка к облачному провайдеру, когда съехать с облака становится очень дорого, потому что все настройки или даже архитектура заточены под него.
6. Условия могут внезапно поменяться к худшему и это может быть затратно (например, недавно Heroku убрал бесплатный тариф)
7. Конфиденциальность — гомоморфное шифрование пока не применяют, так что облачный провайдер имеет доступ ко всем данным.
8. Если что-то сломается, то вы ничего не сможете с этим поделать, только ждать и надеяться, что все будет быстро исправлено.
9. Ложная уверенность в 100% надежности облака могут привести к тому, что ночью никто не будет дежурить и следить за работоспособностью сервиса (впрочем, и без облаков это можно делать).

Получается, что если вы делаете что-то стандартное, то облака дают быстрый и (иногда) дешевый старт, а с ростом будете наталкиваться на ограничения. Тогда уже и стоимость будет выше, и слезть с облаков будет тяжело. Но для какого-нибудь пет-проекта или эксперимента это может и нормально. Может, я старомоден, но мне кажется, что купить/арендовать железку в дата-центре хоть и будет дороже в краткосрочной перспективе, но даст больше преимуществ и гибкости в долгосрочной. Крупняки так вообще свои облака строят.

Жизненная гипотеза: чем больше людей в компании, тем больше времени тратится на совещания и организацию работы, продвигаются те, у кого лучше подвешен язык, а те, кто собственно работу делают — уходят. В итоге ничего и не делается. Много усилий тратится на поддержание процессов, регламентов, отчетости и т.п., и в итоге результаты могут получаться по остаточному принципу. Формализация процессов, которая часто возникает при увеличении количества людей, хорошо работает для простых или однообразных задач, однако мешает при выполнении сложных задач. Сильная формализация затрудняет оценку достижений (а без формализации никак, потому что будут конфликты интересов), что может сильно демотивировать сотрудников, особенно если ценится только героизм устранения последствий, а не кропотливость их предотвращения.

В больших организациях часто более заметен принцип Питера: “В иерархической системе каждый индивидуум имеет тенденцию подняться до уровня своей некомпетентности”. При всем этом большие организации — это обычно стабильно: большая инерция для изменений (как положительных, так и отрицательных).

В (нормальных) маленьких компаниях меньше стоит проблема контроля и они лучше адаптируются к изменениям, но и риски там обычно выше. При этом менеджерам проще уделять внимание рядовым сотрудникам.

Интересно, что в некоторых компаниях решили проблему размера разделением на несколько мелких. Эдакие компании-микросервисы. Это забавно коррелирует с заявлениями в стиле “Наша компания большая, про нее много плохих отзывов, но все зависит от департамента/отдела/команды, вот у нас-то все классно!”

Иногда требуется проверить, что приложение нормально восстанавливает свою работу после обрыва соединения. Можно, конечно, грохать сетевое подключение целиком, но влиять на работу других приложений — так себе идея, а если все еще и локально происходит, то грохать loopback интерфейс — совсем грустно.

Лучше убивать подключения более гранулярно. Для этого может пригодиться утилита tcpkill — во время ее работы она будет обрывать подключения по фильтру. Например,

sudo tcpkill -i lo port 5672

будет убивать все подключения к локальному RabbitMQ. Можно оборвать только часть подключений с помощью подобной колбасы:

sudo netstat -natp | grep ':5672' | grep java | head -n10 | awk '{print $4}' | cut -d':' -f2  | xargs -L1 -P10 sudo tcpkill -i lo port

Тут с помощью netstat выводятся все активные подключения, фильтруются по исходящему порту и приложению, обрезаются до исходящего порта и режутся по нему (я в шоке, что написал это без гугла).

Оказывается, alias работает только для первого слова. Поэтому, если создать alias

alias ll='ls -lF'

то ll будет работать, а вот sudo ll — нет. Однако если текст alias заканчивается на пробел, то следующее за ним слово тоже будет проверено на alias. Т.е. если добавить

alias sudo='sudo '

то sudo ll будет работать.

Во всяких DDD и CQRS очень часто возникают команды и события. Объединяет их обычно то, что они обычно пересекают границы домена или контекстов, обрабатываются асинхронно и представляют собой (возможно устаревшие) ошметки информации о системе. На ранних стадиях проекта очень легко попасть в ловушку и реализовать их практически одинаково с технической точки зрения (а то и вовсе не разделять). Однако между ними на самом деле довольно много различий.

Семантическое. Команда и событие выражают разные сущности. Событие — это бизнес сущность, “что-то произошло”, обычно существительно + краткое причастие (например, “заказ создан”). Команда — это приказ, “надо что-то сделать”, и чаще это техническая сущность (например, “отправь e-mail”).

Количество потребителей и производителей. У команды “потребитель” ровно один — исполнитель команды, а у события — от 0 до бесконечности, причем они могу быть из разных доменов. Команду может дать кто угодно, а произвести событие о том, что “что-то случилось” — только одна сущность.

Срок жизни. Команду сделал и забыл (удалил), а событие обычно стоит сохранить для истории.

Порядок обработки. Обычно для команд не важен порядок обработки, потому что заранее команду создавать — это как-то тупо. А вот события лучше обрабатывать последовательно: вряд ли будет логично обработать сначала доставку заказа, а потом его создание (особенно если при этом клиенту шлется уведомление).

Как следствие, и технологии для потока команд и потока событий обычно стоит выбирать соответствующие: для команд лучше подойдут решения типа RabbitMQ, а для событий — Kafka.

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