Моя книга "Реальность 2.0b" в свободном доступе

Собственно, и сказать-то больше нечего. Книга - здесь, коротенькое интервью со мной - здесь.

Буду благодарен за любые отзывы, предложения и критику.

Жизненный путь: Java и Java-script

Смысл последующего изложения легче понять, если прочитать преамбулу здесь.

Что касается языка программирования Java и его производных, то тут, надо признать мне похвастаться особо нечем. Я начал изучать его из соображений чистого энтузиазма где-то в 1996 году по книге одного из его создателей Патрика Нотона (эту книгу потом "заныкала" моя сокурсница, утверждая, что не отдаст, пока я не выдам ей подарок на день рождения, на который меня, кстати, не пригласили; подарок так и не получила, так что книжку так и не отдала). В то время Java не была таким монстром, как сегодня - воспринималась как средство для анимации картинок на веб-страницах, создания часиков и прочей мишуры. Этой мишурой был набит до отказа каждый второй сайт (с появлением Dynamic HTML от Microsoft ситуация еще более усугубилась). Только спустя несколько лет стало понятно, насколько мощным может быть этот язык в умелых руках - мне доводилось видеть и работать над огромнейшими и полезнейшими приложениями целиком или большей частью реализованными на Java.

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

• наличие автоматической сборки мусора;
  
• неотделимость объявления класса от его реализации;
  
• строгая типизация;
  
• отсутствие непосредственной работы с указателями;
  
• интерпретация и переносимость;
  
• безопасность ПО для клиентского компьютера благодаря "sandbox" или, согласно Нотону, "железному занавесу" (это к вопросу о несостоятельности - первый вирус на Java появился еще в августе 1998);
  
• отсутствие goto и так далее.

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

В Java нет оператора goto... Оператор break в Java работает с метками.

Да, у оператора break с метками в Java имеются определенные особенности, ограничивающие его бесконтрольное применение, и все же у меня тогда прочтение приведенного текста вызвало отчетливое: "Хех! Ну вы, блин, даете"! В итоге, отчасти благодаря скептицизму, я не ушел на Java дальше пробы пера, так что наколдовал за всю свою программистскую жизнь лишь 2 791 строку кода на этом языке в трех десятках аплетов, среди которых были:

• мини-программы для рисования;
  
• динамические фильтры для изображений;
  
• простейшие прыгающие надписи (с музычкой в формате AU!);
  
• те самые электронные часики;
  
• примитивная по интеллекту противника и графическому исполнению игра с компьютером в крестики-нолики (истинное мастерство игрока в нее проявляется не в выигрыше, а в способности проиграть или хотя бы свести к ничьей) и т.д.

Что касается пользы Java в ИТ-производстве, то тут вопросов уже нет - время уже все решило. Относительно этого языка в обучении, я думаю, что он вполне может выступать даже первым и основным - на его базе можно научить практически всем аспектам разработки приложений каких угодно типов (привет переносимости и универсальности), только нужно понимать, что программист, который получится в итоге, будет не тем же самым, который был обучен на базе "Паскаль + Ассемблер + Си + C++". Почему? Потому что примеры, на которых будет обучаться Java-программист, за пределами круга базовых, будут и должны быть, наверное, иными, концепции и парадигмы опять-таки за пределами базовых и их реализация однозначно будут иными (ну, самый простой пример - в Java отсутствует множественное наследование реализаций), книги и их авторы будут иными (со своим видением, так сказать). Java, вообще, стала одним из первых и первым мега-популярным языком, который ставил своей целью не только и не столько эффективность исполнения кода, но и удобство, простоту и заботу о программисте при одновременном наличии широчайших возможностей, а это - совершенно иной мир и иная доктрина.

Спору нет - хороший программист может изучить и второй, и пятый, и десятый язык, но программисты на всех языках, изученных ими после первого, пишут также как на этом первом, но в другом синтаксисе. Страуструп высказал это очень четко (правда, по поводу C++):

