понедельник, 29 декабря 2008 г.

АОП и Delphi (Часть 1)

Давно хотел поговорить про аспектно-ориентированное программирование. В сети про это дело написано немало, я же хотел взглянуть на АОП применительно к Delphi. Но чтобы начать предметное обсуждение, необходимо вначале хотя бы упомянуть о сквозной функциональности, которая, по сути, и явилась катализатором появления АОП. Классическим примером сквозной функциональности является трассировка программы или логгирование действий. Чтобы было все предельно ясно, приведу пример.
Допустим, у вас есть программа, которая соединяется с некоторым сервером, передает ему данные и заканчивает сеанс связи. Протокол для связи вы написали сами и оформили в отдельный модуль или даже компонент. Он надежен, закончен и самодостаточен. И тут возникла необходимость залоггировать действия программы на этапе соединения. По сути дела, следует залезть в отлаженный и красивый код, напихать внутрь много разных странных строк, которые сделают его перегруженным и сложно читаемым, запутают основную логику модуля или, говоря другими словами, безнадежно его испортят. Так подумали и создатели системы тестирования компонентов Кактус, сели, задумались и родили аспектно-ориентированное программирование и его первую реализацию - AspectJ. Но пока мы до него не добрались, давайте посмотрим, что из того, что уже есть в Delphi, поможет нам хоть как-то исправить положение.
Частично решить проблему сквозной функциональности могут хорошо продуманные события компонента, предоставляемые разработчиком компонента пользователю. Конечно, идеальный вариант – это когда разработчик и пользователь – одно лицо, но и просто наличие исходников уже большой плюс. Но как я уже говорил, решение это - частичное. Во-первых, и глупо, и бессмысленно на каждый чих создавать события. Во-вторых, оригинальный код всё равно придется править, а значит вносить в него дополнительные ошибки и тратить время на отладку. В-третьих, проблема раздувания исходного кода компонента ненужной всякий раз логикой в полной мере не решается. Вывод: способ применим, местами удобен, местами нет, проблему полностью не снимает.
Вторым, более современным подходом является использование хелпера. Действительно, в этом случае возникает ситуация, обратная той, что рассматривалась в предыдущем примере – мы не правим исходный код, а лишь дорабатываем те места, где требуется вмешательство и изменение логики. Однако и тут полноценного решения проблемы нет, так как мы не избавлены от внесения сквозной функциональности в тела методов, хотя теперь вряд ли загубим работающий класс необдуманными действиями.
Еще одним интересным решением является использование RTTI информации для перехвата вызова того или иного метода класса. Об этом мы поговорим чуть позже, когда будем подробнее рассматривать одну из реализаций АОП на Delphi.
Можно, пожалуй, придумать ещё несколько способов, основанных, например, на использовании структурных паттернов, например Proxy или Adapter, но и сами паттерны – это зачастую пример жесточайшего кросскаттинга, так что всё это будет далеко от тех идей, которые несет АОП.
(продолжение следует)

пятница, 31 октября 2008 г.

Осеннее обострение

В плотном графике появилась минутка. Хочу поделится некоторыми наблюдениями об окружающем нас пространстве и времени:

  • Очень хорошо, что «Мировой Финансовый Кризис», как его помпезно называют по телеящику, обошел стороной нашу тихую гавань. Ведь только дурак не знает, что в это неспокойное время Россия – уголок стабильности и процветания! В подтверждение этого тезиса на днях мой коллега поделился информацией о том, что им, мягко выражаясь, задерживают существенную часть заработной платы. А это не какая-то там сфера услуг – самый что ни на есть реальный сектор – производство навигационного оборудования для кораблей и самолетов. На эту же тему спич в блоге у Алексея Ковязина.


  • Акции старины Борланда медленно, но верно подбираются к критической отметке в 1 доллар, после чего они не смогут торговаться на бирже Nasdaq.


  • Больше месяца назад на DN появились статьи Ника Ходжеса «Delphi in a Unicode World». Позже был выложен перевод этих статей на русский язык. Статьи понятные и исчерпывающие. Жалко только, что комментарии к ним грешат известной проблемой:
    Опять арабский ереват. Что-то есть в этом символичное…

  • Триадная разработка Windows 7. Не сказать, что свежие идеи – многие IT менеджеры давно отмечают необходимость организации команды по таким принципам. Тот же Йордон в своем Пути Камикадзе.

среда, 17 сентября 2008 г.

Попытка номер шесть

Секретно. Срочно. В центр. По вашему запросу были проведены испытания релиза D2009 на предмет устройства новой версии секретной разработки под кодовым названием «Together». Предыдущее испытание прошло неудачно. По результатам нынешних тестов могу сообщить следующее: вечером, 12-ого сентября 2008 года находился на боевом дежурстве в офисе. Именно в этот вечер были прекращены безуспешные попытки поставить «невесть откуда взявшуюся копию» D2009 и получена пробная четырнадцатидневная версия в виде образа диска, именуемая в простонародии «исошкой». Продукт установился без происшествий, что подтверждается и многочисленными рапортами других наших агентов. После установки программа попросила ввести в специально подготовленную щель на экране специально подготовленный ключ. Сначала в действенности такого способа защиты у меня были сомнения, но если ключ не вставлять, или вставлять что-то другое, то программа не открывается! Мною были предприняты несколько попыток вставить TOPOR, BANAN и BATON, но они не смогли никак повлиять на работоспособность механизма замка. На основании вышесказанного считаю, что защита программы достаточно надежная.
После загрузки среды я предпринял попытки выполнить основную часть своего задания – создание UML модели и последующее преобразование её в код и обратно. Не смотря на некоторые трудности, мне этот процесс удался. Далее привожу полевые заметки, выполненные в боевых условиях:

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

Чтобы её откомпилировать, потребовалось ещё несколько минут, так как некоторые идентификаторы в коде находились не там, где привык находить их компилятор. Ручная перетасовка текста модуля изрядно утомила меня, но дело свое сделала.

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



Любые изменения класса через инспектор объектов перемещают курсор на верхнюю строчку инспектора, где находится названия класса. Это специальное напоминание от разработчиков продукта, чтобы мы вдумчиво называли свои классы и постоянно переосмысливали содеянное. Я считаю - это новый виток развития UML редакторов.

В целом работа системы LiveSource выглядит удовлетворительно: идентификаторы, созданные в коде, появляются на модели и наоборот. Но не обошлось и без странностей. Ручное изменение класса на перечисляемый тип вызывает ступор UML редактора, и последний перестает перерисовывать квадратик «класса-типа» на диаграмме и всячески его игнорирует. Помогает только повторное открытее редактора.

Далее для теста в среде был открыт модуль, реализующий работу GPS эмулятора. Его D2009 обработала успешно, построив красивую диаграмму классов.



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


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



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

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

пятница, 12 сентября 2008 г.

Шустрый пинг

Сегодня 256-ой день с начала года. В эту круглую дату некоторые люди празднуют День программиста. Как гласит легенда, в этот день старые бородатые программисты выбираются из своих берлог, собираются в кружок, надевают свои лучшие нестиранные футболки, берут в руку кружку пива и начинают рассказывать друг другу занимательные истории, которые случились с ними за всю их долгую и непростую жизнь. Со временем эти истории обрастают новыми фактами и превращаются в байки, передающиеся из уст в уста...
Все мы знакомы с историями про кенгуру, атакующих вертолеты, и самолет НАТО, сбоивший в районе Мертвого моря, а так же электронные письма, ходившие только в определенном радиусе от почтового сервера. Ну и я, будучи настоящим бородатым программистом, не буду нарушать эту старинную традицию и расскажу вас занимательную историю, которая случилась со мной и моими коллегами лет эдак 7 назад. Так как история занимательная, то я намеренно упущу технические подробности и нюансы, дабы не выглядеть занудой и не портить вам праздничное настроение. Итак…
Дело было в большой корпоративной сети, размахнувшей свои щупальца на целый регион России. В один прекрасный день удаленный филиал, подключенный по выделенной линии, в лице руководителя технического отдела начал жаловаться на то, что связь с его филиалом отсутствует – ни передача данных, ни IP телефония не работают. Занимающиеся скучной текучкой инженеры тут же активизировались и поспешили проверить высказывание удаленного коллеги самым простым и доступным для этого способом – пингом. Результаты, на удивление, оказались довольно разными – у одних канал работал замечательно, у других – напрочь отсутствовал. Щелкнув нижней челюстью и преодолев минутное замешательство, сотрудники принялись выяснять, что же на самом деле творится в их епархии. Проверив все возможные причины отсутствия связи и ещё добрый десяток пвсевдонаучных теорий, были получены следующие факты:
1) Физический канал работает.
2) Но связь в привычном для пользователя понимании этого слова отсутствует, т.е. передать файлы, почту и позвонить действительно невозможно.
3) Пинг из консоли Билла Гейтса прекрасно циркулирует в обоих направлениях.
4) Пинг из программы Whatsup gold не доходит до адресата.
Пытаясь объяснить такое поведение программ, специалисты развернули бурную дискуссию, в которой то и дело были слышны выкрики про космические лучи и геопатогенные зоны. Арбитром выступил самый главный и самый мудрый Администратор Всех Маршрутизаторов, заявивший, что с его устройств пинга так же нет. Тогда беснующаяся толпа заподозрила в обмане уже самого Била Гейтса, который написал свой пинг неправильно, как и многое другое на этой планете. Особо смелые выразили подозрение, что пинг старика Била просто притворяется, что получает ответ, в то время как связи-то нет! Чтобы проверить утверждение: "А был ли мальчик" - тут же был запущен снифер, который и разрешил все споры, заодно подтвердив полезность советского академического образования в целом, и предмета «Телемеханика» в частности. Дело было в том, что программа Whatsup решила использовать передаваемый пакет в качестве рекламного носителя, записывая внутрь кричащую строку: Whatsup Gold!, Whatsup Gold!. А вот старина Билл поскромничал и в качестве бесполезных данных решил использовать последовательность букв латинского алфавита. А она, как известно, существенно лучше восстанавливается помехоустойчивым кодированием. Следовательно, на канале есть какие-то незначительные помехи, которые портят среднестатистические данные, но не в силах испортить пакет Била Гейтса! Эмпирические исследования показали, что виновником был кабель между маршрутизатором и модемом. Вот так вот банально все и закончилось. Жаль только, что не сохранился тот кабель – было бы с чем приехать на поклон к дедушке Билли.



