Единое окно доступа к образовательным ресурсам

Первая международная конференция разработчиков свободных программ на Протве: Тезисы докладов

Голосов: 0

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

Приведенный ниже текст получен путем автоматического извлечения из оригинального PDF-документа и предназначен для предварительного просмотра.
Изображения (картинки, формулы, графики) отсутствуют.
                      Дневное заседание
                           12:00–14:15

    Секция 1
    (Председатель — Станислав Иевлев)



12:00–12:25
Алексей Воинов                                        Москва, ALT Linux
Проект: WindowMaker

 Состояние разработки проекта WindowMaker

    Аннотация:
    В последнее время у многих могло сложиться впечатление о том, что
    проект WindowMaker заброшен и больше не развивается. На самом
    деле это не так. В докладе описывается текущее состояние проекта,
    а также планы обновлённой команды разработчиков.

    WindowMaker — популярный менеджер окон для X11. Проект был
начат Альфредо Койма в 1997 году сразу после выхода AfterStep 1.0,
и предлагался в качестве одного из путей развития AfterStep. Однако,
остальные разработчики не поддержали Альфредо.
    К 2001 году вокруг проекта сложилась любопытная ситуация. В
проекте выделилось «узкое» место — Дэн Паску. Из-за того, что он не
доверял ничьему коду, он переписывал все присылаемые ему патчи, ис-
пользуя оригинал только как идею. Со временем он просто перестал
успевать обрабатывать весь присылаемый ему материал. Если учесть
возросшую занятость в «реальной жизни» у обоих программистов про-
екта, становится понятно, что развитие проекта начало замедлятся уже
давно. Стороннему наблюдателю это стало заметно значительно позже.
В конце 2002 года была выпущена последняя версия WindowMaker. К
середине 2003 изменения в cvs практически прекратились.
    На самом деле, основная работа окончательно переместилась туда,
где ей всегда уделялось больше времени: к создателям патчей. Как
это ни удивительно, несмотря на почти гарантированное непопадание

                                   51


исправления в основную ветку проекта, люди продолжали их делать.
Если собрать все патчи, включая те, которые были созданы уже после
прекращения изменений в проекте, то получится вполне современный
менеджер окон. В настоящее время в пакете WindowMaker, который
попадает в Sisyphus используется 36 патчей от разных разработчиков.
    В декабре 2003 года я рассказывал о патчах для WindowMaker и
об их создателях на виртуальной конференции Umeet. Я говорил, что
наличие патчей — это очень хорошо, поскольку майнтейнер проекта мо-
жет вовсе не желать поддерживать чей-то чужой код. Однако «простые»
пользователи могут при желании получить нужную им функциональ-
ность, общаясь только с создателем патча. При этом все остаются до-
вольны: майнтейнер проекта доволен, потому что ему не добавляется
лишней работы, автор патча доволен, потому что его работа заметна
и не тонет в тысячах строк основного проекта. В этом смысле, проект
WindowMaker, пожалуй, уникален. Я не встречал больше нигде пат-
чей, не вошедших в основную ветку, которые бы распространялись в
официальном тарболе.
    Наличие большого количества патчей от разных разработчиков
усложняет работу тем, кто хочет применить их все. Обновление пат-
чей — серьёзная задача, требующая много времени.
    В начале 2004 года на irc-канале #windowmaker выделилась груп-
па разработчиков, желающих нормального развития проекта. Был со-
здан репозиторий, в котором началась работа по созданию нового окон-
ного менеджера на базе существующего кода WindowMaker. Приблизи-
тельно через неделю после начала работы старая команда разработчи-
ков WindowMaker была поставлена в известность о новом проекте. В
результате длинного разговора было решено новый проект не создавать,
а продолжить разработку WindowMaker силами обновлённой команды.
    Разработка патчей, на самом деле, накладывает значительные огра-