C++ поддерживает множество стилей программирования. Все они основаны на строгой проверке типов, и целью большей их части является достижение высокого уровня абстракции данных и непосредственного отображения идей программиста. Каждый стиль может эффективно достичь этих целей, в то же время обеспечивая эффективность выполнения и использования ресурсов. Программисты, приходящие из различных языковых сред (например, C, Fortran, Lisp, ML, Ada, Eiffel, Pascal или Modula-2), должны понять: для того чтобы воспользоваться преимуществами C++, необходимо потратить время на изучение и применение стилей программирования, приемлемых для C++. Тоже самое касается программистов, пользовавшихся более ранней и менее выразительной версией C++.

Бездумное применение в новом языке методов, эффективных в другом языке, обычно ведет к неуклюжему, медленному и сложному в сопровождении коду. Такой код к тому же еще и неприятно писать, потому что каждая строка кода и каждое сообщение компилятора об ошибке напоминает программисту, что используемый язык отличается от "старого языка". Вы можете писать в стиле Fortran, C, Smalltalk и т.п. на любом языке, но это и неприятно и неэкономично в языке с другой философией. Любой язык может послужить щедрым источником идей о том, как писать программы на C++. Однако для того, чтобы быть эффективным в новом контексте, эти идеи нужно трансформировать в нечто другое, более соответствующее общей структуре и системе типов C++. Над базовой системой типов возможны только пирровы победы. (Б.Страуструп "Язык программирования C++", 3-е изд. - СПб.: М.: "Невский диалект" - "Издательство БИНОМ"), 1999 г.)

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

Жизненный путь: Паскаль

С написанием программ я завязал в 2004 году. Последней программой стала разработанная в качестве расчетной для кандидатской диссертации. На время завязал или навсегда - не знаю, но, учитывая, что первую программу на Sinclair ZX Spectrum я написал в 7 лет в 1985 году (я знаю, что много раз об этом говорил, но еще неоднократно, наверное, об этом вспомню - горжусь), можно сказать, что у меня к 2004 году было 19 лет практики - не стыдно уже и переключиться на что-нибудь другое.

Давно хотел подвести некую черту, посчитать/вспомнить сколько и чего я создал за все эти годы. Начать решил с Паскаля. С этим языком я познакомился в 1995 году на первом курсе института, в который пришел с отличным знанием 8-ми диалектов Бейсика (gw, Q, Spectrum, Yamaha, БК - не помню, правда, какой именно диалект и т.д.), подозревая, что существуют и другие языки, но не имея опыта работы с ними.

Собственно, все лабораторные работы на первом курсе писались именно на Паскале (Borland Turbo Pascal 7.0). Объектно-ориентированным программированием на нем в моем исполнении разве что только "пахло" - было несколько небольших программ-примеров. Беготни и восторгов по поводу Delphi я не разделял. В свободное время тоже кое-что писалось (я разрывался между тягой к программированию и фанатизмом по установке и сносу Windows 95). По инерции на втором курсе было написано еще несколько программ на Паскале, после чего произошла смена курса - в жизнь пришли C/C++ (к сожалению, сразу вместе) и не желали покидать ее вплоть до 2004 года, смеясь в мозгу над всеми новомодными время от времени появлявшимися новыми языками.

Поскольку в общей сумме на Паскале было написано не так уж много, я взял за труд пересчитать все свои LOC (англ. Lines Of Code - строки кода) во всех файлах, которые смог найти. С ужасом предвижу, что будет, когда я дойду до C++ - там тысячи файлов, разбросанных по сотням каталогов за период в 10 лет. С Паскалем все было проще: программы в основном по одному файлу, под DOS, без излишеств в интерфейсах (зачастую интерфейсом служит командная строка), минимум адресной арифметики, чистые реализации придуманных или позаимствованных алгоритмов в разных комбинациях плюс обработка данных. Жизнь была куда проще, как мне кажется.

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

При подсчете строк я, естественно, выкидывал пустые, а вот комментарии учитывал - не зря же я их писал в назидание себе и потомкам! Еще, думаю, стоит упомянуть, что в качестве стиля расстановки скобок и отступов я всегда использовал так называемый "расширенный стиль" или "стиль Олмана" (конечно, только с тех пор, как узнал, что такое отступы, что такое стиль в кодировании, выработал хоть какой-то свой и решил его придерживаться). Это важно, потому что стиль Олмана предполагает, например, размещение каждого оператора (begin/end) или операторной скобки в отдельной строке, что, естественно, увеличивает общее число строк.

