новое    архив    фото    Харьковские сети    login   


дата:   02-12-2009 20:43:17



Цитата:


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

Почти всё это делают свои или соседские дети, подростки в возрасте от 5 лет и выше. На этажах они срут потому что они туда покурить ходят чтобы родители не увидели, или поссать , чтобы домой не загнали. При этом выбираются либо более высокие этажи ,либо соседний подъезд(потому что мама запрещает далеко со двора уходить). Пакости со звонками и замками они делают не со зла, а потому что им играть негде. Дворы заставлены машинами, гаражами, мусорными баками, злыми бабушками насадивших огороды, последние участки забирают супермаркеты и лотки с сигаретами и пивом. Т.к. на улице места не хватает дети перебираются в подъезды, откуда их естественно периодически выгоняют. Далее объектом для игр становиться подвал для которого выкручиваются лампочки из соседнего подъезда. Если из подвалов выгоняют то переходят на заброшенные или плохо охраняемые стройки, кладбища, посадки, пустыри и т.п.
В другие дворы(чужие) обычно никто не ходит! т.к. существует своего рода раздел территорий(да, именно раздел!).Т.е. если ребёнок увидит "чужака" то может начаться драка(это инстинкты и только у мальчиков...хотя встречал и у девочек)
Это всё потому что НЕТ МЕСТ ДЛЯ ИГР! и замками на дверях вы это не исправите.
Конечно не всё делают дети, остальное делают взрослые. Идя домой и докуривая сигарету -окурок бросается между этажей или на этаже соседа, тоже с пустыми бутылками от пива и всякой рекламой. По пьяни ,не дойдя до своего этаже ,угол становиться туалетом и т.д.
------------
Во всём конечно нужно найти виноватых. Все стараются найти виновных в бомжах и наркоманах и никто не задумался ,что наркоманов и бомжей не так много по масивам блуждает и такое малое количество просто не в состоянии обойти все дома и успеть и поссать, и лампочку выкрутить и набросать мусор и т.п.
Наркоманы днём шляются в основном по центру и в общественном транспорте, чтобы иметь возможность украсть на очередную дозу. Ночью они "кайфуют" на своих общих "блатхатах" и только единицы(на весь город) по ночам могут искать жертву для ограбления, но от них точно замок на подъезде не спасет. Если вы увидели шприц у себя на этаже то 50/50 это соседский подросток "сел на иглу"(дома не колется чтобы родители не заметили)
Бомжи днём тоже стараются в городе "в массах" находиться попрошайничая и собирая бутылки. У бомжей свой маленький мир и у них есть "общаковые места", где они совместно проводят ночи и холодные дни. Им нужно держаться вместе + попрошайнический бизнес очень выгоден и над ними есть свои хозяева.
Если вы заметили грязного, дурно пахнущего мужчину ,валяющегося между этажами то есть большая вероятность ,что это из соседнего дома пьяница подъезды перепутал(или вообще ваш сосед. Мы ведь не знаем всех соседей),а грязный потому что пока дополз все дороги вытер.
Только единицы(также на весь город) могут ночевать на верхних этажах или подвалах(отбившиеся от стада)


добавить отзыв

дата:   29-11-2009 14:54:05



Немножко ляпов от Телекоментаторов

ГП Германии-93 (Сергей Ческидов)

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

Шлем должен быть достаточно прочным, что бы когда машина перевернется, спасти головной мозг

Алексей Попов

В зависимости от температуры литр меняет свой объем. (2002)

Вы знаете, уважаемые телезрители, пилоты Формулы-1 постоянно пьют!!! (2002)

Михаэль вчера Шумахер. (2003)

Над Шумахером прошел дождь. (2006)

Александр Кабановский и Александр Каминский

Кими, не надо тут обгонять! Здесь сыро, скользко и противно...

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

Сато обгонял в Канаде одной левой.

А первым, первым на трассу выезжает, вы не поверите, Фелипе... Фелипе Масса. Я Вам скажу даже больше, это Кими Райкконен

ГП Монако-08 (Кабановский)

Он зацепил отбойник и от его машины начали отваливаться всякие гайки, болты, антикрылья, прокалываться колёса - но Фернандо всё-таки довёл свой болид до боксов.

Интересно, что же там Кими такое сотворил что его поведение будут исследовать специально обученные судьи.
Недаром Монако называют самой лучшей, самое вообще известной гонке в мире, ну не знаю, есть там ещё Индианаполис какой нибудь, но это всё дела американские...

Мечта Сутиля накрылась красным тазом... (Райкконен выбил шедшего четвертым Сутиля)

Разочарование на лицах механиков, разочарование на лицах Сутиля...
И тут Сутиля настиг красный карающий кулак.
Злодей, злодей Райкконен...

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

Мюррей Уокер

Эта машина либо стоит, либо едет.

С машиной все в порядке, просто она горит.

Альберто опустился вверх до пятого места.

И пять первых мест занимают пять разных машин!!!

И в этом году уже было пять гонок - Бразилия, Аргентина, Имола, Шумахер и Монако.

А теперь машина, идущая на третьем месте, собирается обогнать на круг машину, идущую на втором!

Мюррей: Что ж, Берни, за 17 лет с того времени, как вы купили Макларен какое из ваших достижений, Вам больше всего запомнилось? Берни Экклстоун: Я не помню, чтобы я покупал Макларен!

Андре де Чезарис… Это человек, который выиграл наибольшее количество Гран-при, так и не выиграв ни одного из них.


добавить отзыв

дата:   27-11-2009 13:43:48



Последнее изменение: 11 июня 2008г.
Экстремальное программирование – реальность и мифы

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

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

Итак, краткое оглавление.

* Теория и практика XP
* Практики XP
1. Планирование
2. Тестирование
3. Парное программирование
4. Рефакторинги
5. Простой дизайн
6. Коллективное владение кодом
7. Постоянные (непрерывные) интеграции кода
8. Заказчик в команде
9. Частые выпуски версий
10. 40-часовая рабочая неделя
11. Стандарты кодирования
12. Метафора системы
* Мифы об XP
* Предназначение XP
* Проведение грани – тут XP, тут не XP.

Пожалуй, начнем.
Теория и практика XP

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