PPS. Много не пейте.

вторник, 26 августа 2008 г.

Пополнение семейства.

Собственно, родился ещё один дельфенок. Назвали "Дветысячидевятым". С утреца занял очередь, чтобы поглядеть на чадо. Очередь двигается медленно...

Сайт почти валяется - апологеты с открытыми ртами смотрят на мохнатого, волосатого Девида Интерсимона в пестрых рубашках, олицетворяющего собой протошамана Кодгира – этакую квинтэссенцию старой доброй гвардии, успеха и легендарности – все, что оказалось не нужно Борланду на нынешнем этапе его существования. Девид постарел, поседел, но всё ещё может быстро говорить и замечательно читает по бумажке =).
Итак, что интересного? Наконец-то удалось увидеть в действии класс-эксплорер. Похоже, кодгировцы решили отобрать хлеб у Modelmaker-а, но судя по реализации, это произойдет не скоро. Появился также эксплорер ресурсов – вещь чрезвычайно нужная. Появись она лет десять назад, и многие дельфисты не знали бы ещё одну главу из майкрософтовского мануала. А вот конфигурации сборки – довольно интересная штука. Хотелось бы повозится с ней подольше, чтобы понять возможности и удобство использования. Как известно, в D2007 есть определенные сложности с куцей «оболочкой» MSBuild-а.

Переливы Ходжеса про VCL компоненты опущу. Мне кажется, что серьезной компании, создавшей мощнейшее средство разработки, рассуждать о каком-то там компонентике с панельками достаточно смешно. Более интересны доработки вершины пирамиды – TObject обзавелся тремя новыми методами: ToString, GetHashCode и Equals. Из названия ясны задачи, но вот нюансы будут понятны позже - из документации и исходного кода.
Радует полноценная поддержка Unicode. И хотя теперешние мои решения для мультиязычности повзрослели и устаканились, но я всегда с тревогой думал о том часе Х, когда придется реализовывать поддержку иероглифов или что-нибудь подобного. Теперь, думаю, стоит тревожиться о косяках в алгоритмах работы со строками. Наверняка где-нибудь что-нибудь заглючит, потому как библиотек старых полно, писалось много и как бог на душу положит.
Наконец-то появились альфаканалы в иконах и стандартная поддержка формата PNG. Вот уж чего давно не хватало. Не понимаю, почему был полный игнор этих важных для внешнего вида ПО вещей (я имею в виду, конечно же, коммерческие приложения). Ну и TImageList под неутихающие аплодисменты довели до ума. Теперь он поддерживает все зарегистрированные для TImage форматы. О, чудо! Надо где-нибудь заметку зарубить.
Поддерживаю решение дать в нагрузку разработчикам Interbase Developer Edition. Ну действительно, не отправлять же людей к конкурентам. Развивается Intraweb. На мой взгляд – не в том направлении, но об этом может быть позже, в отдельном посте.
Ну и всякие модные штуки, типа Exit с параметром, TStringBuilder-a, дженериков и поддержки лямбда-исчисления, про которые вы уже наверняка много слышали и читали. Не то, чтобы меня они не радуют =) Считаю, что должно пройти некоторе время, прежде чем новые решения приживутся, взойдут и дадут плоды. Я вот, например, всё ещё не использую конструкцию For in (как точно и мило прозвали её аналог for each VB-программисты - ФУРЫЧ), так как использую много Legacy кода, который собирается на старых версиях Delphi. Когда-нибудь это безобразие кончится, и я приобрету новую версию ModelMaker, которая будет всё это знать и уметь. И вот тогда… =) В общем, все это освоим, только дайте срок.

Плохо, что уже несколько релизов подряд так и не может разродиться Компактфреймворк (что не удивительно, так как D2009 не поддерживает .Net). Рынок сбыта медленно, но верно уплывает к более проворным компаниям. Но в целом, маркетинг CodeGear стал гораздо эффективнее и нагляднее. Надеюсь, это положительно повлияет на продажи. Курс верный.

PS. А! Самое-то главное. На днях буду тестировать LiveSource. Первые пять попыткок были неудачными. На очереди шестая. Ваши ставки?

среда, 13 августа 2008 г.

Настройка путей IDE Delphi для продуктивной работы

Недавно зашел к товарищу в гости, и тот пожаловался, что его проект компилируется почти полторы минуты, хотя по размерам относительно небольшой, да и окно Code Completition первый раз после компиляции проекта открывается непозволительно долго. Покопавшись в настройках среды, я обнаружил причину столь медленной работы. На мои замечания товарищ ответил тем, что в хелпе информации по вопросу организации работы сторонних библиотек в IDE крайне мало, после чего родилась эта заметка. Возможно, профессионалам она не пригодится, но кому-то поможет ускорить работу.
Не секрет, что точность, качество и скорость работы любым инструментом зависят не только от того, кто его фирма-изготовитель и из каких материалов сделан инструмент, но и от того, правильно ли закручена какая-нибудь маленькая гаечка в механизме его настройки. Так и с IDE Delphi могут произойти скоростные метаморфозы, стоит только чутка ошибиться с настройками. Сегодняшний разговор затронет плохоосвещенную в документации вещь – настройку путей. А между тем, при правильной настройке путей можно значительно выиграть в скорости компиляции и сборки проекта. Но начну с начала.
Сама по себе пустая как барабан IDE работает хорошо. Проблема возникает, когда в среду устанавливается много сторонних компонентов. Чтобы они работали, необходимо в путях указать их местоположение. Разработчики тоже люди образованные, до девяти считать умеют, поэтому думают, что логичнее всего разные библиотеки хранить в различных папках. В целом, это правильно, однако со временем путей набирается так много, что IDE начинает существенно притормаживать. Самым простым и легким способом дать пинка неповоротливому созданию – отключить в проекте лишние пакеты. Однако если большинство библиотек каким-либо образом задействовано в ваших проектах, можно поступить следующим абсолютно нехитрым образом. Все DCU ото всех библиотек мы достаем из их локальных папок, помещаем в одну папку (назовем её DCUFolder) и прописываем её в Library Path, а упоминания о путях к папкам этих библиотек, напротив, удаляем из Library Path. При этом, данные библиотеки должны быть собраны с соответствующими релизу опциями компиляции, т.е. без отладочной информации, локальных символов и т.д. Таким образом, при компиляции проекта у вас не будет постоянно проверяться валидность DCU, что при большом количестве библиотек занимает существенное время. Ну а при билде проекта не будут перестраиваться библиотечные модули. Для отладки, неплохо бы иметь также папку с названием DCUDebugFolder, куда положить собранные с отладочной информацией библиотеки. Далее эту папку нужно прописать в Debug DCU Path. А для удобной навигации по исходным текстам - папки, в которых хранятся библиотеки, надо добавить в Browsing Path. Собственно говоря, это все.
Теперь несколько замечаний. При такой конфигурации есть принципиальный минус. Он заключается в том, что если вы в Вашем проекте также активно правите какой-то библиотечный модуль, то эти изменения автоматически не появятся в вашей программе без дополнительных телодвижений: вам необходимо в файле проекта библиотеки обязательно указать DCUFolder, куда класть скомпилированные библиотечные модули, добавить проект библиотеки в Вашу группу проектов и создать зависимость главного проекта от этого библиотечного проекта. Тогда при нажатии на F9, IDE сначала проверит, не следует ли скомпилировать библиотеку, и только после этого соберет основной проект, который уже окажется актуальным. Возникает вопрос, а как же быть, если мы хотим собрать некий релиз программы с нашими библиотеками, но так, чтобы были использованы другие опции компиляции. При этом хотелось бы не испортить наши скомпилированные библиотеки, лежащие в DCUFolder, поскольку нам они ещё нужны. В этом случае есть несколько путей. Самый универсальный, подходящий и для старых версий Delphi, и для последних, использующих MsBuild – создать dcc32.cfg файл в каталоге проекта, в котором описать необходимые настройки, а также пути до всех перестраиваемых библиотек (это, пожалуй, самая трудоемкая задача). В этом файле следуют также указать две опции -ERelease\ -NRelease\Dcu, которые заставят компилятор создать библиотеки и сам файл в отдельных папках, не создавая конфликт с другими проектами. Далее можно написать простенький пакетный файл, который бы вызывал dcc32.exe для компиляции Вашего проекта. Dcc32.cfg, находящийся в текущей папке, будет автоматически подхвачен компилятором и перекроет его стандартные настройки. Библиотеки откомпилируются с необходимым опциями и будут положены в отдельные папки. При этом сам файл проекта не меняется и не меняет настроек среды. Конечно, с появлением MSBuild многие задачи автоматической сборки проекта упрощаются. Но это уже тема для отдельного разговора.
Хочу также отметить, что в IDE Delphi существует баг, или скажем так недокументированная фича, когда перестает работать очень удобная и широко используемая команда Find Declaration (также известная как Ctrl + Left Click или Alt + Up). С чем это связано, почему-то затрудняются сказать и сами разработчики IDE, ответы в профильных конференциях уклончивые, на QualityCentral тикет помечен многообещающим словом Reported. Так вот, если вы все сделали правильно, то поиск декларации пропасть не должен. Но если же это все-таки произошло, и некоторые модули сторонних библиотек перестали открываться по щелчку мыши, но открываются по Ctrl + Enter, то в этом случае попробуйте удалить КЭШа проекта (*.identcache), как пишут сами разработчики, что, впрочем, не помогает, или удалить и перекомпилировать dcu файлы этих модулей, как это делаю я. Это помогает =). Очевидно, что эта особенность связана с рассинхронизацией исходного кода и DCU файла (точно сказать не берусь, так как формат dcu недокументирован). В итоге, устаревший файл DCU портит всю малину. Вот, собственно и все, о чем я хотел вам поведать.

