Фиг знает, иногда достаточно просто задать пару вопросов из того списка чтобы определить примерный уровень кандидата, а выдать кастомную задачку надо ещё уметь. Про пару pod'ов общающихся через интернет - слишком общий вопрос, который под собой вероятно имеет какую-то конкретную рабочую ситуацию, и кандидат должен постараться вытянуть из интервьюера достаточное количество подробностей чтобы о чем-то там рассуждать. Тоже впрочем полезный скилл, который имеет смысл проверять на собеседовании. Но для "понимания как кандидат думает" лучше дать четкую задачку на логику.
Мой пойнт в том, что задача не базовая. Оригинально nginx не очень рассчитан на то, чтобы работать в контейнеризированном окружении, а его настройка (даже без контейнеризации) это довольно комплексная задача, требующая понимания многих аспектов работы ОС и сети. Но, если речь про кубер, то нормальный кандидат как минимум должен спросить "эм, вы имеете ввиду настроить ingress?", ну и другие требования уточнить. Запустить пачку pod'ов с nginx'ом != развернуть nginx в кубере.
Если речь не про ingress, то вопрос должен быть "а что именно этот nginx должен делать?". И там даже для раздачи статического контента очень много о чем можно поговорить, кроме использования kubectl и определений ресурсов в YAML.
Нет смысла тестироваться на этой задаче в исходной постановке, ни на русском ни на английском. Она многократно встречается в датасетах на которых эти сетки обучались. Но стоит отметить что во многих бенчмарках используются подобные задачи, правда обычно чуть более простые.
Очень больно бывает когда в компании неожиданно падает мэнеджед кубер, а девопс инженеры считают разворачивание nginx базовой задачей и не знают с какой стороны к лежачему куберу подойти. Впрочем не обязательно ломать сам кубер, можно просто сервис сломанный дать и спросить как его чинить вообще.
Фиг знает, молодцы конечно, но подано это всё немного с преувеличениями. Году в 2013м трогал репозиторий сравнимого размера, на предмет перехода с svn. Размер чекаута основного бранча там был поменьше наверное на порядок, общий размер репы был под 100гб. При грамотной настройке клиентской системы git с полным репозиторием работал довольно шустро, хоть и не без проблем, и какая-то часть разработчиков даже пользовалась git-svn, правда только с нужными ветками и обычно используя sparse checkout. В итоге там решили писать свою систему контроля версий имени этого репозитория :-).
если авторы хотят сделать хорошее для других обитателей планеты, то странно ожидать за это вознаграждения
Авторы хотят заниматься любимым делом - разработкой открытого ПО, не в рамках интересов какой-то одной компании. И ищут пути монетизации своего труда. Это их право, не нужно указывать им что им делать.
интеллектуальная собственность — это фикция. В том числе потому, что её невозможно украсть
Не собираюсь спорить про формулировки, но поясню что имел ввиду: делаешь прошивку, говоришь "я разработал эту прошивку и имею все необходимые авторские права, делайте дальше что хотите" == украл интеллектуальную собственность. Возможно формулировка некорректна, не буду спорить.
доработал его для моего клиента и передал ему с соблюдением лицензии открытого проекта, то о каких нарушениях может идти речь
А клиент потом передавая свой продукт конечному потребителю будет соблюдать условия оригинальной лицензии?
Но вы, являясь разработчиком открытого ПО, получив вознаграждение в таком случае - всё равно молодец, об этом говорится в статье.
Особенно, если доработки отдали в апстрим, и занимаетесь поддержкой своих открытых библиотек, и не подписывали с заказчиком договоров по которым вам для выполнения заказа нужно нарушать чужие авторские права и условия лицензий.
Если такое действительно надо, то логично под vault выделить машинку (а лучше три, и пропатчить чтоб standby ноды запросы на чтение обрабатывали) хотя б с 16 ядрами, тогда не ляжет. Ну и в коде получения секретов в тестах добавить ретрай экспоненциальный.
Речь в статье не про мантейнеров пакетов debian, а про мантейнеров проектов, которые обязательно при этом являются разработчиками, но им приходится заниматься другими задачами чтобы проект оставался живым, причем на код иногда времени просто не остаётся. Но в целом, обычно команда мантейнеров opensource проекта == основные разработчики проекта.
Нужно взглянуть чуть шире. Откуда взялся тот открытый код, на котором зарабатывают "производители" прошивок? Производители эти чаще зарабатывают не на разработке открытого ПО, а на краже интеллектуальной собственности. Умудряясь делать это даже с теми проектами, лицензия которых разрешает коммерческое использование. Но статья не про них. А про тех, кто собственно пишет это ПО. Оглянитесь вокруг, в каждой квартире найдется не одно устройство, за разработку кода используемого в котором, разработчик получил не вознаграждение, а тонну гневных писем от просто неразобравшихся людей, хейтеров и прочих сумасшедших.
(сорян, промазал полем ответа)
Чем в таком кейсе не подошёл dynamic allocation?
И что помешало разбить процесс на несколько задач (на уровне оркестратора)?
Интересный факт, фанаты эппла и не подозревают о возможности подключения внешней видеокарты (и о том что на apple silicon такой возможности нет :-) ).
Вместо этого у эппла есть возможность продать фичу подключения нескольких мониторов :-).
В первом абзаце так много восторженных баззвордов заказанных маркетологами, что дальше уже не хочется читать.
Про подачу - куча воды и реклама телеграм канала в конце. В блоге компании. Туш.
Фиг знает, иногда достаточно просто задать пару вопросов из того списка чтобы определить примерный уровень кандидата, а выдать кастомную задачку надо ещё уметь. Про пару pod'ов общающихся через интернет - слишком общий вопрос, который под собой вероятно имеет какую-то конкретную рабочую ситуацию, и кандидат должен постараться вытянуть из интервьюера достаточное количество подробностей чтобы о чем-то там рассуждать. Тоже впрочем полезный скилл, который имеет смысл проверять на собеседовании. Но для "понимания как кандидат думает" лучше дать четкую задачку на логику.
Обычно как минимум один раз на каждую организацию, которая решает использовать Kubernetes :-).
Мой пойнт в том, что задача не базовая. Оригинально nginx не очень рассчитан на то, чтобы работать в контейнеризированном окружении, а его настройка (даже без контейнеризации) это довольно комплексная задача, требующая понимания многих аспектов работы ОС и сети. Но, если речь про кубер, то нормальный кандидат как минимум должен спросить "эм, вы имеете ввиду настроить ingress?", ну и другие требования уточнить. Запустить пачку pod'ов с nginx'ом != развернуть nginx в кубере.
Если речь не про ingress, то вопрос должен быть "а что именно этот nginx должен делать?". И там даже для раздачи статического контента очень много о чем можно поговорить, кроме использования kubectl и определений ресурсов в YAML.
Нет смысла тестироваться на этой задаче в исходной постановке, ни на русском ни на английском. Она многократно встречается в датасетах на которых эти сетки обучались. Но стоит отметить что во многих бенчмарках используются подобные задачи, правда обычно чуть более простые.
Это какое-то странное умение. Пример в указанной доке использует nginx как hello world. С тем же успехом там мог быть любой другой сервис.
Очень больно бывает когда в компании неожиданно падает мэнеджед кубер, а девопс инженеры считают разворачивание nginx базовой задачей и не знают с какой стороны к лежачему куберу подойти. Впрочем не обязательно ломать сам кубер, можно просто сервис сломанный дать и спросить как его чинить вообще.
Фиг знает, молодцы конечно, но подано это всё немного с преувеличениями. Году в 2013м трогал репозиторий сравнимого размера, на предмет перехода с svn. Размер чекаута основного бранча там был поменьше наверное на порядок, общий размер репы был под 100гб. При грамотной настройке клиентской системы git с полным репозиторием работал довольно шустро, хоть и не без проблем, и какая-то часть разработчиков даже пользовалась git-svn, правда только с нужными ветками и обычно используя sparse checkout. В итоге там решили писать свою систему контроля версий имени этого репозитория :-).
Впрочем это не всегда важно, и один из вариантов - действительно пойти в корпорацию, о чем в статье тоже говорится.
Нет.
Авторы хотят заниматься любимым делом - разработкой открытого ПО, не в рамках интересов какой-то одной компании. И ищут пути монетизации своего труда. Это их право, не нужно указывать им что им делать.
Не собираюсь спорить про формулировки, но поясню что имел ввиду: делаешь прошивку, говоришь "я разработал эту прошивку и имею все необходимые авторские права, делайте дальше что хотите" == украл интеллектуальную собственность. Возможно формулировка некорректна, не буду спорить.
А клиент потом передавая свой продукт конечному потребителю будет соблюдать условия оригинальной лицензии?
Но вы, являясь разработчиком открытого ПО, получив вознаграждение в таком случае - всё равно молодец, об этом говорится в статье.
Особенно, если доработки отдали в апстрим, и занимаетесь поддержкой своих открытых библиотек, и не подписывали с заказчиком договоров по которым вам для выполнения заказа нужно нарушать чужие авторские права и условия лицензий.
Я тоже иногда использую HR как психолога, но лучше этим через чур не увлекаться, и всё таки найти профильного специалиста.
Если такое действительно надо, то логично под vault выделить машинку (а лучше три, и пропатчить чтоб standby ноды запросы на чтение обрабатывали) хотя б с 16 ядрами, тогда не ляжет. Ну и в коде получения секретов в тестах добавить ретрай экспоненциальный.
И у них, внезапно, не меньше проблем с
заработкоммонетизацией этого своего труда, чем у мантейнеров дистрибуции.Речь в статье не про мантейнеров пакетов debian, а про мантейнеров проектов, которые обязательно при этом являются разработчиками, но им приходится заниматься другими задачами чтобы проект оставался живым, причем на код иногда времени просто не остаётся. Но в целом, обычно команда мантейнеров opensource проекта == основные разработчики проекта.
Нужно взглянуть чуть шире. Откуда взялся тот открытый код, на котором зарабатывают "производители" прошивок? Производители эти чаще зарабатывают не на разработке открытого ПО, а на краже интеллектуальной собственности. Умудряясь делать это даже с теми проектами, лицензия которых разрешает коммерческое использование. Но статья не про них. А про тех, кто собственно пишет это ПО. Оглянитесь вокруг, в каждой квартире найдется не одно устройство, за разработку кода используемого в котором, разработчик получил не вознаграждение, а тонну гневных писем от просто неразобравшихся людей, хейтеров и прочих сумасшедших.