Здравствуйте, GlebZ, Вы писали:
VD>>Уже. Борланд, например, поддерживает паттерны в своих средствах проектрования. GZ>Вообще-то не только Борланд. XDE, DSL Tools, и наверняка список можно продолжить(R# в конце концов ).
R#, как я понимаю, остановился в своём развитии на пол пути. А что умеют XDE и DSL Tools?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Nickolay Ch, Вы писали:
NC>Вы опять учите студентов абсолютным истинам и идеалам... В общем то, это характерно для всего нашего ит образования, как уже писалось...
И слава богу, что хоть в образовании еще истина есть...
Здравствуйте, IT, Вы писали:
IT>R#, как я понимаю, остановился в своём развитии на пол пути. А что умеют XDE и DSL Tools?
Не знаю, точно. Только по картинкам смотрел. Все времени не хватает.
Здравствуйте, AndrewVK, Вы писали:
AVK>Когда я учился ничего (т.е. абсолютно ничего) не говорилось о проектировании приложений, за исключением навязшего на зубах восходящего/нисходящего подхода.
Не так уж мало. Т.е. преподавалась методология, стадии, этапы, артефакты, процедуры завершения/приемки стадий и т.д. Взять, на пример, процесс нисходящего специфирования входных и выходных данных подсистем (программных или аппаратных). Ничего не напоминает?
Достаточно общий термин "входные/выходные данные" подменить на частные "сигналы и протоколы взаимодействия" и получим ОО-анализ в действии
Да и бог с ним ОО-анализом, это тоже частный случай частных подсистем. Если я видел ошибки проектирования, то обычно причина их была в элементарной невнимательности или небрежности. Казалось бы — так все просто. Бери сценарии использования как ТЗ и уточняй постепенно требования на каждом уровне проектирования. Как говорится — не промахнешься, если внимателен. (да, кстати, еще же учат проектированию БД, нормализации и пр., тоже мозги на место неплохо вправляет и не только в плане структуры БД)
Единственно, где требуется "эквилибристика ума" в чистом виде, или даже состязание в хорошем вкусе, так это в ситуации, когда сценарии использования не даны и их надо проектировать самому. Однако, все набирающий по численности класс аналитиков считает, что проектировщики систем к этой процедуре не должны лежать никаким боком. Это только их хлеб и они, типа, умеют это лучше всего, учитывая их времяпрепровождение в общении с заказчиком в качестве доктора-психолога. Вероятно, они правы.
AVK>Сейчас ситуация еще хуже — в качестве архитектора современный студент величина отрицательная. Отрицательная, потому что перво-наперво приходится тратить массу усилий на избавление от дурацкий навыков, которым его научили в ВУЗе.
Если кто-то величина отрицательная в этом деле после 5-ти лет учебы, так может не стоит и время тратить на "выбивание"?
Да, мало выходит толковых ребят, менее 10% (по личному наблюдению около 10 толковых было из 100 человек потока, а девушки вообще непонятно зачем на IT учатся). Я же говорил уже многократно, что корень большинства проблем молодого поколения в том, что в IT идут люди, которым не стоит туда идти. Пруться как танки в IT из-за высоких ЗП все подряд, портят общую статистику. Переиначивают понятия, путают ср-ва с целями (как во всей этой ветке про паттерны).
Здравствуйте, vdimas, Вы писали:
V>Единственно, где требуется "эквилибристика ума" в чистом виде, или даже состязание в хорошем вкусе, так это в ситуации, когда сценарии использования не даны и их надо проектировать самому. Однако, все набирающий по численности класс аналитиков считает, что проектировщики систем к этой процедуре не должны лежать никаким боком. Это только их хлеб и они, типа, умеют это лучше всего, учитывая их времяпрепровождение в общении с заказчиком в качестве доктора-психолога. Вероятно, они правы.
Команда должна оставаться всегда командой. Консультации архитектора, или лица который выполняет его обязанности должны вестись еще на стадии определения границ проекта. Вот тут действительно важен опыт и эквилибристика ума. Оценить то, чего еще нет. При написании требований — показ каждого требования архитектору до того, как оно ушло к пользователю уже обязательно. Это понимает каждый адекватный PM.
AVK>>Сейчас ситуация еще хуже — в качестве архитектора современный студент величина отрицательная. Отрицательная, потому что перво-наперво приходится тратить массу усилий на избавление от дурацкий навыков, которым его научили в ВУЗе. V>Если кто-то величина отрицательная в этом деле после 5-ти лет учебы, так может не стоит и время тратить на "выбивание"?
Почему так ценятся у нас выпукники ВМК МГУ. Да потому что они думать умеют. А остальному таких людей легко научить.
V>Да, мало выходит толковых ребят, менее 10% (по личному наблюдению около 10 толковых было из 100 человек потока, а девушки вообще непонятно зачем на IT учатся). Я же говорил уже многократно, что корень большинства проблем молодого поколения в том, что в IT идут люди, которым не стоит туда идти. Пруться как танки в IT из-за высоких ЗП все подряд, портят общую статистику. Переиначивают понятия, путают ср-ва с целями (как во всей этой ветке про паттерны).
А лишние люди быстро сами вымываются из IT. Легко учиться и зубрить, а работать, если у тебя голова не настроена в нужном диапазоне, невозможно. Таких людей видел достаточно, работают обычно не дольше двух недель. Сами уходят.
2 Moderators: Приношу извинения за оффтоп, форс-мажор небольшой, завтра днём проголосую сей оффтоп грохнуть.
2 All: Просьба на это сообщение не отвечать.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
IT>>R#, как я понимаю, остановился в своём развитии на пол пути. А что умеют XDE и DSL Tools?
VD>Что значит остановился? Просто времени не хватает. Вот добъем все дела и доведем R# до совершенства.
Ok, заменим остановился на приостановился
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, vdimas, Вы писали:
V>Не так уж мало.
По современным меркам катастрофически мало.
V>Достаточно общий термин "входные/выходные данные" подменить на частные "сигналы и протоколы взаимодействия" и получим ОО-анализ в действии
Не получим. Либо это какой то странный своей убогостью анализ.
V>Да и бог с ним ОО-анализом, это тоже частный случай частных подсистем. Если я видел ошибки проектирования, то обычно причина их была в элементарной невнимательности или небрежности.
Значит тебе повезло. Все таки, если человек серьезно относится к своей работе, то ошибки там совсем другие. По большей частью вызванные непониманием того, что он делает. Тут не зря народ в один голос твердит — архитектор должен писать код.
V>Единственно, где требуется "эквилибристика ума" в чистом виде, или даже состязание в хорошем вкусе, так это в ситуации, когда сценарии использования не даны и их надо проектировать самому. Однако, все набирающий по численности класс аналитиков считает, что проектировщики систем к этой процедуре не должны лежать никаким боком. Это только их хлеб и они, типа, умеют это лучше всего, учитывая их времяпрепровождение в общении с заказчиком в качестве доктора-психолога. Вероятно, они правы.
Мне кажется ты о другом говоришь. Классический software architect озабочен не сценариями импользования. Задача обычно ставится совсем иначе — есть требуемый и желаемый функционал, есть определенное количество разработчиков, есть уже написанные куски, есть планы по развитию, есть еще куча мелких факторов. Задача — реализовать максимально качественно максимальный функционал за минимальное время.
А уточнение сценариев это уже совсем другой специалист.
AVK>>Сейчас ситуация еще хуже — в качестве архитектора современный студент величина отрицательная. Отрицательная, потому что перво-наперво приходится тратить массу усилий на избавление от дурацкий навыков, которым его научили в ВУЗе.
V>Если кто-то величина отрицательная в этом деле после 5-ти лет учебы, так может не стоит и время тратить на "выбивание"?
Стоит. Иначе у нас бы вобще таких специалистов не было.
V>Да, мало выходит толковых ребят, менее 10% (по личному наблюдению около 10 толковых было из 100 человек потока, а девушки вообще непонятно зачем на IT учатся). Я же говорил уже многократно, что корень большинства проблем молодого поколения в том, что в IT идут люди, которым не стоит туда идти. Пруться как танки в IT из-за высоких ЗП все подряд, портят общую статистику. Переиначивают понятия, путают ср-ва с целями (как во всей этой ветке про паттерны).
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Ох, боюсь, что именно они профессионалы, а не все мы здесь, грешные. Ну разве профессионалы будут обсуждать нелепые конструкции и доказывать , что они нелепые ?
AVK>Думаю будут. Архитектор, который, вместо того чтобы обсудить какие то свои мысли в комьюнити (весьма профессиональном, хочу заметить) продолжает варится в собственном котле и убежден что здесь народ занимается ерундой, не профессионал вовсе, а надутый индюк.
Да не, бывают просто другие, чуть более "направленые" форумы в и-нете по этому направлению. Хотя относительно философии программирования — против истины не попрешь, именно тут беседы самые увлекательные, спасибо VladD2 и Co
Здравствуйте, AndrewVK, Вы писали:
V>>Достаточно общий термин "входные/выходные данные" подменить на частные "сигналы и протоколы взаимодействия" и получим ОО-анализ в действии
AVK>Не получим. Либо это какой то странный своей убогостью анализ.
В любом случае, в основе ОО-проектирования лежит декомпозиция, я намекал на нее.
AVK>Значит тебе повезло. Все таки, если человек серьезно относится к своей работе, то ошибки там совсем другие. По большей частью вызванные непониманием того, что он делает. Тут не зря народ в один голос твердит — архитектор должен писать код.
Выходит, повезло. Мне даже трудно представить на месте архитектора человека, который не понимает, что он делает (!!!). Даже в том пресловутом недавнем случае коллег про "промах" в дизайне было очевидно, что имело место небрежность, она же — шапкозакидательство, ввиду веры в "магическую силу" паттернов. Т.е. элементарно не потрудились провести еще пару итераций и уточнений.
V>>Единственно, где требуется "эквилибристика ума" в чистом виде, или даже состязание в хорошем вкусе, так это в ситуации, когда сценарии использования не даны и их надо проектировать самому. Однако, все набирающий по численности класс аналитиков считает, что проектировщики систем к этой процедуре не должны лежать никаким боком. Это только их хлеб и они, типа, умеют это лучше всего, учитывая их времяпрепровождение в общении с заказчиком в качестве доктора-психолога. Вероятно, они правы.
AVK>Мне кажется ты о другом говоришь. Классический software architect озабочен не сценариями импользования.
По-моему, я именно эту мысль и высказал. Однако — это классический software architect (скорее — идеальный). На практике, отдельную роль аналитика могут себе позволить не все конторы, и эти роли совмещают.
AVK>Задача обычно ставится совсем иначе — есть требуемый и желаемый функционал, есть определенное количество разработчиков, есть уже написанные куски, есть планы по развитию, есть еще куча мелких факторов. Задача — реализовать максимально качественно максимальный функционал за минимальное время.
Тут ты уже примешал роль PM, извини. Правда их тоже часто смешивают. В идеале все упомянутые роли должны работать в связке и как результатом своей деятельности выходить на конкретные ТЗ разработчикам с одной стороны (как следствие разработанной архитектуры/функционала), так и на Project Plan с другой стороны (как результат экономического планирования: ресурсы, время и т.д.).
AVK>А уточнение сценариев это уже совсем другой специалист.
Опять же, в идеале. Да, собственно, и я так же считаю.
AVK>Стоит. Иначе у нас бы вобще таких специалистов не было.
Наверно, у тебя есть конкретные примеры, раз ты так настаиваешь. Можно пару слов о конкретных ошибках? Мне уже интересно, возможно это будет поучительно и мне.
V>>Да, мало выходит толковых ребят, менее 10% (по личному наблюдению около 10 толковых было из 100 человек потока, а девушки вообще непонятно зачем на IT учатся). Я же говорил уже многократно, что корень большинства проблем молодого поколения в том, что в IT идут люди, которым не стоит туда идти. Пруться как танки в IT из-за высоких ЗП все подряд, портят общую статистику. Переиначивают понятия, путают ср-ва с целями (как во всей этой ветке про паттерны).
AVK>Вывод из этого какой?
Кесарю — кесарево. Нам, например, сейчас требуется довольно много людей в команду. И есть уже приличная база резюме, однако... По-любому нужен сильный костяк. Я не рискну доверить опытному разработчику большее количество малоопытных, чем он сможет адекватно "переварить". На мой взгляд, это соотношение должно быть не хуже 1:1. Если в других конторах наблюдается перекос — то это их личное право так рисковать.
Здравствуйте, VladD2, Вы писали:
AVK>>>Не знаю. Я не представляю как нужно извратить логику, чтобы трактовать его собственные фразы так как предлагается. Имхо это просто нежелание признаться в неправоте даже в мелочах.
V>>Я уже давно признал, что выразился более сжато, чем стоило. И потратил время на несколько постов потом, чтобы лично тебе и Владу развернуть свою мысль. Вот тут последние ответы по этой теме: V>>http://www.rsdn.ru/Forum/Message.aspx?mid=1482077&only=1
VD>Возможно ты в очередной раз выразился очень сжато. Но вот что я вижу в твоем "рзборе полетов": VD>Своя цитата: VD>
Именно про этих уродцев я и говорил. И подмечал, что знание паттернов ничуть не помогает в разработке архитектуры.
VD>И следом фраза: VD>
И я не НЕ СОБИРАЮСЬ отказываться от своих слов, т.к. действитльно уже дважды подмечал эту ситуацию.
VD>Собственно с этим я и похоже АВК и не согласны. Обоснований этому мнению ты не привел.
Че-то я окончательно запутался. Ты не согласен с тем, что я это подмечал? По приведенным ссылкам я раскрыл ситуацию более подробно. Дальнейшая подробность — это выкладывать сюда куски проекта с пояснениями.
Или ты не согласен с тем выводом, который я сделал на основе своих наблюдений. Если последнее, так это твое демократическое право, однако сути происходящего оно не меняет и тенденция имеет место быть. А именно — слепая вера в заведомую грамотность дизайна, если в нем использовались паттерны. Нет этой зависимости.
Действительно смешно было пытаться приписать мне мысль о том, что "паттерны вредны". Смешно именно потому, как следующий очевидный логический вывод: "учиться вообще вредно".
Вредным является восприятие чего-либо на веру. И пусть себе народ ползает на животе в выбранном направлении. У меня фраза "ползать на животе" ассоциируется с "пробовать, ошибаться, думать, сравнивать, подглядывать в ответ, снова решать" и т.д. ИМХО, полезное времяпрепровождение...
А насчет того твоего высказывания, что наука потому и движется вперед, что мы пользуемся знаниями предков как трамплином... Я не думаю, что люди стали умнее физиологически. Наука двигается вперед в основном благодаря всю более глубокой и необратимой специализации. Ты еще должен был застать времена, когда слово "программист" обозначало сразу всё. А теперь оно не обозначает НИЧЕГО, без указания специализации.
VD>На мой взгяд это суждение крайне алогично и как верно заметил АВК является призывом к забивинию на паттерны начинающими. По карйней мере ее легко понять так. Все же остальные твои слова — это увретки и ужимки чтобы просто не сказать "да я так думаю" или "извините я не верно выразился".
Здравствуйте, vdimas, Вы писали:
AVK>>Не получим. Либо это какой то странный своей убогостью анализ.
V>В любом случае, в основе ОО-проектирования лежит декомпозиция, я намекал на нее.
Да пофигну что там лежит в основе. Главное — то что рассказывают ныне в вузах имеет к реальной практике проектирования очень отдаленное отношение.
V>Выходит, повезло. Мне даже трудно представить на месте архитектора человека, который не понимает, что он делает (!!!).
Тем не менее 100% даже талантливых выпускников этого не понимают.
V>По-моему, я именно эту мысль и высказал. Однако — это классический software architect (скорее — идеальный). На практике, отдельную роль аналитика могут себе позволить не все конторы, и эти роли совмещают.
Все мало мальски серьезные конторы, которые я видел, все таки старались эти моменты разделить. Уж слишком сильно разнятся требуемые навыки.
AVK>>Задача обычно ставится совсем иначе — есть требуемый и желаемый функционал, есть определенное количество разработчиков, есть уже написанные куски, есть планы по развитию, есть еще куча мелких факторов. Задача — реализовать максимально качественно максимальный функционал за минимальное время.
V>Тут ты уже примешал роль PM, извини.
Неа. PM в классическом понимании должен организовывать процесс. Технические моменты как правило вне его компетенции. PM это прежде всего менеджер, а уж потом программист.
AVK>>Стоит. Иначе у нас бы вобще таких специалистов не было.
V>Наверно, у тебя есть конкретные примеры, раз ты так настаиваешь.
Конечно.
V> Можно пару слов о конкретных ошибках? Мне уже интересно, возможно это будет поучительно и мне.
Ну так чтобы сразу не напишу. Скажем одна из самых неприятных — стремление съэкономить на архитектуре. Очень часто бывает, что есть решение, требующее большого объема проектирования, но сравнительно дешевого кодирования, и есть наоборот — легко проектировать и долго кодировать. Очевидно что первое предпочтительнее, потому что объем кодирования стукнет по башке многократно, но по неопытности народ очень часто это не понимает. Еще из этого же разряда — если система состоит из нескольких кусков, то часто стремятся упростить проектируемый кусок, не думая о том, какие последствия будут для других частей. Например при проектировании сильно упрощать клиента за счет усложнения сервера и увеличения нагрузки на коммуникации.
Еще очень мешает, когда начинают переносить решения из одной области в другую без оглядки на их применимость.
А вот с пиханием куда не попадя паттернов я еще ни разу на практике не сталкивался, зато с незнанием онных сталкиваюсь регулярно.
Здравствуйте, vdimas, Вы писали:
PD>>>Ох, боюсь, что именно они профессионалы, а не все мы здесь, грешные. Ну разве профессионалы будут обсуждать нелепые конструкции и доказывать , что они нелепые ?
AVK>>Думаю будут. Архитектор, который, вместо того чтобы обсудить какие то свои мысли в комьюнити (весьма профессиональном, хочу заметить) продолжает варится в собственном котле и убежден что здесь народ занимается ерундой, не профессионал вовсе, а надутый индюк.
V>Да не, бывают просто другие, чуть более "направленые" форумы в и-нете по этому направлению.
Речь шла не про конкретно данный форум, а про форумы вобще.
AVK>Ну так чтобы сразу не напишу. Скажем одна из самых неприятных — стремление съэкономить на архитектуре. Очень часто бывает, что есть решение, требующее большого объема проектирования, но сравнительно дешевого кодирования, и есть наоборот — легко проектировать и долго кодировать.
Ну да, когда-то я уже высказывался здесь, но применительно к библиотекам, что структура библиотеки должна подразумевать не столько легкое кодирование самой библиотеки, сколько легкость использования (собственно, для чего функционал в либы и выделяют). Однако, этот принцип применим даже к традиционному структурному подходу к проектированию ПО (не говоря уже об ОО) и этому все-таки учат.
AVK>Еще из этого же разряда — если система состоит из нескольких кусков, то часто стремятся упростить проектируемый кусок, не думая о том, какие последствия будут для других частей.
Да и этому тоже учат — сисемный подход. Анализ взаимодействия подсистем. Разбиение функционала по принципу минимизации связей м/у выделенными подсистемами. Эта минимизация обычно прямо или коссвено влияет на "последствия" и "сложность".
AVK>Например при проектировании сильно упрощать клиента за счет усложнения сервера и увеличения нагрузки на коммуникации.
Хм... вот спорно, без дополнительных вводных. Например у нас есть некий мета-енжин на клиенте и сервере. Не скажу, что простой, но реализованные на его основе клиенты действительно просты и буквально "накидываются мышкой". И, разумеется, наличие мета-информации — это лишний трафик. Другое дело, что с этим легко бороться, если предположить, что метаинформация для запущенного экземпляра сервера неизменна, то ее можно просто кешировать.
AVK>Еще очень мешает, когда начинают переносить решения из одной области в другую без оглядки на их применимость.
AVK>А вот с пиханием куда не попадя паттернов я еще ни разу на практике не сталкивался,
2 последних предложения подразумевают потенциальное противоречие
Т.е. если наблюдается первое, то ненулевая вероятность наблюдения второго. Просто ты не наблюдал.
AVK>зато с незнанием онных сталкиваюсь регулярно.
Ну... я тоже далеко не с пеленок с ними столкнулся... Однако, ведь не спроста подавляющую их часть воспринял за "старых знакомых". Т.е. подход не менее важен.
Здравствуйте, vdimas, Вы писали:
V>Ну да, когда-то я уже высказывался здесь, но применительно к библиотекам, что структура библиотеки должна подразумевать не столько легкое кодирование самой библиотеки, сколько легкость использования (собственно, для чего функционал в либы и выделяют). Однако, этот принцип применим даже к традиционному структурному подходу к проектированию ПО (не говоря уже об ОО)
Безусловно.
V> и этому все-таки учат.
Не замечал.
AVK>>Еще из этого же разряда — если система состоит из нескольких кусков, то часто стремятся упростить проектируемый кусок, не думая о том, какие последствия будут для других частей.
V>Да и этому тоже учат — сисемный подход.
Тоже не замечал. У всех молодых специалистов в этом плане полный ноль. Они поначалу просто непонимают о чем ты им говоришь и делают круглые глаза.
AVK>>Например при проектировании сильно упрощать клиента за счет усложнения сервера и увеличения нагрузки на коммуникации.
V>Хм... вот спорно, без дополнительных вводных.
Речь не о конкретике, а о принципе. Один и тот же человек проектируя клиента усложняет сервер, потом, проектируя сервер, усложняет клиента. Просто потому что у него мысль о том, что думать надо о системе в целов даже не возникает.
AVK>>зато с незнанием онных сталкиваюсь регулярно.
V>Ну... я тоже далеко не с пеленок с ними столкнулся... Однако, ведь не спроста подавляющую их часть воспринял за "старых знакомых". Т.е. подход не менее важен.
Здравствуйте, AndrewVK, Вы писали:
AVK>Речь не о конкретике, а о принципе. Один и тот же человек проектируя клиента усложняет сервер, потом, проектируя сервер, усложняет клиента. Просто потому что у него мысль о том, что думать надо о системе в целов даже не возникает.
В общем, пора rsdn-овцам прекращать тусоваться по разным конторам и бороться с, во многом, исскуственными проблемами. Собраться, блин, в один мощный кулак, и писать самый конкурентноспособный софт на свете
А иначе какой толк в обучении молодого поколения, которое, насколько я понял, не потрудилось вынести из 5-летнего протирания штанов даже азы. Где та увлеченность, и не побоюсь этого слова "преданность" своему делу? Подобный "молодой специалист" чуть понабравшись опыта будет ерзать на своем стуле и искать следующее место потеплее. Толку от вложений в него драгоценнейшего времени? У программистов в Питере/Москве в возрасте до 27 лет среднее время пребывания на одном месте 1 год. Смешно, не правда ли? Да — дефицит, да — head-hunting, но таким людям обсуждаемые здесь вопросы мягко говоря до одного места, и принцип "лишь бы работало" — рулит. Ведь за это платят и платят нехило...
Так что, я бы делил на "стремящихся" и всех остальных. Первые априори должны были вынести если не с лекций, то по крайней мере из собственного любопытства и изучения те самые азы. (благо интернет весьма доступен последние годы для всех).
Здравствуйте, AndrewVK, Вы писали:
V>>Ну... я тоже далеко не с пеленок с ними столкнулся... Однако, ведь не спроста подавляющую их часть воспринял за "старых знакомых". Т.е. подход не менее важен.
AVK>Подход штука абстрактная и ни о чем не говорящая.
Именно про этих уродцев я и говорил. И подмечал, что знание паттернов ничуть не помогает в разработке архитектуры.
...
И я не НЕ СОБИРАЮСЬ отказываться от своих слов, т.к. действитльно уже дважды подмечал эту ситуацию.
...
Действительно смешно было пытаться приписать мне мысль о том, что "паттерны вредны".
Вспоминается анекдот про Штирлица:
Идет сикретное заседание в бункере Гитлера...
Вдруг входит штирлиц с блюдом апельсинов. Необращая ни на кого внимания проходит к сейфу. Открывает его. Берет бумаги. Разворачивается и уходит.
Кто-то из новеньких спрашивает:
— Кто это? И почему мы его не остановили?
— А это Штирлиц — русский разведчик. А что до "почему не остановили", дык все равно ведь собака выкрутится. Скажет, что апельсины приносил.
V>извините я не верно выразился
Давно бы так. И не пришлось апельсины с собой всюду таскать.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
). 
Если нам не помогут, то мы тоже никого не пощадим.