пятница, 1 августа 2008 г.

Соединяем файлы. С успехом.

Раз пошла такая пьянка, сегодня замечу ещё кое-что про Starteam.

Страшное слово автомёдж (Automerge). Его боятся многие разработчики. Они просто не знают ещё, что на самом-то деле страшно в конце плодотворного рабочего дня вместо чекина нажать чекаут. Но шутки в сторону. Автомедж – весьма полезная и экономящая кучу времени вещь. Не буду разводить много воды, сразу приступим к примеру. Есть представление Beta, олицетворяющее собой бета-версию продукта, и есть, как водится, представление Release – релиз. Допустим, в Beta мы придумали три новых класса и хотим их интегрировать в релиз. Делается это в три счета: Открываем нужное представление, в меню нажимаем View->Compare/merge, в диалоге выбираем проект и его представление, в которое хотим внести изменения. Появится окно, логику работы которого описать в двух словах непросто, но на деле с ним очень легко разобраться. Ctrl+F поможет найти вам различия в представлениях (на рисунке это файл Manual.txt).

Чтобы соединить два файла в один, нужно выбрать в контекстном меню конфликтного элемента пункт Merge Items или Auto-Merge Items (но это только для крепких духом. Шутка. Если Starteam обнаружит, что в файлах есть конфликт, он всё равно переключится в ручной режим). Так как в нашем файле данные только добавились, то Starteam отрапортует, что все соединилось успешно. Если автоматическая склейка не получилась в силу каких-то причин, среда выдаст ещё одно замечательное окно, которое позволит свести два файла воедино без лишних переживаний (обратите внимание на номера строк в соединяемых файлах – это типичный конфликт. Но не надо думать, что Visual megre работает только по номерам строк. Это достаточно продвинутый инструмент для поиска блоков текста в файлах).


И ещё, если вы хотите соединить данные из разных проектов, то вначале придется эти данные поставить в соответствие друг другу командой Reconcile. Собственно, из страшного все. Остальное несущественно и осваивается в рабочем порядке.

среда, 23 июля 2008 г.

Мир меняется... и синтаксис вместе с ним.

Для новостей есть специальные сайты, но я никак не мог пройти мимо одной статьи. Нынче модно подогревать интерес к новым продуктам через блоги тремя битами выцеженной информации. Вот и Ходжес (а теперь получается и я) разродился заметкой про Тибурон, в которой подтвердились слухи о том, что компилятор наконец-то будет понимать конструкцию Exit(Result). Попытки реализовать это дело были и раньше в некоторых экспериментальных расширениях. Но проникновение в толстую кишку больного с помощью автогена не каждому по душе, поэтому такие расширения имели больше академический интерес. Теперь же это случится официально. Но интересно не это, а комментарии к посту, в которых, помимо глупых «Спасибо дорогому товарищу Сталину!», посыпались как из рога изобилия жалобы, слезы и стенания на конструкции, уже набившие оскомину нашему брату - программеру. Дайте нам мультикаст эвенты, уберите лишний Try и т.д. Пожаловались, так сказать, излили душу =) Эх, был бы результат... В общем, почитайте, прикольно =)

среда, 16 июля 2008 г.

Красавец код

На днях был у коллег в гостях. Они купили стороннюю компоненту за 59 долларов для своего софта. Это ужос! Кашамр! Нет, всё работает, как надо, но код оформлен пренебрежительно плохо, с использованием самобытного урюпинского стиля форматирования. Выставлять такую «красоту» на всеобщее обозрение, а тем более продавать это за деньги … Нет слов, одни буквы.

Итак, для тех, кто ещё не знаком с правилами оформления public кода для Delphi, может прочесть эту статью. Кому некогда – просто скачайте Delfor или тулзу от протестантов на худой конец. И перед тем, как выдать код на свет божий, пропустите его через эти декастомизаторы, чтобы избавить от персонального или корпоративного «дизайна». Планета будет вам благодарна.

PS. Почему бы не встроить стандартный форматтер в среду? И что у нас есть из интегрированного? GExperts вроде не умеют форматировать, в MMX форматирование вызывает только смех, Lextutio я снес после очередного закидона...

пятница, 11 июля 2008 г.

Звездная команда (Часть 8). Хороший тон использования представлений на примере небольшой команды.

Теперь давайте на примере рассмотрим реализацию небольшого проекта на Starteam.

Перечислим основные постулаты, которых будем придерживаться при развертывании проекта:
1) Главное представление используется для реализации основной линии проекта;
2) Проект конфигурируется таким образом, чтобы предписать создание запросов на изменение, задач, обсуждений, или требований для каждого "модуля". Понятие "Модуль" определено свободно.
3) Для стандартных билдов используются метки представления (View labels) и, возможно, содействующие состояния (promotion states).

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



Когда необходима модификация ("mod"), разработчик отмечает (check-out) требуемые файлы в основном представлении, блокируя те, которые планирует изменить. После создания локальных изменений рабочего файла, включая и создание любых новых файлов, разработчик выполняет испытания модуля, чтобы быть уверенным, что файлы могут быть использованы другими разработчиками. Когда тестирование закончено, разработчик загружает(Check- in) новые и измененные файлы в БД.
Автоматизированный сценарий (не изображен на рисунке) выполняется периодически и создает новую метку представления. Выгрузка (Check-out) файлов из БД делается по этой метке, чтобы откомпилировать и собрать проект и запустить наборы тестовых программ.
Когда в основном потоке разработки приходит время выпуска приложения, от определенной метки представления (например, "Билд 5.3.142 Кандидат релиз") или от содействующего состояния создается branch-all представление. Такое представление используется как представление для поддержки этого релиза, так как единственные изменения, осуществляемые в этом представлении будут патчами для исправления ошибок. Развитие же системы продолжается в основном представлении.
Если изменение, сделанное для представления поддержки считают актуальным для других выпусков, то оно также объединяется с основным представлением (не изображено на рисунке). Сравнение/объединение представлений для этого обычно не требуется. Вместо этого, объединяются конеретные файлы, так как основное представление продолжает развиваться, в то время как представление поддержки остается относительно постоянным для определенного релиза. Этот процесс повторяется для каждого мажорного релиза. В результате для каждого релиза создается свое представление для поддержки.
Для больших проектов и больших команд используются несколько другие принципы ведения проекта, но это все вы без труда найдете в документации Starteam - было бы желание... шефа.
На этой радостной ноте я заканчиваю целенаправленное промывание мозгов аудитории всяким пропеиетарным софтом, как пишут некоторые читатели. Надеюсь, эти статьи были полезны русскоязычной аудитории и смогли хоть чуть-чуть прикрыть ту астрономическую пустоту, которая существует в рунете на тему Starteam.
PS. Возможно, я буду периодически публиковать посты на животрепещущие темы. Вот, например, про мёрдж(merge) народ интересуется. Вроде бы простая вещь, а ставит в тупик. Наверное, это какой-то психологический блок?

среда, 2 июля 2008 г.

Звездная команда (Часть 7). Как следует и как не следует работать с представлениями.

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

