А за чем бы вы пошли по дороге из желтого кирпича? Ясно, что не хватает, как всегда, мозгов, как у Страшилы.
А чего - хочется? Мне бы сердце..
пятница, 30 августа 2013 г.
Lesson 288
Совместно со стажером выполнили первый пункт полугодового плана группы - повесили сетку. К ней прилагаются восемь мячиков.
Ништяк.
Слово Канеру
Используйте уровни тестирования для упрощения обсуждения сложности теста
Чтоб упростить взаимодействие по поводу стратегии тестирования, для многих проектов полезно различать уровни тестирования. На низком уровне более простые, менее обширные тесты. Тесты высокого уровня более сложны и всеохватывающи. Это позволит упростить обсуждение стратегии тестирования by providing a shorthand for talking about classes of testing. Вот пример иерархии уровней тестирования:
- Уровень 0: Smoke тестирование. Простые тесты, показывающие, что продукт готов к тестированию, a sanity check. Если не прошли тесты нулевого уровня, отправьте код назад к программистам.
- Уровень 1: Тестирование возможностей. Тесты, проверяющие работоспособность фич. Цель — убедиться в том, что каждая функция выполняет свою задачу. На этом уровне стоит избегать раздутых сценариев, сложных данных и взаимодействия фич.
- Уровень 2: функциональное тестирование. Тесты, проверяющие как работу, так и надежность каждой функции продукта. Интерес представляет покрытие тестами и сложные методы оценки результата. Используйте граничные значения, стресс-тесты, тесты на обработку ошибок, но избегайте запутанных сценариев и взаимодействия функций.
- Уровень 3: комплексное тестирование. Тесты на взаимодействие потоков управления группами функций, сложные сценарии. Фокус расширен и включает оценку производительности, совместимости, конфликты за ресурсы, утечки памяти, надежность и другие критерии качества, которые становятся проверяемыми по мере зрелости продукта.
Каждому из этих уровней может соответствовать ряд различных техник тестирования и их комбинаций. Общий смысл в том, чтоб начать тестирование с сочувствием к продукту, а затем перейти к коварству по мере роста продукта. Использование 3 уровня на ранних стадиях развития продукта без использования уровней 1 и 2 приведет к раздражению программистов. Скорее всего. Вы просто не сможете провести эти тесты.
 |
