Девелопмент тулз

Архив

Окончание. Начало в #327

А в это время в Linux...

При оценке средств разработки для Linux нельзя исходить из критериев, которые приходят на ум в отношении Windows-средств разработки. Так, компилятор здесь не привязан (и не может быть привязан) к IDE. При создании программ для Linux можно обойтись простейшим текстовым редактором, компилятором egcs (или gcc, но он "старше") и головным мозгом. Но можно и не обходиться. Средства RAD-разработки пока находятся в зачаточном состоянии. Компания Inprise обещала выпустить Kylix [1] (Delphi для Linux), есть ранняя alpha-версия VDK Builder - C++ Builder-подобной среды, основанной на библиотеке VDK (которая является настройкой над gtk+), есть QtEz, но его при всем желании RAD-средством назвать трудно. Кроме того, широко используется Glade - генератор GUI, дающий на выходе готовый код gtk+ (к сожалению, C, а не C++). Однако "настоящие индейцы" пользуются либо vi/autoconf/automake/gdb/egcs/rcs/cvs, либо тем же самым набором, но вместо vi используют EMACS. Отдельно стоит упомянуть autoconf/automake. Это средство, позволяющее сгенерировать файлы сборки (makefiles) конкретно для ваших платформы, машины, операционной системы и компилятора. Одно лишь использование autoconf/automake, конечно, не гарантирует переносимости программы, но сильно облегчает жизнь тем, кто все-таки решит воспользоваться вашим гениальным творением. В идеале компиляция программы для Linux состоит из трех шагов. Если записать в три строчки, это выглядит так:

./configure
make
make install

К сожалению, так бывает не всегда, хотя и довольно часто. И уж совсем редко руки у разработчиков программ для Linux доходят до такой вещи, как make uninstall. А зря. Именно трудности с удалением инсталлированных программ зачастую мешают новичкам экспериментировать с open source программами. Отличие Linux (да и любой Unix) в том, что разработка в ней не замкнута на какой-либо конкретный язык программирования. Вы можете программировать на десятках (sic!) языков и решать задачи одинаково хорошо на каждом из них, пусть и с разной скоростью. В Windows все, как правило, сводится либо к C++, либо к Object Pascal. Здесь же выбор куда богаче. Фактически для Unix доступны компиляторы/интерпретаторы всех языков программирования, когда-либо созданных человеком (кроме, пожалуй, Visual Basic). Существует также достаточно много разных свободных библиотек для решения практически любых задач. Трудно найти такую задачу, для которой уже не было бы написано хотя бы пары библиотек. Об их качестве умолчим, ибо проблема эта неоднозначная (it is good for the price, как говорят англичане) - встречаются как шедевры, так и откровенная халтура. Причем последнего, как и везде, больше. Если абстрагироваться от библиотек, инкапсулирующих/дополняющих сервисы системы, и переместиться поближе к пользователю, то есть в область графических интерфейсов, то тут также разнообразие. Есть как полностью свободные, но, IMHO, "трудные" (что вовсе не означает "плохие") решения вроде gtk+, так и коммерческие, более простые в программировании, - Qt. Кроме названных двух, доминирующих, есть еще как минимум десяток разных библиотек для реализации GUI. Выбор, конечно, хорошо. Но есть и "плохая" сторона. Так, например, я не исключаю возможности, когда на вашей машине будут работать одновременно 4-5 разных GUI-библиотек. Все они будут занимать отдельные (и, как правило, не маленькие) участки памяти. Однако это уже лирическое отступление.

Для тех разработчиков, кто хочет попробовать свои силы в Linux, но, не считая себя "настоящим индейцем", желает работать хотя бы с минимальным комфортом, есть минимум три бесплатные альтернативы. Это Code Crusader, KDevelop и KDE Studio. Первая использует собственную GUI-библиотеку (но не принуждает вас пользоваться ею при разработке своих приложений), последние две привязаны к Qt/KDE.

Code Crusader