Итак, в общей сложности я насчитал 21 366 строк кода на Паскале. Из них:

• 11 778 строк - это, собственно, лабораторные работы по программированию (I курс, осень 1995 - июнь 1996 гг.);
  
• 5 709 строк - это лабораторные работы по другим дисциплинам (периодически на протяжении обучения с 1995 по 2000 я решал, что все-таки стоит использовать Паскаль для программ, где не требуется интерфейс, которые по характеру являются чисто расчетными) например по таким, как:
  • "Физика" - работа по визуализации действия законов Брюстера и Маллюса;
    
  • "Формальные языки и формальные грамматики" - вычисление лишних правил в контекстно-чувствительных грамматиках;
    
  • "Анализ алгоритмов" - задача о восьми ферзях;
    
  • "Технология разработки ПО" - сейчас уже не могу ни вспомнить, ни понять, что именно это было, так странно оно выглядит;
    
  • "Оптимальное управление" - программа численного решения однопродуктовой задачи и т.д.;
• оставшиеся 3 879 строк - это то что писалось для души, например:
  • шифровка и архивация файлов с применением бинарного дерева по методу Хаффмана;
    
  • всякая мелочь с применением Turbo Vision (хотя любая "мелочь" с применением Turbo Vision превращается в большую программу) - кто не знает, есть такая библиотека оконных классов для DOS (и в консольных окнах отлично работает), собственно, на ее основе реализованы пользовательские интерфейсы самого Turbo Pascal 7.0, других продуктов Borland и не только Borland той эпохи;
    
  • фракталы (посмотрел сейчас на них - ну и жуть);
    
  • модули общего назначения для отображения меню;
    
  • несколько программ для Windows на чистом Паскале и т.д.

Интересно копаться в старых программах - рекомендую. Иногда находятся весьма любопытные творения. Я, например, уже который год восхищаюсь своим опусом под названием chtoto.pas. Году так в 2001, если не изменяет память, я уже пытался вспомнить/понять, что же эта программа рисует. Основных версий было 2: то ли она визуализирует какие-то данные, то ли пытается вращать куб в странной проекции. Нужно сказать, что я писал ее на раннем жизненном этапе и, видимо, в расширенном сознании, потому что ни одного отступа в коде нет, ни одного комментария нет плюс программа объектно-ориентированная (по-моему, на Паскале она таковая чуть ли не единственная более-менее крупная, остальные так - "Hello world!"). Так вот тогда в 2001 я отчаялся, переименовал ее в chtoto.pas и забросил. C той поры я раз в год повторяю эту процедуру: открываю, смотрю, забрасываю. Традиция...

Голубой экран впереди, и зеленый - сзади...

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

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

20 лет назад все было намного сложнее, тогда не было таких вычислительных мощностей, как сейчас, и многие идеи, хоть и витали в воздухе, но еще не были воплощены в чем-то, что можно использовать. В частности поэтому "Terminator 2" получил в 1992 году 4 "Оскара" (в том числе за спецэффекты). Если разобраться, то значительный объем эффектов там был использован для создания персонажа Роберта Патрика - T1000, и эти эффекты в основном включали различные вариации morphing (постепенного "превращения" одного объекта или изображения в другое) и bump-mapping (наложение на объект в качестве текстуры отражений окружающих предметов), то есть такие техники, которые сегодня мы видим чуть ли не в каждом фильме или компьютерной игре. Тогда мы, конечно, об этом не задумывались, а просто восхищались: виртуальный персонаж проник в живой фильм, а Шварценеггера расплавили - вау! Тут, однако, важно сделать небольшое отступление и вспомнить, что лучшим фильмом по мнению киноакадемиков в 1992 стал не "Terminator 2", а "Молчание ягнят", где компьютерных спецэффектов было поменьше (по крайней мере, они не были так очевидно заметны).