| Альбом: office |
Ништяк.
Слово Канеру
Используйте уровни тестирования для упрощения обсуждения сложности теста
Чтоб упростить взаимодействие по поводу стратегии тестирования, для многих проектов полезно различать уровни тестирования. На низком уровне более простые, менее обширные тесты. Тесты высокого уровня более сложны и всеохватывающи. Это позволит упростить обсуждение стратегии тестирования by providing a shorthand for talking about classes of testing. Вот пример иерархии уровней тестирования:
- Уровень 0: Smoke тестирование. Простые тесты, показывающие, что продукт готов к тестированию, a sanity check. Если не прошли тесты нулевого уровня, отправьте код назад к программистам.
- Уровень 1: Тестирование возможностей. Тесты, проверяющие работоспособность фич. Цель — убедиться в том, что каждая функция выполняет свою задачу. На этом уровне стоит избегать раздутых сценариев, сложных данных и взаимодействия фич.
- Уровень 2: функциональное тестирование. Тесты, проверяющие как работу, так и надежность каждой функции продукта. Интерес представляет покрытие тестами и сложные методы оценки результата. Используйте граничные значения, стресс-тесты, тесты на обработку ошибок, но избегайте запутанных сценариев и взаимодействия функций.
- Уровень 3: комплексное тестирование. Тесты на взаимодействие потоков управления группами функций, сложные сценарии. Фокус расширен и включает оценку производительности, совместимости, конфликты за ресурсы, утечки памяти, надежность и другие критерии качества, которые становятся проверяемыми по мере зрелости продукта.
Каждому из этих уровней может соответствовать ряд различных техник тестирования и их комбинаций. Общий смысл в том, чтоб начать тестирование с сочувствием к продукту, а затем перейти к коварству по мере роста продукта. Использование 3 уровня на ранних стадиях развития продукта без использования уровней 1 и 2 приведет к раздражению программистов. Скорее всего. Вы просто не сможете провести эти тесты.
среда, 28 августа 2013 г.
Lesson 287
Слово Канеру
Тестируйте продукт на зрелость
Хотя общие стратегии для фаз жизни проекта, как правило, недостаточны, все же имеет смысл применять разные стратегии на разных фазах, в зависимости от того, насколько зрелым является продукт:
- На старте проекта тестируйте снисходительно. В начале проекта продукт плохо работает и вы мало о нем знаете. Серьезные тесты на данном этапе по большей части не нужны, так как даже простые тесты найдут ошибки. Таким образом, программисты, знающие, что продукт еще не готов, будут огорчены излишним усердием тестировщиков. Программисты хотят знать, работают ли функции, которые они реализовали.
- В середине проекта тестируйте агрессивно. Так как продукт поставляется вместе с реализованными фичами и техническим долгом, простые тесты теряют свою эффективность. Программисты чувствуют себя уверенно в продукте. Они переходят от реализации фич к фулл-тайм исправлению багов. Самое время, чтоб провести полное и более сложное тестирование. Mine flaky parts of the product for all they're worth. Найтиде и зарепортьте так много дефектов, как можете. Создайте беклог ошибок для разработчиков.
- Ближе к концу проекта тестируйте разными способами. В зрелом продукте сложнее найти ошибки, тестирование должно быть более творческим. Это время довести разнообразие тестирования до пределов вашей фантазии. И руководство окажет вам поддержку. Используйте помощников, автоматизацию, мероприятия тестировщиков (bug finding parties or bug bounties), эвристику, бетатестеров и все остальное. Если вы все сделаете правильно, ваша кривая скорости поиска ошибок будет идеальной кривой, как на диаграмме. Поднимите ее вверх на ранних этапах за счет агрессивного тестирования и удерживайте там во время завершения проекта за счет разнообразного тестирования, пока у вас не кончатся идеи для новых и лучших тестов.
- В последние дни проверяйте тщательно. Ошибка последних дней может стоить вашей компании очень дорого. Когда вы приближаетесь к дедлайну, тестирование должно стать оборонительным. Тщательно проверяйте каждое изменение. Проверьте каждый файл, который будет выпущен в релиз. Используйте парное тестирование, чтоб обеспечить вдвое больше глаз, наблюдающих за тестированием.
Общая цель заключается в том, чтоб непрерывно корректировать стратегию тестирования продукта, удерживая скорость нахождения важных ошибок в продукте на высоком уровне.
Картинки.
Раз:
Два:
Три:
Четыре:
Тестируйте продукт на зрелость
Хотя общие стратегии для фаз жизни проекта, как правило, недостаточны, все же имеет смысл применять разные стратегии на разных фазах, в зависимости от того, насколько зрелым является продукт:
- На старте проекта тестируйте снисходительно. В начале проекта продукт плохо работает и вы мало о нем знаете. Серьезные тесты на данном этапе по большей части не нужны, так как даже простые тесты найдут ошибки. Таким образом, программисты, знающие, что продукт еще не готов, будут огорчены излишним усердием тестировщиков. Программисты хотят знать, работают ли функции, которые они реализовали.
- В середине проекта тестируйте агрессивно. Так как продукт поставляется вместе с реализованными фичами и техническим долгом, простые тесты теряют свою эффективность. Программисты чувствуют себя уверенно в продукте. Они переходят от реализации фич к фулл-тайм исправлению багов. Самое время, чтоб провести полное и более сложное тестирование. Mine flaky parts of the product for all they're worth. Найтиде и зарепортьте так много дефектов, как можете. Создайте беклог ошибок для разработчиков.
- Ближе к концу проекта тестируйте разными способами. В зрелом продукте сложнее найти ошибки, тестирование должно быть более творческим. Это время довести разнообразие тестирования до пределов вашей фантазии. И руководство окажет вам поддержку. Используйте помощников, автоматизацию, мероприятия тестировщиков (bug finding parties or bug bounties), эвристику, бетатестеров и все остальное. Если вы все сделаете правильно, ваша кривая скорости поиска ошибок будет идеальной кривой, как на диаграмме. Поднимите ее вверх на ранних этапах за счет агрессивного тестирования и удерживайте там во время завершения проекта за счет разнообразного тестирования, пока у вас не кончатся идеи для новых и лучших тестов.
- В последние дни проверяйте тщательно. Ошибка последних дней может стоить вашей компании очень дорого. Когда вы приближаетесь к дедлайну, тестирование должно стать оборонительным. Тщательно проверяйте каждое изменение. Проверьте каждый файл, который будет выпущен в релиз. Используйте парное тестирование, чтоб обеспечить вдвое больше глаз, наблюдающих за тестированием.
Общая цель заключается в том, чтоб непрерывно корректировать стратегию тестирования продукта, удерживая скорость нахождения важных ошибок в продукте на высоком уровне.
Картинки.
Раз:
 |
