Приглашаю принять участие в голосовании по поводу использования UML www.uml2.ru/forum/index.php. Не посчитайте за труд проголосовать во всех 4 голосованиях. Спасибо

http://moikrug.ru/feed/814227147/
 

24 - 2 5 июля 2010 года, в городе Иваново, в компании ЗАО "НПО Консультант" для сотрудников Департамента информационных систем Алексей Баранцев проводил тренинг по теории и практике тестирования.

Первый день был ориентирован на теоретические аспекты тестирования. При этом основная целевая аудитория этого дня были аналитики и разработчики (архитекторы, проектировщики и программисты).

Алексей начал свой тренинг с того, что обратился к программистам, руководителям отделов с вопросом: "Что такое тестирование с их точки зрения, чем должны заниматься тестировщики, какая от них собственно польза?"

Умело используя приемы майевтики, Алексей практически заставил аудиторию, самим сказать все, что нужно, почти не внося коррективы в ход дискуссии.

Что же выяснилось? Тестировщики должны давать некую информацию. При этом, как получают эту информацию тестировщики, по большему счету никого не интересует. 

Может тестировщики регулярно впадают в транс и подключаются к информационному полю Земли, где, как известно, существует вся информация которая была, есть и будет.

А может они просто "от балды" заполнили логи и сказали, вот так и будет.

Или всю ночь работала скрупулезно построенная, любовно выращенная, потом выстраданная тестировочная сеть, результаты деятельности, которой и есть основа той самой сокровенной информации.

Способ получения не столь важен, однако нужна гарантия, что информация достаточно достоверная и объективная, т.е. нужны убедительные доказательства того, что выводы тестировщиков, информация от них верны, и им можно доверять.

Однако и в этом случае проведение тестов вовсе необязательно. Может достаточно авторитета руководителя группы тестирования? Или зеленого лога в рассылке?

Но, по-серьезному, без тестов не обойтись. Но является ли при этом тестирование единственным методом контроля качества? Конечно нет! Существует масса иных активностей, способствующих этому: проверка кода, нормоконтроль, компиляция, статический анализ, профилирование и т.п.

Затронули вопросы покрытия системы тестами. Возможно ли это, как это измерять? Если проверяем соответствию требованиям, то , вероятно, ожидаем, что тесты покрывают все требования. Но можно ли покрыть требование? Скорее всего можно, но не полностью и не каждое. Можно ли составить столько тестов, что они обеспечивают 100% гарантию от ошибок?

Алексей привел пример про треугольник. Т.е. задача - есть поле, куда вводится строка из трех чисел, и нужно определить можно ли из них получить треугольник и какой он. Упражнение было вообщем впечатляющим, но ответ на вопрос выше как-то повис в воздухе.

Далее тренер углубился в философские вопросы о том, какие тесты нужны, каковы они и как классифицируются. Упомянули Карла Попера (если я не ошибаюсь) и его фальсификацию теорий. Получалось, что самые важные тесты - это тесты, которые фальсифицируют, опровергают гипотезу о отсуствии ошибок. В том смысле, что сотню и более положительных тестов легко перевешивает один негативный тест.

Естественно поговорили о модульном и системном тестировании. Обсудили, чем одно отличается от другого. Алексей признался, что не очень доверяет такой классификации, она не всегда (или часто) не удобна.

Он предлагает делить тестирование на тестирование внешних интерфейсов (и тогда это системное) или внутренних интерфейсов (и тогда оно модульное). Причем всегда, что считать в данный момент внешними, а что внутренними интерфейсами определяется общим контекстом задачи.

Также он предлагает делить тестирование через пользовательские интерфейсы - а это то что можно тестировать вручную и через API (т.е. по сути программным, автоматизированным способом)

Далее поговорили о том, каквоа главная задача тестировщиков - сделать тестов, как можно меньше, и убедить остальных, что этого достаточно.

Естественно плавно перешли к вопросам уменьшения числа тестов. Познакомились с эвристиками помогающие придумывать тесты и обеспечивать по возможности полное покрытие. DUFFSSCRA. Особенно много потратили времени на доменное тестирование.

Также рассмотрели другой набор эвристик, позволяющий правильно формировать оракулы: HICCUPSSF.

В ходе обсуждения пришли к выводу, что эвристики могут быть весьма полезны и аналитикам, и проектировщикам, и программистам.