1) Трактуйте представления как потоки для реализации определенного этапа жизненного цикла приложения. Элементы представления могут сильно изменяться или не изменяться вообще в зависимости от назначения этого представления.
2) Используйте главное представление как основу проекта. В нем также следует содержать все компоненты и вспомогательные файлы проекта. В зависимости от вашей модели жизненного цикла и размера вашей группы разработки, изменения в проекте могут быть сделаны разнообразными способами с помощью различных представлений. Однако, все изменения в конечном счете перемещаются в главное представление.
3) Используйте branch-all представления. Это Ваша основная рабочая лошадка. Используйте ссылочные представления для read-only задач, таких как, например, сценарии компиляции и компоновки.
4) Метки представления и содействующие состояния удобны и эффективны. С помощью метки представления вы можете быстро отметить все элементы в представлении, выполнить загрузку отмеченных файлов из БД и корректировать ревизию индивидуальных файлов. Содействующие состояния позволяют вам определять логические состояния жизненного цикла программы, такие как тестовые версии, релиз кандидаты и т.д. На основе метки представления или содействующих состояний также могут быть созданы новые представления.
5) Не используйте глубоко вложенных представлений. Представления необходимы в основном как непосредственные дочерние записи основного представления. Иногда необходимы представления третьего уровня (внуки). Если вы создаете представления глубже третьего уровня, вероятно, вы используете представления не эффективно.
6) Не используйте некоторые типы представлений. Не используйте non-derived представления, "плавающие" представления, или изменяемые ссылочные представления кроме как в случае крайней необходимости и только тогда, когда вы полностью понимаете поведение этих типов представления.
7) Не используйте слишком много представлений. Представления - это "тяжелые" объекты. Их создание из существующего представления может занимать значительное время. Они обычно добавляют тысячи новых дочерних элементов в БД. Нормально использовать до нескольких сотен представлений на одном сервере Starteam.
8) Представления не следует использовать как “личное рабочее пространство” для индивидуальных разработчиков.

(окончание следует)

среда, 18 июня 2008 г.

Звездная команда (Часть 6). Дополнительные инструменты организации работы.

Тяжелая болезнь не дает мне заниматься общественно полезными делами. Но все-таки я нашел времечко и залил в эту бездонную гуглевскую бочку ещё одну статью на заданную тему. Надеюсь, что админ, который должен настраивать бэкапы этого сервера, компетентен и не позволит пропасть в неизвестности двум килобайтам текста, который дается мне сейчас с большим трудом. Статью про "Хороший тон использования представлений" я решил отложить на следующий раз в связи с вышекуазанным хронофагом, будь он трижды не ладен! Вот так вот, по доброму, без ненормативной лексики, мы переходим к сути этого эссе.
Контейнеры, объекты и элементы, о которых велась речь ранее, в полной мере дают возможность вам отображать части предметной области и организовывать их согласно потребностям вашего проекта. Этих механизмов достаточно, чтобы уверенно ориентироваться в разных версиях вашей программы. Но StarTeam также предоставляет дополнительные инструменты, которые позволяют оперировать такими понятиями, как билд, релиз и версия. Вот некоторые из них:

1) Связи(Links). Свзяи в StarTeam позволяют связывать произвольные объекты между собой. Например, запрос на изменение может быть связан с файлом - патчем, который призван устранить ошибку в программе. Объекты конечной точки связи (у связи имееся две точки – начальная и конечная. В Starteam существует разница между этими точками.) могут быть прикреплены к определенной ревизии объекта, или они могут быть «плавающими», т.е. быть связанными с последней версией объекта.
2) Метки (Labels). Используются для того, чтобы можно было легко сослаться на определенный набор объектов нужной версии. Метка представления (View Label) обычно ссылается на определенную версию всех объектов этого представления, а ревизионные метки (revision label) обычно ссылаются на определенные версии небольшой группы объектов. (Легко представить такую ситуацию: есть стабильная версия приложения, и требуются провести большие изменения. Перед обновлением кода в Starteam можно создать метку, назвав её «Супер-пупер стабильная версия» или «перед сумасшедшими изменениями, выклянченными любимым заказчиком». Теперь, в случае чего, в любое время можно одним мановением руки вернутся к этой проверенной версии, а следовательно - спокойно спать ночами)
3) Содействующие состояния (Promotion states) в StarTeam построены как раз на основе меток представления и поддерживают понятие итерационных билдов, релизов и процессов развертывания. (По сути, содействующее состояние – это ссылка на метку. Процесс применения содействующих состояний можно показать на таком вот простом примере: допустим, у нас есть стабильная версия программы. Мы создаем метку представления и называем её «1.0». Есть также тестовая версия программы – для неё используется метка «1.1». Далее администратор создает два содействующих состояния: «Release» и «Test» и связывает их с первой и второй меткой соответственно. Это нужно для того, чтобы неотокрые пользователи Starteam работали не с конкреноной меткой, а с некоторым абстрактным понятем, характеризующими состояние проекта. Например, исходные файлы стабильной версии программы выгружаются и компилируются автоматическим скриптом, используя содействующее состояние «Release». А группа тестирования продукта выгружает и строит исполняемые файлы, используя состояние «Test». Через некоторое время мы закончили работу над версией «1.1», и эта версия программы стала стабильной, а для новой тестовой версии создается новая метка «1.2 Новогодние задумки». Для работы в новых условиях администратору надо только изменить в соответствующих содействующих состояниях ссылки новые на метки, а конфигурацию автоматического сборщика и группы тестирования менять не надо – они как работали, так и работают с текущими настройками и могут даже ничего не знать о произошедших изменениях)
4) Правила обработки (Process Rules): проект может быть сконфигурирован так, чтобы предписать использование специальных правил, которые определяют, какие действия нужно выполнить перед добавлением нового файла или check-in файла в хранилище Starteam (Для версии 2005 реализована только возможность потребовать связать добавляемый файл с задачей, требованием или CR). Правила обработки удобны для создания ключевых билдов или конфигураций.
(продолжение следует)

четверг, 29 мая 2008 г.

Звездная команда (Часть 5). Объекты и элементы.

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

Важно понять, как объекты отображаются с помощью представлений (видов). Каждый объект отображается в некоторый вид с помощью дополнительной сущности, называемой элементом (Item) или, как ещё говорят, членом представления. Когда новый объект, допустим файл, добавляется к представлению, Starteam создает новый объект типа файл с версией 1.0, и это влечет за собой создание нового элемента, который "указывает" на тот файл. Элемент не только определяет, на какой файл ссылаются, но и определяет папку, в которой появится файл. Так, например, если Вы перемещаете файл из одной папки в другую, Вы фактически изменяете элемент - файл, чтобы указать на другой родительский элемент - папку, но сами объекты файл и папка фактически не измененяются. Отношения между элементами и объектами иллюстрированы на следующем рисунке.
В этом примере изображены два представления, указывающих на элемент - корневую папку. Каждый элемент указывает на соответствующий объект, и каждый элемент, отличный от элемента-коренвой папки указывает на родительский элемент-папку, определя тем самым, где располагается этот элемент.
Элемент, созданный от имени нового объекта называют родительским элементом. Дочерний элемент, созданный копированием родительского или дочернего элемента, позволяет отобразить тот же самый объект в другом месте. Дочерний элемент указывает на родительский элемент, с которого он был скопирован. Дочерние элементы создаются в двух случаях:
1) Когда используются дочерние представления(child views): В случае, когда новое представление создано как потомок другого представления, элементы родительского представления копируются, чтобы создать элементы дочернего представления. Сами объекты при этом не копируются – новые дочерние элементы представления просто указывают на те же самые объекты.
2) Когда используются разделяемые ресурсы (Shares): Элемент может быть явно скопирован, создавая "разделяемый" элемент (надо держать Ctrl и тянуть мышкой нужный элемент в StarTeam клиенте). В этом случае, выбранный элемент будет скопирован и будет указывать на тот же самый объект, что и оригинальный элемент.

Основное различие между дочерними представлениями и дочерними разделяемыми элементами - их начальная конфигурация. На поведение объекта частично влияет конфигурация родительского или дочернего элемента, по средствам которого мы имеем возможность управлять этим объектом. Чтобы понимать, как ведут себя родительские и дочерние элементы, необходимо понять разницу между свойствами элемента и свойствами объекта.
Свойства объекта: Большинство свойств, которые Вы видите – имя, кем изменен, версия, данные (для файла), и т.д. – принадлежит объекту. Когда любое из свойств объекта изменяется – создается другая ревизия объекта. Например, если текущая ревизия Запроса об изменении - 1.2, и свойство «Ответственный» изменено, модифицированный объект типа «Запрос об изменении» будет сохранен с ревизией 1.3. Если в новой версии файла текущая ревизия 1.4.1.2, то следующая будет соответственно - 1.4.1.3.

Свойства элемента: Элемент обладает свойствами, которые определяют, на какой объект этот элемент ссылается, папку, в которой он должен отображаться, и как должны обрабатываться изменения объекта через элемент. Большинство свойств элемента, например, родительское представление и родительская папка управляется StarTeam неявно на основании действий клиента. Однако, существует три ключевых свойства элемента, которые непосредственно затрагивают свойства объекта, на который ссылается элемент:
1) Код объекта (Object ID): Это свойство определяет ветвь объекта, на которую ссылается элемент. Каждый новый объект получает уникальный Код объекта, и его номер ревизии начинается с 1.0. Номер ревизии объекта увеличивается каждый раз, когда обновляется состояние объекта (1.1, 1.2, и т.д.), но код объекта при этом остается неизменным. Следовательно, код объекта, на который ссылается элемент, указывает на целую ветвь объекта и возможно на конкретную ревизию. Когда же объект ветвится, создается новый объект с новым кодом объекта, и номер его ревизии расширяется, чтобы отразить точку ответвления (например, 1.2.1.0). Элемент ссылается на новую ветвь, обновляя код объекта, на который он указывает.
2) Конфигурация поведения элемента (Behavior Configuration): Это свойство определяет, является ли элемент «плавающим» или привязан к определенному моменту времени. Когда поведение элемента определено, как плавающее, элемент указывает на последнюю ревизию ветви объекта, на который ссылается этот элемент. Когда поведение привязано к конкретному моменту времени, элемент ссылаестся на ревизию объекта, которая был актуальным на то время.
3) Автоматическое ветвление при изменении (Branch-on-change): Это свойство действительно только для дочернего элемента, ссылающегося на файл или «запрос на изменение». Оно определяет, что случается при изменении объекта через элемент. Если это свойство установлено в True, Starteam при любой модификации заставляет начинать новую ветвь объекта. Например, если файл загружается в БД (check in) через элемент, и текущая ревизия равна 1.2, автоматически создается новая ветка 1.2.1.0. Когда это свойство установлено в False – это означает, что, или основной объект уже ветвился через этот элемент, или изменение через элемент оперирует тем же самым объектом что и родительский элемент, или этот элемент только для чтения (заморожен).

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

