Development:Краткий обзор

Многие спрашивают, как организована разработка Moodle. Эта страница даст вам беглый обзор, который также поможет в понимании другой документации по разработке.

Ключевые игроки

Мартин Догиамас

Мартин – ведущий разработчик Moodle. Обычно он пытается способствовать демократии и меритократии, но иногда должен принимать исполнительные решения по текущим вопросам.

Штаб-квартира Moodle

Команда разработчиков, состоящая в основном из австралийцев, которая финансируется непосредственно проектом Moodle, постоянно работает над основной частью разработок. Среди разработчиков Мартин Догиамас (moodler), Элои Лафуэнт (stronk7), Питер Скода (skodak), Метью Петит-Клаир (scyrma), Никалас Каннаут, Дошенг Каи , Хелен Фостер (wildgirl) и иногда Джемми Пратт (jamiesensei). Фото каждого из них можно найти здесь http://moodle.com/hq/

Catalyst

Команда разработчиков работает для клиентов Moodle через Catalyst ЛТД в Новой Зеландии, проводит наибольшую часть основных разработок. Среди разработчиков Мартин Лангоф, Пенни Леак (mjollnir), Мет Кларксон и Донал Макмулан.

Открытый университет

Команда разработчиков работает над выполнением Moodle в Открытом Университете в Великобритании. Среди них Тим Хант, Сэм Маршал, Ник Фриар, Танх Ли и Женни Грей. Много других людей сотрудничает с Moodle во многих направлениях, это всего лишь главная группа, которая сейчас работает над основными разработками. Смотрите полный список людей с правом записи в Moodle.

Версии Moodle

Главные релизы Moodle происходят приблизительно раз в 6 месяцев, по незафиксированному расписанию. Каждый такой релиз увеличивает номер версии на 0.1. Менее значительные релизы (без новых возможностей, только исправление ошибок) могут происходить в любое время, когда бы ошибки не были готовы к исправлению. Более детально можно посмотреть в Релиз заметках. Текущая разрабатываемая версия является всегда главной cvs (Система Конкурирующих Версий) (т.е. в вершине/голове), в то время как для каждой основной версии выделяются постоянные направления (напр. MOODLE_18_STABLE).

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

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

Стадии разработки программного обеспечения

Обычно цикл разработки работает так:

Быстрая разработка

Длинный период продолжительностью в несколько месяцев в течении которого добавляется код в главную (HEAD) версию Moodle. В тоже время, все ошибки, не касающиеся изменений в базе данных или серьезных изменений в основе (ядре) системы, устраняются путем «бекпорта» на последних двух или трех основных версиях.

Заморозка

В определенный момент Мартин Догиамас объявляет заморозку новой работы, пока ядро системы не будет стабильно. Изменяются все базы данных, и все главные изменения в ядре системы требуют явного разрешение от Мартина. Все разработчики должны закончить работу над новыми функциями и исправлением ошибок в новом коде. Этот период длится 1 или 2 недели.

Бета период

Однажды главная версия(HEAD) становиться абсолютно устойчивой, Мартин объявляет Бетта версию, и этот момент отмечается как MOODLE_XX_BETA (напр. MOODLE_20_BETA). Пакеты для инстоляции генерируются ежедневно из более поздних версия для более широкого тестирования и обратной связи через Трекер. Новые разработки заморожены, тестирование и исправление продолжаются. Этот период тестирования длится от 2 до 6 недель.

Главный релиз

Когда код ядра проходит все тестирования мы можем его выпустить. Флажок MOODLE_XX_BETA увеличивается. При этом текущая точка отмечается как начало новой версии, называемой MOODLE_XX_STABLE. Создаются пакеты и объявляется релиз. Затем все начинается с начала!

Контроль качества

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

Тестеры