По занавес первого дня обсудили проблемы регрессионного тестирования. К сожалению "серебрянную пулю" не получили :(.

Хотя несколько интересных идей все-таки в нашу копилку занесем.

Второй день были только тестировщики, и по сути этот день превратился в полноценный консалтинг. Основой послужили эвристики составления стратегического плана тестирования: SFDPOT, анализ того, как мы работаем и где у нас проблемы.

Поняли, что тестировщики тоже, могут быть очень серьезной силой, влияющей на архитектуру системы, культуру разработчиков, юзабилити интерфейса и системы в целом.

Дело за малым, получив знания, умело их приментить, а не растворить в рутине.

Читайте тут: http://blogs.uml2.ru/post/Odin-den-iz-zhizni-LAF2010

Я потихоньку веду блог также и в другом месте. Поэтому пока часть информации просто дублирую.

Прочитал, вернее пробежался с углубленным прочтением отдельных мест, книгу Моделирование на UML. Теория , практика , видеокурс Новикова Ф.А и Иванова Д.Ю. "Ну, еще одна книга про UML" - скажите Вы - "Мало ли таких книг, а толку". Да, еще одна книга про UML. Но зато какая!

Авторы наши, российские, написана хорошим родным русским языком, выдержана в отличных традициях русской (российской) научной школы, неукоснительное следование стандарту UML, масса продуманных, тщательно выверенных, я бы сказал выстраданных, примеров.

Книга, естественно, про UML, но не только и гораздо больше, чем только UML. В книге кратко, ярко и очень уместно приводится масса комментариев и отступлений, по которым можно проследить историю зарождения науки и профессии программирования, следом за авторами понять, как создавался UML, что влияло на него и как в нем трансформировалось.

Эта книга - кладезь для преподавателей вузов, для отвественных за обучения персонала. Книга полезна будущим специалистам, т.е. студентам. Студентам вообще просто нужно читать книгу, хотя бы для того, чтобы получить системное представление о своей профессии.

Лично я узнал массу нового и полезного для себя. Я читал и изучал многие книги по UML. С восторгом рекомендовал их студентам. Но, пожалуй, ни в одной из них я не смог получить такого ясного и точного понимания о назначении и порядке использования таких диаграмм, как диаграммы состояний (или автоматов), диаграммы деятельности.

Замечательная книга. Но сразу скажу - это нелегкое чтение. Это серьезная и скрупулезная работа. Главное, что следует уяснить, в книге можно найти ответы! Не стоит пугаться. Книга многослойна и многоярусна. Становится сложно - идите дальше. Потом всегда можно вернуться, а общего смысла и общей канвы - не потеряете.

Обязательно прочтите пятую главу "Дисциплина моделирования", открытий может и не сделаете, но понимания зачем все это нужно прибавится.

Очень интересна глава вторая "Моделирование использования". Последователи Коберна и текстовых описаний вариантов использования, возможно, будут несколько удивлены.

Заканчиваю. Рекомендовано к прочтению, изучению и использованию!

Лето, природа и приятная компания!

Летний Аналитический Фестиваль

10-11 июля 2010 года

город Иваново


ВСЕ на Летний Аналитический Фестиваль!

Приглашаем аналитиков, интересующихся и желающих обменяться опытом или просто пообщаться во время Летнего Аналитического Фестиваля, посвященного профессии аналитика, анализу, моделированию в проектах по разработке ПО и всяким другим интересным вопросам.

Организаторы: Сообщество аналитиков uml2.ru и ЗАО "НПО Консультант"

Наша приятная компания – аналитики и все все все.

Фестиваль будет интересен:

• Аналитикам

• Менеджерам проектов

• Архитекторам

• Ведущим разработчикам

• Ведущим тестировщикам.

• Другим специалистам Software Engineering



Фестиваль продлится два дня.

День первый – познавательный (10 июля)
Доклады в двух секциях
45 минут на доклад и обсуждение темы

Место встречи: ЗАО «НПО Консультант», 153000, г. Иваново, ул. Палехская, дом 10 (карта)


День второй – отдыхательный (11 июля)
свежий воздух, шашлыки, новые знакомства
обсуждение всех интересующих вопросов
обмен опытом
неформальное общение

Место встречи: Центр отдыха «Малинки» (схема проезда от г. Иваново).



Приезжайте и уезжайте не с пустыми руками!

Коллективный обмен визитками. Всем брать визитки обязательно, а у кого их нет, рисовать от руки, можно на листах формата А4!

На конференции можно будет приобрести футболки(~500 руб.), кружки(~300 руб.) и бейсболки(~500 руб.). Укажите Ваши пожелания при регистрации.



Тематика фестиваля:
· Зачем нужен ИТ Аналитик не в ИТ компаниях. Что он там должен и может делать.
· Сценарии использования. Как применять в проектах по разработке ПО.
· Кросс-платформенное моделирование. Увеличение производительности работы разработчиков программных систем.
· Совместная работа над проектами.
· и многое другое



Что почем:
Стоимость участия в фестивале: условно-бесплатно (участник оплачивает проезд и проживание).
Ориентировочные цены:

1. Стоимость участия в конференции - бесплатное (при условии предварительной регистрации, количество мест ограничено, спешите)

2. Билеты из Москвы до Иваново и обратно ~ 1000 руб. (плацкарт) *

3. Проживание (из расчета 1,5 дня ) ~ 2-2,5 тыс. руб. (http://www.malinki.ru/rooms/) **

4. Еда на второй день ~ 1000 руб. **

5. На базе есть лошади, рыбалка, прыжки с парашютом и т.д. ~ X руб. (http://www.malinki.ru/advanced/)***

* - для тех кто едет не из Иваново

** - для тех, кто едет на два дня.

*** - кто хорошо работает, тот хорошо и отдыхает!

Ждём вас на ЛАФ-2010!
All you need is ЛАФ!

 

22-23 мая 2010 в городе Иваново проходил корпоративный тренинг на тему "Управление командой технических специалистов". Мне посчастливилось участвовать в этом тренинге в качестве слушателя.

Тренинг проходил на базе центра отдыха Малинки. Погода была отличная, тренинг проходил в комфортной обстановке. Надоедали только комары.

Тренинг проводили Константин Кондратюк и Екатерина Скрибцова, и проводили на высоком профессиональном уровне!

Узнали много полезного как в теоретическом, так и в практическом плане. Тренинг проходил в частых дискуссиях по вопросам, которые вызывали живой отклик у слушателей. Множество примеров из собственного опыта Константина и Екатерины сделали тренинг увлекательным и весьма полезным. Масса практических заданий, кейсов, тестов позволили аудитории взглянуть на многие проблемы и задачи совершенно по-другому, увидеть себя со стороны, выявить проблемные места во взаимоотношениях, но и получить удовлетворение от осознания своих сильных сторон.

Программа курса была очень насыщенной. Настолько, что ряд участников высказались за то, чтобы сделать программу более узкой, но вместе с тем и более глубокой.

Первый день бы посвящен вопросам, связанным с понятием команды, встраиванием команды в организацию, жизненным циклом команды, вопросами управления команды на разных фазах, вопросами построения эффективной команды.

Второй день рассказывал об особенностях технических специалистов и управления ими. Как управлять конфликтами, как управлять временем команды.

Для руководителей отделов после обеда была дополнительная сессия, на которой обсуждались вопросы мотивации, работы со сложными сотрудниками, организации и проведения переговоров с сотрудниками.

Естественно мы не только учились, но и весело отдыхали. После завершения программы первого дня были устроены шашлыки. Жарили куропаток, свинину, баранину и с удовольствием все это поедали. Посттренинговые обсуждения не прекращались ни на минуту. Более того дискуссии были порой столь острые и интересные, что продолжались до 4 часов утра.

Конечно, мы не только думали о делах, но и веселились и отдыхали. Посмотрели как живут еноты (есть мнение, что это были енотовидные собаки), ходили на стрельбище, болели за наших в матче с Германией.

Не обошлось и без курьезов. Когда мы были на костровой площадке неожиданно подул ветер с ипподрома (конюшни). Ну я вам доложу была и вонь :)

Время пролетело не заметно. Все и участники-слушатели, и сами тренеры получили массу незабываемых впечатлений, удовольствия от неформального общения.

Вы не используете "Восточный экспресс"? Тогда мы идем к ВАМ!

17 апреля текущего года состоялась очередная конференция "Training Labs". Напомню, что конференция ориентирована на знакомство участников с уже имеющимися тренингами в области IT-образования и смежных областях, анонсирование новых тренингов и саморекламу тренеров, соответственно. Дополнительно в рамках программы представлены доклады на некоторые актуальные темы. В частности было несколько докладов, посвященных проблемам образования в высшей школе.

Конференция традиционно проходила на базе учебного центра Luxoft. В целом организация была отличная, разве что многие участники отмечали запутанную систему навигации по аудиториям, в результате которой участники попадали не туда, куда ожидали, или серьезно опаздовали.

Поскольку традиционно работало сразу 6 секций да еще на некоторых секциях тренинги проходили двумя параллельными потоками, попасть на все интересующие участника доклады, было практически невозможно. Мудро поступили те, кто сумел отправить сразу небольшую делегацию от своей организации. В этом случае охват оказался более широкий и потом можно было обменяться информацией и составить общее представление о тренере (докладчике) и его тренинге (докладе).

Наше сообщество было представлено Александром Байкиным, Андреем Вербицким и мною. Не так много, но свой вклад мы все-таки сделали. Ну, конечно, среди участников наши были! А Гриша Печенкин самоотвержено записывал секцию по тестированию!

Слушал Александра Байкина с докладом "Техника выявление проблем, как основной инструмент Аналитика". Тема действительно очень интересная и актуальная. Теоретически не очень сложная, на мой взгляд, но вызывающая массу проблем при ее практическом применении. К сожалению у меня не сформировалось мнение о то, что Саша предоставил действительно отработанный и серьезный тренинг. Необходимо сказать, что аудитория была довольно подкованная и знающая, а тренинг скорее был рассчитан на начинающих. Мне кажется, именно в этом и был просчет. Чувствовалось, что на некоторые серьезные вопросы Саша просто не был готов ответить. Примеры, которые использовались, тоже, как мне кажется, были не проработаны и не совсем понятны. Тем не менее жаркая дискуссия, масса вопросов показывают, что есть большой интерес к этой теме, а у тренинга есть большой скрытый потенциал.

Зная, что на конференции будет выступать Андрей Вербицкий с мастер-классом "Бизнес анализ: Искусство изобретения велосипеда - принцип Парето на практике; переговоры с заказчиком", я, естественно, не колеблясь, записался на него. Было очень интересно посмотреть на Андрея в живую. С первых минут чувствовалось, что Андрей умеет выступать и главное любит это делать. Что касается мастер-класса, то, я предполагал, что в мастер-классе демонстрируют свое мастерство или искусство в решение каких-то задач, но выступление скорее походило на семинар в учебном заведении с использованием принципов и приемов майевтики. К тому же начал Андрей с того, что пытался донести аудитории мысль, что не следует изобретать некий ИТ-велосипед, просто следует покопаться в закромах и найти его. Не знаю, что подумали другие участники, но в конечном итоге не совсем понял к чему все это было сказано. К тому же решение проблемы ИТ-велосипеда несколько затянулась. Во второй части Андрей стал рассказывать о том, как правильно использовать правило Парето. Как раз то, что не прозвучало у Александра. При этом у меня возникло некое смутное ощущение, что понятие ИТ-велосипеда было очень важно именно для использования его во второй части, т.е. как правильно применять правило Парето к управлению требованиями и планированию дальнейшего хода разработки. Отправной точкой в рассуждениях Андрея было предположение, что многое уже изобретено, поэтому уже в начале проекта мы быстро можем получить образ будущего решения, основываясь на аналогах. Причем в данном контексте Андрей трактует понятие аналога более широко. Это не только аналогичная, уже созданная кем-то, ИТ-система, но и просто аналогичные решения, реализованные может быть и без информационных технологий. Например, рассматривался пример с защитой какой-то королевской казны и ее возможной аналогией при создании многоуровневой системы защиты доступа к информации в банковской системе. Правда, почему это является изобретением ИТ-велосипеда, я не совсем понял. На мой взгляд перенос знаний из некоторой области в другую процесс творческий и изобретательский.

Большое число докладов (тренингов) было посвящено вопросам разрешения конфликтов и проблемных ситуаций. Мне удалось посетить два доклада: "Конфликты и проекты" и "Жесткие переговоры". Оба тренинга по сути были отличной рекламой, и были построены именно в этом ключе. На мой взгляд авторам вполне эта реклама удалась.

Ну и в конце несколько слов о своем докладе. Как я и ожидал, количество слушателей было невелико. Чего уж я не ожидал, что столь не велико! Присутствовали только 4 человека, кроме самого докладчика. Причем один из них модератор секции. Естественно в данной ситуации доклад получился не совсем в том ключе, в котором ожидался, т.е. как же все-таки выращивать специалиста-практика. Разговор скорее свелся к обсуждению проблем высшей школы и путей их преодоления. Дискуссия впрочем была жаркая и острая. В ходе доклада я попросил участников заполнить диаграмму Ишикавы на тему "в чем проблемы низкого уровня подготовки ИТ-специалистов". Мною была подготовлена заготовка с выделением четырех факторов. Участников я просил назвать несколько важных по их мнению причин по каждому из факторов. Вот что получилось:

Преподаватели:

1. нет четких ориентиров, чему учить
2. сильная зависимость от вендоров
3. слабая оснащенность ИТ-инструментарием
4. быть преподавателем невыгодно
5. не высокая квалификация в ИТ
6. медленная реакция на изменения требований в ИТ-индустрии

Студенты

1. упал престиж высшего образования
2. в смежных областях можно заработать больше и сразу
3. вуз - возможность откосить от армии, и только
4. низкий уровень школьной подготовки
5. влияние общества
6. отсутствие дисциплины, требующейся ИТ-специалисту

Государство

1. нет гос.поддержки высшей школы
2. много вузов, которые не в состоянии готовить качественных специалистов
3. нет подготовки преподавателей высшей школы
4. отстает от реалий жизни - реформирует образование с отставанием и неэффективными методами
5. нет четкого заказа к системе образования

Индустрия

1. ждет готового специалиста "вынь да положь!!!"
2. нужны не обученные специалисты, а умеющие переобучаться
3. уход в регионы - дешевая рабочая сила, но слабая вузовская подготовка
4. развивается по инерции, снижение потребности в инженерных кадрах
5. далека от вузов, нет общего языка между бизнесом и вузами
6. высокая изменчивость процессов
7. завышенные требования к специалисту

 
С презентацией доклада можно ознакомиться здесь.
 

 Уважаемые друзья!

17 апреля я выступаю на конференции Training Labs (http://www.training-labs.ru/), организованной Учебным Центром Luxoft, с докладом "Преподавание информационных технологий в ВУЗе: как вырастить специалиста-практика".

Как написано в моем анонсе на сайте конференции в докладе будут рассмотрены следующие вопросы:
1. Как мотивировать студента на получение хороших знаний?
2. Почему теория и практика так сильно разнятся: университеты не понимают нужд практической деятельности или практическая деятельность слишком консервативна?
3. Почему к примеру Химическая технология представлена несколькими десятками специализаций, а Информационная технология практически едина: как объять необъятное?
4. Почему же в вузах используется в основном функциональный подход в обучении?
5. Что такое масштабная личность?
6. Почему студенческие проекты в основном никчемный мусор?
7. Учить учиться?
8. Широта кругозора или твердость знаний?
9. А что такое специалист по IT? Жнец, кузнец и на дуде игрец?

Полную структуру выступления я пока сохраню в тайне. Надеюсь, что затронутая тема вызовет живой отклик и будет полезна 

Жду встречи с Вами на Training Labs!

 Пожалуй, только ленивый никак не высказался по этому поводу. Образование в области информационных наук, и в первую очередь высшее профессиональное образования, по мнению многих оставляет желать лучшего.

Недавние выпускники сетуют на то, что им дают либо устаревшие знания, либо слишком много теории и мало практики.

Ежегодно у меня возникают дискуссии со студентами на тему: "А зачем нас заставляют изучать эти предметы, а не читают вот эти?". Вряд ли мне удается убедить студентов, но я им отвечаю примерно так.

Программа обучения определена государственным образовательным стандартом. В нем закреплен профиль специальности. С ним всегда можно ознакомиться, когда выбираешь, куда пойти и где учиться. Так что ответственность за выбор с будущего студента никто не снимает. Другое дело, что часто будущий студент не всегда в состоянии сделать выбор правильно. Конечно, вузы проводят дни открытых дверей, на которых знакомят со своими специальностями. У большинства кафедр, и тем более ИТ-кафедр, имеются сайты с достаточно подробной информацией. Беда в том, что абитуриент часто мифологизирует будущую специальность, имеет в голове некое свое идеализированное представление, которое к действительности имеет мало отношения. Это, на мой взгляд, является одной из причин, почему уровень подготовки части выпускников бывает очень низкий. В ходе получения образование возникает разочарование, конфликт желаемого и реального. Такие студенты часто учатся по инерции. Ясно, что такое "учение" никому не доставляет удовольствия.

С другой стороны следует попенять и преподавателям таких кафедр. Парадокс, но порой преподаватели той или иной ИТ-специальности сами не в состоянии ясно определить, а чему они собственно учат. Не в смысле какие знания они дают студенту, а для чего их нужно давать, как их нужно давать, как эти знания согласуются с другими знаниями. Вообще, такая ситуация очень показательна. Каждый преподаватель стремится преподать свой предмет качественно, считает свой предмет очень важным. В теории ограничения систем Голдрата часто приводятся такие примеры, когда, стремясь оптимизировать каждый участок, мы в конечном итоге приходим к полному коллапсу системы. По-моему, так получается и в вузах. Идеально прочитанные предметы, не означают, что выпускник будет обладать всей суммой знаний и нужных ему компетенций. Конечно, ситуация не так плачевна. Преподавателей много, все они разные, кто-то из них общается со студентами на протяжении всего периода обучения, создавая преемственность и связи. Кроме того, практики, курсовые, квалификационные работы в определенной мере позволяют привести знания в систему.

Некоторые говорят, что получение образования в вузах почти пустая трата времени. Особенно ИТ-образования. С развитием Интернета практически каждый человек получает возможность эффективно самообучаться. Следовательно вузы нужны только для получения корочек? Да в этом есть доля правды. Однако, образование не равно обучению. Что же такое образование?

Образование - по законодательству РФ - целенаправленный процесс воспитания и обучения в интересах человека, общества, государства, сопровождающийся констатацией достижения обучающимся гражданином установленных государством образовательных уровней (образовательных цензов). Уровень общего и специального образования обуславливается требованиями производства, состоянием науки, техники и культуры, а также общественными отношениями.

Образование - это еще и воспитание. Вы можете возразить, что можно заниматься и самовоспитанием, так же как и самообучением. Да, наверное, но... Самовоспитание - формирование человеком своей личности в соответствии с сознательно выбранными целями, идеалами и убеждениями. Всегда ли студент понимает эти свои цели, идеалы и убеждения?

Как мы видим преподаватель не только должен давать знания, но и воспитывать. Вопрос чему, как? Личным примером, умными заданиями, в ходе общения? А может весь процесс обучения именно в вузе совместно с однокурсниками, различные жизненные ситуации, возникающие на протяжении лет обучения, достижения и неудачи - все это создает незабываемую атмосферу, которую невозможно получить, занимаясь дистанционно и самостоятельно? Может, задача вуза дать не только знания, но и создать ту атмосферу, ауру, которую часто называют Школа?

Но разве те же самые проблемы не случаются у химиков, механиков, энергетов, металлургов и т.п.? Почему мы не слышим , что у нас выпускают никудышных инженеров. Скорее говорят, что мало выпускают. Все хотят быть юристами и экономистами. Может быть ответ в том, что, во-первых, все эти инженерные специальности методически выверены; во-вторых, сложилось точное и ясное понимание чему и как учить; и, в-третьих, потому что там учат именно инженерным специальностям, т.е. показываются как знания по физике, химии, математики и т.п. применять на практике?!

Вспоминается анекдот. Чем физик отличается от инженера? Дали решать задачу физику и инженеру: рассчитать устойчивость трехножного стула.
Инженер пошел в библиотеку, засел за справочники и рекомендации и принес решение через 3 дня. Физик пропадал месяц и... и принес универсальное решение как рассчитать устойчивость любого n-ножного стула. Что лучше? Да, конечно, решение физика лучше в стократ, но ...

Вот в чем парадокс. Лично у меня складывается впечатления, что, готовя ИТ-специалиста, мы по сути не дотягиваем до "физика": ведь это требует определенного интеллектуального уровня, одаренности студента; но и не готовим "инженера", сбивая студента с толку изучением естественно научных дисциплин, забывая дать их привязку к реальным ситуациям, то есть забываем давать инженерию!

В аккурат под Новый год. Ну было что-то без четверти суток до НГ, пошел я в гараж за зимними запасами.

Возвращаюсь не спеша, погода новогодняя. Легкий снежок, температура не сильно в минусе.

Подхожу к "Спецавтоматике". Там открываются ворота, и выезжает пикапчик. Местная собака, кажется Найда, лает, надрывается. Я иду мимом. Собака кидается на меня и облаивает. Делаю вид, что меня это не касается. Собака видно совсем офонарела от такой наглости с моей стороны и, не долго думая, цапнула меня за правую ногу. Пришлось спасаться бегством отбиваться, еле отбился :).

Результат: штаны порваны, на ноге рана не рана, но V-образная отметина, словно чем прищемили. Приятного мало, но все-таки жизненный опыт