понедельник, 19 мая 2008 г.

Звездная команда (Часть 4). Понимание представлений.

Сегодня я подробнее расскажу о представлениях (View), которые реализованы в Starteam. Но прежде я хотел бы сделать несколько замечаний про терминологию, которая используется в статье. Во многих системах контроля версий для обозначения копии файла, полученного в результате изменения оригинала используется слово "Версия" (Version). Собственно, отсюда и возникло название таких систем. И Starteam в этом случае не исключение, только версии файла в Starteam называются Revision (что тоже, в общем-то, интуитивно понятно). Кроме простой версионности в Starteam реализовано так называемое ветвление (Branching), которое позволяет рассматривать версии файлов в рамках некого дерева изменений, имея несколько актуальных версий изменяемого элемента (файла, требования и т.п.) на разных ветках этого дерева. Поэтому полный номер версии элемента определяется атрибутом Branch revision, который представляет собой композицию номеров версий файла и ветки. Т.о. когда в статье идет речь про ветвление, то это автоматически подразумевает и версионность элемента.
Когда Вы создаете проект, Вы также создаете начальное или корневое представление этого проекта. В процессе работы над проектом также может быть создано несколько представлений дополнительно. Зачем они нужны? Представления позволяют реализовать очень важную функциональность сервера Starteam – отображать только определенные элементы, входящие в его состав. Причем, критерием отбора могут являтся не только обычные атрибуты элемента, вроде имени и типа, но и дата создания и изменения, версия элемента и т.д. Другими словами, Вы можете конфигурировать представление так, чтобы показать элементы, существовавшие раньше или позже определенного события, на конкретный момент времени, базирующиеся на специальной метке или находящиеся в некотором состоянии. В зависимости от своего назначения можно классифицировать представления по нескольким типам:

1) Представления, динамически отображающие изменения исходного кода и документов в вашем проекте (Dynamic view). Заданное по умолчанию корневое представление относится как раз к этой категории. Оно позволяет вам видеть все файлы и другие элементы проекта «как есть» на текущий момент времени. Представление этого типа отображается, когда Вы выбираете в меню View > Select Configuration > Current Configuration.
2) Изменяемое представление – ссылка (Reference view). Под ссылкой в данном случае следует понимать ссылку на подмножество элементов, найденных в первоначальном представлении. Такое представление часто содержит только элементы, представляющие интерес для определенной группы разработчиков. Любое изменение, сделанное в представлении этого типа изменяет тот же самый элемент в первоначальном представлении. Это происходит потому, что представление содержит ссылки к элементам в первоначальном представлении и не ветвится (см. ниже), когда происходят изменения.
3) Неизменяемое представление-ссылка (RO reference view). Оно основано на определенном состоянии первоначального представления. Такое представление-ссылка создается обычно для удобства поиска конкретных ревизий элементов, используемых в определенных релизах программы. Оно может быть "плавающим" или жестко привязан к определенной дате. Представления этого типа используются в основном для того, чтобы можно было легко восстановить старые версии программы.
4) Представления, разрешающее выполнять ветвление элементов (Branch all view. Также часто их называют версионными). Ветвящиеся представления можно использовать, чтобы изменить элементы, найденные в определенном представлении, не затрагивая эти элементы в других представлениях. Таким образом, мы можем создать несколько ветвящихся представлений в одном проекте и работать над разными версиями программы параллельно, не вызывая конфликтов. Поэтому, ветвящееся представление должно использовать рабочую папку, отличную от рабочей папки ее родительского представления. Использование той же самой рабочей папки для обеих представлений не только запутывает, но и может создать серьезные проблемы. Например, изменения в файлах одного представления могут быть затерты, когда Вы выгружаете файлы из БД от другого представления. Эта происходит потому, что два этих файла имеют одинаковые названия и рабочую папку. Или же состояние файла на клиенте может быть определено неправильно и ввести пользователя в заблуждение. Например, StarTeam может сообщить о состоянии файла в одном представлении как "Неизвестное", "Устаревшее" и т.д., когда действительное состояние файла "Отсутствует", и файл от другого представления с тем же самым названием находится в рабочей папке. Следует отметить, что благодаря своим своствам ветвящиеся представляния - самые востребованные производные представления в Starteam. Обычно, разработчики используют исключительно их.
5) Неветвящееся представление (Branch None view). Этот тип представления, как и ветвящееся представление, основывается на некотором родительском представлении. Как следует из его названия – элементы данного представления не ветвятся при их изменении.
6) Непроизводное представление (Non-derived view). Это самостоятельное представление, которое не наследуется от какого-либо другого представления. Соответственно, оно по умолчанию создается пустым и все элементы в него добавляются по желанию пользователя.
Теперь давайте подробнее рассмотрим наиболее интересные и полезные ветвящиеся представления. Ветвящееся представление - представление, которое разрешает папкам, и другим элементам в представлении отделиться от соответствующих элементов в родителе и, начиная с этого момента, стать изменяемой копией родителя. Ветвление применяется только к папкам, файлам, и запросам на изменение. При этом можно настроить представление так, чтобы определенные его элементы не ветвились. Требования, задачи и обсуждения не ветвятся никогда. Изменения таких элементов можно осуществить в представлении, в котором они были созданы, в представлении, в которое они были перемещены или расшарены, или в "плавающем" дочернем представлении, предназначенном только для чтения. Новые ревизии таких элементов могут быть рассмотрены в любом "плавающем" дочернем представлении.
Пока элемент не ветвится, соответствующие элементы в обоих представлениях остаются идентичными. После того, как пользователь изменил элемент, появляется новая ветвь или, как ещё говорят, версия этого элемента, и они больше не являются идентичными. При этом номер ревизии элемента указывает на новую ветвь. Единственный способ снова сделать элементы идентичными состоит в том, чтобы вручную объединить их, сравнивая и объединяя представления с помощью команды Compare/merge views. После того, как происходит ветвление, StarTeam больше не посылает и не применяет обновления от соответствующего элемента в родительском представлении. Из соображений безопасности, удаления, сделанные в родительском представлении не размножаются к дочернему представлению и наоборот. Если Вы хотите удалить папку или элемент изо всех связанных представлений, Вы должны удалить их из каждого представления в отдельности.
Ветвящиеся представления предназначены для различных целей:
1) Выполнение разнообразных потребностей в зависимости от ваших задач. Например, можно создать исправленную версию или заказную версию вашей программы, ответвленную от предшествующего коммерческого релиза.
2) Начало разработки следующего релиза вашей программы, используя некоторые или все файлы от предыдущего выпуска.
3) Хранение части вашего проекта приватно, пока она полностью не закончена и не протестирована. Когда потребуется, Вы можете объединить ваши изменения с основным проектом.
(продолжение следует)

среда, 14 мая 2008 г.

Звездная команда (Часть 3). Логическая конфигурация проекта

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

Итак:
1) Каждый Starteam сервер может содержать несколько проектов:
2) Каждый проект имеет главное представление (View) и любое количество дочерних представлений: 3) Каждое представление (и главное, и дочерние) ассоциировано с некоторой StarTeam-папкой, называемой главной (root folder): 4) Каждая главная StarTeam-папка может содержать иерархию дочерних папок, называемых StarTeam-каталогом (иерархией папок):
5) Когда администратор создает новый проект, автоматически создаются главный вид и главная папка проекта. Они будут иметь такое же имя, как и имя проекта, например «GreatApp» (позднее администратор может поменять эти названия): Рассмотрим пример, показанный на следующем рисунке.

В нем конфигурация сервера содержит два проекта: Dev1, чье главное представление имеет 2 дочерних представления, и Doc1, главное представление которого имеет единственное дочернее представление, которое в свою очередь тоже имеет дочернее представление. Как видно из рисунка, развитие проектов сохранено в консолидированном репозитарии – базе данных и файловом архиве. В любое время пользователь Starteam может выбрать нужное ему представление и начать с ним работу. Однако, чтобы понять все нюансы работы с представлениями, следует подробнее разобраться, что же представляет собой это представление. Об этом мы поговорим очень скоро, как только я сформулирую свои мысли в виде буквенно-цифровых последовательностей, называемых в простонародии текстом.


(продолжение следует...)

четверг, 8 мая 2008 г.

Продалися =)

То, о чем так долго говорили большевики, свершилось! А я уж, грешным делом, думал, что идея продавать софтверный бизнес оставила Borland. Многочисленные блоги пестрят сообщениями о том, как это круто. Наверное, так оно и есть. Ценник, правда, сбили на 70 мультов. Но, видимо, для Borland и это хорошо. То, что мирового лидера с многолетней историей в области разработки языков программирования, компиляторов и IDE покупает фирма, делающая утилитки для баз данных о чем - то да говорит. Воистину, мир меняется... и мы вместе с ним.
Ну, как говорится, на новом месте - приснись жених невесте =) Пожелаем удачи CodeGear в новой итерации.