ничения на тех, кто их пишет. Мало кто будет озабочен прикладыва-
нием к своей версии программы патча, который не добавляет какого-то
заметного изменения. Это обстоятельство не способствует улучшению
качества кода основной версии, если за этим не следит майнтейнер.
Именно поэтому первоочередной задачей новой команды стала чистка
кода.
    Другие (сформулированные) задачи включают:
   • адаптацию и интеграцию уже разработанных патчей в основную
     ветвь проекта;



                                52


   • поддержку динамической загрузки модулей, добавляющих новые
     возможности;
   • улучшение интерфейса пользователя, включая все диалоговые
     окна и программу конфигурирования.
    Адаптация патчей необходима, потому что многие из них разрабо-
таны так, чтобы вносить минимум исправлений в существующий исход-
ный код, а это далеко не всегда приводит к лучшим решениям. Разде-
ление на модули позволит сделать WindowMaker намного более гибким
и позволит изменять набор возможностей во время работы без пере-
компиляции. Сейчас, например, есть вариант компиляции lite, который
отключает довольно много кода, но это невозможно изменить во время
работы. У существующего интерфейса есть масса недостатков. Напри-
мер, при запуске WindowMaker с переводом некоторые переведённые
надписи не умещаются в отведённых им позициях.
    Важно, чтобы отношения новой команды с пользователями скла-
дывались не хуже, чем у старой команды. Пока это удаётся, но прошло
ещё слишком мало времени, чтобы говорить наверняка. Нам ещё не
присылали новых патчей, мы ещё не выпустили ни одной новой версии.
Версии WindowMaker из новой ветви начнут выходить только после
того, как будет выпущена версия 1.0.



12:25–12:50
Денис Слюсарев                                      Москва, ainmarh lab
Проект: QPLATFORM

                   Основы QPLATFORM
    Аннотация:
    QPLATFORM — это комплекс программных средств для разработки
    CGI(fastcgi)-приложений, рассчитанных на высокую нагрузку. Глав-
    ными достоинствами проекта являются: язык разработки — C, встра-
    иваемые в бинарный код программы html-шаблоны, динамическое кэ-
    ширование контента (с вероятностью попадания в кэш около 90% при
    типичных задачах) и система управления пользовательскими сессия-
    ми.

    В комплекс входят:

                                  53


  • FastCGI система организации работы CGI-приложений, как
    отдельных программ (демонов/сервисов), которые после запуска
    постоянно находятся в памяти и обрабатывают приходящие к
    ним от web-сервера запросы.
  • QTP (или Q-Lang) препроцессор шаблонов, рассчитанных на
    высокую нагрузку и оптимизированных для встраивания
    непосредственно в код программы.
  • CGIX — модифицированная версия CGIC, оптимизированная для
    работы с FastCGI и QTP (или Q-Lang).
  • QCM — система динамического кэширования.
  • QSM — система контроля пользовательских сессий.
  • QDBC — система, унифицирующая работу с базами данных (в
    данный момент находится в стадии разработки).

   Преимущества использования QPLATFORM:

  • Высокая скорость работы приложений.
  • Наличие необходимого инструментария для быстрого построения
    cgi-приложений.
  • Возможность post-кэширования обработанных запросов.
  • Возможность автоматического динамического кэширования
    (libqcm).
  • Возможность получения «Content-Length» для результата работы,
    а, следовательно, возможность использования http-акселераторов
    на полную мощность.
  • Система QSM (session manager) позволяет с помощью сессий
    решать проблемы безопасности.

    Основной причиной появления проекта QPLATFORM является от-
сутствие на данный момент инструментария для создания в короткие
сроки быстрых cgi-приложений на языке C. Существует достаточно
большое количество шаблонных библиотек, XML/XSL-процессоров, ко-
торые являются очень громоздкими и непроизводительными. Так, при
создании даже небольших проектов программисты сталкиваются со

                               54


сложной дилеммой: если выбрать интерпретируемый язык как платфор-
му для создания web-приложений, то при возрастании уровня посещае-
мости появятся проблемы с производительностью; при выборе же ком-
пилируемого языка разработка займёт очень много времени, которое,
возможно, будет потрачено даром, если проект не будет иметь успеха.
Компромисса не существует, поэтому приходится жертвовать либо од-
ним, либо другим. А QPLATFORM можно рассматривать как золотую
середину: длительность разработки не больше, чем при разработке на
PHP, однако скорость выше, чем при создании приложения с использо-
ванием большинства существующих библиотек для C.
    Существует несколько причин низкой производительности совре-