Происходит XP из простой посылки. Программное обеспечение – чрезвычайно непостоянная вещь. И эта непостоянность вызывает закономерные проблемы при стандартных способах разработки. Хуже всего то, что требования могут меняться непосредственно в то время, когда разрабатывается продукт. Т.е. к моменту выхода он уже несколько устаревает. Именно эту проблему – жесткости стандартных методик разработки – и призвана решить методология XP.

Здесь, однако, есть небольшой нюанс. Все книги, которые я читал, – они несколько популяризаторского толка. И именно в таком шоу-стиле они и написаны. "Йо, вау, аплодисменты, XP это круто" – такие ощущения просвечивают тут и там. И уже одно это зачастую вызывает неприятие. Кроме того, некоторые высказывания народ почему-то склонен понимать буквально, что приводит опять-таки к неприятию идей еще до того момента, как их успевают осознать.

Есть еще один момент, которого не учитывают многие. Дело в том, что между теорией и практикой – пропасть. Вы можете прекрасно знать теорию, но не быть способным применить ее на практике.

Приведу пример. Он, правда, не из области программирования, а из области вождения машины. Мне как-то эта область весьма близка. Допустим, некто (пусть это будет девушка) учится водить машину. Для определенности – трогаться с места. Она прекрасно знает, что надо плавно отпустить сцепление. И тем не менее – машина глохнет. Раз, другой, третий, десятый. Почему? Потому что это практика. Создатели педального узла не предусмотрели вождение на "шпильках". В нужный момент каблук теряет опору и проскальзывает, в результате сцепление отпускается рывком.

Ладно, обувь сменили. Машина продолжает глохнуть. Почему? Потому что отпускать сцепление плавно нужно не на всей длине хода, а только на рабочей – 2 см от силы. И если отпускать сцепление с той скоростью, которая нужна именно на рабочей части хода – до этой рабочей части нога будет подниматься минуту. Затечет, заболит, этот процесс в конце концов просто надоест. В результате – сцепление брошено, машина заглохла.

Что же нужно на самом деле? Практика и ничего более. БЫСТРО поднять ногу до рабочей зоны, плавно и существенно медленнее отпустить педаль в рабочей зоне, после схватывания отпустить вообще. Практика, практика и еще раз практика. И очень желательно – вместе с инструктором. Который точно знает, где начинается рабочая зона, и даст это почувствовать обучаемому.

Точно так же, как надо учиться вождению с инструктором – XP надо изучать рядом с тем, кто уже знает практические тонкости, сильно меняющие всю картину. А чаще всего бывает вот как: человек "XP изучал с пристрастием (хотелось понять, что же это за фигня такая на мою голову), так что понял всё правильно", потом "пережил два внедрения XP в разных проектах и дважды задавил эту ересь", и на этом основании делает далеко идущие выводы – "XP полностью ... исключает возможность получения качественного результата". Это все равно, что девушка из примера выше после трех попыток, закончившихся заглохшим двигателем, безапелляционно заявила бы, что на коробке с ручным переключением водить невозможно. Ересь это. Автогонщиков бы такое заявление весьма позабавило, я думаю.

У меня опыт работы по классической методологи XP больше года. Причем я начинал в команде, которая уже давно работала с использованием XP, так что у меня была возможность обойти те грабли, на которые наступают теоретики. На текущем же месте работы мы применяем некоторые из практик и постепенно движемся в сторону введения остальных. Постепенно – ввиду сильной сопротивляемости менеджмента. В следующей части я хочу дать описание практик XP прежде всего с точки зрения их реального применения, а не с позиций голой теории.

Еще один момент. XP – это не набор правил из серии "шаг вправо, шаг влево, прыжки на месте – расценивается как попытка к бегству и карается расстрелом". Это всего лишь рекомендации. Каждая из них имеет свой смысл и способна дать свой эффект. В какой степени применять каждую из этих рекомендаций – нужно решать по обстоятельствам. И это один из моментов, который понимаешь только при работе с методикой. Применение практик "в максимальной степени" на деле означает "в максимальной степени, возможной в каждом конкретном случае". Ибо, как и в любой работе, приходится иметь дело с людьми. Другой вопрос, что вместе практики дают эффект, зачастую сильно превосходящий сумму. Это можно сравнить с резонансом. Полк, проходящий по мосту, способен разрушить его, если не собьет шаг (существует специальная команда, и обусловлена она именно этим, были прецеденты!) И это при том, что то же самое, но вразбивку (фактически, сумма воздействий) он выдерживает "на ура".

Итак, перейдем к рассмотрению непосредственно практик XP.
Практики XP

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

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

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

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

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

Допустим, разрабатывается система документооборота. Заказчик хочет в нее добавить выставляемые счета и платежи по ним. Что нужно сделать:

1. Добавить в систему такие понятия как invoice и payment. Т.е. определить их в базе, сделать бизнес-объекты, сделать UI под каждый из них. Итого – по дню работы на каждый элемент.
2. Добавить в систему возможность сопоставлять счета и платежи. Бизнес-логика, таблица сопоставления в базе, UI. В зависимости от сложности логики – это 1-3 дня.
3. Добавить в систему возможность связывать счета с уже имеющейся в системе информацией по сделкам, издержкам и т.п. Это опять-таки бизнес-логика, изменения в базе, UI.

Для начала хватит. Что нужно выяснить у заказчика:

1. Какая информация должна содержаться в объектах типа счет и платеж. Поля, названия их, которые должны фигурировать в UI, форматы вводимых данных, возможная их валидация. Должны ли вводимые данные соответствовать чему-то имеющемуся в системе, например, выставляемый счет может относиться к определенному контрагенту, соответственно, нужна возможность поиска контрагента вместо его ввода в UI, и т.д. и т.п. Вам нужна ВСЯ информация, которая потребуется вам для реализации этого требования заказчика.
2. Может ли один платеж быть соотнесен с несколькими счетами? Может ли один счет быть оплачен несколькими платежами? Что должно быть видно пользователю, какие действия он должен предпринять, чтобы поставить в соответствие счет и платеж? Должен ли пользователь видеть полностью оплаченные счета? Полностью расписанные по счетам платежи?
3. Должен ли пользователь иметь возможность создавать счет прямо из UI, относящегося, скажем, к сделке, или он всего лишь может выбрать уже существующий счет? Должен ли пользователь иметь возможность выставлять несколько счетов на сделку? Один счет на несколько сделок?

