BerndPol разработка &UNIX; программирование история языки сценариев &UNIX; история &UNIX; конфейер &UNIX; оболочка shell &UNIX; С самого начала, программы в &UNIX; разделились на два разных типа. Один тип — это мир языков программирования системы и приложений, где некоторый исходный код транслируется в машинный транслирующей программой, компилятором или интерпретатором. Примером является язык программирования C. &UNIX; была первой ОС, написанной на таком языке высокого уровня (относительно), вместо ассемблера, ориентированного на конкретную машину (на самом деле одним из изначальных назначений языка C было написание ядра &UNIX; и вспомогательных программ на машинах DEC PDP-11). Второй тип — это мир сценариев (скриптов). Он развился с приходом оболочки &UNIX; (shell), которая являлась интерфейсом пользователя к ОС — и в то же время языком программирования очень высокого уровня. Сценарии используют набор маленьких утилит, таких как grep, sed и find, каждая из которых создана для конкретной задачи. Хитрость заключается в том, что любая такая программа может быть соединена с другой посредством простого транспортного механизма, который называется конвейером, суть его заключается в том, что он перенаправляет вывод одной программы на ввод другой. Это есть основа многофункциональности и гибкости инструмента. С течением времени, оба мира бурно развивались. Язык C до сих пор используется преимущественно в качестве системного язык программирования, тогда как C++ — дальнейшее развитие C, воплощающее объектно-ориентированную модель программирования, — с начала 90-ых используется при программировании сложных структурированных систем. Кроме того, осталась поддержка многих других языков программирования, даже таких, как FORTRAN77 и Ada, которые всё ещё используются в некоторых областях. Ну, а в мире сценариев произошла перестановка, от оболочки, недостатком которой было отсутствие полной переносимости, до языков, которые унифицируют всю общую необходимую функциональность в своих стандартных библиотеках, оставляя возможность прибегать к конвейерному механизму. Общее всех этих сценарных языков — их переносимость между клонами &UNIX;, Microsoft &Windows;, &MacOS;, или даже VMS. Также, для всех их доступны свободно распространяемые реализации. Perl языки сценариев Perl &perl; популярен как язык обработки текста и, следовательно, системного администрирования. На заре World Wide Web, CGI-скрипты на &perl; использовались для генерирования динамических web-страниц на основе базы данных. Сегодня такой метод реализован в виде модуля mod_perl web-сервера &apache;. Среди сильных сторон &perl;'а — его встроенная поддержка расширенных регулярных выражений и богатый архив свободных модулей к нему, для подробностей см.: Comprehensive Perl Archive Network (CPAN). Python языки сценариев Python &python; отличается элегантностью классовой системы, лёгкостью и гибкостью, с которой можно внешние библиотеки могут быть подключены — к ним можно обращаться как к стандартным классам и функциям &python;. В отличие от &perl;, &python; имеет прозрачный и сконцентрированный встроенный &API;, что делает его прекрасным средством поддержки сценариев для программ, написанных на C и C++, . PHP языки сценариев PHP &php; встраивается прямо в &HTML;-страницы, и, следовательно, применяется для генерирования динамических web-страниц. Высокоуровневые приложения обычно более медлительные и не так гибки в применении. Это проявляется в мире программ с графическим пользовательским интерфейсом (GUI), таких как &kde;. Потребность в некоем подобии конвейеров низкоуровневых консольных программ для высокоуровневых приложений привела к появлению CORBA и, позже в среде &kde;, &DCOP;. CORBA языки сценариев CORBA связь CORBA CORBA (Common Object Request Broker Architecture) - это механизм, позволяющий разным программам работать совместно через сеть. Он разработан комитетом стандартов OMG (Object Management Group). Программы, поддерживающие CORBA, используют протокол IIOP для связи. Реализации, основанные на IIOP, есть для многих операционных систем, языков программирования, и сетей, что делает его хорошо переносимым. Основной недостаток CORBA - это его очень низкая скорость. Возможно это не так существенно. в сетях с мощными серверами, но на обычных компьютерах, для которых предназначен &kde;, это является главным. DCOP языки сценариев DCOP связь DCOP Протокол DCOP разработан для связи и более тесной интеграции между приложениями &kde;, т.к. использование медленного CORBA, имеющего ряд ограничений, привело бы к всеобщей "неподъёмности" &kde; на обычных компьютерах. &DCOP; расшифровывается как Desktop COmmuniсation Protocol (протокол связи рабочих станций). Он реализован как простой механизм IPC/RPC, построенный для оперирования сокетами. Словом, он обеспечивает удобства схожие с традиционным конвейерным механизмом &UNIX;. Традиционные сценарии основываются на очень маленьких программах, которые были созданы для работы на строго текстовой основе. &DCOP; позволяет графическим программам связываться между собой схожим путём. Т.е. одна &kde;-программа может посылать сообщения другой (возможно своей копии), и сама получать и обрабатывать данные от неё. Однако у такого метода всё же есть и недостатки — для использования &DCOP; в программу нужно встроить специальный код интерфейса &DCOP;. Кроме того, связь происходит несколько медленно (но значительно быстрее CORBA), хотя, в свою очередь, она даёт мощь и гибкость сценариев &UNIX; высокоуровневым программам с графическим пользовательским интерфейсом. Для подробностей см. DCOP: Desktop COmmunications Protocol или &API;-справочник библиотеки &DCOP;. Кроме самых простых случаев, ваш проект будет состоять из множества блоков исходного кода, разделённых по нескольким файлам для удобства сопровождения. Для преобразования исходного кода в машинный, нужно транслировать всё это в несколько машинных модулей в удобном для чтения операционной системой формате. Для этого как минимум требуется текстовый редактор — для написания исходного кода, транслирующая программа, обычно это компилятор, — для преобразования исходного кода в объектные файлы, библиотекарь — для сборки объектных файлов в библиотеки для последующего их использования без необходимости перекомпилирования, компоновщик — связки нескольких объектных файлов и библиотек в один исполнимый файл, система сборки, претендующая на управление всем этим "добром", и отладчик — чтобы найти (надеемся) все ошибки в исходных кодах, и, возможно, другие диагностические утилиты для последующей оптимизации кода. Когда у вас имеется большой проект, состоящий из возможно сотен исходных файлов, процесс компиляции может быть медлительным. Не нужно компилировать заново все файлы когда был изменён только один, вместо этого следует компилировать файлы, которые были затронуты изменениями. На самом деле это не так очевидно, как кажется на первый взгляд. Например, если вы изменили прототип функции в заголовке, нужно перекомпилировать каждый файл, включающий этот заголовок. И если в проекте таких файлов много, легко пропустить один делая это вручную. Сборочная система обеспечивает автоматизацию такой работы. make Makefile правило перекомпиляция target (целевой) зависимости команды Инструмент, выполняющий перекомпиляцию называется make. Его работа управляется специальными правилами, которые описывают необходимые действия в случае изменения определённой информации (обычно объектного файла или файла исходного кода). Все правила, принадлежащие определённому проекту записываются в т.н. Makefile, который обрабатывается командой make в любое время когда вы хотите обновить вашу работу. Каждое правило состоит из нескольких сборочных блоков, а именно целевого(target), т.е. файла, который нужно собрать набора зависимостей, обычно это имена файлов, от которых зависит целевой (target), например это может быть имя исходного файла, где целевой будет упомянут как объектный, команд, которые выполняются для сборки целевого файла (например его компиляции или компоновки нескольких объектных файлов). Обычно команда make читает правила, одно за другим, проверяет каждый файл из списка зависимостей конечного файла и собирает его заново если хотя бы один файл из списка зависимостей был изменён. В больших проектах Makefile может стать очень большим и сложным. Мы не можем здесь углубляться в подробности, однако рекомендуем вам изучить хотя бы основы синтаксиса make. Даже если вы не используете его напрямую, понимание принципов системы сборки вам должно пригодиться. Для подробностей см. GNU Make Manual. Для подробностей, касающихся &tdevelop;, см. главу Сборка и управление проектом. Доступно несколько руководств, см. в главе Сборка и управление проектом. GUI графический пользовательский интерфейс пользовательский интерфейс GUI Разработчики программного обеспечения вынуждены создавать не только библиотеки и алгоритмы, но и удобный пользовательский интерфейс, гибкий и интуитивный. Однако большинство программистов не удаляют этому большого внимания, и, как результат, хорошие программы имеют бедный дизайн. На протяжении годов, были выработаны некоторые общие принципы реализации интерфейса. Настоятельно рекомендуется придерживаться их. Таким образом ваши пользовательские интерфейсы будут сохранять общий вид и интуитивность, что непременно будет оценено пользователями. Визуальная разработка &kde; также имеет свои принципы. Их можно найти на странице принципов дизайна пользовательского интерфейса в уголке разработчика &kde;. Краткое введение в дизайн графического пользовательского интерфейса можно найти здесь, либо здесь (больший уклон в сторону умирающей ОС). IDE интегрированная среда разработки разработка IDE окружение IDE Для каждого этапа процесса программирования существует множество отдельных инструментов — планирование, редактирование, управление файлами и компилирование (сборка), отладка, документирование и т.д. Однако по мере роста проекта, он (почти всегда) становится громоздким, и процесс его дальнейшего программирования становится затруднительным. Наиболее повторяющаяся работа проделывается при проектировании, компилировании и отладке программы. Большую часть такой работы можно автоматизировать используя шаблоны и сценарии. Другую большую часть — наличием инструментов. способных связываться один с другим через общий визуальный интерфейс (GUI). К примеру, действительно удобно, когда отладчик может открыть исходный код в редакторе и расположить курсор в месте, где произошла ошибка. Такую схему совершенствуют интегрированные среды разработки (&IDE;). Они собирают воедино все шаблоны, инструменты и сценарии, необходимые для продуктивного процесса разработки. Для всевозрастающей платформы &kde; таким &IDE; является &tdevelop;. Эта среда разработки содержит широкий набор инструментов, обеспечивая простое окружение разработки и сопровождения ПО, использующего разные языки программирования и платформы. &tdevelop; возможности возможности Управление всеми средствами разработки на языке C++, такими как компилятор, компоновщик, отладчик и система сборки Мастер приложений, упрощающий создание новых программ Интегрированный редактор, основанный на редакторе &kwrite;, QEditor от Trolltec или другой. Генератор классов, для создания новых классов и интегрирования их в проект Управление исходными, заголовочными файлами, документацией и т.д. Помощь при написании руководства приложения средствами &kde; Автоматическое генерирование &API;-документации в формате &HTML;, включающей описания классов проекта и перечня используемых библиотек Поддержка интернационализации, &kbabel; Поддержка управления проектом через систему управления версиями (например, &CVS;) Встроенный интерфейс к отладчику. Встроенный эмулятор консоли. Синтаксическая подсветка в файлах исходного кода. Автодополнение кода для переменных класса, его методов, аргументов функций и т.п. Шаблоны для конкретных задач (написание модулей &kcontrol;, &konqueror;, апплетов &kicker;, TDEIO, а также стилей рабочего стола) Четыре дерева информации, для наглядного разделения исходных, заголовочных файлов, классов и документации, что позволяет отказаться от внешнего проводника Кросс-компилирование, с возможностью указания разных компиляторов, их ключей, архитектуры процессора и т.п. Поддержка проектов Qt/Embedded (таких как Zaurus и iPAQ). Простота использования внешних программ, в виде добавления их в меню Сервис.