Не совсем полная калька с Code Warrior (который для Linux тоже доступен, но за деньги). Перечисление всего, что он позволяет делать, заняло бы слишком много места, поэтому перечислю лишь главное. Бесплатен. Сам генерирует makefile, причем автоматически пересобирает библиотеки, являющиеся субпроектами главного проекта, от которых он зависит. Работает практически с любым компилятором. Позволяет использовать все средства make, причем сборка программ идет в отдельном потоке, так что можно не прекращать редактирование кода. Имеет интегрированный отладчик CodeMedic. Понимает консольные сообщения об ошибках из make и девять разных компиляторов (то есть позволяет перейти сразу к тому месту в коде программы, где обнаружена ошибка). Похожий на гипертекст интерфейс к man [2], позволяющий получать справку по функциям прямо из исходного текста. Графическое отображение диаграмм наследования с поисковыми функциями и возможностями PostScript/EPS-печати. Полноценный редактор исходного кода, с макроподстановками, функциями поиска и подсветкой синтаксиса, автоотступом и пр. Имеется также возможность использовать другой (не встроенный) текстовый редактор (например, EMACS или vi). Конфигурируемые панели инструментов. API для подключения не поддерживаемых по умолчанию языков. Ну и на закуску - прокрутка колесом IntelliMouse. Среда производит очень хорошее впечатление и к тому же не вынуждает вас использовать какую-либо конкретную библиотеку.

KDevelop

Внешне очень похож на Visual C++. Есть даже браузер классов. IntelliSense, конечно, отсутствует, но направление взято верное, и я не исключаю, что средства, аналогичные IntelliSense появятся в одной из последующих версий. Главный недостаток - среда целиком и полностью "заточена" под Qt/KDE. Таким образом, чтобы создавать коммерческие приложения, вам придется заплатить приличную сумму Troll Tech. Можно, однако, создавать консольные приложения: в этом случае лицензионных отчислений не требуется.

KDevelop имеет довольно удобный (даже для человека, избалованного "излишествами" Windows) интерфейс. Генерируемые проекты совместимы с autoconf/automake. Содержит редактор диалогов, причем IDE можно указать - генерировать ли код сразу или просто загрузить диалог из файла диалога во время выполнения. Есть очень похожий на MS VC++ браузер классов, поддерживающий вложенные классы, структуры внутри классов и операторы. Есть похожие на те, что реализованы в MS VC, мастера приложений (поддерживаемые типы скелетных приложений - приложения KDE, Qt и консольные). Кроме того, в KDevelop включены: удобный браузер документации, текстовый редактор с подсветкой синтаксиса, генератор классов, интегрированный отладчик [3]. Эта IDE развивается быстрее всех, но в настоящее время производит впечатление менее проработанной и стабильной (хотя и более удобной), нежели Code Crusader.

KDE Studio

Эта среда пока находится в бета-стадии, но ее успешное будущее не вызывает сомнений. А вот GPL'ное - вызывает... Создали KDE Studio, судя по всему, наши соотечественники [4]. Она появилась недавно, в июле этого года, но выглядит очень и очень профессионально и грамотно сделанной. Скриншоты можно посмотреть на www.softarc.com/~msharkey/kdestudio/screenshot.html. Последние нововведения делают из этой среды нечто похожее на коктейль из Builder и MS VC, причем из обеих взято только самое лучшее и нужное. Среда для истинных сибаритов. Стыкуемые окна, браузер классов и файлов, средства проектирования диалогов, очень похожие на эталон от Borland, подсветка синтаксиса, менеджер проектов, меню по правой кнопке мыши везде, эргономика - все на высоте. Да и потом, это просто красиво, тут явно поработал дизайнер. Тестовый проект, созданный мышью, однако не заработал, потому что не компилировался. Будем надеяться, что это недостаток не KDE Studio, а меня, как "не линуксоида", не уловившего всех тонкостей работы с продуктом. А если проблема и не во мне, то, надеюсь, она временная.

Впрочем, стоит заметить, что и здесь существует альтернатива в лице вышеупомянутого VDK Builder [5]. Эта среда уже дошла до версии 1.0.3. Однако памятуя о скорости разработки в проектах, взявших за основу что-либо отличное от Qt, я не стал бы пророчить этой системе большого будущего. Хотя кто знает?..

Любителям кофе