И т.д. и т.п. Вопросов может быть существенно больше.

Когда все требования таким образом сформированы – они фиксируются где-нибудь в письменном виде. Дабы не было разногласий. Затем заказчик определяет приоритеты. Допустим, ему очень нужна возможность выставлять счета, причем из UI сделок. А соотношение с платежами пока не очень актуально. Тогда именно в этом порядке и сортируются данные задачи. Причем обратите внимание – в примере заказчику нужна часть пункта 1, часть пункта 3. Т.е. эти пункты должны быть разбиты на подзадачи.

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

Первое – оценивать задачу может лишь тот, кто будет ею непосредственно заниматься. По той простой причине, что разработчики не идентичны. Один может сделать задачу быстрее, другой – медленнее. Следовательно, точная оценка при обсуждении задач с заказчиком сделана быть не может. Впрочем, она не может быть сделана по определению. :)

Второе. Разработчики работают в разных ситуациях. Они могут целый день не отрываться от задачи, а могут полдня потратить на консультации других разработчиков, исследования и т.п. Это непредсказуемо. Возможно лишь статистическое накопление информации. Так вот, как правило, на разработку из-за таких отвлекающих факторов тратится больше времени, нежели изначальная оценка. Потому в XP принят такой подход. Оценка работы при условии, что разработчик будет сконцентрирован исключительно на задаче, что его ничто не будет отвлекать, что он будет работать с максимальной продуктивностью – эта оценка называется идеальное время. Время, потраченное на разработку в действительности, называется реальным. Отношение этих времен, усредненное за определенный промежуток времени (например, за 8 циклов разработки, см. Частые выпуски версий), называется коэффициентом загрузки (load factor).

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

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

