В таком случае, я бы рекомендовал запланировать цикл статей и обыграть подходы заголовке, да хоть бы просто пронумеровать статьи, вместо оборывания нумерации в теле текста.
Мы в iCore знаем: универсального рецепта "правильного" DevOps не существует
DevOps это и есть универсальный рецепт, нюансы начинаются в трактовке, пожалуйста, найдите время ознакомиться с "Руководством по DevOps" (Джин Ким, Патрик Дебуа, Джон Уиллис, Джез Хамбл), чтобы примерно соответствовать методологии, и не верить ИИ генерации на слово.
Вот представь, что тебе доверили достроить за другим прорабом лабораторию на острове. Ты приходишь на объект, а там кроме недостроенного здания: огромный вентилятор (размером со здание), большой воздушный шар и комната набитая швабрами. Почесав голову, ты разбираешь этот хлам и доделываешь лабораторию. Сдаешь объект ученным, но через 5 минут они выбегают с криком: "УТЕЧКА ЯДОВИТОГО ГАЗА!!!".
- Как так-то, блять! Должно же работать! - в отчаянии кричишь ты и звонишь прошлому прорабу:
- Вася, у нас ядовитый газ потёк! В чем проблема?
- Не знаю, должно было все работать. Что-то в проекте менял?
- Немного, швабры вынес...
- Швабры потолок держали!
- Что??? Что, блять, извините???
- Говорю, швабры потолок держали. Над ними цистерны с газом были. Очень тяжелые, пришлось в комнату снизу швабры напихать.
- Ты хотя бы записку на двери повесил бы, что швабры для держания потолка! У нас тут ядовитый газ течет! Что нам делать?
- Включай вентилятор. Он сдует газ с острова.
- Я его, блять, демонтировал сразу же!
- Зачем?
- Зачем ты построил 120 тонный вентилятор? Ты не мог положить ящик блядских ПРОТИВОГАЗОВ?
- Ящик противогазов искать нужно, а вентилятор у меня с прошлого заказа оставался.
- Вася, я убрал твой вентилятор! Мы тут задыхаемся!
- Херли вы тогда там делаете? Садитесь на воздушный шар и уебывайте!
В компании, особенно крупной, особенно с высокой инженерной культурой, встречи 1 на 1 приносят больше вреда, и вот несколько аргументов почему:
Такие встречи неестественные и формальные: В хорошей инженерной культуре обратная связь даётся по делу и сразу. Форсированные беседы выглядят искусственными.
Микроменеджмент: Частые 1:1 могут восприниматься как контроль, а не поддержка.
Потеря времени: Хороший инженер сам знает, когда ему нужна помощь или совет. Форматные 1:1 отвлекают от основной работы.
Невозможность искренности: В «официальных» встречах сложно быть честным, особенно если есть иерархия.
Все члены команды должны вручную создавать (и пересоздавать) свои собственные самоподписанные сертификаты.
Так же как при использовании lcl.host и mkcert
Самоподписанные сертификаты нужно вручную добавлять в каждое хранилище доверия в системе.
Так же как при использовании lcl.host и mkcert
Домены app.localhost работают не везде, поэтому для небраузерных клиентов (например, curl) требуются записи в /etc/hosts или DNS-сервер разработки.
Какое-либо расширенное разрешение доменных имён не предо при использовании lcl.host и mkcert, и работает точно так же при использовании любого инструмента управления сертификатами.
Запуск приложений в локальных контейнерах требует постоянного обновления сертификатов и хранилища доверия.
Так же как при использовании lcl.host и mkcert
Описанные инструменты lcl.host и mkcert всего лишь упрощают работу с *самоподписанными сертификатами* и имеют те же ограничения, а так же дополнительно ограничивают использование, за счёт чего они и снижают требования к разработчику.
Я считаю, что прежде чем нахваливать ограниченный инструмент, стоит попробовать разобраться в принципе его работы, найти реальные преимущества перед другими, а затем уже рекомендовать новичкам.
если берётесь сравнивать, то сравнивайте по существу, например, helm это не только язык шаблонов, в отличии от jsonnet, а ещё и сервис доставки и менеджер пакетов
к слову, был когда-то проект приложения jsonnet к k8s
Собственно, примерно об этом статья
В таком случае, я бы рекомендовал запланировать цикл статей и обыграть подходы заголовке, да хоть бы просто пронумеровать статьи, вместо оборывания нумерации в теле текста.
DevOps это и есть универсальный рецепт, нюансы начинаются в трактовке, пожалуйста, найдите время ознакомиться с "Руководством по DevOps" (Джин Ким, Патрик Дебуа, Джон Уиллис, Джез Хамбл), чтобы примерно соответствовать методологии, и не верить ИИ генерации на слово.
Спасибо за статью, однако после прочтения не покидает чувство незавершённости...
Где подходы 2, 3 и другие?
https://pikabu.ru/story/chuzhoy_kod_5762938
Какие профессии реально может заменить ИИ?
редактора журнала
автора тетелеграм-канала
Вероятно, уже заменил
Даже ретроспективы в компании с высокой инженерной культурой — это плохой паттерн:
Повторение очевидного: В зрелой культуре проблемы обсуждаются сразу, а не по расписанию.
Круговорот банальностей: «Что пошло хорошо/плохо» быстро вырождается в формальность.
Без последствий: Часто ретро — это выговор без последующих изменений.
Выгорание от саморефлексии: Постоянное копание в процессе может деморализовать.
про еженедельное планирование (груминг), опять же в компании с высокой инженерной культурой:
Избыточное планирование: В командах с высокой зрелостью лучше работает pull-модель задач — без необходимости «грумить» заранее.
Интеллектуальный фоновый шум: Груминг ради оценки очков — это имитация продуктивности.
Потеря гибкости: Чем больше обсуждений заранее, тем сложнее адаптироваться к изменениям.
Инженеры ≠ менеджеры: Не все хотят участвовать в «покерных» дискуссиях. Это утомляет.
Про тимбилдинги, тоже при условии высокой инженерной культуры:
Форсированная социализация: Хорошие инженеры могут быть интровертами. Заставлять "веселиться вместе" снижает мотивацию.
Имитация культуры: Настоящая культура создаётся в совместной работе, а не в пейнтболе или Zoom-квизах.
Время ≠ результат: Лучше хорошо сработаться над сложной задачей, чем поиграть в мафию.
Псевдотерапия за счёт компании: Тимбилдинги не решают структурных проблем — только маскируют.
спасибо, отлично освоили чатгпт для статей
В компании, особенно крупной, особенно с высокой инженерной культурой, встречи 1 на 1 приносят больше вреда, и вот несколько аргументов почему:
Такие встречи неестественные и формальные: В хорошей инженерной культуре обратная связь даётся по делу и сразу. Форсированные беседы выглядят искусственными.
Микроменеджмент: Частые 1:1 могут восприниматься как контроль, а не поддержка.
Потеря времени: Хороший инженер сам знает, когда ему нужна помощь или совет. Форматные 1:1 отвлекают от основной работы.
Невозможность искренности: В «официальных» встречах сложно быть честным, особенно если есть иерархия.
простите, но Basilisk
Так же как при использовании lcl.host и mkcert
Так же как при использовании lcl.host и mkcert
Какое-либо расширенное разрешение доменных имён не предо при использовании lcl.host и mkcert, и работает точно так же при использовании любого инструмента управления сертификатами.
Так же как при использовании lcl.host и mkcert
Описанные инструменты lcl.host и mkcert всего лишь упрощают работу с *самоподписанными сертификатами* и имеют те же ограничения, а так же дополнительно ограничивают использование, за счёт чего они и снижают требования к разработчику.
Я считаю, что прежде чем нахваливать ограниченный инструмент, стоит попробовать разобраться в принципе его работы, найти реальные преимущества перед другими, а затем уже рекомендовать новичкам.
так как марка немецкая, то по алфавитному произношению букв в немецком языке
Бе эМ Ве
уж простите, но в механизме, чтобы он работал слаженно и долго, не клей нужен, а смазка
а книга подойдёт для внерабочего чтения, перевод хороший, автор рассказывает интересные типовые задачи, приводит примеры
если берётесь сравнивать, то сравнивайте по существу, например, helm это не только язык шаблонов, в отличии от jsonnet, а ещё и сервис доставки и менеджер пакетов
к слову, был когда-то проект приложения jsonnet к k8s
https://github.com/ksonnet/ksonnet
"ансибл"
"инвентарь"
хорошие слова, возьмите, пользуйтесь
кмк, скорее "умение идти на компромисс"
systems implementation diagram is from sebokwiki.org
typo in source name
ddns вроде https://www.nsupdate.info/ и portforward
не хотите заниматься выпуском и ротацией самостоятельно?
не хотите / не умеете / нет времени автоматизировать всё это?
посмотрите на готовые встроенные опции работы с let's encrypt у хостера или у вашего web / reverse proxy / api gateway сервера
например traefic / kong / openresty (nginx + lua) уже умеют это сами или с плагином