Если кто-то один Dockerfile сломал, а другой потерял, то можно его почти полностью восстановить из готового образа:

docker run -v /var/run/docker.sock:/var/run/docker.sock --rm alpine/dfimage yourimage:tag

В событийно ориентированной архитектуре хуки довольно полезны: можно перед коммитом добавлять в транзакцию все события (transactional outbox, все дела), а после коммита — отправлять их в очередь сообщений. Однако стоит помнить, что количество соединений к базе ограничено и делать в них что-то длительное не стоит. И на эти грабли я наступил в процессе разработки, сделав отправку сообщений в RabbitMQ после коммита: соединения долго висели и в итоге кончались.

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

Уже потом нашел репозиторий-пост, в котором описан практически идентичный случай.

GitOps предполагает, что артефакты сначала создаются в репозитории, а потом синхронизируются с целью. Но в случае дашбордов это хоть и рабочий вариант, но очень болезненный: все-таки, большинство вещей “накликивается” через веб-морду, а не описываются через JSON (тем более, что в Grafana создать через UI одну панельку, а не весь дашборд, даже из готового JSON весьма нетривиально). При этом создание дашборда через CI позволяет его шаблонировать и относительно легко разворачивать на несколько сред (например, чтобы иметь одинаковый дашборд для stage и prod, если их дашборды в разных местах).

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

Если все обложить переменными, то тогда можно легко импортировать дашборд для внешнего использования. При импорте для другой Grafana будет автоматически предложено поменять все источники данных и, что самое важное, все константные переменные — так что в них можно забить все отличия, а в репозитории хранить только бэкапы. Таким образом можно и репе все хранить, и менять все более удобным способом.

Пост, в котором весьма сжато изложена эволюция web’а от статических страниц до-javascript’ной эпохи до современных MPA-фреймворков. Описаны проблемы, которые возникали в процессе развития этой экосистемы и подходы, которые применялись в фреймворках для их решения. Требует быть чуточку в теме, но в целом хорош для ответа на вопросы типа “чем отличается React от Vue” или “почему SPA уже не модно”.

Продолжаю делать Павликов, потому что все нужное как всегда глубоко закопано и надо выбирать стул. На этот раз на очереди internal, который ограничивает видимость элемента модулем (т.е. если он в какой-то библиотеке, то только библиотека имеет к нему доступ). Его очень любят использовать сами Jetbrains в Ktor, корутинах, Exposed и т.п.

Но на самом деле это только ограничение компилятора самого Kotlin — на уровне java нет никакой видимости “на уровне модуля”, и можно этот internal использовать как угодно. И на уровне Kotlin обойти его тоже элементарно: нужно всего лишь добавить @file:Suppress("INVISIBLE_MEMBER", "INVISIBLE_REFERENCE").

При этом многострадальный package-private, который сообщество хочет чуть ли не с релиза, в язык не добавляют. И очень смешно, что один из основных аргументов это “ну, все равно особо ни от чего не защищает, используйте internal”.

В общем, типичная позиция JetBrains — если хочется, то совместимость с java — священная корова, а если очень надо — то и плевать на нее.

Год назад была работа про использование ML для сортировок. А на прошлой неделе — статья в Nature про использование нейронок для умножения матриц. Что интересно, для поиска оптимального алгоритма задачу представили в виде игры и переиспользовали наработки от AlphaZero (которая обыгрывала чемпионов мира по шахматам, сеги и го).

Как сказал один из моих студентов: “Не знал, что нейронные сети можно использовать для чего-то полезного” :)

Поды, завершившиеся с ошибкой, могут висеть в кубере до посинения (тикет).

Чтобы почистить все руками, можно выполнить что-то вроде такого:

kubectl -n namespace delete pods --field-selector=status.phase=Failed

Хотя, конечно, лучше разобраться с первопричиной падения подов:)

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

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

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

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

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

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 так вообще с непонятными исключениями. Конкретных приемов, как все это подружить, Мартин, увы, не приводит, поэтому практическая польза не очень высокая, но как затравка для холивара — неплохая тема.