Пойдем дальше. Описание задачи получено, временная оценка тоже, приоритеты расставлены. При работе с заказчиком удобно иметь систему общего доступа, в которой будут отражаться все детали, касающиеся разработки. Что-нибудь типа TWiki (http://www.twiki.org/). Это позволяет оперативно вносить изменения в работу. Итак, в TWiki создается т.н. история (user story), в которой описывается все, что относится к конкретной задаче. Все, что сообщил заказчик, временные оценки, приоритет. Возможно, комментарии в процессе реализации. После того, как история создана, заказчик еще раз просматривает ее и подтверждает, что все верно и он с такой постановкой задачи согласен. Всё, можно работать.

Такой подход может показаться весьма муторным. Однако он служит одной очень важной цели. Такое обсуждение заставляет заказчика продумать до мелочей его требования к системе. Следовательно, сильно уменьшается вероятность того, "через неделю заказчик меняет требования на противоположные", как упоминал кто-то из форума. Да и вообще, часто оказывается, что часть изначальных требований заказчику и не нужна, а нужно ему что-то совсем другое. Если бы он просто написал ТЗ, а потом бы его реализовали, – пришлось бы переделывать очень много. И заказчик был бы явно недоволен. В случае же XP-планирования – он с гораздо большей вероятностью получает именно то, что хочет.

Стоит еще упомянуть вот какой момент, связанный с планированием. Если какая-то функциональность вызвала затруднения в реализации и все, что запланировано, не укладывается в рамки очередного релиза – объем реализуемой функциональности необходимо снизить. Именно так – не отодвинуть выпуск продукта, а уменьшить функциональность. Почему – см. в разделе Частые выпуски версий. Т.е. убрать из запланированной функциональности то, что наименее критично. Решить это должен заказчик, и никто кроме него не может это сделать. Парадоксально, но факт, – часть функциональности таким образом вообще отсеивается. Что означает, что она изначально не была нужна.

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

О планировании пока всё. Переходим к следующей практике XP –
Тестирование

А точнее – написание тестов ПЕРЕД написанием кода.

Тестирование вообще процесс, нелюбимый разработчиками. Написание тестов – тем более. А уж написание тестов ДО кода – вообще смертоубийство.

Между тем, тесты приносят реальную пользу. В каждый момент времени, выполнив все тесты, мы можем сказать, что система работает так, как от нее ожидают. Очень часто это помогает при каких-то внутренних изменениях, которые не должны затрагивать функциональность, например, при рефакторингах. Да, команда тестировщиков в конечном итоге скорее всего выловит ошибку. Но сколько пройдет времени? Собрать версию, выложить ее на тестовый сервер, запуск нагрузочных тестов, запуск приемочных тестов. День. Если не больше. А могут вообще и не найти ошибку. И вылезет она только уже в рабочей системе, найдут ее пользователи. При том, что для выявления ошибки с помощью тестов нужно 20-30 минут. Столько, как правило, выполняются тесты в системах среднего размера.

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

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

Так вот, если оставить тест на потом, то мы уже будем знать, как работает этот черный ящик. И вольно или невольно, но мы можем заложиться на собственную реализацию. Т.е. для теста блок функциональности будет уже не черным ящиком, а механизмом, принцип работы которого известен. Таким образом, если этот блок изменится, но продолжит работать корректно – тест может не пройти. Это еще полбеды. Хуже, если в тесте мы будем проверять не конечный результат, а именно работу механизма. И тогда, с точки зрения теста механизм может работать верно, но на выходе даст не В, а С. Я видел и такое. Польза от подобного теста сомнительна. Чтобы избежать такого эффекта, и нужно писать тесты ДО функциональности.

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

Двигаемся дальше. На очереди практика, вызывающая очень много вопросов, критики и т.п., а именно –
Парное программирование

В прямом смысле этого слова. Парное – два разработчика за одним компьютером. Критики обычно утверждают, что в таком раскладе общая производительность пары разработчиков ниже, чем по отдельности. Хочу поделиться опытом.
Собственный опыт

Декабрь 2000 года. Мы с коллегой сидим в длительной коммандировке в Голландии. Днем работа, вечером делать нечего. Пиво пить мы не любим. В карты играть – вдвоем неинтересно. Пойти тоже особо некуда. Есть один компьютер на двоих.

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

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

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

Я хорошо помню процесс разработки. Ошибки вылавливались еще до того, как код компилировался впервые. Существенный плюс второй пары глаз. В процессе написания кода постоянное обсуждение, в результате чего код получался чистым, ибо оптимизировался на лету. Очень большое количество интересных идей – результат мышления в одном направлении, один был катализатором для другого.

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

Итак, написание кода вдвоем. Что это дает? Прежде всего – мышление у людей не совпадает. В результате в каждой точке ветвления есть большая вероятность, что я и кто-то другой изберем разные направления движения. Т.е. родятся две идеи вместо одной. Соответственно, появляется возможность выбрать более оптимальную из них. Если такое происходит в каждый момент, как это бывает при парном программировании – оптимальность и ясность кода резко возрастает. Соответственно, падает количество ошибок, что немаловажно для стоимости дальнейшей поддержки кода. Критики этого, как правило, не учитывают.

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

Третье. При работе в паре разработчики, фактически, подстегивают друг друга. В результате этого повышается скорость работы каждого из них. Это же, кстати, является и минусом парной работы. Работать вдвоем в таком режиме 8 часов в день – ОЧЕНЬ тяжело. Средний выход сильно выше, соответственно, выше и усталость. Но общий эффект, даже при отдыхе, перекурах, питье кофе, чая и т.п. все равно лучше, нежели при программировании порознь.

Довольно часто парное программирования настолько пугает заказчика (как вариант – руководство компании), что от XP отказываются только поэтому. В таком случае можно применять т.н. параллельное программирование. Отличается от парного оно исключительно тем, что у разработчиков не один компьютер, а два. И внешне ситуация гораздо приятнее для руководящего ока. В случае применения такой практики есть два "но". Первое – разработчики должны сидеть за соседними столами, так, чтобы быть максимально близко друг к другу. Это даст им возможность обсуждения задачи. Опять-таки можно подвинуться на полметра в сторону – и оказаться за одним компьютером. Правда, при этом несколько упадет эффективность написания кода, ибо уже не будет одновременного мышления в одном направлении при работе на двух компьютерах. Но даже это способно дать лучший эффект, чем программирование порознь.

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

В этом месте очень многие критики заявляют – это уже не XP. Потому еще раз хочу подчеркнуть – XP не есть набор наручников и железных клеток. Это всего лишь рекомендации. И степень применения каждой из них надо выбирать в каждом случае. Да, модификации могут повлиять на общую производительность, но общий эффект все равно будет. Называйте то, что получилось как хотите. Я лично это называю XP.

В противном случае можно договориться до того, что из двух автомобилей один является автомобилем, а другой нет, на том основании, что какой-то гуру двадцать лет назад описал автомобиль как имеющий механическую коробку передач, а у второго из них она автоматическая. Не стоит относится к чьим-то словам фанатично, пусть даже они и стояли у истоков. В 1977-м году Кен Олсон, основатель Digital Equipment Corp. (DEC), сказал, что "нет никаких причин кому-либо желать иметь дома компьютер". Что вы ответите тому, кто будет отговаривать вас купить домой компьютер только на основании этого утверждения?

Подводя итог. Парное программирование имеет несомненные плюсы. Я это знаю на личном опыте. Если по каким-то причинам не получается ввести именно парное программирование – используйте хотя бы параллельное. С течением времени, когда доверие со стороны заказчика (руководства) к методике в общем возрастет (ибо они будут видеть результат!), можно будет перейти и на парное программирование.

Переходим к одной из наиболее обсуждаемых практик –
Рефакторинги

Как правило, само слово "рефакторинг" – словно красная тряпка для быка. Причем как для критиков XP, так и для руководства. Меня однажды уволили после произнесения этого слова. Руководство просто не смогло понять, что можно сделать в течение двух месяцев, если не разрабатывать новую функциональность.

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

Я уже говорил, но повторю еще раз. Программное обеспечение – вещь непостоянная, подверженная изменениям. Требуется новая функциональность. Расширяется старая. Вот тут и зарыта собака размером с доброго слона.

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

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

Через некоторое время (иногда немалое!) появились новые требования к продукту. И теперь старое решение уже не очень хорошо. Единственным возможным вариантом является переработка старого решения так, чтобы оно отвечало новым требованиям, но при этом вся старая функциональность сохранилась.
Пример

Пусть у нас есть система, скажем, что-то типа webmail administration. Создание почтовых ящиков, управление квотами и т.д. и т.п. При некоторых действиях администратора происходят изменения не только в базе данных, но и в LDAP и на диске. И изменения эти должны быть выполняться целиком и в определенной последовательности, чтобы избежать несоответствий. Т.е. при изменениязх, скажем, А и В, проводимых из двух потоков одновременно, состояние после завершения изменений должно быть либо (А1,В1), либо (А2,В2), но никак не (А1,В2) или (А2,В1). Т.е. – нужна синхронизация. Какое решение можно предложить? Использовать механизм синхронизации Java – synchronized- методы и блоки. Просто и красиво. Сделали. Работает.

Через год в систему введены фоновые процессы. Которые тоже надо синхронизировать, причем как между собой, так и со старым кодом. И если со старым кодом еще как-то можно использовать ту же модель синхронизации, то при синхронизации процессов между собой это уже проблематично. Дело в том, что процесс может длиться достаточно долго. И если ждать, пока завершится первый процесс, чтобы затем запустить второй (а именно так и будет при использовании synchronized) – запрос к системе будет висеть. Администратор может решить, что где-то сбой, нажать Stop в браузере, потом запустить процесс еще раз. В общем, ничего хорошего не получится. Нужно иметь возможность не ждать, если ресурс уже блокирован. В случае с synchronized-кодом это невозможно.

Решение – использовать, скажем, библиотеку синхронизации Дуга Ли. Причем не напрямую, а с созданием некого интерфейсного слоя. Дело в том, что эта библиотека введена в Java 1.5 (пакет java.util.concurrent), но интерфейс ее сильно при этом изменен. В свете планирующегося перехода на версию 1.5 лучше полностью повторить именно этот интерфейс, чтобы впоследствии миграция состояла бы только в замене имени пакета – с собственного на java.util.concurrent. Cделали. Работает. Замечательно!

Еще через год от бизнеса приходит требование – обеспечить устойчивость системы. Т.е. – поднять ее на не менее чем двух серверах. А это значит – обеспечить синхронизацию при наличии нескольких JVM. Все методы, используемые до этого времени, не годятся. Решение – используя уже существующий интерфейс, написать реализацию системы распределенной блокировки. Т.е. на поверхности – ровно те же интерфейсы, что и в Java 1.5, а под ним что-то принципиально другое. На основе, например, транзакционного кластерного кеша. JBossCache, Tangosol Coherence и иже с ними. Сделали. Работает. Причем основной код вообще не пришлось трогать! Подменили реализацию библиотеки синхронизации. С библиотеки Дуга Ли на собственную.

Разумеется, при всех переделках система внешне осталось той же. Не изменились ни поведение, ни бизнес-логика.

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

Критики часто утверждают, что рефакторинг есть следствие некачественного кода, дизайна, и т.п. Дескать, если система написана хорошо, никакие рефакторинги ей не нужны. Это в корне неверно. Рефакторинг МОЖЕТ быть следствием неправильного дизайна. Но я за 3 года ни разу не встречался с подобными случаями, хотя рефакторингами занимаюсь постоянно.

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

В XP приняты т.н. постоянные рефакторинги. Зачем это делается? Сравним с тем же ремонтом. На кухне стала качаться плитка. Можно подклеить, а можно и оставить на потом. Подклейка займет час. Дует из окон, пыль проникает. Можно поменять рамы на современные, пластиковые, шумоизолирующие и т.п., а можно оставить на потом. Замена займет полдня. Ну и т.д. и т.п. А теперь представьте себе, что ВСЁ, что каким-то образом не устраивало в кухне, оставляют на потом. Что будет в итоге? В итоге из кухни вынесут мебель, плиту, мойку, собьют ВСЮ плитку, т.к. она уже наполовину осыпалась, снимут рамы, ..., ... В общем, разнесут кухню вдребезги напополам. Ремонт будет продолжаться неделю, в течение которой в квартире жить будет невозможно. А после ремонта еще и убрать надо будет.

Что в итоге? В итоге мы имеем капитальный ремонт, который во-первых, дольше, во-вторых, дороже текущего. И весь промежуток времени до капитального ремонта мы будем жить в состоянии, которое нас каким-то образом не устраивает. Жить, конечно, можно, но... При том, что в случае текущего ремонта – это было бы и быстрее, и дешевле, и комфортнее в конечном итоге.

Параллель с постоянным (текущим) рефакторингом проводить или уже не стоит?

Рефакторинги жизненно необходимы в любой эволюционирующей системе. И тем более – при использовании XP, которая изначально ориентирована именно на гибкую разработку. Единственный вопрос. "За чей счет этот банкет? Кто оплачивать будет?" – как говорил незабвенный Иван Васильевич.

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

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

Я не знаю, откуда что берется, но у подавляющего большинства противников XP прочно укоренилось утверждение: простой == плохой (некачественный, безграмотный). Может, из-за того, что кто-то где-то сказал про минимально возможное количество классов. Может, еще из-за чего. Но их этого правила делается совершенно фантастический вывод – XP ориентирована на безграмотный дизайн и, следовательно, на безграмотный код.

Господа! Если вам кто-то сказал, что "просто" значит "безграмотно" – вас этот кто-то обманул. Можно писать просто, но при этом грамотно. А можна – как слышыца. И эта какрас и будит бизграматна. А можна писать са страшна сложными граматичискими канструкцыями упатрибляя диипричасные абароты и все равно эта будит бизграматна.

Грамотность – она не зависит от сложности кода. Это правило означает всего лишь одно – изобретать паровоз надо только тогда, когда лошадь уже не справляется. А пока она бодро топает, причем вас устраивает и скорость и грузоподъемность – паровоз вам не нужен. Если бы в примере, упомянутом выше, с самого начала разрабатывали распределенную синхронизацию – добром бы это не кончилось. Во-первых, с самого начала намаялись бы страшно, ибо библиотеки, пригодные для использования, появились существенно позднее. Во-вторых, систему все равно пришлось бы неоднократно переделывать. Потому как два года назад предугадать требования, выдвигаемые сегодня – НЕ-ВОЗ-МОЖ-НО! А следовательно – время, силы и средства потрачены впустую. Наконец, третье. Где гарантии, что то, на что вы хотите заложиться сегодня, ВООБЩЕ понадобится? На мой взгляд система вообще не требовала дублирования. Были проблемы с устойчивостью, но обусловлены они были исключительно системными проблемами. И решать их надо было на системном уровне – операционной системы и железа. Решение же этих проблем на уровне ПО было продиктовано исключительно политикой.

Итак, что же все-таки означает "простой дизайн"? Делайте то, что нужно именно сейчас. Никто не мешает делать это грамотно. Но не закладывайтесь на то, что может произойти далее чем через два месяца! Потому что два месяца – это уже достаточный срок для пересмотра направления движения.

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

Вернемся к аналогии с ремонтом. Вариант "сделать просто, но не поддерживать постоянно" мы уже рассматривали. Рассмотрим теперь другой вариант – "сделать сложно и поддерживать". Представьте, что вместо аккуратно крашеного потолка, обоев и кафеля мы сделаем на потолке штукатурные фрески, а пол покроем деревом. Как то было сделано, скажем, в 17 веке во дворцах саксонских королей. И все это – на кухне. К чему это приведет?

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

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

Это – классический пример того, зачем нужен простой дизайн. Я сталкивался с таким много раз, еще до того, как познакомился с XP. Функциональность сначала создавалась сложная, запутанная, потом она использовалась дай Бог на 10%, потом ее упрощали, а половину вообще уничтожали на корню. И оставался вопрос – а зачем так было делать с самого начала?

Что в итоге? В итоге мы приходим к тому, что

ПРОСТО не тождественно ПЛОХО

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

Идем дальше. Следующая практика –
Коллективное владение кодом

Что это означает? Означает это вот что: у кода нет автора, его может менять любой разработчик.

Что это НЕ означает? Это НЕ означает, что за код не отвечает никто. Существует четкое правило: сломал – чини. Если изменения, внесенные кем-то, сделали код неработоспособным – именно автор изменений ответственнен за приведение кода в рабочее состояние. Причем не когда-нибудь потом, а ПРЯМО СЕЙЧАС! Разработчик не имеет права заниматься чем-либо другим до того, как исправит внесенные им ошибки.

Потому, когда говорят, что если у кода нет автора, то это анархия – не верьте. Автор кода – вся команда. И всегда есть тот, кто за код отвечает. Это тот, кто менял его последним.

Больше по этому поводу сказать нечего. Следующая практика –
Постоянные (непрерывные) интеграции кода

Зачем это надо. Чтобы быть уверенным, что продукт не сломан последними изменениями. Это дает возможность быстро отреагировать на возможные проблемы. Кроме того, "интеграция" вовсе не означает "компиляция". Это еще и всевозможные проверки целостности кода, включая запуск тестов.
Собственный опыт

В текущем проекте у нас сборки происходят раз в полчаса, если за это время были изменения в коде, лежащем в репозитории. Сделано это на основе CruiseControl. Кроме unit-тестов (см. JUnit) у нас запускается проверка кода с помощью FindBugs, которая находит весьма нетривиальные ошибки, и проверка с помощью JCSC – на соответствие нашим стандартам кодирования. Все это вместе минимизирует возможность того, что в продукт попадет неработающий или даже просто не соответствующий стандартам код.

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

Следующая практика –
Заказчик в команде

Идея проста. Чем длиннее цепочка, тем больше она напоминает испорченный телефон. Каким бы тщательным ни было планирование – некоторые вопросы все р


добавить отзыв




дата:   26-11-2009 16:27:37



http://code.google.com/p/zfdebug/


очень полезная штука.
ставится с минимальной обточкой напильником


добавить отзыв

дата:   26-11-2009 16:05:01



Включение условных запросов в приложениях на Zend Framework

Источник: Enable your Zend Framework App with Conditional GET!
Автор: Danila Vershinin
Перевод: Лобач Олег

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

Эта техника предполагает использование условного GET-запроса (HTTP conditional GET). Это базовая возможность HTTP-протокола. Посылая правильные HTTP-заголовки, ваше приложение позволяет браузерам посетителей кэшировать страницы вашего сайта.

Вы беспокоитесь о посетителях, имеющих старые версии страниц в кэше? Не стоит! Предлагаемый метод позволяет получить все выгоды от кэширования на стороне клиента без внесения каких-либо изменений, и требует всего 5 минут вашего времени для ее интеграции :).

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

