При нагрузке выше VO2 max "горит" всё — и ноги, и лёгкие (лактат там тоже накапливается). Но, в отличие от ног, я ни разу не сталкивался с "усталостью" дыхательных мышц; лактат вызывает дискомфорт, но не более.
Если взять условный all-out тест на 20 минут, то при высоком каденсе (100-110 RPM) к концу останавливаешься не из-за усталости, а потому что терпеть такой стресс дольше психологически невозможно. На низком каденсе за те же 20 минут ноги "отвалятся" — по крайней мере, у меня.
Если постепенно увеличивать нагрузку то за год (1-2 сезона) можно справиться. Первые 2-3 месяца будет что-то вроде адаптации (болит всё и постоянно, самое классное время). Большая нагрузка требует много еды, очень много еды - х2 х3 порции легко. Я за первые несколько лет какое-то чудовищное количество риса с курицей съел...
Нагрузку можно перекладывать на лёгкие через увеличение RPM - лёгкие восстанавливаются быстрее чем ноги (по сути: крутить быстрее, а на жать сильнее). Если поддерживать высокий RPM то, со временем, увеливается эффективность отвода лактата (и в лёгких и в ногах), снижается потребление кислорода, повышается граница до которой организм всё ещё может использовать жир и 20 км/ч легко превращаются в 30-35 км/ч за год. Дальше уже сложнее.
Я последние 5 лет практически не пишу юнит-тесты на крудовую бизнес-логигку, в первую очередь из-за того что тонны тестов только замедляют рефакторинг и превращаются в копипаст: логика переносится в тесты (осмысленно или нет - не так важно), так как цель - зелёная галочка, а не корректность. С таким подходом начинают появляться и подрывать доверие к системы false-positive тесты; со временем начинаешь задаваться вопросом: а стоили ли 2000 зелёных галочек потраченного на них времени...
Если я правильно понял, что самого кода сервисов генератор тестов не видит, т.е он не может превратить баг имплементации в фичу, т.е шанс на false-positive уменьшается. Также не должно быть проблем с рефакторингом, так как тесты можно перегенерировать всегда.
Интересно, какие категории ошибок может такой подход находить и не приведёт ли это к тому, что разработчики будут тратить время на вставку ассертов вроде if arg < 0 throw no-way-exception куда надо и не надо чтобы осчастливить генератор?
Другими словами, не добавит ли это разработчикам больше не самой полезной работы?
На мой взгляд, разделение тестировщиков на автоматизиторов и ручных очень условное. Ручные тестировщики тоже пишут много "кода", только этот код выглядит как текстовые сценарии интерпретируемые человеком. При наличии навыков автоматизации, такие сценарии можно заменить реальным кодом; особенно удобно, если авто-тесты пишут в том числе и разработчики: это позволяет обучать тестировщиков навыкам рефакторинга, или как минимум поддерживать сценарии в актульном состоянии.
Покрытие - сложный вопрос. Лучше меньше покрывать и чаще запускать, чем покрывать всё и запускать только по праздниками или выборочно. Избыточное покрытие приводит к медлительности тестирования, которое приводит к желанию запускать меньше или выборочно, что, в свою очередь, сводит на нет пользу от полного покрытия.
Нельзя просто так сказать, нам в команду нужен крутой автоматизатор и в течение месяца он у вас появился.
Был случай, когда мы наняли тестировщика, который, мягко говоря, преувеличил свои навыки автоматизации. Через пару месяцев работы бок о бок с разработчиками его навык уже позволял работать самостоятельно. В изоляции он бы не выжил.
Во-первых, тогда он должен досконально изучить наш сервис. Что не всегда возможно.
Высокая скорость разработки и короткие итерации позволяют фокусироваться на самых важных для бизнеса вещах. Разработка должна отговаривать тестирование впадать в крайности и тестировать всё, до чего руки дотянутся. Это всё из той же оперы, что и "проектирование наперёд" и "абстрактные фабрики абстрактых фабрик" в разработке: приводит только к увеличению стоимости изменений и рефакторинга, а ощущать "рефакторинг" как что-то болезненное нельзя ни в коем случае.
Понятно, что чем меньше покрытие, тем больше вероятность пропустить баг, но разработчики со стажем знают в каких сценариях они часто ошибаются и могут направлять тестирование на самые злачные кейсы.
В конце концов, нужно больше общаться и меньше впадать в крайности.
Не стоит ассоциировать каждого продакта и проджекта с бизнесном. Чаще всего это точно такие же наёмные рабочие которым на "принесёт ли денег фича" соврершенно плевать, так как к моменту, когда фича может начать или не начать приносить деньги, он, менеджер, уже будет работать где-то в другом месте или пойдёт на повышение. А вот программистам кучу криво написанного кода поддерживать придётся, если конечно они сами не свинтят куда-нибудь.
Возможность писать качественный код и получать удовольствие от работы всегда и везде приходится выгрызать зубами. Если не хочется выгрызать, значит не очень и хочется писать качественный код.
Да, сможет. Личного опыта не имею, но коллега + жена + 2 ребёнка живут на стандартную экспатскую зарплату. В Амстердаме жить вряд ли получится, но купить\снять дом в Almere можно.
Всё это, к сожалению, правда. Разрыв между крупными корпорациями и небольшими компаниями становится всё больше и больше, а олдскульные компании упрямо сидят на 85к максимум (и то, если повезёт). При этом никого не смущает, что искать человека на такую зарплату придётся целый год или два, тратя кучу ресурсов и времени.
Как человек уже 4 года живущий в Амстердаме и постоянно собеседующий разработчиков скажу, что у кандидатов из "СНГ" очень высокие зарплатные ожидания, и это, пожалуй, самая популярная, если не единственная причина отказа. Чем олдскульнее голландская компания, тем меньше она хочет платить выше психологической отметки в 85к в год. Современные средние\крупные компании могут платить и выше, но тут как повезёт.
В плане квалификации у среднего программиста из "СНГ" проблем быть не должно никаких: уровень среднестатистического кандидата из Индии и Турции несравнимо ниже, но им легко дадут стандартные 60-75, даже если от их решений хочется рыдать кровавыми слезами.
На мой взгляд, Амстердам идеален для "хочется пожить в Европе и разговаривать по-английски", но с зарплатой и техническим уровнем тут сложно (исключительно с точки зрения кандидатов из РФ).
При нагрузке выше VO2 max "горит" всё — и ноги, и лёгкие (лактат там тоже накапливается). Но, в отличие от ног, я ни разу не сталкивался с "усталостью" дыхательных мышц; лактат вызывает дискомфорт, но не более.
Если взять условный all-out тест на 20 минут, то при высоком каденсе (100-110 RPM) к концу останавливаешься не из-за усталости, а потому что терпеть такой стресс дольше психологически невозможно. На низком каденсе за те же 20 минут ноги "отвалятся" — по крайней мере, у меня.
Есть есть, даже в очень тощих визуально людях достаточно жира.
Если постепенно увеличивать нагрузку то за год (1-2 сезона) можно справиться. Первые 2-3 месяца будет что-то вроде адаптации (болит всё и постоянно, самое классное время). Большая нагрузка требует много еды, очень много еды - х2 х3 порции легко. Я за первые несколько лет какое-то чудовищное количество риса с курицей съел...
Нагрузку можно перекладывать на лёгкие через увеличение RPM - лёгкие восстанавливаются быстрее чем ноги (по сути: крутить быстрее, а на жать сильнее). Если поддерживать высокий RPM то, со временем, увеливается эффективность отвода лактата (и в лёгких и в ногах), снижается потребление кислорода, повышается граница до которой организм всё ещё может использовать жир и 20 км/ч легко превращаются в 30-35 км/ч за год. Дальше уже сложнее.
Я последние 5 лет практически не пишу юнит-тесты на крудовую бизнес-логигку, в первую очередь из-за того что тонны тестов только замедляют рефакторинг и превращаются в копипаст: логика переносится в тесты (осмысленно или нет - не так важно), так как цель - зелёная галочка, а не корректность. С таким подходом начинают появляться и подрывать доверие к системы false-positive тесты; со временем начинаешь задаваться вопросом: а стоили ли 2000 зелёных галочек потраченного на них времени...
Если я правильно понял, что самого кода сервисов генератор тестов не видит, т.е он не может превратить баг имплементации в фичу, т.е шанс на false-positive уменьшается. Также не должно быть проблем с рефакторингом, так как тесты можно перегенерировать всегда.
Интересно, какие категории ошибок может такой подход находить и не приведёт ли это к тому, что разработчики будут тратить время на вставку ассертов вроде
if arg < 0 throw no-way-exceptionкуда надо и не надо чтобы осчастливить генератор?Другими словами, не добавит ли это разработчикам больше не самой полезной работы?
На мой взгляд, разделение тестировщиков на автоматизиторов и ручных очень условное. Ручные тестировщики тоже пишут много "кода", только этот код выглядит как текстовые сценарии интерпретируемые человеком. При наличии навыков автоматизации, такие сценарии можно заменить реальным кодом; особенно удобно, если авто-тесты пишут в том числе и разработчики: это позволяет обучать тестировщиков навыкам рефакторинга, или как минимум поддерживать сценарии в актульном состоянии.
Покрытие - сложный вопрос. Лучше меньше покрывать и чаще запускать, чем покрывать всё и запускать только по праздниками или выборочно. Избыточное покрытие приводит к медлительности тестирования, которое приводит к желанию запускать меньше или выборочно, что, в свою очередь, сводит на нет пользу от полного покрытия.
Был случай, когда мы наняли тестировщика, который, мягко говоря, преувеличил свои навыки автоматизации. Через пару месяцев работы бок о бок с разработчиками его навык уже позволял работать самостоятельно. В изоляции он бы не выжил.
Высокая скорость разработки и короткие итерации позволяют фокусироваться на самых важных для бизнеса вещах. Разработка должна отговаривать тестирование впадать в крайности и тестировать всё, до чего руки дотянутся. Это всё из той же оперы, что и "проектирование наперёд" и "абстрактные фабрики абстрактых фабрик" в разработке: приводит только к увеличению стоимости изменений и рефакторинга, а ощущать "рефакторинг" как что-то болезненное нельзя ни в коем случае.
Понятно, что чем меньше покрытие, тем больше вероятность пропустить баг, но разработчики со стажем знают в каких сценариях они часто ошибаются и могут направлять тестирование на самые злачные кейсы.
В конце концов, нужно больше общаться и меньше впадать в крайности.
Не стоит ассоциировать каждого продакта и проджекта с бизнесном. Чаще всего это точно такие же наёмные рабочие которым на "принесёт ли денег фича" соврершенно плевать, так как к моменту, когда фича может начать или не начать приносить деньги, он, менеджер, уже будет работать где-то в другом месте или пойдёт на повышение. А вот программистам кучу криво написанного кода поддерживать придётся, если конечно они сами не свинтят куда-нибудь.
Возможность писать качественный код и получать удовольствие от работы всегда и везде приходится выгрызать зубами. Если не хочется выгрызать, значит не очень и хочется писать качественный код.
Нет, не работает.
Да, сможет. Личного опыта не имею, но коллега + жена + 2 ребёнка живут на стандартную экспатскую зарплату. В Амстердаме жить вряд ли получится, но купить\снять дом в Almere можно.
Всё это, к сожалению, правда. Разрыв между крупными корпорациями и небольшими компаниями становится всё больше и больше, а олдскульные компании упрямо сидят на 85к максимум (и то, если повезёт). При этом никого не смущает, что искать человека на такую зарплату придётся целый год или два, тратя кучу ресурсов и времени.
Как человек уже 4 года живущий в Амстердаме и постоянно собеседующий разработчиков скажу, что у кандидатов из "СНГ" очень высокие зарплатные ожидания, и это, пожалуй, самая популярная, если не единственная причина отказа. Чем олдскульнее голландская компания, тем меньше она хочет платить выше психологической отметки в 85к в год. Современные средние\крупные компании могут платить и выше, но тут как повезёт.
В плане квалификации у среднего программиста из "СНГ" проблем быть не должно никаких: уровень среднестатистического кандидата из Индии и Турции несравнимо ниже, но им легко дадут стандартные 60-75, даже если от их решений хочется рыдать кровавыми слезами.
На мой взгляд, Амстердам идеален для "хочется пожить в Европе и разговаривать по-английски", но с зарплатой и техническим уровнем тут сложно (исключительно с точки зрения кандидатов из РФ).