менных web-приложений. Самое главное — это база данных (будь то
MySQL, PostgreSQL, или даже Oracle), которая занимает большую
часть ресурсов сервера. Вторая причина — использование интерпрети-
руемого языка (PHP, Perl, Python и др.), И третья — низкая скорость
работы самой системы, например, запуск приложения при каждом за-
просе (если мы избрали путь CGI).
    Обойти все эти проблемы или свести их долю к минимуму можно
следующим образом.

  1. Чтобы избежать чрезмерного использования базы данных, нужно
     кэшировать контент, который сохраняет своё наполнение между
     изменениями, то есть построить правила, определяющие
     принадлежность, наличие и устаревание кэша для конкретной
     страницы. QCM (QPLATFORM Cache Manager) позволяет
     делать это посредством определения префикса и имён
     GET/POST полей, по значениям которых будет определяться
     местоположение данной страницы в иерархии кэша; а также с
     помощью определения имени тестера (timestamp), позволяющего
     разбить кэш на группы, чтобы при внесении изменений в
     какую-то конкретную группу можно было объявить кэш этой
     группы устаревшим.
     Единственное ограничение, с которым сталкивается разработчик
     приложения QPLATFORM, — это невозможность кэшировать
     страницы, показываемые залогиненным пользователям (т. к.
     кэширование производится для всей страницы целиком);
     конечно, если не используются html-frame’ы или не задействован
     механизм обновления данных через JavaScript, то есть чтобы
     страница целиком оставалась одна и та же. Но это ограничение
     мы планируем в ближайших версиях обойти.

                                55


  2. Использование языка С позволяет достичь максимальной
     скорости обработки данных.
  3. В случае с QTP приложение запускается только в самом начале,
     а не для каждого запроса заново, и обрабатываются запросы в
     бесконечном цикле. Чтобы не тратить время на парсинг
     шаблонов, превратим, используя QTP (QPLATFORM Template
     Preprocessor), .html-шаблон в обычную программу на C и,
     согласно правилам QPLATFORM, опишем call-back процедуры
     для заполнения шаблона данными. При правильном построении
     QTP шаблонов можно добиться полной независимости друг от
     друга дизайна и сgi-приложения. QSM (QPLATFORM Session
     Manager) позволяет хранить сессии пользователей в Shared
     Memory, что также ускоряет работу web-приложения.

     И, наконец, рассмотрим то, что волнует менеджеров, которые явно
не хотят долгое время платить программистам и не видеть результа-
тов, — скорость разработки. Стандартное web-приложение должно:

  1. Получить данные из базы.
  2. Произвести некие преобразования данных.
  3. Вывести данные на страницу.
  4. Иметь возможность взаимодействовать с системой.

    Для этого как раз и создавалась система QPLATFORM. Она поз-
воляет:

  1. Получить данные из базы через QDBC (QPLATFORM DataBase
     Connector), воспользовавшись удобным унифицированным
     интерфейсом.
  2. Произвести над данными преобразования посредством языка C.
     Описать правила кэширования контента.
  3. Воспользоваться QTP для создания гибких и удобных в
     использовании шаблонов.
  4. Получить возможность взаимодействия с системой по
     умолчанию.



                                56


12:50–13:15
Артём Кастелин, Александр Ковтушенко                          Москва,
                                                МГТУ им. Н.Э. Баумана

    Инструмент для визуализации трассы
выполнения параллельной программы — TV 1.0

    Аннотация:
    Предлагаем инструмент визуализации истории выполнения трассы па-
    раллельной программы, выполняющейся в среде MPI. Инструмент
    представляется полезным для поиска возможностей оптимизации па-
    раллельной программы.

     Параллельное программирование все ещё остаётся экзотической
областью, редко используемой в прикладном программировании. Воз-
можности для организации параллельных вычислений существенно вы-
росли — прежде всего в виде «железа». Реально доступны (в том числе
и не слишком дороги) решения в виде «кластеров», т. е. вычислительных
систем, построенных на серийных процессорах, и специально для это-
го применения производимых коммутаторов. Имеется целый ряд сред
программирования для подобных систем, причём необходимый набор
инструментов доступен и в виде открытого программного обеспечения.
     Эти средства остаются на наш взгляд невостребованными по двум