| Альбом: bug |
Два:
 |
| Альбом: bug |
Три:
 |
| Альбом: bug |
Четыре:
 |
| Альбом: bug |
понедельник, 26 августа 2013 г.
Гибкое тестирование
Читая первые 50 страниц книги о гибком тестировании (пикрелейтед), никак не мог отделаться от мысли:
- «Максим, помни, Лайза Криспин не восторженная дурочка, а опытный специалист».
Страницы с 80й стало полегче. Вообще, ничотак книга.
- «Максим, помни, Лайза Криспин не восторженная дурочка, а опытный специалист».
Страницы с 80й стало полегче. Вообще, ничотак книга.
 |
| Альбом: office |
среда, 21 августа 2013 г.
Lesson 286
Вчера украинец прошел испытательный. И уже сегодня пришел не на час раньше, а на 45 минут всего. Расслабился.
К вопросу о именовании, нового стажера назову Наташа.
Слово Канеру
На каждом этапе проекта спрашивай себя: «Что я могу проверить сейчас и как я могу это сделать?»
Иногда мы видели проекты, на которых брали определенную фазу, например, системная интеграция, и говорили, что будут проводить только определенные виды тестирования, к примеру, только тестирование требований. Это так же загадочно, как запрет на ношение белой одежды после дня труда. Зачем следовать настолько общим и sweeping правилам?
На фазе проекта, когда вы тестируете архитектуру (класса, подсистемы или системы) — основная задача — продумать стратегию тестирования. Основная, но не доминирующая. Мы рекомендуем просто спросить себя в любой из моментов: «Что я могу проверить здесь и сейчас и как я могу сделать это хорошо?»
Не думайте, что определенные виды тестирования полезны только в определенное время. Пусть ваша стратегия тестирования будет конъюнктурной. В любое время, независимо от тестов, которые вы проводите, используйте любые техники, которые помогут удовлетворить клиентов.
К вопросу о именовании, нового стажера назову Наташа.
Слово Канеру
На каждом этапе проекта спрашивай себя: «Что я могу проверить сейчас и как я могу это сделать?»
Иногда мы видели проекты, на которых брали определенную фазу, например, системная интеграция, и говорили, что будут проводить только определенные виды тестирования, к примеру, только тестирование требований. Это так же загадочно, как запрет на ношение белой одежды после дня труда. Зачем следовать настолько общим и sweeping правилам?
На фазе проекта, когда вы тестируете архитектуру (класса, подсистемы или системы) — основная задача — продумать стратегию тестирования. Основная, но не доминирующая. Мы рекомендуем просто спросить себя в любой из моментов: «Что я могу проверить здесь и сейчас и как я могу сделать это хорошо?»
Не думайте, что определенные виды тестирования полезны только в определенное время. Пусть ваша стратегия тестирования будет конъюнктурной. В любое время, независимо от тестов, которые вы проводите, используйте любые техники, которые помогут удовлетворить клиентов.
вторник, 20 августа 2013 г.
Lesson 285
Слово Канеру
Ваша первая стратегия тестирования проекта всегда неправильная
Стратегия должна развиваться по мере того, как вы работаете с продуктом и узнаете о его модели ошибок. Мы рекомендуем базировать вашу стратегию на рисках. Это ставит перед вами проблему: вы на знаете риски продукта. В начале проекта у вас есть только слухи о том, где могут находиться хорошие баги. Educated guesses, if you're lucky. В начале проекта ваша стратегия страдает, по меньшей мере, от одной из двух проблем: она не сфокусирована на рисках или сфокусирована на областях, которые не относятся к рискам.
Вы не сможете решить эту проблему постоянно используя одну и ту же стратегию. Позвольте стратегии развиваться по мере изучения продукта, когда вы увидите, где его слабые стороны, когда узнаете, как их протестировать.
Жизненные циклы, подобные V-Model ожидают, что вы знаете, какой будет ваша стратегия в самом начале проекта. А значит, вы должны быть не только гением, но гением с умением читать мысли, чтоб сделать идеальную стратегию с первого раза. Поэтому мы считаем V-Modelплохим способом организации. Если вы застряли с V-Model, создайте план тестирования пораньше, а затем тайком улучшайте его, после того, как все перестали обращать внимание на документацию и просто пытаются отгрузить продукт вовремя.
Ваша первая стратегия тестирования проекта всегда неправильная
Стратегия должна развиваться по мере того, как вы работаете с продуктом и узнаете о его модели ошибок. Мы рекомендуем базировать вашу стратегию на рисках. Это ставит перед вами проблему: вы на знаете риски продукта. В начале проекта у вас есть только слухи о том, где могут находиться хорошие баги. Educated guesses, if you're lucky. В начале проекта ваша стратегия страдает, по меньшей мере, от одной из двух проблем: она не сфокусирована на рисках или сфокусирована на областях, которые не относятся к рискам.
Вы не сможете решить эту проблему постоянно используя одну и ту же стратегию. Позвольте стратегии развиваться по мере изучения продукта, когда вы увидите, где его слабые стороны, когда узнаете, как их протестировать.
Жизненные циклы, подобные V-Model ожидают, что вы знаете, какой будет ваша стратегия в самом начале проекта. А значит, вы должны быть не только гением, но гением с умением читать мысли, чтоб сделать идеальную стратегию с первого раза. Поэтому мы считаем V-Modelплохим способом организации. Если вы застряли с V-Model, создайте план тестирования пораньше, а затем тайком улучшайте его, после того, как все перестали обращать внимание на документацию и просто пытаются отгрузить продукт вовремя.
пятница, 16 августа 2013 г.
Lesson 284
Пересмотрел Место встречи изменить нельзя.
Дальше на очереди - Семнадцать мгновений весны.
Просто вид из окна с рабочего места.
Слово Канеру
Собирайте ресурсы для усиления стратегии тестирования
Ваша стратегия возможна благодаря имеющимся ресурсам. На протяжении всего проекта и на всех проектах развивайте эти ресурсы так, чтоб максимально использовать возможности стратегии. Вот некоторые из ресурсов:
- Ваши навыки техник тестирования
- Ваше знание основных технологий продукта
- Друзья со особыми навыками тестирования
- Репозитории исходников
- Варианты тестовых платформ, операционные системы, аппаратные конфигурации
- Разнообразие инструментов тестирования
- Актуальные пользовательские данные
- Фичи продукта, обеспечивающие его тестируемость (логи, проверки, тестовые меню)
Дальше на очереди - Семнадцать мгновений весны.
Просто вид из окна с рабочего места.
 |