понедельник, 5 мая 2008 г.

Звездная команда (Часть 2). Объекты Starteam

Объекты – это основные информационные единицы в пределах сервера Starteam. Все объекты являются версионными. Это означает, что существует возможность обратиться к отдельным ревизиям объекта, отметить отдельные версии, создать ответвления (про ветвление будет подробнее рассказано в следующей части) и т.д. Содержимое объекта хранится как ряд свойств, каждое из которых имеет имя и значение. Для каждого объекта также Вы можете добавить произвольные свойства. StarTeam поддерживает следующие типы объектов:



  1. Файлы(Files): Как во всех SCM системах, файлы - самый важный тип объекта в StarTeam. Свойства файла содержат метаданные, такие как атрибуты безопасности, история изменения, ссылка на лицо, изменившее файл и т.д. Понятно, что файлы и сами по себе содержат двоичные или текстовые данные и сохраняются в хранилище(Vault) на сервере. Файлы являются версионными и могут ветвиться в отдельные версионные деревья. Файлы поддерживают и возможность создания связей(линков) и прикрепления меток.


  2. Запросы об изменении(Change Requests): StarTeam поддерживает систему отслеживания ошибок и изменений с помощью объектов типа Change Requests. Подобно файлам, CR может быть версионной, связанной, помеченной метками, ветвиться и т.д. CR обычно используется, чтобы представить дискретные запросы типа сообщений об ошибке, некорректной, неправильной работе программы, а также для внесения изменений в её работу.

  3. Задачи(Tasks): В StarTeam задачи похожи на этапы планирования работы, используемые в системах руководства проектоми типа Microsoft ® Project (Фактически, задачи StarTeam могут быть синхронизированы с задачами Microsoft Project). Задача обычно представляет один конкретный шаг в решении комплексного задания и может быть назначена нескольким сотрудникам. Задача может быть разделена на подзадачи и отслежена через лог записей о её выполнении. Задачи также являются версионными и могут быть промаркированы, связаны, и т.д, однако они не могут ветвиться в версионные деревья подобно файлам и запросам об изменени.

  4. Темы(Topic): тема - подобие сообщения в телеконференции, которое может быть послано одним пользователем, ответ написан другим и т.д. Цепь сообщений на данную тему создает “дерево обсуждений”, которое может быть присоединено к файлу, запросу об изменении, или другому объекту. Подобно задачам, темы являются версионными, но не не могут ветвиться в версионные деревья.

  5. Требования(Requirements): StarTeam поддерживает упрощенную систему требований, которая может быть использована для документирования на ранних стадиях разработки жизненного цикла проекта. Требования могут быть созданы и реализованы непосредственно в StarTeam, или они могут быть импортированы и синхронизированы с объектами от других систем управления требованиями типа CaliberRM ™. Требования являются версионными, но не не могут ветвиться в версионные деревья.

  6. Папки(Folders): Каждое представление(вид) имеет корневую(главную) папку, которая обычно содержит дерево подпапок. Папка может содержать объекты любого типа, включая другие папки. Хотя папки – это по сути дела "контейнеры", они имеют свойства и являются версионными. Следовательно они также являются объектами StarTeam, и, подобно файлам и запросам об изменении, могут ветвиться в версионные деревья. Обратите внимание, что логический путь папки определяется на основании пути его родительских папок. Однако, путь к соответствующей рабочей директории, в котором сохранены файлы на клиенте, может не соответствовать логическому пути. Т.о. рабочая директория может быть переопределена на клиенте. Это очень удобно, так как у разных разработчиков системы настроены по разному. Более того, могут использоваться разные ОС, например Windows и Linux.

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

вторник, 29 апреля 2008 г.

Звездная команда (Часть 1)

Ну что ж, как и обещал, выкладываю первую часть статьи про Borland Starteam. В ней кратенько рассказывается об основных возможностях продукта. Тон получился немного помпезный, но это потому, что в качестве шпаргалки для написания статьи были использованы презентационные материалы, а они, знаете ли, грешат глянцем =). Starteam (как и CaliberRM) изначально был разработан компанией Starbase, а в начале 2003 года куплен Borland и интегрирован в линейку их ALM решений. Сейчас на сайте Borland доступен для скачивания Starteam 2008 с триальной серверной лицензией на 30 дней. Клиентские лицензии в данном случае не требуются. Далее я буду приводить актуальные на сегодняшний день куски статьи вперемешку со своими комментариями.

Приложения масштаба предприятия, безусловно, нуждаются в управлении процессом их создания и эксплуатации. Очень важно, чтобы правильно осуществлялись проектирование приложения и управление проектом, управление изменениями, а также, чтобы производительность труда участников проекта была максимальной. Borland StarTeam - система конфигурирования и координации действий всех участников проекта - позволяет достичь этих целей. StarTeam представляет собой средство управления конфигурациями и изменениями на основе системы контроля версий. Продукт поддерживает несколько клиентских интерфейсов (в частности, Windows- и Web-интерфейс (раньше была отдельная версия Starteam для веба, теперь же это просто довесок для выноса интерфейса в веб. Только под IIS)), утилиту командной строки для пакетных задач), имеет мультиплатформенного Java клиента, может интегрироваться с оболочкой Windows Explorer (это так называемый StarDisk – средство, представляющее сервер Starteam в виде ещё одного диска в ОС. Средство, безусловно, полезное для менеджеров, далеких от разработки ПО, но имеющих документы в репозитарии Starteam), Microsoft Project и некоторыми другими сервисами, позволяет организовывать дискуссии между членами проекта, имеет встроенную систему планирования и управления проектом, организацией рабочего времени участников проекта, беэгтрекинга и управления требованиями. На базе StarTeam можно создавать и свои собственные решения для конфигурационного управления — для этой цели Borland предоставляет API для Java, COM и Microsoft .NET Framework.
Все данные о проекте (исходные тексты, модели, документы, рисунки, графики) хранятся в едином репозитарии. Все, что относится к одному и тому же проекту (документы, модели, код), хранится на одном и том же сервере, где можно осуществлять управление этими активами и организовывать документооборот. Репозитарий доступен по протоколу TCP/IP с поддержкой криптования для удаленных соединений и управляется с помощью сервера. Данные, относящиеся к проекту, хранятся в серверной СУБД (Microsoft SQL Server/Oracle) и в специальном файловом хранилище (хочу отметить, что версии файлов лежат на диске, а другие артефакты - в БД). Т.о. распределенным командам нужен лишь доступ в Интернет.
Borland StarTeam интегрируется с системой Borland CaliberRM – специализированной системой управления требованиями, обеспечивая совместное использование средств поиска и анализа информации (Search Server и Datamart соответственно), что позволяет искать и анализировать информацию во множестве распределённых хранилищ (Это для суровых разработчиков. Небольшой команде в небольшом зеленом проекте хватает за глаза и за уши встроенной в Starteam системы требований). За счет этого можно улучшить предсказуемость, контролируемость и качество процесса разработки программных продуктов. Вторым важным продуктом, с которым интегрируется StarTeam, является Borland Gauntlet – среда для непрерывной автоматической сборки и тестирования.
С целью уменьшения нагрузки на системных администраторов крупных организаций, использующих Windows Server 2000/2003, система StarTeam обеспечивает поддержку аутентификации пользователей средствами Microsoft Active Directory по протоколу LDAP (в том числе и через SSL). Благодаря этому сисадмины могут централизованно контролировать различные аспекты аутентификации пользователей на сразу на нескольких серверах StarTeam (В целом штука, безусловно, удобная, так как экономит время админу. Но вот чтобы настроить SSL, надо прикрутить центр сертификации).
Для распределения и балансировки нагрузки, повышения отказоустойчивости, а также увеличения быстродействия системы в целом в сетевой архитектуре Starteam предусмотрена возможность создания кеширующих серверов (Startem MPX server), поддерживающих мультикаст.
Чтобы получить более конкретное представление о Starteam, можно посмотреть ролики, выложенные на официальном сайте.
На этом введение заканчивается, а на следующей неделе я постараюсь подготовить и опубликовать статью про логическую структуру сервера.

четверг, 24 апреля 2008 г.

Стартуем!

Коллеги! На днях хочу выложить для всеобщего ознакомления свою давнишнюю статью про идеологию Starteam версии 2005R2, которую я написал по материалам из статей о продукте и его документации. Статья была написана для внутреннего использования, поэтому её нужно вначале подрихтовать и убрать лишние неологизмы =). Сейчас уже появился Starteam 2008, и конечно, многое изменилось, но основы и идеи, заложенные в предыдущих версиях, актуальны и сейчас. Но прежде я хотел бы поговорить про несколько странное отношение к системам контроля версий со стороны Borland.