Несмотря на то что Java-технологии все еще довольно незрелы, неуклюжи и в России очень редко используются, нельзя оставить без внимания детище столь напористой компании, как Sun Microsystems. То, что Java все еще не умерла, трудно объяснить чем-либо, кроме феноменальной напористости ее создателя. В самом деле, ну кто еще мог себе позволить делать коренные изменения в библиотеке разработчика (JDK) при выпуске каждой новой версии? Кто еще может себе позволить предлагать платформу, столь неэкономно относящуюся к оперативной памяти и ресурсам процессора, в качестве основы для embedded applications? И это лишь самые, на мой взгляд, абсурдные вещи, встреченные IT-менеджерами (но, конечно, не разработчиками) с непонятным энтузиазмом. Обидно также, что Java помешала гораздо лучшему идеологически проекту Juice/Oberon [6]. Ну да не будем о грустном.

В целом преимущества Java известны: независимость от платформы (не для Visual J++), безопасность, легкость интеграции в Internet/intranet, относительная универсальность, простота, потенциально высокая степень повторного использования кода, высокая (в сравнении с другими интерпретаторами) скорость исполнения байт-кода программ. К тому же автоматическая "сборка мусора", дающая возможность не озадачивать себя удалением объектов, и отсутствие указателей позволяют еще на этапе кодирования избежать многих неприятных и труднообнаруживаемых ошибок.

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

Рынок средств разработки для Java делят между собой главным образом "борцы-тяжеловесы": Sun, IBM, Symantec, Microsoft и Inprise, причем Sun, как ни странно, не контролирует большей его части. Если исключить ее из этого списка, остальные компании на сегодняшний день предлагают соответственно: Visual Age for Java 3.0, Visual Cafe, Microsoft Visual J++ 6.0, Inprise JBuilder 3.0. Опробованные мною последние две среды я и рассмотрю ниже.

Microsoft Visual J++...

...Или как сделать из Java Visual Basic. Именно так и никак иначе можно было начать этот абзац. Ниже станет ясно почему. Пусть вас не введет в заблуждение 6-й номер версии продукта, это вовсе не означает, что до него было пять версий (предыдущая - 1.1). Среда разработки покажется очень и очень знакомой разработчикам Visual Basic. Присутствует классический набор средств: IntelliSense, визуальная генерация кода, компонентная разработка, редактор свойств объектов; везде, где только возможно, drag'n'drop, cut'n'paste, point'n'click... Одним словом, среда разработки сделана на уровне, и придраться практически не к чему.

Однако картину портят два существенных недостатка. Первый: возможности Visual J++ как Java-средства весьма ограничены по той простой причине, что среда использует библиотеку WFC (Windows Foundation Classes), тесно привязанную к Windows, что в корне противоречит идеологии Java: "build once, run anywhere". Вы, конечно, можете использовать JDK 1.1, но возможности среды в этом случае уже отнюдь не впечатляют. В VJ++ нет (и, похоже, не предвидится) поддержки JavaBeans - второй громадный минус, так как JavaBeans является стандартом визуального Java-программирования. Однако надо признать, что для Windows она подходит как нельзя лучше. Так, например, VJ++ позволяет писать полноценные ActiveX-элементы управления, что дает возможность использовать их в Visual Basic, Visual C++, Delphi, C++ Builder. Кроме того, поддерживается технология J/Direct, позволяющая использовать ActiveX/COM-компоненты в Java-приложениях и получать полный доступ к Windows-specific функциям. На столь мощном фундаменте нетрудно было реализовать все остальное, чем балует Java-разработчиков Microsoft, а именно: доступ к ADO [7] версии 2.0 (вместо стандартного JDBC), конверсию JavaBeans в ActiveX-компоненты, классы поддержки DHTML, довольно большой выбор компонентов, визуальные средства работы с базами данных и т. п.

Если вы планируете разрабатывать Java приложения исключительно для Windows либо писать на Java ActiveX/COM-объекты, альтернативы Visual J++ у вас нет, так как на сегодняшний день не существует Java-библиотек, инкапсулирующих Windows-API, а WFC ускоряет выполнение Java-приложений примерно вдвое.

JBuilder