Шли годы. В 1995 году Pixar и The Walt Disney Company выпустили "Историю игрушек" - первый полнометражный фильм, целиком сделанный на компьютере. Публика неистовствовала. Постепенно компьютерные эффекты, все более изощрявшиеся с появлением новых технологий и ростом вычислительных мощностей, стали неотъемлемой частью создания практически всех фильмов: где-то их было побольше, где-то поменьше. В скольких бы фильмах впоследствии ни применялись morphing+bump-mapping, сколько бы "Шреков" ни было сделано, ни один из этих фильмов не "Terminator 2" и не "История игрушек". С компьютерной графикой как технологией произошло то, что и должно было произойти - она взлетела как знамя, как нечто, что может перевернуть кинематограф, а потом органично вписалась в процесс как одна из составляющих. И все бы ничего, если б не такое явление, как кинематограф российский...

Мне все равно, сколько автомобилей и денег было уничтожено при съемках "Антикиллера" - фильм отвратительно смонтирован (второй значительно лучше, третий еще не видел). "Ночной дозор" - это извращение книги, несмотря на переворачивающиеся автобусы и вампира Лагутенко, а в каждом кадре "Дневного дозора" (который неясно почему называется именно так) сквозит желание киношников по-быстрому снять что-нибудь, отвязаться и уехать на "Фабрику грез". "Параграф 78" (оба) - это жалкое подобие "Resident Evil"; это не блокбастер, поскольку слишком много разговоров, и не глубокий философский фильм, поскольку разговоры эти довольно банальные и полные клише. "Запрещенная реальность" - это вообще феерия: если бы меня попросили кратко охарактеризовать сюжет фильма, мне осталось бы только сказать, что "есть типа добро, типа зло... и типа все", или, выражаясь словами моего друга, выдаваемыми по каждому поводу: "Что происходит"? Страшно жить - уже боишься выходов российских дорогих фильмов, поскольку заранее готовишься разочароваться, и, что типично, подготовка оказывается не излишней. Что еще хуже, отличные актеры вляпываются в это (в случае "Запрещенной реальности" - это И.Петренко, А.Балуев, В.Вдовиченков, причем последний еще раньше "въехал" и в "Параграф").

Создается впечатление, что наши киноделы в какой-то момент говорят себе: "Ну все, хватит снимать - остальное будет графика"! Причем происходит это, судя по всему, не на съемках, а еще при написании сценария. Скажу банальность, но: люди, графика не является определяющей для качества фильма и уж точно не является определяющей для сценария! Вспомним про "Молчание ягнят", я же не зря его привел в пример. Если вы разрабатывали программы для ПК, то должны понимать, что есть некая задача, и выбор средств для ее решения вторичен (по крайней мере, должен быть таковым) по сравнению с получением этого решения. Сценарист не имеет права думать: "Вот здесь будет зеленый экран", он вообще не должен знать о нем - это не его дело, как будет снята сцена. Кстати, это ответ и тем, кто считает, что "Запрещенная реальность" страдает сценарными и монтажными промахами, но задает качество картинки для отечественного кинематографа". Ужас, что такие идеи приходят в головы - я хочу кино смотреть, а не формат оценивать и не стандарт на него читать. Как специалист в области программирования интерактивной графики (не "голливудского" уровня, конечно), я, кстати, еще могу защитить свою психику, откатившись на этот плацдарм оценки, а остальным людям как это вынести?

Я не говорю о том, что такие фильмы снимают только у нас, а также не утверждаю, что у нас все фильмы такие. Проблема не в том, что графика есть, а в том, что нет такого ее гармоничного вливания в процесс создания фильма, о котором я ранее говорил. Пользователями, клиентами, то есть теми людьми, жизнь которых графические технологии в кино должны делать лучше - это зрители, а не киношники. Здесь можно провести аналогию с программными продуктами: как бы вам понравилось, если бы вместо компьютерной игры, вам выдали бы описание того, что может делать оборудование и средства разработки, используемые для ее создания, а также набор картинок, не связанных между собой, не объяснили бы к чему это все и какая между всем этим связь, да вдобавок предварительно взяли с вас денег за все это? А как вам офисное приложение, которое ничего не делает, зато показывает вам кучу красивых "скриншотов" со своими формами? - Смотрится впечатляюще, но использовать нельзя ни с какой разумной целью! Оно вам надо? Но ведь в кино происходит именно это! Выражаясь словами А.Купера (Купер А. "Об Интерфейсе". - СПб.: Символ-Плюс, 2009. Он говорит это о файловых системах, преподносимых в качестве систем извлечения информации.):

