Если в компании есть процессы, которые окружающие не соблюдают, то требовать их соблюдения (или пересмотра/отмены) - это не пассивная агрессия, а банальная адекватность. Вы слышали про Итальянскую забастовку? Это очень хороший пример пассивной агрессии, где используется подход, когда требуют соблюдания процессов. Процессы - это палка с двумя концами, которая может быть использована как во благо и так во зло.
Тут можно пояснить ассоциацией: если на тебя нападают с оружием, то ты защищаешься, беря в руки оружие. То же самое с токсичностью, если ты каждый день вынужден защищаться от токсичности, то ты сам берешь ее на вооружение и рано или поздно становишься сам токсичным человеком.
Ваш пример — это шикарный пример, когда специалист, не боится высказываться и отстаивать свою точку зрения даже под угрозой увольнения.
И это еще один пример того, что людей просят быть гибкими (реальная цитата), а подразумевается зачастую то, что специалист должен закрыть глаза на нарушения по тем или иным причинам!
В результате страдают все, кроме тех, кто считает прибыль. Прибыль то есть!
Пассивные агрессоры вообще скользкие люди. К ним подкопаться очень сложно, они же по правилам все делают, даже ожидают похвалы за то, что они указали на проблему. ) Таких не любят, согласна полностью. Мой посыл, что в определенных ситуациях пассивная агрессия - это то, к чему можно прибегнуть, но не долго ! И если ваша цель уйти из компании или проекта и больше никогда не работать с этими людьми.
Я бы предложила испьльзовать блокчейн технологию на бэке, что бы не возможно было изменить результаты голосования.
Кто заплатит за разработку? И как будут возвращени инвестиции? - после ответа на эти вопросы можно будет начать разработку. Если нету ответа, то бесполезно начинать.
Спасибо за статью, интересный код. Но я бы хотела прояснить вопрос с тестированием.
Что конкретно тут тестируется? Соединение с Kafka?
Если я использую Kafka при тестировании на проекте, то я либо получаю сообщения из нее и проверяю из валидность. Или наоборот, я отправляю сообщения в Kafka, чем запускаю работу какой-либо функциональности, которая ее ждет.
Т.е. не соединение с Kafka основная цель тестирования, а сообщения и их валидность.
«Потому что пользователи работают с приложением. И сценариев его использования много.»
Это неверное понимание. Сервис всегда предоставляет ограниченный набор действий для пользователя — его функционал. Этот набор всегда известен при тестировании. Из всего этого набора ограниченное количество действий нагружается пользователем — это и есть сценарии для нагрузки, остальное можно отсечь.
Интересный подход и интересное мнение.
Думаю, что в определенных ситуациях его советы очень пригодятся, но в целом я не согласна с мнением, что если сложно, то надо писать меньше.
Описанная сложность для меня тоже не убедительна, это то, с чем приходится каждый день иметь дело. При грамотно написанных сценариях их поддерживать — это не такая и сложная задача.
А вот ситуация с анализом логов при помощи листика и ручки для меня выглядит пугающей. )
Анализаторы логов автором не дооценены.
Мне нравится как написана статья, хорошая последовательность изложения мыслей, хороший понятный язык.
В целом это действительно описание велосипеда одного конкретного архитектурного стиля, НО хорошее описание велосипеда!
Одно замечание с моей стороны, универсальности архитектуры можно достигнуть, если мы говорим о наборе однотипных проектов, иначе об универсальности речи идти не может.
То, что лекции не эффективны на столько как активные способы обучения, обсуждается очень давно и долго. Но у лекций есть одно очень востребованное преимущество в отличии от активных способов обучения — это инструмент, при помощи которого можно за краткое время донести информацию большому колличеству людей. Что и было востребовано очень долго. Конечно, на сколько эта информация усвоится — это другое дело.
Второе — в этом мире отменили армию.
Я готов поставить большие деньги на то, что уже на следующий день начнут пустеть вузы
Не согласна с этим утверждением. Тут можно взять пример Израиля, где молодежь идет в армию, что бы поступить в ВУЗ. Причем армия действующая!
Если в компании есть процессы, которые окружающие не соблюдают, то требовать их соблюдения (или пересмотра/отмены) - это не пассивная агрессия, а банальная адекватность.Вы слышали про Итальянскую забастовку? Это очень хороший пример пассивной агрессии, где используется подход, когда требуют соблюдания процессов.
Процессы - это палка с двумя концами, которая может быть использована как во благо и так во зло.
Тут можно пояснить ассоциацией:
если на тебя нападают с оружием, то ты защищаешься, беря в руки оружие.
То же самое с токсичностью, если ты каждый день вынужден защищаться от токсичности, то ты сам берешь ее на вооружение и рано или поздно становишься сам токсичным человеком.
Спасибо, что поделились!
Ваш пример — это шикарный пример, когда специалист, не боится высказываться и отстаивать свою точку зрения даже под угрозой увольнения.
И это еще один пример того, что людей просят быть гибкими (реальная цитата), а подразумевается зачастую то, что специалист должен закрыть глаза на нарушения по тем или иным причинам!
В результате страдают все, кроме тех, кто считает прибыль. Прибыль то есть!
Спасибо за наглядную демонтрацию )
Пассивные агрессоры вообще скользкие люди. К ним подкопаться очень сложно, они же по правилам все делают, даже ожидают похвалы за то, что они указали на проблему. )
Таких не любят, согласна полностью.
Мой посыл, что в определенных ситуациях пассивная агрессия - это то, к чему можно прибегнуть, но не долго !
И если ваша цель уйти из компании или проекта и больше никогда не работать с этими людьми.
Я бы предложила испьльзовать блокчейн технологию на бэке, что бы не возможно было изменить результаты голосования.
Кто заплатит за разработку? И как будут возвращени инвестиции? - после ответа на эти вопросы можно будет начать разработку. Если нету ответа, то бесполезно начинать.
Спасибо, очень детализированная и объёмная статья! Выложу ссылку у себя в блоге.
Что конкретно тут тестируется? Соединение с Kafka?
Если я использую Kafka при тестировании на проекте, то я либо получаю сообщения из нее и проверяю из валидность. Или наоборот, я отправляю сообщения в Kafka, чем запускаю работу какой-либо функциональности, которая ее ждет.
Т.е. не соединение с Kafka основная цель тестирования, а сообщения и их валидность.
С уважением, Ирина
«Потому что пользователи работают с приложением. И сценариев его использования много.»
Это неверное понимание. Сервис всегда предоставляет ограниченный набор действий для пользователя — его функционал. Этот набор всегда известен при тестировании. Из всего этого набора ограниченное количество действий нагружается пользователем — это и есть сценарии для нагрузки, остальное можно отсечь.
Думаю, что в определенных ситуациях его советы очень пригодятся, но в целом я не согласна с мнением, что если сложно, то надо писать меньше.
Описанная сложность для меня тоже не убедительна, это то, с чем приходится каждый день иметь дело. При грамотно написанных сценариях их поддерживать — это не такая и сложная задача.
А вот ситуация с анализом логов при помощи листика и ручки для меня выглядит пугающей. )
Анализаторы логов автором не дооценены.
А вы при помощи ScalaCheck генерируете тестовые данные?
Самописный генератор?
Прямо угадали мои тайные желания этого года!!!
Спасибо, пошла пользоваться )
Единственный момент, что тестирование фри-лансерами очень ограничено в применении.
Мне нравится как написана статья, хорошая последовательность изложения мыслей, хороший понятный язык.
В целом это действительно описание велосипеда одного конкретного архитектурного стиля, НО хорошее описание велосипеда!
Одно замечание с моей стороны, универсальности архитектуры можно достигнуть, если мы говорим о наборе однотипных проектов, иначе об универсальности речи идти не может.
Отправлю в общий чат почитать. )
Не согласна с этим утверждением. Тут можно взять пример Израиля, где молодежь идет в армию, что бы поступить в ВУЗ. Причем армия действующая!