| Альбом: office |
Слово Канеру
Собирайте ресурсы для усиления стратегии тестирования
Ваша стратегия возможна благодаря имеющимся ресурсам. На протяжении всего проекта и на всех проектах развивайте эти ресурсы так, чтоб максимально использовать возможности стратегии. Вот некоторые из ресурсов:
- Ваши навыки техник тестирования
- Ваше знание основных технологий продукта
- Друзья со особыми навыками тестирования
- Репозитории исходников
- Варианты тестовых платформ, операционные системы, аппаратные конфигурации
- Разнообразие инструментов тестирования
- Актуальные пользовательские данные
- Фичи продукта, обеспечивающие его тестируемость (логи, проверки, тестовые меню)
четверг, 15 августа 2013 г.
Так
Услышал, что, несмотря на 9-11 классов образования в школе и пару курсов физики в институте, практически никто не может сам убедиться в том, что наш мир - не плоский, не покоится на четырех слонах, которые стоят на спине черепахи А'Туина.
Ну серьезно, давайте представим, у вас неделя времени и ползарплаты в кармане.
В космос не пустят. На ползарплаты не арендовать самолет и не слетать к краю земли.
Физические опыты? Наблюдения за звездами? М-м-м?
В свете всего этого предлагаю считать мир плоским.
Или у вас есть свои версии?
Ну серьезно, давайте представим, у вас неделя времени и ползарплаты в кармане.
В космос не пустят. На ползарплаты не арендовать самолет и не слетать к краю земли.
Физические опыты? Наблюдения за звездами? М-м-м?
В свете всего этого предлагаю считать мир плоским.
Или у вас есть свои версии?
Lesson 283
Тестер 1: зацените постановку на скрипт
Тестер 3: Добавь комментарий "Ну н-н-н-ахер"
Тестер 3: Или такой вариант Выбор типа запроса из 2.2.1.1.2. не дополняет, но полностью противоречит типу из 2.2.1.2.1., при этом услуга 2.1.2.1. может быть не найдена
Тестер 2: Второй вариант значительно круче
Тестер 1: А по смыслу почти то же самое
Слово Канеру
Применяйте разные полумеры
Менее проработанная, но более диверсифицированная стратегия тестирования лучше, чем более проработанная, но менее разнообразная. Другими словами, лучше применить больше разных видов тестирования на достаточно хорошем уровне, чем один или два на отличном. Мы называем это принципом разнообразных полумер.
Этот стратегический принцип проистекает из структуры сложности программных продуктов. Во время тестирования, вы упрощаете сложное. Ни одна техника не сможет проверить продукт так, чтоб быстро найти все важные проблемы. Любая техника сперва может найти достаточно много багов, на затем скорость поиска выравнивается. При переключении на технику, чувствительную к другому виду проблем, скорость поиска багов может возрасти вновь. С точки зрения общей продуктивности поиска багов, нужно использовать каждую технику до ее точки неэффективности и браться за другую.
Другая цель диверсификации в головоломке: Как можно проверять продукт за несколько месяцев и выпустить его, и при этом на следующий день обнаружить серьезные проблемы о которых вы не знали. Вот несколько причин, которые могут к этому привести. Основная причина: туннельное видение. Это не значит, что вы мало тестировали или делали это неправильно. Мы видели компании, которые прогоняли сотни тысяч тестов и все же пропустили очевидные проблемы, так как у них было мало разных тестов.
Для того, чтоб обеспечить разнообразие используйте все пять подходов к тестированию из главы 3 «Техники тестирования». Диверсифицируйте виды тестов для обеспечения максимальной скорости. Используйте разные тесты, чтоб свести к минимуму вероятность пропуска важной проблемы.
Тестер 3: Добавь комментарий "Ну н-н-н-ахер"
Тестер 3: Или такой вариант Выбор типа запроса из 2.2.1.1.2. не дополняет, но полностью противоречит типу из 2.2.1.2.1., при этом услуга 2.1.2.1. может быть не найдена
Тестер 2: Второй вариант значительно круче
Тестер 1: А по смыслу почти то же самое
Слово Канеру
Применяйте разные полумеры
Менее проработанная, но более диверсифицированная стратегия тестирования лучше, чем более проработанная, но менее разнообразная. Другими словами, лучше применить больше разных видов тестирования на достаточно хорошем уровне, чем один или два на отличном. Мы называем это принципом разнообразных полумер.
Этот стратегический принцип проистекает из структуры сложности программных продуктов. Во время тестирования, вы упрощаете сложное. Ни одна техника не сможет проверить продукт так, чтоб быстро найти все важные проблемы. Любая техника сперва может найти достаточно много багов, на затем скорость поиска выравнивается. При переключении на технику, чувствительную к другому виду проблем, скорость поиска багов может возрасти вновь. С точки зрения общей продуктивности поиска багов, нужно использовать каждую технику до ее точки неэффективности и браться за другую.
Другая цель диверсификации в головоломке: Как можно проверять продукт за несколько месяцев и выпустить его, и при этом на следующий день обнаружить серьезные проблемы о которых вы не знали. Вот несколько причин, которые могут к этому привести. Основная причина: туннельное видение. Это не значит, что вы мало тестировали или делали это неправильно. Мы видели компании, которые прогоняли сотни тысяч тестов и все же пропустили очевидные проблемы, так как у них было мало разных тестов.
Для того, чтоб обеспечить разнообразие используйте все пять подходов к тестированию из главы 3 «Техники тестирования». Диверсифицируйте виды тестов для обеспечения максимальной скорости. Используйте разные тесты, чтоб свести к минимуму вероятность пропуска важной проблемы.
вторник, 13 августа 2013 г.
Lesson 282
Для меня регулярные выражения - апофеоз программистской души и символ ее метаний и стремлений.
Регулярки занимают минимум места при максимуме функциональности.
Регулярки быстро пишутся.
Регулярки проще переписать заново с нуля.
Неспециалисту они кажутся смесью бреда с магией.
Регулярки сложно поддерживать. Мне.
Надо будет их выучить.
Слово Канеру
Стратегия объясняет ваши тесты
Если вы четко представляете стратегию и тестируете в соответствии с ней, вы сможете быстро и убедительно рассказать о вашем процессе тестирования тем, кто о нем спросит. Это обеспечит поддержку других участников разработки. Когда у вас нет стратегии тестирования, ваши объяснения будут звучать запутанно и неубедительно.
Хорошая стратегия:
- Специфична для продукта. Какую бы вы ни придумали стратегию, стратегия, созданная для конкретного продукта — лучше.
- Сфокусирована на рисках. Покажите, что процесс тестирования будет заниматься наиболее важными вещами. Соедините процесс тестирования и вашу миссию в проекте.
- Диверсифицирована. В большинстве случае диверсифицированная стратегия лучше монолитных. Диверсифицированная — включающая в себя множество различных техник и подходов. Проблемы, которые пройдут мимо одной техники, наверняка найдет другая.
- Практична. Вы должны быть в состоянии придерживаться этой стратегии. Не планируйте стратегию, находящуюся за возможностями проекта.
Регулярки занимают минимум места при максимуме функциональности.
Регулярки быстро пишутся.
Регулярки проще переписать заново с нуля.
Неспециалисту они кажутся смесью бреда с магией.
Регулярки сложно поддерживать. Мне.
Надо будет их выучить.
Слово Канеру
Стратегия объясняет ваши тесты
Если вы четко представляете стратегию и тестируете в соответствии с ней, вы сможете быстро и убедительно рассказать о вашем процессе тестирования тем, кто о нем спросит. Это обеспечит поддержку других участников разработки. Когда у вас нет стратегии тестирования, ваши объяснения будут звучать запутанно и неубедительно.
Хорошая стратегия:
- Специфична для продукта. Какую бы вы ни придумали стратегию, стратегия, созданная для конкретного продукта — лучше.
- Сфокусирована на рисках. Покажите, что процесс тестирования будет заниматься наиболее важными вещами. Соедините процесс тестирования и вашу миссию в проекте.
- Диверсифицирована. В большинстве случае диверсифицированная стратегия лучше монолитных. Диверсифицированная — включающая в себя множество различных техник и подходов. Проблемы, которые пройдут мимо одной техники, наверняка найдет другая.
- Практична. Вы должны быть в состоянии придерживаться этой стратегии. Не планируйте стратегию, находящуюся за возможностями проекта.
Ы!
Автор указан у: http://tancred2.livejournal.com/207084.html
Однажды в германии 16-го века заезжий мастер меча вызывал на бой местного булочника. Тот не мог отказаться от поединка из-за своего положения в обществе, вышел на бой и зарубил к ебеням заезжего мастера меча. Прежде чем стать булочником он проходил 10 лет в ландскнехтах. На двойном жаловании.
А все потому что надо осторожнее выбирать объект для насмешек.
Однажды в италии 17-го века заезжий фехтовальщик вызвал на бой местного портного, тот не мог отказать от поединка из-за своего социального статуса, поэтому благодаря своим связям нанял 10-к местных бандитов, те подкараулили заезжего фехтовальщика на выходе из борделя, отпиздили и ограбили. Он провалялся в койке 3 недели и был вынужден уехать из города без гроша в кармане, потому что все что осталось после ограбления отдал врачу.
А все потому что прежде чем ссориться с человеком надо узнать кто у него друзья.
Однажды в германии 15-го века заезжий фехтовальщик вызвал на бой молодого художника, тот не мог отказаться от поединка. Вышел на бой и пырнул заезжего фехтуна мечом, а после поймал за вооруженную руку и бросил на землю оставив руку в захвате. Рана от меча зажила, но больше он уже не с кем не фехтует. Руку то в трех местах сломали, со смещениями.
А все потому что прежде чем затевать ссору узнай как звать твоего противника и над чем он работает. А то вдруг это Альбрехт Дюрер, который как раз составляет иллюстрации к учебнику фехтования и борьбы?
Однажды во франции 18-го века заезжий фехтовальщик вызвал на бой местного винодела, тот не мог отказаться от поединка и пошел за советом к мастеру фехтования которые держал зал неподалеку. Принес ему бочок отличного вина и рассказал о проблеме. Хуйня война, сказал маэстро фехтования, главное маневры. Я пойду погляжу на твоего противника. И сняв колет и поменяв тупую рапиру на острую, пошел искать заезжего фехтуна. Выцепил его в кабаке, затеял ссору, поединок и проткнул ему обе руки. Довольный вернулся в зал где его поджидал грустный винодел.
Нее, сссы, братуха сказал он ему, теперь этот мудак не сможет фехтовать, а если решится выйти на поединок то ты без проблем справишься с ним, просто сбивай его клинок в бок и коли его в корпус вот так. Пару часов винодел поупражнялся выполнять батман с уколом.а на след день узнал что заезжий фехтун уехал нахуй из города.
Но с тех пор маэстро фехтования бесплатно пил хорошее вино, а винодел 3 раза в неделю упражнялся в фехтовании.
А все потому что не грех спросить помощи у опытных друзей.
Однажды на Руси заезжий фехтовальщик вызвал на дуэль местного плотника. Тот не дослушал до конца и разбил заморскому гостю рожу кулаками.
А все потому что не в почете у нас были дуэли на мечах, зато кулаками в рожу совать умели.
Однажды в Польше заезжий фехтовальщик вызвал на бой местного колбасника, тот не стал отказываться от поединка но по доброте душевной предложил гостю поужинать, подсыпал в колбасу отравы и тихонечко похоронил его за сараем.
А все потому что не все будут играть по придуманным тобой правилам.
Одного итальянского архитектора и художника 16-го века вызвал на бой заезжий фехтовальщик. Но как только узнал что задумал драться с самим Камилой Агриппой ахуел от собственной наглости, три раза извинился и уехал домой.
А все потому что полезно читать книги, иначе мог бы не узнать автора фехтбука.
Однажды в германии 16-го века заезжий мастер меча вызывал на бой местного булочника. Тот не мог отказаться от поединка из-за своего положения в обществе, вышел на бой и зарубил к ебеням заезжего мастера меча. Прежде чем стать булочником он проходил 10 лет в ландскнехтах. На двойном жаловании.
А все потому что надо осторожнее выбирать объект для насмешек.
Однажды в италии 17-го века заезжий фехтовальщик вызвал на бой местного портного, тот не мог отказать от поединка из-за своего социального статуса, поэтому благодаря своим связям нанял 10-к местных бандитов, те подкараулили заезжего фехтовальщика на выходе из борделя, отпиздили и ограбили. Он провалялся в койке 3 недели и был вынужден уехать из города без гроша в кармане, потому что все что осталось после ограбления отдал врачу.
А все потому что прежде чем ссориться с человеком надо узнать кто у него друзья.
Однажды в германии 15-го века заезжий фехтовальщик вызвал на бой молодого художника, тот не мог отказаться от поединка. Вышел на бой и пырнул заезжего фехтуна мечом, а после поймал за вооруженную руку и бросил на землю оставив руку в захвате. Рана от меча зажила, но больше он уже не с кем не фехтует. Руку то в трех местах сломали, со смещениями.
А все потому что прежде чем затевать ссору узнай как звать твоего противника и над чем он работает. А то вдруг это Альбрехт Дюрер, который как раз составляет иллюстрации к учебнику фехтования и борьбы?
Однажды во франции 18-го века заезжий фехтовальщик вызвал на бой местного винодела, тот не мог отказаться от поединка и пошел за советом к мастеру фехтования которые держал зал неподалеку. Принес ему бочок отличного вина и рассказал о проблеме. Хуйня война, сказал маэстро фехтования, главное маневры. Я пойду погляжу на твоего противника. И сняв колет и поменяв тупую рапиру на острую, пошел искать заезжего фехтуна. Выцепил его в кабаке, затеял ссору, поединок и проткнул ему обе руки. Довольный вернулся в зал где его поджидал грустный винодел.
Нее, сссы, братуха сказал он ему, теперь этот мудак не сможет фехтовать, а если решится выйти на поединок то ты без проблем справишься с ним, просто сбивай его клинок в бок и коли его в корпус вот так. Пару часов винодел поупражнялся выполнять батман с уколом.а на след день узнал что заезжий фехтун уехал нахуй из города.
Но с тех пор маэстро фехтования бесплатно пил хорошее вино, а винодел 3 раза в неделю упражнялся в фехтовании.
А все потому что не грех спросить помощи у опытных друзей.
Однажды на Руси заезжий фехтовальщик вызвал на дуэль местного плотника. Тот не дослушал до конца и разбил заморскому гостю рожу кулаками.
А все потому что не в почете у нас были дуэли на мечах, зато кулаками в рожу совать умели.
Однажды в Польше заезжий фехтовальщик вызвал на бой местного колбасника, тот не стал отказываться от поединка но по доброте душевной предложил гостю поужинать, подсыпал в колбасу отравы и тихонечко похоронил его за сараем.
А все потому что не все будут играть по придуманным тобой правилам.
Одного итальянского архитектора и художника 16-го века вызвал на бой заезжий фехтовальщик. Но как только узнал что задумал драться с самим Камилой Агриппой ахуел от собственной наглости, три раза извинился и уехал домой.
А все потому что полезно читать книги, иначе мог бы не узнать автора фехтбука.
Еврейская женщина русской отличный урок преподаст, коня на скаку перекупит, горящую избу продаст.
Нашел у Сиоку
Нашел у Сиоку
суббота, 10 августа 2013 г.
Рутина
Всех стажеров в планах обучения я именовал не по имени и фамилии.
В нашей группе отметились последовательно:
- Юный падаван
- Буратино в гестапо
- Нью хоуп
- Школьник
- Украинец
На очереди - еще стажер, что бы выбрать? Хм.
UPD на самом деле не всех, был еще просто Сережа, но он стал программистом и не считается.
В нашей группе отметились последовательно:
- Юный падаван
- Буратино в гестапо
- Нью хоуп
- Школьник
- Украинец
На очереди - еще стажер, что бы выбрать? Хм.
UPD на самом деле не всех, был еще просто Сережа, но он стал программистом и не считается.
Lesson 281
Почему то считал, чтоб собрать хороших людей достаточно фразы:
Всем своим. %день_недели%, %название_кабака%
Оказалось, каждый ждет персонального приглашения и сомневается, ему ли адресовано послание. Напомнило этот баш:
ааа: дебил
xxx: ты мне?
yyy: ты мне?
zzz: кто, я?
aaa: вы просмотрели миниатюру "детская самооценка"
Но все это неважно, мы все равно соберемся. Люди же хорошие, хех.
Да, велик и я самопочинились после пары недель аута, ингресс снова с нами.
А еще на работе грядут сугубо интересные и веселые изменения: юнглинг Украинец рискует стать падаваном, а на печеньки нашей стороны соблазнилось небесное создание, которое мы будем учить плохому.
Слово Канеру
Стратегия тестирования больше, чем просто тесты
Ваша стратегия тестирования содержит причины тестов, которые вы проводите. Когда вас о ней спрашивают, то хорошей идеей кажется сказать: эти 500 тестов и есть моя стратегия тестирования продукта. Это, может быть, и точный ответ, но не очень полезный. Это перегрузка информацией и она ничего не говорит о том, могут ли эти тесты выполнить свою миссию. Предоставляйте информацию, которая помогает: обобщите методы и мотивы, по которым были созданы тесты.
Всем своим. %день_недели%, %название_кабака%
Оказалось, каждый ждет персонального приглашения и сомневается, ему ли адресовано послание. Напомнило этот баш:
ааа: дебил
xxx: ты мне?
yyy: ты мне?
zzz: кто, я?
aaa: вы просмотрели миниатюру "детская самооценка"
Но все это неважно, мы все равно соберемся. Люди же хорошие, хех.
Да, велик и я самопочинились после пары недель аута, ингресс снова с нами.
А еще на работе грядут сугубо интересные и веселые изменения: юнглинг Украинец рискует стать падаваном, а на печеньки нашей стороны соблазнилось небесное создание, которое мы будем учить плохому.
Слово Канеру
Стратегия тестирования больше, чем просто тесты
Ваша стратегия тестирования содержит причины тестов, которые вы проводите. Когда вас о ней спрашивают, то хорошей идеей кажется сказать: эти 500 тестов и есть моя стратегия тестирования продукта. Это, может быть, и точный ответ, но не очень полезный. Это перегрузка информацией и она ничего не говорит о том, могут ли эти тесты выполнить свою миссию. Предоставляйте информацию, которая помогает: обобщите методы и мотивы, по которым были созданы тесты.
Подписаться на:
Сообщения (Atom)