Сейчас использую Notion для хранения общей информации и пет-проджект для хранения типовых решений (например Dockerfile + docker-compose для go, python, php - но с комментами и пояснениями почему так для каждой строчки которая не в руках), при обновлении докера соотвественно обновляю примеры (например когда новый тип кеширования завезли)

Два года платил за Miro, но в итоге оказалось не так удобно использовать. Evernote/OneNote крутые, но как то не прижелось по итогу.

Я сразу же отключил, так как сломался вывод моего zsh, с выводом гит ветки и прочего, автокомплит - меня устраивает тот что даёт zsh+плагины которые я сам выбрал и настроил. В плане визуализации, чтало меньше влезать контента, тоде минус

Один из моментов в том что это все меньше нужно рядовой компании, к примеру взять Talos - ни ssh, read-onle fs - обновление os/кубера одной командой

А если нужно обновить sysctl, то вот вам yaml-файл в котором можно задать нужные значения, хотя конечно, в этом случае понимание что под капотом будет не лишним, благо есть всякие hard way-туториалы в которых есть в том числе и про то что под капотом

Можно локально поставить npm-registry - например https://verdaccio.org/ (но на гитхабе есть и другие варианты) и проксировать зависимости через него - заодно и от падений npm/github защитит

О, да! Имел опыт разнорабочего в 14 и 17лет, мне даже нравилась размеренность жизни, режим дня - но быстро понимал что для меня это скучно, что условно еще пол года и все что нужно освоить я освою, а дальше 20лет монотонно одно и тоже

Поддерживаю, более того в варианте с APIFirst типовые запросы/ответы можно вынести в схемы и переиспользовать в более высокоуровневых элементах (все что касается авторизации, базовых ошибок, Item->Items, и т.д.) в итоге получаются вполне компактные спеки даже в средних по размеру проектах. Еще + в том что для изменения в формате логирования/трейсов/etc достаточно поменять темплейт и перегенерировать код

Как развитие идеи модулей - хорошо заходит DI - google/wire например, можно сделать набор провайдеров и потом через запятую указать нужные, в целом к этому при желании можно и promt-прикрутить что бы в диалоге прописать какие модули нужны для сервиса

p.s. генерация графана-дашбордов выглядит интересно, полезная вещь, было бы интересно посмотреть как генерите и какие метрики туда вносили (и почему добавили те или иные - тоже было бы интересно послушать)

Не увидел ссылки на продолжение этой истории - github.com/cmuratori/misc

Там автор статьи ведет обсуждение с дядюшкой Бобом. Каждый остался при своем, но дискуссия занятная

Собственно в плане Crossplane не очень понятно чем он дополняет Argo CD. Разве что создавать с нуля кластер, а дальше - управление БД - операторы для rabbitmq, kafka и так дают описать все что нужно в Helm-чарте и не понятно зачем использовать кастомный для конкретного кластера mysqlcluster если можно взять оператор, который не будет завесить от вендора

CoreOS была крутой OS, использовали долгое время, крутой механизм обновлений с откатом если что-то пошло не так на последнюю рабочую версию, синхронизация времени между машинами (etcd-кластер), протестированные докер/кубер из коробки и что самое главное - долгое время это была наиболее полная дока по работе с k8s на baremetal

А разве для этих кейсов не подойдет kyverno или OPA? Также можно задать правила и автоматически проверять, что у разработчиков все правильно (в плане описания информации о сервисах команды, что установлены лимиты по ресурсам, есть пробы).

• можно еще kind поднимать прямо в CI и прогонять тесты еще до деплоя в k8s - в этом случае, конечно, свои тесты имеют смысл.

Двояко, например в wire нельзя делать провайдеры которые возвращают одинаковую структуру (например когда у нас есть отдельно redis для кеша, отдельно для сессий и тп) - нужно писать свои врапперы, зато при падении (или получении nil как описано ниже в комментах) будет сразу понятно что ошибка возникла в wire_gen.go:37:5 RedisSessionStore - условно, и граф зависимостей виден в файле в виде линейной последовательности вызовов - ну и тестов особо не нужно, IDE подстветит код если сгенерировалось что-то не валидное, да и golang не даст скомпилировать неправильный код, хотя риск ошибок в рантайм конечно остается

wire особенно удобен в монорепах, можно сделать DefaultSet (с логером, трейсами, grpc-clients/server) и сильно сократить объем дублирования кода

p.s. хотя еще один момент что иногда стреляет в wire это то что он игнорит зависимости если их никто не требует явно, и бывает странно, вроде добавил в зависимости Tracer а в wire_gen.go он не попал, но это скорее повод подумать об рефакторинге кода и убраь не явные ожидания от окружения

p.s. еще DI неплохо использовать не только на уровне main.go но и на уровне модулей, что бы точно также объединить одной строчкой нужные репозитории, сервисы, домены - хотя это и спорное решение

Вопрос. Рассматривали ли вариант со статической генерацией графа зависимостей, например wire и если да, то почему выбор пал на uber.fx