Как-то на одной из презентаций 2007-ой версии Delphi я задал вопрос Кириллу Ранневу о том, куда делся интегрированный Starteam – клиент, который был в D2006, и почему исчезли любые упоминания о Starteam из Delphi. Ответ был его достаточно интересным. Дело в том, что Borland и CodeGear договорились о том, что CodeGear будет SCM нейтральным, а Borland – IDE нейтральным. Причин этому может быть много, но мне теребит мозг только одна - топ - менеджеры Borland так хотели дистанцироваться от своего убыточного софтверного подразделения, что даже отказались от дополнительных продаж в общем-то хорошей SCM системы через своего партнера. Видимо, желание продать неприбыльный актив было столь сильным, что такие нюансы даже не брали в расчет. Сейчас же, когда Borland второй год подряд терпит убытки, а CodeGear приносит прибыль, эта стратегия могла бы измениться. Ведь достойного покупателя CodeGear так и не нашли, и расставаться с компанией, приносящей реальный доход, теперь, похоже, уже никто не собирается. Однако ж, заглядывая в обновленный роадмап, мы не видим никаких упоминаний про интеграцию со Starteam. Удивительное дело, но эти хитрые «договоренности» сыграли плохую шутку сразу со всеми заинтересованными сторонами. Во первых страдают продажи Starteam, которые могли бы быть основаны на бесплатной рекламе со стороны IDE, во вторых – страдает имидж IDE, которая опять не имеет готового и полновесного решения, в третьих – страдают разработчики, которым предоставлена мнимая свобода выбора, а по сути дела – тыкание пользователя лицом в веб для поиска, установки и тестирования подходящего решения самостоятельно.
А ведь интегрированный клиент Starteam появился впервые в ещё D2005. Позднее он был дописан и доработан в D2006 и начисто пропал из D2007. Его нет нигде, ни в официальном вебе, ни в хелпе и даже на партнерском DVD. Вот насколько мощно CodeGear соблюдает ранее достигнутые договоренности. Но это ладно, удивляет другое. На самом сайте Starteam мы можем найти интеграции и к Эклипсу, и SCC и даже к VS! Пользователи же «родных» средств разработки посланы взад к своему дистрибутиву, в котором эту интеграцию днем с огнем не сыщешь. Все, сушите весла, круг замкнулся. Вот такой вот хитрый бизнес…

Знающие люди утверждают, что можно использовать пакет starteam-extensions.jar из дистрибутива D2006, но сама по себе интеграция – не самоцель. Если уж быть до конца честным, лично я не использовал её в своих проектах, довольствуясь стандартным клиентом Starteam, поскольку встроенное в IDE решение было урезанным и не понимало самой вкусности Starteam, а именно багтрекинга и простой, но достаточно эффективной для небольших проектов системы управления требованиями. Но! Как можно представить себе современного разработчика ПО, не обеспеченного системой контроля версий? Это же как надо себя не любить, чтобы отказываться от такого простого и эффективного механизма управления своей работой, способного сэкономить много времени и сил! А ведь многие себя не любят, потому что:
1) Считают использование SCM неоправданно дорогим и сложным.
2) Не видят существенной необходимости в этом.
3) Используют альтернативные пути в виде подпорок из батников и разных других допотопных возможностей ОС.
4) Просто ленятся и т.п.

Вот типичный пример - History Tab – ещё одна красивая подпорка, которая реализует версионность файлов, достаточную, чтобы вскрикнуть: «Ой, что-то здесь было до того, как я выделил текст и нажал энтер!». Безусловно, вещь полезная для тех, кто ещё не научился настраивать бэкап. Но как с помощью неё параллельно делать разные релизы, выпускать для них одинаковые патчи, вести исследовательскую разработку и одновременное тестирование пререлиза, да и ещё много чего другого – не написано ни в одном хелпе. А именно это повседневно нужно коммерческому разработчику ПО.

Самым правильным, на мой взгляд, было бы предложить интегрированное или легко настраиваемое решение, полностью поддерживаемое IDE. Так, чтобы поставил Delphi и опа, вот тебе современный, нужный и настроенный сервис, дорогой ты наш разлюбимый разработчик. Для этого следует поставлять урезанный StarTeam на MSDE c преконфигурённой БД на диске вместе с Delphi. Лицензия должна быть, как у BlackFishSQL, т.е. например 1-2 разработчика – бесплатно, все что больше – платите деньги. И самое важное – подробная и внятная инструкция о том, зачем все это нужно, как это использовать и какие преимущества в работе это дает. Я думаю, эффект будет потрясающим. Потому что слабыми местом Delphi всегда было и остается отсутствие комплексной методологии разработки ПО. А если хочется претендовать на что-то большее десятого места, надо этим делом активно заниматься. Управление жизненным циклом ПО – достаточно сложный и многогранный процесс. Starteam – это не просто система контроля версий, это гораздо большее. Starteam охватывает очень объемную и важную часть жизненного цикла ПО. Грамотное использование таких решений сильно изменит результаты нашей с вами работы. Осталось только донести это в полной мере до всех разработчиков.

вторник, 1 апреля 2008 г.

Поможем хелпу?

Во многих компьютерных играх бустер - это наиважнейшее условие победы. Не припомню геймера, добровольно отказавшегося от бустера. От бонусов отказывались, от рулезов тоже, но чтобы от бустера... Да ни в жись! Вот и на вооружение дельфистов поступил соответствующий бустер: Delphi-PRAXiS Help-Booster. Долго я его парил в папке Download, потом в папке Musor, и вот, наконец, руки дошли и до установки.




Поставил, повертел в руках, решил не сносить. Он хоть и сыроватый, но нормальный, интегрированный в среду поиск. Хорошая штука по скорости работы и удобству использования.
Из шероховатостей:

1) Очень скромный размер помощи. Есть только VCL/RTL для Delphi и сильно урезанный WIN SDK. Конечно, проект ещё слишком молод. Надеюсь, позднее все добавиться.
2) Ставится по умолчанию в странное место и там же хранит индексные файлы. Такое ощущение, что автор никогда не сталкивался с системой безопасности Windows. Или он думает, что все сидят с правами администраторов? =).
3) Ну и разные неприятности типа:



Сам-то я пользуюсь TypeAndRun (бывшый winconsole), так что мне особо этот бустер не нужен. Но все-таки давно хотелось, чтобы в Delphi IDE было что-то подобное. Как в других взрослых средах.

пятница, 29 февраля 2008 г.

Приключения дурака или как не надо делать опросы.

Как только на сайте появилась информация про опрос, я решил, что надо непременно заполнить анкету, так как в прошлый раз это возымело больше действие и помогло вернуть CodeGear из маркетинговых джунглей на грешную землю, поближе к нам, обычным трудягам – разработчикам. Вообще, хорошая идея спросить у покупателя, что он на самом деле желает. Если ещё сделать это в непринужденной обстановке, с кучей бонусов и улыбками на лице – думаю, это будет не только полезно интервьюеру, но и приятно самому отвечающему на вопросы. Шутка ли – потратить 30 минут собственной жизни в угоду какой-то коммерческой конторе, которая хочет содрать с тебя побольше денег. Требуем бонусов! И бонусы не заставили себя ждать…

Попытка №1.

Анкета большая, подробная, с математическими заскоками и полным отсутствием защиты от дурака. Да ещё всё происходило под конец рабочего дня, так что это довольно утомительно. Нажимаю сабмит с трепетом в душе, что сейчас вся моя работа пропадет из-за какого-нибудь глюка сети или сервера. Ну да, конечно – сервер выдает приглашение ввести имя и пароль… Какое имя, какой пароль? И никаких ссылок на регистрацию, просто тупо имя и пароль. Но уже поздно, пора домой. Поэтому нажимаю бэк, и браузер любезно достает из КЭШа заполненную мной анкету. Разберусь завтра, где взять пароль, чтобы этот CodeGear согласился принять мой голос.

Попытка №2

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


Попытка №3

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

Попытка №4.

На Delphiplus появляется информация, что готова русская версия опроса. Ну ладно, с утра время есть немного, попробую помочь Delphi своими мыслями. Но в начале хочется проверить, не будет ли опять как в прошлый раз – пишешь, стараешься, а тебе отлуп. Сразу нажимаю сабмит – опа, все работает, да быстро так. Значит что-то поднастроили там, на той стороне Атлантики… Можно догадаться, что эта мощная система опросов выдала мне, когда я все заполнил и нажал на заветную кнопку: Sorry, this survey does not accept duplicate submissions. Your new answers were not registered. В общем-то я на неё не обижаюсь, как нельзя обижаться на уродца. Он же не виноват в этом. Его таким сделала природа. Кстати, перевод на-русский вышел страшненкый.

вторник, 5 февраля 2008 г.

Так давайте же задокументируем это.

Проблема автоматической документации кода не пропадет до тех пор, пока сам язык не будет предусматривать готовых конструкций для реализации документации или же не появится единый и всемогущий стандарт, который все примут как единственно верный и будут следовать ему, заглядывая в рот, всегда, везде и во веки веков. Говоря другими словами, проблема исчезнет не очень скоро =). Но хорошие подвижки в этом направлении есть. В основном, они заключаются в появлении мощных средств автоматизации документирования кода, нежели каких-то семантических изысканиях, но и это уже хорошо. Осталась мелочь - воспитать сознательных разработчиков =). Но это не задача технических писателей, которые оказываются крайними в данной ситуации и которым только и остается жаловаться на своих коллег-программистов: «Вот, дескать, какие нерадивые, не заставить их толком что-нибудь черкнуть по теме». Это прямая обязанность PM проявить свою волю, характер, новый лакированный кнут, наконец, и добиться от кодеров не только стройного кода, но и скупого и сумбурного слова. Выражаться это может в чем угодно: в изменении штатного расписания, премиях и выговорах, приклеивании на лоб стикера с цитатами из «соглашения о кодировании», запретом в качестве наказания использовать в своих программах переменную i сроком на год и т.д. Это что качается организации работы. Ну а с технической точки зрения, если оценивать текущее положение дел по сравнению с тем, как это было лет …надцать назад, когда для создания небольшого HLP файла нужно было пролить ведро пота и слез, не говоря уже про какую-то там синхронизацию документации и кода, то у меня на губах невольно появляется улыбка. Сквозь пелену небытия я вижу светлое будущее, в котором профессия программиста последует в легенду, прямиком за профессией трубочиста. А я буду разводить пчел в деревне далеко от этой суетливой жизни и вспоминать эти дни с легкой грустью в области поясницы. Ну да ладно. Довольно иронии, поговорим более конкретно о документации.

