QA это не столько тесты гонять, сколько про стратегию обеспечения качества (если у вас не так, то это просто был неправильный QA). Тут часто цитируют Сунь-Цзы:
Стратегия без тактики - это самый медленный путь к победе. Тактика без стратегии - это просто суета перед поражением
Когда есть функциональные и нефункциональные требования, для которых определены измеримые атрибуты качества, построены тест планы с четким пониманием что за тест-кейсы в них содержатся и зачем они там нужны, то кому писать автотесты или хелсчеки вопрос тактический.
Я часто вижу в командах такую ситуацию. Разработчики сильно погружены в детали, для того чтобы хорошо держать рамки снаружи. Тим лид же считает, что ему по долгу службы не положено заниматься подобными вещами. В итоге проект, оставшись без QA, ещё какое-то время летит по инерции на прежних наработках и ребята рапортуют об успехах. Но за этим стоит постоянно наростающая энтропия - вариация на тему техдолга.
Предложите варианты дополнительного заработка внутри компании для тех кому нужна подработка.
В любой компании есть какие-то несрочные, но важные задачи. Расценки можно выставлять ниже рынка. Предложение все равно будет конкурентоспособным из-за меньшей нагрузки на администрирование и успокоения различных моральных тараканов в голове.
Да, это создаёт определенные трения между "основным" проектом и остальными. Но это процессные издержки, которые вы сами можете легко контролировать. Результаты работы в любом случае достанутся компании, а не внешним конкурентам.
Ну при том, что оно обеспечивает среду для вашего существания. Мета-модели, если угодно: с образованием, деньгами, зарабатыванием, бизнесами и всем остальным. Действительно, среда не идеальна, но что в этом мире есть действительно идеального?
Сделайте. Пока это вашиличные деньги, государству до этого дела нет. Вот обмениваться с другими уже не получится, иначе нарушается баланс.
Граждане это ресурс, который принадлежит государству. Оно дает бизнесу попользоваться вами в общих интересах и прибыль вы потом тоже должны делить на троих.
Демосфен говорил, что уважающий себя эллин имеет трёх жен: супругу для продолжения рода, рабыню для чувственных утех и гетеру для душевного комфорта. Но при таком раскладе женщин на всех, видимо, не хватало и общество пошло по пути оптимизации - либо три-в-одном, либо ни как. Естественно, что в природе такое встречается ещё реже и количество недовольства и стаданий среди мужей только выросло).
Деньги это фактически имущество государства, которыми вам дали попользоваться. Они тут были до вашего рождения и останутся после вашей смерти. Налогами оно лишь возвращает свое назад, и то не все, а только часть. Какие могут быть претензии?)
Развитие персонала это дорогое удовольствие и крайне неблагодарное в наше нестабильное время. Если готового проще взять с рынка, тогда это просто деньги на ветер.
У ЦК и КФК есть общий интерес к сотрудникам: больше доить и меньше кормить. Поэтому все лишнее оптимизируется и у первых на это практически ни когда не нужных денег, а у вторых - времени. Поскольку так происходит во многих компаниях, то это равновесное состояние.
На практике под видом развития чаще предлагаются дешёвые около -мотивационные программы для удержания на одном месте. Т.е. это не апгрейд, а техническое обслуживание для продления срока службы ресурса. Но рано или поздно сотрудник все равно поломается и будет заменен новым.
Ubuntu bionic это 18.04, с поддержкой только cgroups v1. При попытке запустить что-то более-менее свежее будут не особо очевидные проблемы с правами. Зачем это предлагать в 2023?
Вообще Docker Compose позиционируется как инструмент для локальной разработки. Именно поэтому он устанавливается лишь как опция. Отсюда связка с Ansible выглядит немного анекдотично. Зачем? Для продакшн у них Docker Stack в стандартной коробке - с конфигурацией в том же формате, но иными механизмами хранения secrets, масштабирования и т.п.
Docker compose v2 выпустили в 2020. Примерно с тех же времён v1 они не рекомендуют к использованию. v1 не поддерживает многие опции, описанные в актуальной документации. Сейчас эти знания могут пригодиться лишь для работы с каким-то легаси на локалхосте.
Если статья не про docker, а про Ansible, то невооружённым взглядом видно, что код из примеров не пройдет даже элементарные проверки ansible-lint. Разве это не показатель уровня материала?
На мой взгляд, статья выглядит как калькуляция где-то устаревших, а где-то и вредных советов. Хотя для новичка, который только входит в тему, качество материала скорее всего будет не очевидным. Я бы мог понять, если бы такой материал опубликовал школьник или студент в личном блоге. Но как текст от компании, предлающей образовательные программы, вызывает разные вопросы.
Конечно, docker-compose (v1) как в статье, уже давно не поддерживается. Может OTUS специально добавляют ляпы, чтобы запутать новичков и те шли получать актуальные знания на рекламируемых курсах? Либо уровень курсов и правда такой...
Добавьте отсутствие ресурсного плана, анализа рисков, нефункциональных требований, инфраструктуры и получится идеально трешовый проект где дали порулить командами каким-то детям без совести и образования.
Не-а, первыми приезжают спасатели - разгребать завалы для минимизации последствий. А строители привезут свою технику когда уже всех спасут, спланилуют, посчитают и выделят бюджет на реконструкцию, если руководство не решит оставить все как есть и строить в другом, более безопасном месте.
Можно гонять строителей через весь город чинить водопровод или выносить мусор на уже сданном объекте. Но цена такого решения копеечных проблем - срывы строительства новых домов на миллионы денег. Поэтому так обычно не делают. Локальными вопросами занимаются отдельные люди кто отвечает за коммунальное хозяйство (то же саппорт из мира ЖКХ).
Тактика отдавать разработчикам фикс багов в наказание, чтобы сами от них же страдали, это больше из области мотивации персонала, нежели реального управления проектами. На практике какой-то эффект это может давать первый месяц, когда по старой памяти они могут быстрее разобраться в проблеме, чем люди со стороны. Но на длинных дистанциях особого толку нет - они уже все забудут или уволятся. Поэтому на системном уровне это не решение, если у вас длинные проекты.
An estimate is not a commitment. По моему в этом суть всех Agile методологий. Если руководство воспринимает эту идею не как ценность, а как проблему, значит выбран не тот подход к управлению и все остальное просто следствия.
Загуглите "L3 support". В жизненном цикле продукта большая часть затрат приходится не на разработку, а на эксплуатацию. Поэтому то, как решаются вопросы поддержки, принципиально влияет на точность эстимаций ваших разработчиков, если вся поддержка остаётся у них в скоупе до конца дней. Команда, которая строит звездолёт с нуля у себя в ангаре, и команда которая строит звездолёт с нуля, параллельно не давая упасть уже построенному на Альфе Центавра это две принципиально разные ситуации в плане ресурсов и управления.
Могли бы начать с себя и проверять тексты законов и постановлений по этим словарям. Заодно отработали методику бы. А так звучит как идея для стартапа. Интересно кто первым запилит сервис?
Статья больше похожа на SEO кликбейт, с целью собрать внутри популярные ключевые слова и не спалиться. По содержанию пропущены важные структурные концепции (модель коммуникации OSI, например), поэтому выглядит как поток сознания какой-то нейронки.
QA это не столько тесты гонять, сколько про стратегию обеспечения качества (если у вас не так, то это просто был неправильный QA). Тут часто цитируют Сунь-Цзы:
Когда есть функциональные и нефункциональные требования, для которых определены измеримые атрибуты качества, построены тест планы с четким пониманием что за тест-кейсы в них содержатся и зачем они там нужны, то кому писать автотесты или хелсчеки вопрос тактический.
Я часто вижу в командах такую ситуацию. Разработчики сильно погружены в детали, для того чтобы хорошо держать рамки снаружи. Тим лид же считает, что ему по долгу службы не положено заниматься подобными вещами. В итоге проект, оставшись без QA, ещё какое-то время летит по инерции на прежних наработках и ребята рапортуют об успехах. Но за этим стоит постоянно наростающая энтропия - вариация на тему техдолга.
Предложите варианты дополнительного заработка внутри компании для тех кому нужна подработка.
В любой компании есть какие-то несрочные, но важные задачи. Расценки можно выставлять ниже рынка. Предложение все равно будет конкурентоспособным из-за меньшей нагрузки на администрирование и успокоения различных моральных тараканов в голове.
Да, это создаёт определенные трения между "основным" проектом и остальными. Но это процессные издержки, которые вы сами можете легко контролировать. Результаты работы в любом случае достанутся компании, а не внешним конкурентам.
Ну при том, что оно обеспечивает среду для вашего существания. Мета-модели, если угодно: с образованием, деньгами, зарабатыванием, бизнесами и всем остальным. Действительно, среда не идеальна, но что в этом мире есть действительно идеального?
Сделайте. Пока это ваши личные деньги, государству до этого дела нет. Вот обмениваться с другими уже не получится, иначе нарушается баланс.
Граждане это ресурс, который принадлежит государству. Оно дает бизнесу попользоваться вами в общих интересах и прибыль вы потом тоже должны делить на троих.
Демосфен говорил, что уважающий себя эллин имеет трёх жен: супругу для продолжения рода, рабыню для чувственных утех и гетеру для душевного комфорта. Но при таком раскладе женщин на всех, видимо, не хватало и общество пошло по пути оптимизации - либо три-в-одном, либо ни как. Естественно, что в природе такое встречается ещё реже и количество недовольства и стаданий среди мужей только выросло).
Деньги это фактически имущество государства, которыми вам дали попользоваться. Они тут были до вашего рождения и останутся после вашей смерти. Налогами оно лишь возвращает свое назад, и то не все, а только часть. Какие могут быть претензии?)
Развитие персонала это дорогое удовольствие и крайне неблагодарное в наше нестабильное время. Если готового проще взять с рынка, тогда это просто деньги на ветер.
У ЦК и КФК есть общий интерес к сотрудникам: больше доить и меньше кормить. Поэтому все лишнее оптимизируется и у первых на это практически ни когда не нужных денег, а у вторых - времени. Поскольку так происходит во многих компаниях, то это равновесное состояние.
На практике под видом развития чаще предлагаются дешёвые около -мотивационные программы для удержания на одном месте. Т.е. это не апгрейд, а техническое обслуживание для продления срока службы ресурса. Но рано или поздно сотрудник все равно поломается и будет заменен новым.
Лично вам - плюсик, остальное - тому кто прочитает.
Ubuntu bionic это 18.04, с поддержкой только cgroups v1. При попытке запустить что-то более-менее свежее будут не особо очевидные проблемы с правами. Зачем это предлагать в 2023?
Вообще Docker Compose позиционируется как инструмент для локальной разработки. Именно поэтому он устанавливается лишь как опция. Отсюда связка с Ansible выглядит немного анекдотично. Зачем? Для продакшн у них Docker Stack в стандартной коробке - с конфигурацией в том же формате, но иными механизмами хранения secrets, масштабирования и т.п.
Docker compose v2 выпустили в 2020. Примерно с тех же времён v1 они не рекомендуют к использованию. v1 не поддерживает многие опции, описанные в актуальной документации. Сейчас эти знания могут пригодиться лишь для работы с каким-то легаси на локалхосте.
Если статья не про docker, а про Ansible, то невооружённым взглядом видно, что код из примеров не пройдет даже элементарные проверки ansible-lint. Разве это не показатель уровня материала?
На мой взгляд, статья выглядит как калькуляция где-то устаревших, а где-то и вредных советов. Хотя для новичка, который только входит в тему, качество материала скорее всего будет не очевидным. Я бы мог понять, если бы такой материал опубликовал школьник или студент в личном блоге. Но как текст от компании, предлающей образовательные программы, вызывает разные вопросы.
Похоже, в физике грядут темные времена, и чем дальше тем темнее.
Конечно, docker-compose (v1) как в статье, уже давно не поддерживается. Может OTUS специально добавляют ляпы, чтобы запутать новичков и те шли получать актуальные знания на рекламируемых курсах? Либо уровень курсов и правда такой...
Больше похоже на partial application, чем curry. //зануда мод
Добавьте отсутствие ресурсного плана, анализа рисков, нефункциональных требований, инфраструктуры и получится идеально трешовый проект где дали порулить командами каким-то детям без совести и образования.
Не-а, первыми приезжают спасатели - разгребать завалы для минимизации последствий. А строители привезут свою технику когда уже всех спасут, спланилуют, посчитают и выделят бюджет на реконструкцию, если руководство не решит оставить все как есть и строить в другом, более безопасном месте.
Можно гонять строителей через весь город чинить водопровод или выносить мусор на уже сданном объекте. Но цена такого решения копеечных проблем - срывы строительства новых домов на миллионы денег. Поэтому так обычно не делают. Локальными вопросами занимаются отдельные люди кто отвечает за коммунальное хозяйство (то же саппорт из мира ЖКХ).
Тактика отдавать разработчикам фикс багов в наказание, чтобы сами от них же страдали, это больше из области мотивации персонала, нежели реального управления проектами. На практике какой-то эффект это может давать первый месяц, когда по старой памяти они могут быстрее разобраться в проблеме, чем люди со стороны. Но на длинных дистанциях особого толку нет - они уже все забудут или уволятся. Поэтому на системном уровне это не решение, если у вас длинные проекты.
An estimate is not a commitment. По моему в этом суть всех Agile методологий. Если руководство воспринимает эту идею не как ценность, а как проблему, значит выбран не тот подход к управлению и все остальное просто следствия.
Это как если бы тушить пожары к вам домой приезжали строители, которые возводили объект - такое возможно, но будет не очень эффектно и очень дорого.
Загуглите "L3 support". В жизненном цикле продукта большая часть затрат приходится не на разработку, а на эксплуатацию. Поэтому то, как решаются вопросы поддержки, принципиально влияет на точность эстимаций ваших разработчиков, если вся поддержка остаётся у них в скоупе до конца дней. Команда, которая строит звездолёт с нуля у себя в ангаре, и команда которая строит звездолёт с нуля, параллельно не давая упасть уже построенному на Альфе Центавра это две принципиально разные ситуации в плане ресурсов и управления.
Я отвечал на вопрос про HTML, где используется лишь подмножество методов HTTP (из двух штук). WebDAV, ReST и т.п. это отдельная история.
Могли бы начать с себя и проверять тексты законов и постановлений по этим словарям. Заодно отработали методику бы. А так звучит как идея для стартапа. Интересно кто первым запилит сервис?
Статья больше похожа на SEO кликбейт, с целью собрать внутри популярные ключевые слова и не спалиться. По содержанию пропущены важные структурные концепции (модель коммуникации OSI, например), поэтому выглядит как поток сознания какой-то нейронки.