взаимообусловленным причинам: во-первых, разработка практичного
прикладного параллельного алгоритма требует специальных навыков,
вероятно — специальной подготовки. Во-вторых, слаб или почти отсут-
ствует спрос на вычислительно ёмкие прикладные решения, т. е. нет
постановки задачи, требующей параллельного счета. Таких постанов-
ки могут быть связаны с самыми разными проблемами промышлен-
ности или задачами управления: замена натурных испытаний вычисли-
тельным экспериментом, оптимизация управляющего воздействия и т. д.
Недостаток специалистов, способных формулировать такие постановки
задачи и решать их, является существенным препятствием.
     Используемый нами набор средств для создания параллельного
программного обеспечения включает в себя: средство для создания па-
раллельных программ на основе стандарта MPI (в основе — библиотека
реализующая программный интерфейс MPI), системные средства вы-
полнения полученной параллельной программы на кластере. Стандарт
MPI предлагает широкий выбор средств коммутации и синхронизации.

                                  57


Потребность в параллельной программе появляется тогда, когда вычис-
лительная ёмкость задачи высока, поэтому эффективность параллель-
ного алгоритма, эффективность использования аппаратуры вычислите-
ля — важнейшая цель. Её очень проблематично достичь «сходу», не ва-
рьируя параллельный алгоритм. Отладка параллельной программы (по
большей части) — это последовательность попыток приблизиться к при-
емлемой скорости счета. Одна из основных проблем — процесс выполне-
ния программы имеет существенно больше (по сравнению с «обычной»
последовательной программой) факторов, влияющих на динамику вы-
числений.
    Одним из ценных средств экономии сил в этой борьбе явля-
ется предлагаемая пара инструментов — библиотека для автоматиче-
ской (точнее — «почти автоматической») фиксации событий времени вы-
полнения параллельной программы + диалоговая среда для просмот-
ра/анализа накопленных данных.
    Имеется достаточно длинный список подобных инструментов. Со-
шлёмся на две из них. Во-первых, это профилировщик+визуализатор
Vampir немецкой компании Palas — продукт наиболее распространён-
ный, по отзывам, по документации — имеющий много достоинств, но
коммерческий. Во-вторых, это визуализатор ParaGraph (восходит к
1990 г.), в настоящее время в качестве трассировщика использует биб-
лиотеку MPICL (разрабатываемая Patrick H. Worley с 1997 г в Oak
Ridge National Laboratory) — оба продукта являются открытыми. Одна-
ко использование ParaGraph не слишком комфортно. Программа реали-
зована на базе непосредственно X Window, на наш взгляд ей недостаёт
средств управления.
    Предлагаемый нами визуализатор TV 1.0 также как ParaGraph ис-
пользует библиотеку MPICL, имеет при этом следующие отличия:
   • Визуализатор разработан на основе среды Qt, что позволило
     сделать его более удобным в работе (при этом система Vampir
     рассмотрена в качестве аналога).
   • Имеется в том числе и сборка визуализатора для выполнения на
     ОС MS Windows (трассы формируются в виде текстовых файлов,
     т. е. переносимы), что позволяет использовать её «любому
     пользователю».
    Надеемся, что TV 1.0 окажется полезным дополнением в ящике ин-
струментов разработчика параллельных прикладных программ на осно-
ве MPI.


                                58


13:15–13:40
Виктор Капустин, Анна Корсун                         Санкт-Петербург,
                      Санкт-Петербургский Государственный университет