Давайте создадим наш плагин фронт-контроллера:

<?php
/**
* Plugin to support conditional GET for php pages (using ETag)
* Should be loaded the very last in the plugins stack
*
* @author $Author: danila $
* @version $Id: Conditional.php 15741 2009-02-08 11:58:44Z danila $
*
*/
class Smartycode_Http_Conditional extends Zend_Controller_Plugin_Abstract
{

public function
dispatchLoopShutdown()
{
$send_body = true;

$etag = '"' . md5($this->getResponse()->getBody()) . '"';

$inm = split(',', getenv("HTTP_IF_NONE_MATCH"));

$inm = str_replace('-gzip', '', $inm);

// TODO If the request would, without the If-None-Match header field,
// result in anything other than a 2xx or 304 status,
// then the If-None-Match header MUST be ignored

foreach ($inm as $i) {
if (
trim($i) == $etag) {
$this->getResponse()
->
clearAllHeaders()
->
setHttpResponseCode(304)
->
clearBody();
$send_body = false;
break;
}
}

$this->getResponse()
->
setHeader('Cache-Control', 'max-age=7200, must-revalidate', true)
->
setHeader('Expires', gmdate('D, d M Y H:i:s', time() + 2 * 3600) . ' GMT', true)
->
clearRawHeaders();

if (
$send_body) {
$this->getResponse()
->
setHeader('Content-Length', strlen($this->getResponse()->getBody()));
}

$this->getResponse()->setHeader('ETag', $etag, true);
$this->getResponse()->setHeader('Pragma', '');
}
}

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

