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

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

Сайт почти валяется - апологеты с открытыми ртами смотрят на мохнатого, волосатого Девида Интерсимона в пестрых рубашках, олицетворяющего собой протошамана Кодгира – этакую квинтэссенцию старой доброй гвардии, успеха и легендарности – все, что оказалось не нужно Борланду на нынешнем этапе его существования. Девид постарел, поседел, но всё ещё может быстро говорить и замечательно читает по бумажке =).
Итак, что интересного? Наконец-то удалось увидеть в действии класс-эксплорер. Похоже, кодгировцы решили отобрать хлеб у 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. Первые пять попыткок были неудачными. На очереди шестая. Ваши ставки?

Настройка путей 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 портит всю малину. Вот, собственно и все, о чем я хотел вам поведать.

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

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

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

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

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