Тестеры ответственны за проверку правильности изменений сделанных разработчиками. Тестеры выбирают, какие они хотят проверить ошибки, согласно области их знаний, и выбирают поле QA Assignee, чтобы идентифицировать себя как тестера. Если ошибка проходит тестирование успешно, тестер изменяет ее статус с «решаемая» на «закрытая». Если ошибка проходит тестирование неудачно или если проблема не решена, тогда тестер открывает ошибку заново. Релиз Moodle будет считаться готовым, когда все «блокирующие» ошибки для конкретной версии будут «закрыты».

Еженедельный обзор кода

Каждый вторник(во все часовых поясах), тестеры и разработчики ядра останавливают разработку нового кода и фокусируются на пересмотре изменений, сделанных в системе за прошлую неделю(на уровне кода и на уровне интерфейса). Этот процесс предназначен для улучшения качества ранее разработанных пакетов и для нахождения каких-либо новых ошибок, которые должны были получиться, когда исправляли старые. Последующие пакеты помечаются как MOODLE_XX_WEEKLY(этот тег обновиться, после того как еженедельный обзор будет завершен). Смотри более детально «Development: Еженедельный обзор кода» (Development:Weekly Code Review).

Стандарты кодирования

Полная версия Coding Guide предоставляет все подробности, но здесь некоторые главные моменты, которым ваш код должен соответствовать:

XMLDB

Вся схема нашей базы данных создана с помощью файлов XML install.php, и обновлена с помощью команд для агностики баз данных, содержащихся в файлах upgrade.php. Любая версия любой части Moodle может быть легко обновлена до более поздней версии в этом стиле (с широким выбором, поддерживаемых баз данных).

XHTML

Весь вывод Moodle должен быть подчинен XHTML Strict 1.0, а также общим правилам стандартов Accessibility Guidelines(руководства по доступности веб-содержания) (такого как W3C WAG).

Формы

Все формы должны использовать библиотеку Moodleforms, если это возможно. Это из-за единого стандартизированного вывода, который дизайнеры могут модернизировать единым образом.

Параметры

Все параметры должны быть проверены с помощью require_param() и optional_param(), которые безопасно очистят все входящие данные для использования и обеспечения установки значений по умолчанию в вашем коде.

Вывод

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

Доступ

Все проверки прав доступа должны использовать библиотеку "Access library" чтобы проверить соответствие текущим возможностям. Наиболее общая функция, которую Вы будите использовать – это has_capability(), она проверяет права текущего пользователя, чтобы определить, можно ли ему осуществлять данную операцию. Не исправляйте специфические роли в вашем коде(напр. учитель/студент) так как это сделает ваш код непригодным.

Другие библиотеки ядра

Другие библиотеки с которыми вам стоит познакомиться:

1) moodlelib.php – хранилище все возможных полезных функций и констант

2) datalib.php – все функции, которые вам могут понадобиться для взаимодействия с базой данных

3) weblib.php – все функции, которые вам могут понадобиться для создания и вывода XHTML

Плагины

Я недавно подсчитал, что в Moodle есть около 22 разнообразных типов плагинов. Обычно плагины - это независимой отдельные директории, содержащие скрипты, изображения, таблицы стилей и файлы языков, все в одном пакете, который может быть перенесен в директорию Moodle скриптов в нужное место. После этого от администратора требуется только зайти на страницу администрирования, чтобы установить их. Большинство плагинов работают одним из двух способов, они либо предоставляют lib.php, наполненный стандартными функциями и кое-какими скриптами со стандартными именами или содержат подкласс протокол-плагина и перегружают несколько методов для выполнения их целей. Лучший способ научиться – это выбрать пример из кода ядра, который похож на то, что Вы хотите сделать и «поиграть» с ним. Есть также шаблонные плагины, которые помогут вам начать.

Процесс разработки

Не вся разработка Moodle происходит так, как здесь написано, но это должно быть так.

Главная разработка

Главная разработка – это важная часть нового кода, добавление новой функциональности к Moodle.

Удостоверься, что это хорошая идея

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

Создайте спецификацию в документах Moodle