$frontController->registerPlugin(
new
Smartycode_Http_Conditional(),
101
);

Обратите внимание на «101». Вы должны зарегистрировать плагин последним в стеке плагинов.

Эти простые шаги сделают ваше приложение на Zend Framework более дружелюбным к окружению:

*
Работа AJAX-запросов происходит через зендовский MVC (все виды запросов)
*
Если страницы не изменялись со времени последнего запроса, то они не будут передаваться
* Можно также полагать, что вы получите пользу для SEO — поисковые системы, поддерживающие Etag, смогут эффективно пропускать загрузку / повторный анализ страниц сайта, что ускорит индексацию страниц вашего сайта
* Отправка заголовка Content-Length включает постоянные соединения (Keep-Alive connections)


добавить отзыв

дата:   20-11-2009 17:31:47



Коварным болезням, которые могут повлечь аварию, можно помочь нехитрыми упражнениями

Знаете ли вы, что травматизм, связанный с автомобильными авариями, занимает второе место среди глобальных проблем медицины, уступив онкологии?

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

Надежный способ избежать аварий – это, как не банально, знание и соблюдение правил дорожного движения. Но в действительности все не так просто: правила одни для всех, а водим мы автомобиль по-разному, и зависит это не только от знания правил дорожного движения и мастерства вождения. Психологи, на основе проведенных наблюдений, пришли к выводу: “Человек руководит автомобилем так, как он живет”. Это значит, что если в жизни человек не считается с окружающими, с чужим мнением, считает себя “пупом земли”, склонен к агрессии, то так же он ведет себя и на дороге. На стиль вождения может влиять не только врожденная или приобретенная раздражительность, но и временные личные (семейные, например) проблемы.

