Обычно скрам-мастер не вовлекается в планирование в такой роли. Его зона ответственности это сам scrum-процесс, как форма организации деятельности. Он обучает участников правилам игры, следит за тем, чтобы правила соблюдались, и напоминает, если что-то идет не так. Решений по существу он не принимает. Работу при планировании делают Product Owner и команда.
Scrum это фреймворк для управления командой исполнителей, нацеленный на обеспечение решения тактических задач в рамках текущего проекта.
По моим ощущениям, данная система очень похожа на те, что описываются руководствах по боевой работе армейских подразделений. Когда есть SMART-цель, задача и приказ. А креативный подход, творчество и смекалка со стороны исполнителей конечно же всячески приветствуются, если они позволяют как-нибудь оптимизировать решение поставленной задачи.
Но если вы мечтаете, что-то творить выходящее за рамки конкретных задач спринта — нет, это не про скрам. Это абсолютно прямо противоположная затея. Так же Scrum не предназначен для стратегического планирования, планирования инвестиционной деятельности, целеполагания и еще многих других важных для организации штук.
Аналогичная проблема с метаданными на файлах в гетерогенных сетях уже давно решается в Samba. С ограничениями, но не такими чтобы пользователю нельзя было создавать или менять файлы. Docker for Window сейчас использует самбу и CIFS для реализации разделяемых томов. Это компромиссное решение, но чисто с практической точки зрения оно лучше, чем предлагаемое WSL.
Файловая подсистема в Windows содержит достаточно средств для гибкой работы с файлами (например, сжатие, шифрование и т.п.). Технология позволяет по аналогии сделать отдельный загончик для линуксячих файлов, со своими правилами для прозрачной трансляции метаданных в обе стороны.
Т.е. на концептуальном уровне приемлемое решение существует и есть возможности на уровне технологий. Это не какая-то там научная проблема. Реализовать (читай взять и сделать) в WSL — чисто техническая задача для инженеров из Microsoft.
При тестировании SUT через API («front door») проверяются связи между значениями на прямых входах и значении на выходе (direct inputs и direct outputs). В данном случае при подаче на вход валидного значения Payload ожидается конкретный результат MessageHandlerResult.Success на выходе:
public void Should_save_valid_data()
{
var result = handler.Handle(validPayload);
Assert.Equal(MessageHandlerResult.Success, result);
}
Такого же уровня детализации стоит придерживаться и при формулировании требований в отношении Indirect Output при тестировании «back door»:
public void Should_log_to_messaging_events_on_saving_valid_data()
{
var result = handler.Handle(validPayload);
messagingLogger.Verify(m => m.Received(It.Is(validPayload)), Times.Once())
}
Необходимо протестировать работу метода Handle(). Вопрос стоит в том, чтобы убедиться, что методы DbCommands и MessagingLogger были вызваны.
Требование к Indirect Outputs какое-то мутное. Если по аналогии сформулировать требование к выходу (Direct Output) самого метода Handle(), то получится что-то типа: «Необходимо протестировать работу метода Handle(). Вопрос стоит в том, чтобы убедиться, что метод возвращает результат.».
Тот факт, что мы просто должны дергать за ручки back door систем, не очень осмысленный, так же как мало смысла в проверке, что метод возвращает «неважно что». При верификации выходов SUT (Direct или Indirect) в первую очередь стоит проверять, что выполняются контракты по значениям на этих самых выходах. А для этого и требования должны формулироваться соответствующим образом.
Test Doubles удобно рассматривать в разрезе ролей, которую они выполняют в тестах сайд-эффектов: Stubs — предоставляют заданные значения для входов SUT (Indirect Inputs), Mocks — дают возможность для верификации выходов SUT (Indirect Outputs), Fake — реализуют штуки, которые в тесте не важны, но без которых SUT не работает (null-objects, dummy и т.п.).
В этом смысле оба варианта, предложенных в статье, предназначены для проверки Indirect Outputs и реализуют Mock. Первый использует программную генерацию (ad-hoc), второй написан лапками (hard coded).
Кислород нельзя получить без синтеза в звезде, даже в нескольких поколениях звёзд.
интересно, что «привело астрономов к мысли, что примерно 7 миллионов лет повсюду во Вселенной можно было найти жидкую воду», если кислорода тогда еще не было?
Если даже розничные сети, типа Магнита, открывают вакансии полиграфологов, значит это кому-нибудь нужно. https://krasnodar.superjob.ru/vakansii/glavnyj-specialist-poligrafolog-12310158.html
Ребятам, которые делают GitHub, надо бы устроить акцию просвещения среди мейнтейнеров ядра. Иначе кто-то снова сядет, и напишет за один день. Они это могут, и кто его знает, что тогда будет с этим вашим GitHub через два года. :)
Суть ведь не в том, чтобы обойти блокировщики или как-то еще навязать рекламу. Технически, в этом нет какой-то особенной проблемы. Но, поступая таким способом, сайт с большой вероятность лишь отпугнет пользователей.
В этой нише есть интересный момент: практически каждый посетитель, с большой степенью вероятности является потенциальным потребителем. Распугивать потребителей, наверно, немного глупо для бизнеса.
Поэтому сервису важно убедить пользователей воспринимать рекламу на сайте не как что-то враждебное, а как может быть даже нужное.Только этом случае она начинает нормально работать. Что собственно они и делают. А нечастые акции по обходу блокировщиков это отработанный PR ход, направленный на привлечение внимания.
Боюсь, не поможет. Разработчики станут добавлять необходимые слайды с хайрез графикой в какие-нибудь заставки, переходы между локациями и т.п. Уже сто раз так делали, правда с другими целями.
По моим ощущениям, данная система очень похожа на те, что описываются руководствах по боевой работе армейских подразделений. Когда есть SMART-цель, задача и приказ. А креативный подход, творчество и смекалка со стороны исполнителей конечно же всячески приветствуются, если они позволяют как-нибудь оптимизировать решение поставленной задачи.
Но если вы мечтаете, что-то творить выходящее за рамки конкретных задач спринта — нет, это не про скрам. Это абсолютно прямо противоположная затея. Так же Scrum не предназначен для стратегического планирования, планирования инвестиционной деятельности, целеполагания и еще многих других важных для организации штук.
Файловая подсистема в Windows содержит достаточно средств для гибкой работы с файлами (например, сжатие, шифрование и т.п.). Технология позволяет по аналогии сделать отдельный загончик для линуксячих файлов, со своими правилами для прозрачной трансляции метаданных в обе стороны.
Т.е. на концептуальном уровне приемлемое решение существует и есть возможности на уровне технологий. Это не какая-то там научная проблема. Реализовать (читай взять и сделать) в WSL — чисто техническая задача для инженеров из Microsoft.
Такого же уровня детализации стоит придерживаться и при формулировании требований в отношении Indirect Output при тестировании «back door»:
Требование к Indirect Outputs какое-то мутное. Если по аналогии сформулировать требование к выходу (Direct Output) самого метода Handle(), то получится что-то типа: «Необходимо протестировать работу метода Handle(). Вопрос стоит в том, чтобы убедиться, что метод возвращает результат.».
Тот факт, что мы просто должны дергать за ручки back door систем, не очень осмысленный, так же как мало смысла в проверке, что метод возвращает «неважно что». При верификации выходов SUT (Direct или Indirect) в первую очередь стоит проверять, что выполняются контракты по значениям на этих самых выходах. А для этого и требования должны формулироваться соответствующим образом.
Stubs — предоставляют заданные значения для входов SUT (Indirect Inputs),
Mocks — дают возможность для верификации выходов SUT (Indirect Outputs),
Fake — реализуют штуки, которые в тесте не важны, но без которых SUT не работает (null-objects, dummy и т.п.).
В этом смысле оба варианта, предложенных в статье, предназначены для проверки Indirect Outputs и реализуют Mock. Первый использует программную генерацию (ad-hoc), второй написан лапками (hard coded).
интересно, что «привело астрономов к мысли, что примерно 7 миллионов лет повсюду во Вселенной можно было найти жидкую воду», если кислорода тогда еще не было?
В точку! :)
В этой нише есть интересный момент: практически каждый посетитель, с большой степенью вероятности является потенциальным потребителем. Распугивать потребителей, наверно, немного глупо для бизнеса.
Поэтому сервису важно убедить пользователей воспринимать рекламу на сайте не как что-то враждебное, а как может быть даже нужное.Только этом случае она начинает нормально работать. Что собственно они и делают. А нечастые акции по обходу блокировщиков это отработанный PR ход, направленный на привлечение внимания.