Начните новую страницу в Moodle документах вики, похожую на Development:Grades. Ваша страница должна наметить строение таблицы для базы данных, графический интерфейс пользователя (GUI), как и почему и т.д. Включите деталей столько, сколько вам нужно, но старайтесь оставлять ее чистой и логически организованной.

Найдите и освойте общественную обратную связь.

Напишите о новой странице на соответствующем форуме на Using Moodle, чтобы привлечь внимание к ней и стимулировать обсуждение ваших разработок. Чем шире у вас обратная связь, тем лучше, особенно, если она охватывает большое количество пользователей (разработчиков, преподавателей, студентов и т.д.). Редактируйте вашу страницу в ответ на комментарии или предложите людям сделать это самостоятельно. Старайтесь улучшать спецификацию, чтобы все пользователи были довольны. Иногда очень трудно найти лучший способ что-то сделать без добавления еще одной опции.

Установите задания в Трекере

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

Используйте CVS(Система Конкурирующих Версий) и подключите фиксацию к Трекеру

Если это возможно, программируйте в хранилище для открытого кода (и предпочтительно использовать Moodle CVS!). Если вам нужно CVS право на запись в код ядра или доступ в contrib (общедоступное) хранилище пакетов, используйте колонку "Apply for CVS Access" на http://moodle.org/cvs. Получить доступ к главному коду ядра достаточно трудно, но мы обычно даем свободный доступ к contrib каталогу. Всегда, при сохранении, вставляйте подробное сообщение о новом коде и всегда проставляйте номер ошибки на Moodle Трекере (напр. MDL-7777). Тогда Moodle Трекер точно будет готов сохранить ваши изменения и присоединит их к прикрепленному (связанному) отчету об ошибках.

Комментируйте завершение важных этапов на форумах и Трекере

Если Вы закончили важный этап, или вам нужен тестер, чтобы проверить что-то, не стесняйтесь объявлять об этом в соответствующих форумах на Using Moodle. Чем больше людей Вы сможете заинтересовать в рассмотрении и испытании вашего кода, тем лучше, поверьте мне.

Реагируйте на отчеты об ошибках

Конечно вам нужно слушать ваших пользователей.(Ну хорошо, большинство из них.) Поощряйте людей сохранять информацию об ошибках, и исправляйте их. Если вам нужна помощь в наладке категории проекта на Трекере, обращайтесь по support@moodle.com. Это гарантирует, что все ваши ошибки будет легко найти и отследить.

Менее значительные разработки

Для более маленьких модулей, исправлений, усовершенствований и других публикаций.

Создавайте новые публикации на Трекере

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

Прилагайте патчи

Если у вас есть какой-то код, пожалуйста, присоедините его к теме на форуме или, если это на вашем собственном сайте, бросьте ссылку. Не присоединяйте код на Moodle форумах. Он быстро «сгниет» и только забьет moodle.org старым бесполезным кодом.

Прорекламируйте патч

Всеми путями привлекайте внимание к вашей работе в Moodle форумах (упомяните номер ошибки) или посылайте письма разработчикам напрямую, помогая им ознакомиться с ней. Вы можете также добавить разработчиков как «наблюдателей» за темой на Трекере, если хотите, это значит, что они будут получать сообщение на электронную почту каждый раз при изменении в теме.

Ссылки для разработчиков

• Developer FAQ – часто задаваемые вопросы, особенно полезны для новичков Moodle
• Moodle tracker - bug доклады, специальные вопросы и другие виды выходов
• General developer forum
• CVS code – просмотр кодов Moodle через web
• Cross reference - phpxref – выход для просмотра ресурсов кода в Moodle
• Moodle PHP doc reference – автоматически производимая документация
• Database Schema – для новых публикаций
• Development news and discussion раздел курса Moodle Using
• YUI documentation - YUI официальная AJAX библиотека в Moodle.
• Setting up Eclipse for Moodle development - Eclipse грандиозное издание для проявления php навыков, если Вы если вы сможете выработать план установки .
• Unmerged files – изменение устойчивого направления в CVS которое может быть не совместимо с HEAD