С таким же успехом можно вручить ему пакет с продуктами и назвать его вкусным ужином.

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

Яблони в цвету (не ко времени, но хотелось банально сострить)

Apple разрабатывает технологии, которые в буквальном смысле позволят человеку слиться с компьютерным устройством. Об этом сообщает издание AppleInsider, ссылающееся на очередную заявку, поданную компанией в Бюро по регистрации патентов и торговых марок США.

В документе описываются способы, которые позволили бы сенсорному экрану устройства распознавать не только в отдельности каждый палец (указательный, средний, безымянный и так далее), но и определять, пальцем какой именно руки прикасается пользователь (левой или правой) и даже прикосновение ладоней. Все это Apple предлагает реализовать в «универсальном и эргономичном компьютерном устройстве».

Источник: CNews (который ссылки на свои источники почему-то не дает).

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

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

• неразбериху с лицензированием;
• изгнание и второе пришествие Джобса;
• упорную борьбу со всеми мыслимыми и немыслимыми трендами на рынке;
• бесконечную череду кадровых перемещений;
• подписание самоубийственных документов и последующие заранее обреченные на неудачу судебные иски против "сами-знаете-кого";
• многократные расширения номенклатуры продукции для обогащения с многократными же ее сокращениями ради спасения компании;
• объятья с теми, кого вчера называли врагами, и наоборот (впрочем, в бизнесе это не редкость);
• ошеломляющий интерес покупателей практически к каждому новому продукту со скоростным угасанием этого интереса в течение последующих нескольких месяцев;
• рост рыночной доли и продаж при одновременном росте убытков;
• снижение продаж и рыночной доли при росте прибылей;
• и так далее, и тому подобное...

Беспрецедентное образование.

Apple - это уникальная компания. Каждый человек, купивший iPhone или iPod готов гордиться этими устройствами, но мало кто из гордящихся может четко и весомо сформулировать преимущества этих устройств над аналогами, а иногда попытки перечислить эти преимущества больше смахивают на антирекламу. В поклонении этим произведениям искусства (выражаясь словами одного моего коллеги, употребленными, правда по совсем другому поводу) "больше специфики, чем смысла". Творения Apple - это какой-то "от-кутюр" (фр. haute couture - высокая мода) в мире IT (или "ИТ-кутюр").

Честно говоря, я даже не знаю, восхищаться или поражаться бессмысленности происходящего, но ближе к первому: не потому, что так и надо (а даже если бы и было надо, то неизвестно, получилось бы), а потому что так есть, есть такая компания и такая компания в мире ИТ - единственная.

Вдобавок, специфическая культура поведения Apple - это не случайность. Свою уникальность "Яблоко" обрело во многом с "тяжелой" руки одного человека - Стивена Джобса. Последний всегда был уверен, что

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

(сказано это было где-то рядом с тем временем, когда был представлен iMac, а это было 6 мая 1998 г.). Уникальность компании берет корни в уникальности одного человека, подобных которому, получается, в мире так и нет (хотя в свете всего того, что я о нем читал, как субъект общения и работодатель он бы мне вряд ли понравился - был у меня в недалеком прошлом один очень "ресурсоемкий", активный и, без сомнения, талантливый начальник, который похоже учится на примере Стивена, так вот работать "под ним" было большую часть времени "карой небесной", и мы выдержали друг-друга только полгода).

Ну и, конечно, вне зависимости от модных тенденций, Apple навсегда останется в истории ИТ. Браво!

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

Детская непосредственность

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

Конструктор на мой взгляд (и, к счастью, не только на мой) удался. На определенном этапе была выпущена рабочая версия, обладающая всем основным функционалом. Занимательно другое: архив с шаблоном (приложение было реализовано в виде шаблона MS Visio) включал файл под названием install.txt (даже не помню сейчас, как получилось, что он не назывался read_me.txt), в котором перечислялись все замечания к текущей на тот момент версии конструктора. Я много говорю об отношениях между разработчиками и пользователями, о преодолении непонимания, а потому решил честно поделиться содержимым этого файла, из которого ясно, что мои взгляды на данную проблему сформировались эволюционно, не сразу, и в 2000 они еще даже не начали формироваться. Тогда 9 лет назад я смотрел на происходящее с точки зрения молодого специалиста, живущего в несколько ином мире, чем мои пользователи. Сейчас Вы в этом убедитесь.

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