Но даже если вы суперводитель, таки есть одно “но”, которое может стать причиной ДТП. И это “но” – ваше самочувствие. Все мы об этом знаем, но почему-то забываем или не обращаем внимания. А между тем некоторые психофизические особенности и дефекты являются серьезными противопоказаниями для вождения автомобиля. О наркомании и пьянстве говорить не будем, поскольку здесь все понятно. Но есть еще и слабость или инертность нервной системы. Первая обусловливает высокую импульсную принятия решений, непоследовательность действий, а друга – заторможенность, медленность в реагировании. К противопоказателям также принадлежат врожденные дефекты внимания: неспособность руководить желаниями, склонность к азарту, риску. Все эти свойства могут стать причиной аварий. Кроме того, есть целый букет болезней, наличие которых может стать причиной аварии. Такими болезнями является сердечнососудистая недостаточность, гипертония, ревматизм, астма. В этом случае лучше ходить пешком, или же, если жизнь без четырехколесного друга уже невозможна, следует быть чрезвычайно внимательным к своему самочувствию, особенно за рулем.

Также существует множество факторов, которые временно мешают руководить автомобилем. На них мы и остановимся подробнее. Первый фактор – это эмоции. Правда, дело здесь не совсем в эмоциях, а в тех следствиях, что они влекут. Умеренное эмоциональное нарушение даже заостряет чувствительность: более четко воспринимаются звуковые и зрительные сигналы, мобилизируются резервные силы организма. Но эмоциональное потрясение, причем как позитивное, так и негативное, может быть серьезным препятствием для водителя. Следовательно, нужно быть крайне осторожными и пытаться не садиться за руль под властью эмоций. В любом случае, если вы нервозны, не стоит садиться в машину. А если нужно? Тогда попробуйте расслабиться.

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

1. Поднимите голову, опустите руки, расслабьте мышцы шеи. Сделайте наклоны головы вперед, вернитесь в исходное положение, наклоните голову назад, вправо, влево, возвращая каждый раз в исходное положение. Повторите это дважды. При этом повторяйте мысленно: “Мышцы шеи расслаблены. Дыхание глубокое и свободное”.

2. Свободно откиньтесь на сидение, ноги снимите из педалей и поставьте на пол, руки свободно опустите вниз. Мысленно повторите дважды: “ Мышцы рук и ног расслабленные. Дыхание свободное”.

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

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

Много неприятностей влечет и усталость. Умеренной усталости может предотвратить изменение деятельности. Именно поэтому люди умственного труда, уставшие работой, могут на протяжении часа с удовольствием руководить авто. Но при сильной усталости ни одно изменение деятельности не поможет, потому что хочется лишь покоя. Потому, если вы “едва передвигаете ноги” и засыпаете на ходу, не думайте, что в машине вы сможете расслабиться. Временно побороть усталость можно путем волевого усилия или с помощью более сильной эмоции, следовательно, можете попробовать нахамить начальнику и выслушать, что он о вас думает.

Еще одним из факторов, которые мешают нам наслаждаться процессом вождения, является спешка. Стоит отметить, что многие из нас спешат, так сказать, по инерции. Психологическая инерция настраивает человека на спешку. Поэтому иногда целесообразно сказать себе: “Стоп! Действительно ли существует цейтнот, выдумал ли я его сам? Может, я спешу по инерции? И сыграют ли жизненно важную роль те 5-10 минут, которые я сэкономлю, потратив столько энергии?” А скорость вашей машины, согласитесь, лучше всего демонстрировать на гонках, а не на городских улицах.

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

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

Однако следует отметить, что на пустой желудок также не рекомендуется отправляться в дорогу, ведь связанное с этим уменьшение сахара в крови часто приводит к ошибкам в управлении авто, потому всегда в машине нужно иметь “НЗ” – плитку шоколада или конфеты. Спровоцировать дорожный гипноз может также высокая температура в салоне или пережитый накануне нервный стресс. Бороться с данным препятствием можно по-разному. Это может быть и беседа с умным человеком, в крайнем случае, поговорите вслух сами с собой или включите музыку (понятно, не колыбельную).


добавить отзыв




дата:   20-11-2009 17:29:52



Методы психологической активации мышления

Методы психологической активизации творческого мышления направлены на устранение так называемой психологической инерции мышления, препятствующей более всестороннему рассмотрению проблемы. Эти методы позволяют значительно увеличить число выдвигаемых идей и повышают производительность этого процесса. Однако для решения сложных креативных задач, в основе которых заложены противоречия, эти методы малоэффективны. Для решения подобных задач необходимо применение методов направленного поиска, таких, например, как Технология поиска бизнес-идей и ТРИЗ.

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

Наиболее известные методы психологической активизации:

* Мозговой штурм
* Обратная мозговая атака
* Корабельный совет
* Аналогии (cинектика)
* Оператор РВС
* Метод маленьких человечков

Мозговой штурм

Наиболее известным методом психологической активизации мышления является "мозговой штурм", предложенный А.Осборном (США) в 40-х годах. "Мозговой штурм" является коллективным методом поиска новых идей, основная особенность которого заключается в разделении участников на критиков и "генераторов"", а также разделение процесса генерации и критики идей во времени. Кроме этого "мозговой штурм" предусматривает выполнение ряда правил:

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

Главная цель - получить как можно больше идей.

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

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

Обратная мозговая атака

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

План действий:

1 этап. Недостатки

1. организовать совещание специалистов, знающих особенности совершенствуемого объекта
2. Ознакомить участников с правилами совещания
3. составить наиблее полный списк недостатков
4. провести анализ и оценку недостаткв

2 этап. Идеи

1. сформулировать задачи
2. генерировать и отобрать идеи решения по правилам мозгового штурма

Корабельный совет

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

* Высказываться по проблеме должны все.
* Порядок и очередность выступлений устанавливает капитан - от юнги к капитану, от младшего к старшему.
* Вопросы задает только капитан. Участники совещания могут критиковать и защищать идеи только по команде капитана.
* Все участники совещания должны критиковать, а затем и защищать идеи отобранные капитаном, в том числе и свои собственные.
* Итоги работы Совета подводит капитан.

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

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

Аналогии (Синектика)

Приемы использования аналогий относятся к методам психологической активизации творческого мышления. Наиболее интересным методом, использующим аналогии, является "Синектика" – метод решения проблем группой специалистов, широко использующих различные типы аналогий. Этот метод был предложен У. Гордоном (США) в 1952 году. Он основан на свойстве человеческого мозга устанавливать связи между словами, понятиями, чувствами, мыслями, впечатлениями, т. е. устанавливать ассоциативные связи. Это приводит к тому, что отдельное слово, наблюдение и т. п. могут вызвать в сознании воспроизведение раннее пережитых мыслей, восприятий, и "включить" богатую информацию прошлого опыта для решения поставленной задачи. Аналогия является хорошим возбудителем ассоциаций, которые в свою очередь стимулируют творческие возможности.