Само по себе документирование кода – процесс непрерывный, который не останавливается ни на минуту, пока изменяется код и дышит программист =). Может быть, это звучит чересчур пафосоно, но дело обстоит так, что код и документация к нему – слишком связанные между собой вещи, чтобы можно было бы себе позволить работать с ними по отдельности. И если в прикладных программах зачастую встречается некий временной лаг в выпуске документации, который пытаются заполнить юзенетом и форумами поддржки, то для разного рода SDK, API, IOS-ов и систем с частыми и критическими обновлениями отсутствие или ляпы в документации могут стоить хороших денег.

Как и любая серьезная среда разработки, Delphi, помимо обычных комментариев, давно имеет встроенное средство автоматизированного документирования кода. Если быть точным, то их целых два! Разных. В первом случае можно поставить галочку «Generate XML Documentation» в опциях проекта, и помимо откомпилированных файлов мы получим ещё несколько XML файлов с документацией! Дальше можно делать с ними все, что заблагорассудится. Вот так вот по-спартанcки просто и красиво. Примечания, которые попадут в документацию, должны содержать три знака «деления» (по научному, три слэша ) и идти перед идентификатором. Но к сожалению, баги, как всегда, портят всю малину. Уже года два как Borland спешит исправить их в прекрасном встроенном средстве документирования кода, так что пользоваться внутренней генерилкой многим пока что-то неохота. Подробнее о проблемах можете почитать у коллеги

Второй способ предоставляет нам Тогезер. Это более мощное и тяжеловесное решение. О нем я уже упоминал в своих «сентенциях». Документация на выходе получается шибко навороченная, с диаграммами классов, деревьями и закладками. Проблема одна: хрупкость конструкции «модель – код», которую очень легко привести в нерабочее состояние шаловливыми ручонками, после чего модель и код живут сами по себе, а процедура синхронизации между ними способна уничтожить и то, и другое.

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

Pasdoc – калька Javadoc для Паскаля. Для тех, кто привык к Javadoc – это пожалуй, самое подходящее решение. Только мы же пишем на Паскале, поэтому хотелось бы воспользоваться теми особенностями, которые он предоставляет, а именно – разделение интефейса и реализации. Многие современные языки избавлены от этой заскорузлой традиции, берущей свои корни где-то в глубинах середины прошлого века. Встретить такой дотошный подход можно, пожалуй, что только в родственниках Паскаля – Модуле, Аде, PL/SQL и т.д. Основным неудобством здесь является дублирование информации, т.е. двойное описание процедур и методов, если они должны быть видны вне этого модуля. Поменял что-то в реализации - изволь править в интерфейсной секции и наоборот.

Многие «паскалисты» уже не помнят, что процедуры, функции и методы в Implementation – секции можно не описывать подробно. Достаточно указать название, но можно опустить все параметры и даже тип возвращаемого значения функции. Например, такой модуль замечательно откомпилируется, но жутко режет глаз (не только потому, что его тяжело отформатировать в этом блоге):

unit Unit1;

interface

uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls;

type
TForm1 = class(TForm)
Button1: TButton;
procedure Button1Click(Sender: TObject);
private
public
procedure MyTest(Num3: Integer);
end;

procedure Test(Num1: Integer);
function isTest(Num2: Integer): Boolean ;

var
Form1: TForm1;

implementation

{$R *.dfm}

function isTest;
begin
Result := Odd(Num2);
end;

procedure Test;
begin
Sleep(Num1);
end;

procedure TForm1.Button1Click;
begin
MyTest(1000);
end;

procedure TForm1.MyTest;
begin
Test(Num3);
isTest(Num3)
end;

end.

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

Раньше, когда в возможности редакторов входили только функции перевода каретки, двойная работа особенно тревожила начинающих программистов-максималистов, которые острее всего чувствуют, как плохо устроен этот мир. Сейчас, слава богу, появились технологии, которые позволяют синхронизировать код интерфейса и реализации практически бескровно, поэтому преимущества разделения выходят на первый план. Полистайте-ка описание какого-нибудь класса с десятью – пятнадцатью методами в той же Яве, да ещё с подробным описанием для Javadoc и сравните с объявлением в Delphi. Вы будете приятно удивлены конкретностью и лаконичностью последнего, помещающегося всего на одной страничке. Так вот, возвращаясь к Pasdoc, хотелось бы, чтобы в сей замечательной программе была предусмотрена возможность хранить комментарии и в теле методов. Во-первых, это добавило бы компактности интерфейсной части кода. А во вторых, решило бы проблемы разного рода генераторов и автоформаттеров кода, после работы которых комментарии начинают гулять по модулю, потеряв всякую привязанность к своим прародителям. В остальном, Pasdoc – готовое решение для создания неплохой документации.

Более дельфовым можно считать другой Opensource проект: DelphiCodeToDoc. Развивается он медленно, но верно, и за 4 года достиг версии 0.20 Beta! Смех смехом, но эта разработка умеет понимать комментарии в секции реализации и использует синтаксис JavaDoc. Кто привык к Inline комментариям, может воспользоваться ими. В целом, неплохая альтернатива PasDoc.

Небольшая, но платная программа Pascal Browser тоже может создать HTML документацию по вашему проекту. Штука предельно простая, комментарии берет как из интерфейсной части, так и из реализации. Основным её преимуществом, по-видимому, является то, что ключевым в названии Pascal Browser является слово Pascal. Следовательно, она для Паскаля самое что ни на есть родное решение. Не знаю, можно ли её рекомендовать для серьезных разработок, потому что никогда ей всерьез не пользовался. =) Но работает. По крайней мере, в песочнице.

Doc-o-matic. Посмотрев на это чудо, понимаешь, что будущее если не здесь, то уже где-то совсем близко. По крайней мере, я до этого не много встречал настолько демократичных и удобных программ по работе с исходными кодами. Ей совсем не важно наличие хитрых управляющих конструкций из загадочных звездочек, крышечек, закорючек, собачек и всего подобного перлового антуража, который приводит обычных людей если не в бешенство, то в легкий ступор. Если ваш исходный код имеет комментарии, и эти комментарии в нем расположены перед идентификаторами, то можете считать, что половина работы уже сделана. Надеюсь, что великий эстет в вас уже благополучно помер, поэтому останется только немного причесать внешний вид получаемого файла, добавив чуточку форматирования. Благо, оно практически не отражается на исходных комментариях, поскольку реализовано с помощью интуитивно понятных тегов. Результирующий хелп может быть представлен в различных форматах, среди которых обычный HTML, CHM, XML, PDF и старый добрый HLP. А как реализован QA менеджер для поиска недокументированных частей проекта! Это просто песня! (Похожую идею я наблюдал в SequoiaView шесть лет назад. И надо признаться, даже сейчас ей периодически пользуюсь, когда надо найти нечто большое, засирающее диск.)
Нельзя сказать, чтобы в Doc-o-matic не было глюков, но где их нет? Периодически всплывают проблемы с блуждающими комментариями, когда из-за редактирования исходного кода случается, что программа принимает описание одного идентификатора за другой. Есть закавыка с конкурентными изменениями исходного кода из Doc-o-matic и из другой программы. В этом случае программа не дает сохранить добавленные комментарии в код, ссылаясь на то, что код был изменен и требует ресинхронизировать файлы. В принципе, понятно и разумно, но очень неудобно. Самый же главный недостаток Doc-o-matic – это его цена. Правда, недавно вышла урезанная бесплатная версия – для личных нужд. Ну а целом, Doc-o-matic - решение зрелое и удобное. Джедаисты опять же давненько юзают. В общем, как говорится – «Выбор редакции» =).
В заключении хотелось бы отметить, что есть множество и других систем, неплохо зарекомендовавших себя в этом нелегком деле – документировании кода. Стоило бы, пожалуй, упомянуть и RoboDoc и XHelpGen из KOL. Но конечный выбор стоит всегда за командой разработчиков со своими традициями, наработками и решениями. Что-либо советовать в этом деле я считаю неуместным, так как наличие собственной головы приносит неоценимую пользу в жизни. Правда, не всем. И ещё грустно сознавать, что декларативные заявления небезызвестных компаний о том, что та или иная фича реализована в её продукте ещё не значат, что эта фича работает как надо. И это не касается только CodeGear. Это явление повсеместно. Помните, как в том анекдоте:
Секретарша шефу по мобильному:
- Вы по пути в офис? Осторожнее, по радио передали, что какой-то придурок едет по встречной полосе!
- Да он тут не один! Их тут ТЫСЯЧИ!
Пока в руках не повертишь, не поймешь – действительно ли дело обстоит так, как написано в глянцевом пресс-релизе. Наличие же стороннего ПО, аналогичного по функциональности, может быть сигналом: "Что-то не так в консерватории". Ведь, как известно, свято место пусто не бывает…