Итак, install.txt:

1. Всем заинтересованным лицам напоминаю, что эта версия конструктора Arcitect является даже не бетой, а прототипом, поэтому за глюки я не, что не отвечаю, а даже их и не замечаю :). Тем не менее, даже эта версия, благодаря моим трехмесячным невъе###ным программистским усилиям показала стабильную работу без сбоев на как минимум 7 моделях, часть из которых насчитывала до 40-50 узлов. Всем спасибо!

2. Для инсталляции необходимо папку Imitational Modeling целиком переписать в поддиректорию Program Files\Microsoft Office\Visio10\1033\Solutions (если, конечно, Visio 2002 устанавливался в папку по умолчанию), иначе ищите, куда вы его запихнули (Визио 2002) и переписывайте папку соответственно в [Путь до папки Visio 2002]\1033\Solutions. После этой бесхитростной мега-инсталляции, запускайте Визио 2002 и в галерее шаблонов выберите Imitational Modeling\Pilgrim5 Arcitect. При загрузке шаблона 2 раза выскочит табличка с вопросами: "Включать ли макрос?" (один раз для самого шаблона, другой для набора фигурок). Следует, естественно, ответить ДА (Включать, On, Enable, Yoohoo, OOOOYes и т. д.) Вот и весь процесс установки.

3. То что я постоянно употребляю не Visio, а Visio 2002 --это не потому что меня клинит, а потому что все версии до 2002 безбожно глючат при программировании (точнее версия 2000 глючит, а все до нее вообще его не поддерживают). Вследствие этого шаблон реализован и работает только под (угадайте что? ...правильно) Visio 2002. Она тоже безбожно глючит, как и все остальные, но ведь версии новее еще нет? Вот то-то и оно. Как минимум в версии 2002 глюки были значительно обновлены, улучшены и запрятаны так глубоко, что натыкаешься на них уже тогда, когда разойдешься (то есть бросить уже нельзя), зато ищешь потом несколько дней в чем же дело... Ладно скажу еще, что поскольку программа работает под (еще раз) Visio 2002, этот (и последний раз) Visio 2002 должен быть предварительно установлен и не на соседней машине, а на вашей собственной. ОК.

4. Как основные преимущества данного конструктора отмечу следующие недостатки:

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

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

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

4.4 В Create нельзя выставить параметр копирования свойств транзактов, поскольку я о нем слишком поздно узнал.

4.5 Узлом с переходом по умолчанию конечно можно выставлять какой-нибудь узел из середины списка, но в этом случае условия перехода для узлов находящихся под ним из-за последовательной однопроходной трансляции работать никогда не будут: конструкция в файле на Си будет иметь вид вроде

if (a>b)
{
   NextTop=1;
}
else
{
   if (1)
   {
      NextTop=2; //Узел по умолчанию
   }
   else
   {
      if (c<d)
      {
         NextTop=3;
      }
   }
}

Понятно, что в этом случае до строки if (c<d) программа никогда не дойдет, если только 1 не станет 0. Так что настоятельно рекомендую делать узлом по умолчанию--последний. Наслаждайтесь.

4.6 Не сообщается о присутствии выхода из Терминатора. Но это тоже только дурень может нарисовать.

4.7 Возможности узла Delet по отбору транзактов не реализованы. кстати на практике они вообще никогда еще не использовались, если я правильно помню.

4.8 Отсутствует возможность менять размеры узлов. Это меня самого бесит. Потерпим вместе.

4.9 Нельзя группировать элементы. Не делайте этого -- трансляция не состоится...

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

4.11 Еще хотелось сделать пакетное сохранение параметров всех узлов в отдельный файл и восстановление из него. Еще хотелось отчет о модели чтобы генерировался автоматически. Много чего хотелось... До сих пор хочется...

4.12 И ВООБЩЕ -- ЭТО ФРИВАРЕ. Не жалуйтесь!

5. Из фирменных глюков мною лично замечен следующий:

5.1 Неправильно транслируется значение true. На его место в файле на Си подставляется prty, отнако эти макросы в Simulate.h определены по-разному:

#define true 1
#define prty 3

Это создает проблемы, например, при проверке ключа на открытость генерируется строка:

if (addr[3]->op==prty)

Истинным выражение в скобках никогда не будет, как можно заметить, так как addr[3]->op может быть равно либо false (0), либо true (1), но уж точно не prty (3). Решение проблемы очевидно: проверяйте ключ не на открытость, а на закрытость или НЕзакрытость при этом будет сгенерировано что-нибудь типа:

if (addr[3]->op==none)
или
if (addr[3]->op!=none)

Как можно заметить, вместо false в этом случае генерируется none, но false и none определены в Simulate.h одинаково:

#define none 0
#define false 0

Вот так то.

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

В этом случае остается либо все переделать заново, либо вызвать процедуры инициализации всех модулей вручную и дописать исчезнувшее. Правда нумерацию это никак не восстановит -- придется вставлять фиктивные узлы до тех пор, пока не дойдете до следующего нужного вам номера. (Это нужно в том случае, если у вас нарисовано скажем 100 узлов и нужно вставить 101 и 102... А нумерация-то после сброса опять с 1 идет). В общем, если вы тки их как-нибудь вставите, обещаю, что
трансляция пройдет успешно. Кстати 102 узла на страницу все равно не влезут!!!

Ну вот и все... Желаю счастья!!! Ikshot AKA SoulHunter
"Улыбайтесь -- это всех раздражает", (С) Василий Стрельников

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

Небольшое ностальгическое отступление

В 90-е годы произошел скачек во всем, что касалось разработки ПО. Качественно изменялись инструменты, каждый программист хотел достать последние версии той или иной среды разработки. Мы передавали друг другу на дискетках Turbo Pascal, обрезанный в плане файлов настолько, чтобы помещаться на эту дискетку.
Мы соревновались, кто кому с помощью программы качественнее «поломает» компьютер, и как быстро сможет человек с поломанной машиной ее воскресить и понять, что сделала программа конкурента. У нас была Горбушка – совсем не та, что сейчас, а развал под открытым небом.

Нам было интересно, преподавателям было интересно. Наша специальность была самой крутой и самой программисткой, несмотря на то, что в дипломах у нас написано «математик». Builder-a не было, первые версии VB были настолько ужасны, что непонятно было что с ними делать. Первые версии Delphi были каким-то откровением. Люди которые начинали писать под Windows, а не под DOS вообще считались «ламерами» (тезис о том, что "настоящая программа должна работать с командной строки", сегодня не кажется таким уж мудрым, но тогда казался). Borland была могуча, она не была тем, что от нее сейчас осталось.

Была романтика, была целая культура избранности, если хотите. Но потом все это стало постепенно размываться, появились смешанные специальности – не поймешь ИТ или не ИТ. Больше вузов накинулось на ИТ-кусок в плане подготовки студентов, компьютеры распространились везде, и «каждый суслик стал считать себя агрономом». Компании стали дрессировать свободолюбивых программистов… и романтика исчезла. Сейчас ТА наша культура практически вымерла. А в вымирающей культуре редко появляются фанатики и вообще талантливые люди, иначе бы она не вымирала. Даже на факультете Вычислительной математики и кибернетики МГУ студенты не всегда могут правильно назвать свою специальность и больше озабочены тем, как открыть дело, а не тем, какой код они пишут.

А ведь на самом деле такая специальность как «Математическое обеспечение и администрирование информационных систем» (МОиАИС) восходит корнями к «Прикладной математике», которую я имел честь заканчивать (и мы свою специальность никогда не забывали – нам не давали, поскольку ласково называли «приматами»), а та к «Механизированной обработке информации», каковая существовала на заре развития ИТ в СССР. Эта специальность имеет свою историю и традиции. Так что если мы – это метафорически дети, тех кто строил ИТ в стране, то нынешние студенты специальности МОиАИС – это метафорические внуки этих людей. Очень бы хотелось, чтобы они это понимали. Чтобы понимали, что помимо эгоистичных желаний денег и всего остального, что конечно важно (программисты щедры в своем эгоизме и эгоистичны в своей щедрости), у них есть часть славы этих людей и часть унаследованной ответственности. Это важно помнить.