Известно много примеров аналогий, среди которых можно отметить следующие:

* Прямая аналогия, в соответствии с которой осуществляется поиск решений аналогичных задач, примеров сходных процессов в других областях знаний с дальнейшей адаптацией этих решений к собственной задаче.
* Личная аналогия предлагает представить себя тем объектом, с которым связана проблема, и попытаться рассуждать о "своих" ощущениях и путях решения проблемы.
* Символическая аналогия отличается тем, что при формулировании задачи пользуются образами, сравнениями и метафорами, отражающими ее суть. Использование символической аналогии позволяет более четко и лаконично описать имеющуюся проблему.
* Фантастическая аналогия предлагает ввести в задачу фантастические средства или персонажи, выполняющие то, что требуется по условию задачи. Смысл этого приема заключается в том, что мысленное использование фантастических средств часто помогает обнаружить ложные или избыточные ограничения, которые мешают нахождению решения проблемы.

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

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

Оператор РВС

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

К таким методам относится, например, "Оператор РВС (Размер, Время, Стоимость)". Суть метода заключается в мысленном изменении условий решаемой задачи. Предлагается рассмотреть задачу при мысленном изменении от нуля до бесконечности сначала размера совершенствуемого объекта, а затем временных и стоимостных факторов. В результате существенным образом изменяются представления о решаемой задаче и могут появиться совершенно неожиданные идеи, навеянные новым взглядом на проблему.

Метод маленьких человечков

Этот метод широко применяется в ТРИЗ (Теория решения изобретательских задач).

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

Техника применения метода сводится к следующим операциям:

* Необходимо выделить часть объекта, которая не может выполнять требования задачи и представить эту часть в виде маленьких человечков.
* Разделить человечков на группы, действующие (перемещающиеся) по условиям задачи.

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


добавить отзыв

дата:   27-10-2009 00:12:42



Приведу пример. На одном из промышленных предприятий закупили импортное оборудование по точному измерению размеров шариков для шарикоподшипников. В один прекрасный день оборудование стоимостью больше миллиона долларов сломалось, срок гарантии уже вышел и тогда пригласили двух специалистов по ТРИЗу. Они пару дней пытались разобраться в сложной механике и электронике этого чуда технической мысли, потом им это надоело и они использовали ТРИЗовский подход. Когда ТРИЗовцы пригласили руководство предприятия, то те увидели металлическую планку, по которой один за другим скатывались шарики. Если шарик был не идеально круглый, то он не докатывался до конца и падал налево или направо в корзину для брака. Руководители испытали психологический шок, но тщательная проверка показали, что этот «прибор» сортирует шарики безошибочно.

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


добавить отзыв

дата:   24-10-2009 18:26:57



10 тайников, где НЕ надо хранить деньги. Туда воры заглянут в первую очередь
"Граждане, храните ваши деньги в сберегательных кассах", - этот совет Жоржа Милославского по-прежнему актуален. По статистике МВД, каждое девятнадцатое зарегистрированное преступление - это квартирная кража.



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

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

Вот десять самых популярных "тайников":

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

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

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

4. Под матрасом. Мало кто в этом сознается, но люди по старинке предпочитают хранить деньги именно там.

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

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

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

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

9. В бытовой технике. Скорее всего, если вор не найдет тайник, то просто унесет его вместе с аппаратурой.

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

Попробуйте хранить свои ценности в аквариумах, горшках с кактусами, банках с вареньем и стоптанных кроссовках. Есть вероятность, что вор просто не обратит внимания на эти вещи.

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


добавить отзыв




дата:   24-10-2009 01:14:37



Итак, наиболее важным событием ГП Германии-2004 стало нетривиальное поведение Батона, который долго и сосредоточенно щупал себя за шлем. Если кто мне не верит – что это наиболее важное событие – посчитайте суммарный хронометраж выделенного под это событие телеэфира. Идя навстречу многочисленным пожеланиям верных почитателей Королевы автоспорта, открываю обсуждение этого ключевого момента ГП Германии.

Итак, что же там происходило? Байки, что не по возрасту рачительный Батон пытался не дать отвалиться столь ценной защитной пленочке – безусловно не заслуживают никакого доверия. Точно так же я не хочу обсуждать ужасное предположение, что это у карабас-барабаса Берни где-то там зацепилась ниточка от дженсоновой правой руки. Думаю, стоит сосредоточится на обсуждении причинах вполне реальных, легко объяснимых с научной точки зрения.

Почему же трогал себя Баттон? Мои версии:

1. У него чесалось в ухе. Лично мне эта версия кажется самой понятной и убедительной.

2. Мучился похмельем. Тоже вполне понятно и логично.

3. Размышлял. Близко к предыдущей версии, но согласитесь – определенная разница есть.

4. Заметил, что его показывают по телевизору – и пытался поправить прическу.

5. В его радиоканал вклинился Попов. (Это не я придумал - то ли Шумофил, то ли КАА).

6. Хотел показать, как он клево водит одной рукой.

7. Переживал, из-за потерянных 10 позиций.

8. Переживал, что забыл купить хлеб

9. Проверял, на месте ли голова.

10. Стеснялся

PS Может быть Вы спросите меня: "А где же вариант Другое? Или Своя версия?" "А вот куй!" - отвечу я Вам - "очень мало вариантов предлагают нам для размещения в голосовалке!" И вообще - я вон в теме про дождь сколько замечательных вариантов предложил. И чем все кончилось? А? Большинство забило на мои замечательные варианты. Короче - пора кончать эти игры в демократию и политкорректность. "Надо отмывать тем мылом, которое есть!" (громила Джо громиле Винсенту, "Криминальное чтиво" MIRAMAX, 1994 год, в переводе неизвестно кого с черти-какой пиратской кассеты)


добавить отзыв


Hits: 59     Host: 19
Human: 42
Robot: 17
    Human: 11
Robot: 8


Hits: 1     Host: 1
Human: 1
Robot: 0
    Human: 1
Robot: 0


0.021376848220825