Проект: Web-based IDEF Functional Modeler
http://sourceforge.net/projects/web-based-idef/

          Инструмент для функционального
                  моделирования

    Аннотация:
    Функциональное моделирование (IDEF0) использует несложный гра-
    фический язык. Программные средства поддержки этого языка, одна-
    ко, достаточно дороги (в основном, за счет избыточной функциональ-
    ности) и работают, в основном, на платформе MS Windows. Мы ис-
    пользуем браузер для обеспечения минимально необходимых для со-
    здания IDEF0 диаграмм возможностей, создавая кросс- платформен-
    ную среду моделирования. Программный инструментарий — HTML,
    JavaScript и CSS. Современные (почти-) DOM-совместимые брау-
    зеры позволили изолировать несовместимости в отдельный модуль-
    обертку. Мы отказались от внешне привлекательного пути кодирова-
    ния HTML-элементов непосредственно в JavaScript и использования
    свойства innerHTML. Вместо этого мы строго разделяем код и раз-
    метку, выделяя графические элементы в отдельные шаблоны, каждый
    из которых хранится в отдельном HTML-документе, подгружаемом
    в свой (обычно невидимый) iframe. Это заметно усложняет програ-
    мирование, но, мы надеемся, позволит привлечь независимых дизай-
    неров для качественной прорисовки элементов интерфейса. Посколь-
    ку компоненты разрабатываемого ПО можно использовать в составе
    других программных средств, распространение его планируется осу-
    ществлять под GLPL.

    Функциональное моделирование (IDEF0) использует несложный
графический язык. Программные средства поддержки этого языка, од-
нако, достаточно дороги (в основном, за счёт избыточной функциональ-
ности) и работают, в основном, на платформе MS Windows. Мы исполь-
зуем браузер для обеспечения минимально необходимых для создания
IDEF0 диаграмм возможностей, создавая кросс-платформенную среду
   1 Работа частично поддержана Российским фондом фундаментальных исследований,

грант 03-07-90299.


                                      59


моделирования. Программный инструментарий — HTML, JavaScript и
CSS. Современные (почти-) DOM-совместимые браузеры позволили изо-
лировать несовместимости в отдельный модуль-обёртку.
     Мы отказались от внешне привлекательного пути кодирования
HTML-элементов непосредственно в JavaScript и использования свой-
ства innerHTML. Вместо этого мы строго разделяем код и разметку,
выделяя графические элементы в отдельные шаблоны, каждый из ко-
торых хранится в отдельном HTML-документе, подгружаемом в свой
(обычно невидимый) iframe. Это заметно усложняет программирование,
но, мы надеемся, позволит привлечь независимых дизайнеров для каче-
ственной прорисовки элементов интерфейса.
     Поскольку компоненты разрабатываемого ПО можно использовать
в составе других программных средств, распространение его планиру-
ется осуществлять под GLPL. Обсуждается возможная смена базовой
технологии проекта (XML, CSS3).
     Функциональное моделирование (IDEF0) находит своё применение
в отраслях, связанных с созданием сложных организационных и ин-
формационных систем, поддержкой жизненного цикла сложных систем
и изделий. IDEF0 был предложен более 30 лет назад в авиакосмиче-
ской промышленности США, и стандартизован в США1 и в России2 . В
то время как эти стандарты доступны свободно, программные средства
поддержки IDEF0 выпускаются рядом известных фирм. Эти программ-
ные средства имеют тяжеловесные графические интерфейсы, перегру-
жены различными факультативными функциями, дороги, что является
препятствием для их массового применения.
     Графический язык IDEF0, в основном, ограничен горизонтальными
и вертикальными прямыми линиями и фигурами, образуемыми такими
линиями. Такая графика легко реализуется в HTML, что привело к
идее разработки инструмента поддержки создания IDEF0-диаграмм в
виде веб-приложения.
     Аналитик, создающий функциональную модель, должен иметь воз-
можность манипуляции графическими объектами модели (прямоуголь-
никами, линиями) и текстовой информацией, связанной с этими объек-
тами. Объем этой информации и данных о положении объектов может
быть значительным, и реализация поддержки каждого действия анали-
тика в виде серверных программ (скриптов) сделает работу аналитика
  1 IntegrationDefinition for Function Modeling (IDEF0)/FIPS Publication 183. — 1993
  2 Рекомендации   по стандартизации Р50.1.028-2001. Информационные технологии под-
держки жизненного цикла продукции: Методология функционального моделирования. —
Госстандарт, 2001


                                        60



    
Яндекс цитирования Яндекс.Метрика