Очень и очень "правильная" среда, выдержанная в духе Delphi/Builder, но при этом написанная на чистом Java. Удобный и мощный продукт от Inprise полностью поддерживает Java2, JavaBeans, JFC/Swing, AWT, JDBC, CORBA и RMI. Приложения, создаваемые с помощью JBuilder, работают (по крайней мере, должны) на любой платформе, поддерживающей Java. К сожалению, сам JBuilder пока работает только на двух: Solaris и Windows, хотя в начале будущего года обещан выход версии для Linux.

О том, что Java созрела для серьезных приложений, говорит уже то, что традиционно для Inprise среда JBuilder написана с использованием себя самой. Она полностью компонентна и визуальна, поддерживает традиционные для Borland two-way-средства (изменения в коде отображаются в форме и наоборот), браузер классов, менеджер проектов, гипертекстовую навигацию в исходном коде, автозавершение и прочие приятные мелочи, знакомые пользователям Builder/Delphi. Компилятор, поставляемый в комплекте, поддерживает JDK 1.2; кроме того, JBuilder позволяет подключать другие компиляторы и виртуальные машины Java, например, от Sun или Microsoft. Встроен неплохой отладчик, позволяющий отлаживать компоненты, апплеты и сервлеты. Есть поддержка удаленной отладки, причем ваше приложение может работать, скажем, под Solaris, а вы - под Windows. Есть довольно удобные средства создания приложений для работы с базами данных (Data Modeler, SQL Explorer, SQL Builder, встраиваемая транзакционная БД JDataStore) и распределенных приложений с использованием CORBA. Для облегчения разработки последних имеется встроенный IDL-компилятор, взаимодействие с репозиторием интерфейсов и возможность управления ORB-соединениями. Имеется хелп с полнотекстовым поиском и OpenTools API, позволяющий писать модули, расширяющие возможности среды.

Нельзя оставить без внимания один большой недостаток JBuilder: программа очень требовательна к аппаратным ресурсам компьютера. И если для рабочей станции Sun это некритично, то мой двухпроцессорный Pentium II 350 со 128 Мбайт памяти периодически захлебывается в свопинге. Inprise, несомненно, стоит снизить "прожорливость" JBuilder.

Заключение

Нельзя объять необъятное. За рамками статьи остались коммерческие средства разработки для Linux (я, по понятным причинам, не имел возможности с ними поработать), средства разработки на других языках, нежели С/C++, Object Pascal и Java, и средства контроля версий (TeamSource в Delphi, SourceSafe в MS VC, rcs/cvs и прочие, имя им - легион, в Linux). Не упомянуты и "более традиционные" для Unix/Linux средства разработки, такие как редакторы EMACS и vi, консольный отладчик gdb и средство автоматизации сборки make (а также autoconf/automake), что, я думаю, вполне простительно, так как предметом статьи явились "ярко выраженные" IDE, которые специально создавались, чтобы облегчить жизнь разработчикам. Я старался не концентрировать внимание на преимуществах и недостатках тех или иных ОС, понимая в то же время, что методология программирования, предлагаемая KDevelop и KDE Studio, во многом навеяна Windows way, и в данном контексте состоит в том, что GUI и функциональность интегрируются в один исполняемый файл, а также в отказе от GUI wrapper'ов консольных приложений. Плохо это или хорошо, пусть каждый решает для себя сам. Буду рад критическим отзывам читателей.

---

1 (обратно к тексту) - У меня вызывает большие сомнения, что Unix-программисты встретят Kylix с пониманием. В Unix до сих пор безраздельно царит C, и предпосылок к изменению ситуации пока не видно.

2 (обратно к тексту) - От "manual".

3 (обратно к тексту) - Kdbg.

4 (обратно к тексту) - Если судить по файлу Authors, то автор - Макс Юдин.

5 (обратно к тексту) - Заинтересовавшихся отправляю к первоисточникам. См. страницу проекта: www.programmers.net/artic/Motta/vdkbuilder.

6 (обратно к тексту) - См. http://caesar.ics.uci.edu/juice.

7 (обратно к тексту) - ActiveX Data Objects - новый основанный на COM стандарт взаимодействия с базами данных.