статья Алексея Дьяченко
Когда заказчик просит развернуть ПО для eLearning или дистанционного обучения, каждый вкладывает в эти слова свой смысл:
В действительности, понятие eLearning шире всего перечисленного — это прежде всего новая модель учебного процесса, а не просто перенос в online привычных практик, вместе с отсканированными методичками, набитыми на скорую руку тестами и добавлением функции интернет-магазина.
С точки зрения IT, eLearning это прежде всего инфраструктура, обеспечивающая базовые и дополнительные сервисы:
Этот список можно дополнить, но предлагаю условиться, что управление учебным процессом мы выносим за скобки, так как здесь потребности разных организаций различаются еще сильнее.
Таким образом вырисовывается архитектура eLearning: базовая платформа, с которой интегрируются управленческие базы данных, а также специфические сервисы и учебные материалы, такие как вебинары, интерактивные лаборатории и т.д. Исходя из этого, появляются требования открытости, масштабирования, стабильности, расширяемости, документированности и устойчивости развития базовой платформы.
Этим требованиям в полной мере соответствует Moodle — Модульная Объектно-Ориентированная Дистанционная Учебная Среда. Сравнение Moodle с закрытыми и открытыми аналогами не является темой данной статьи. Скажу лишь относительно внутренней или заказной разработки: приберегите эти ресурсы для действительно специфических задач, таких как разработка хороших учебных ресурсов, симуляций, а также разработку или кастомизацию системы управления учебным процессом. Изобретая собственный велосипед вы всё-равно не догоните команду разработчиков, работающую с 2002 года на полный рабочий день: ядро команды разработчиков свободного ПО Moodle являются штатными сотрудниками фонда Moodle в Австралии, который финансируется региональными партнерами и грантами.
Moodle хорош именно как интеграционная платформа: достаточно стабилен, если не ставить экспериментальные версии (больше 60 тысяч инсталляций выявляют большинство проблем раньше, чем вы их заметите), масштабируем (имеются инсталляции более чем с 1 миллионом пользователей), а модульность и поддержка открытых протоколов интеграции с самого начала были приоритетом разработчиков. Помимо этого, в нём на достаточно высоком уровне реализована поддержка всех типов учебной активности, которую можно было реализовать на используемых технологиях. К сожалению, вебинары требуют сервера потокового вещания, который на LAMP-хостинге не живёт, но большинство открытых или коммерческих продуктов этой категории уже имеют готовые модули интеграции в Moodle.
Процесс установки максимально автоматизирован: пошаговый мастер выполняет большую часть работы, от диагностики сервера до создания структуры базы данных. Главное не в пасть в заблуждение — лучше эту работу выполнять опытному веб-мастеру, понимающему, как устроен Internet, как работает Apache, как управлять правами доступа в Linux, что такое Cron, как ходит почта из веб-приложения и как уменьшить вероятность её попадания в спам. Установить Moodle можно и без этого, в конце-концов, есть Денвер, вот только за дальнейшую судьбу такого внедрения и стабильность работы я бы не поручился. Если такого специалиста нет, дешевле и надёжнее привлечь стороннего, чем брать в штат и учить своего: на полный день работы по обслуживанию Moodle от одной системы не наберётся, а загруженность разнотипными задачами снижает качество и мотивацию.
После этих нехитрых манипуляций мы получаем чистую систему, и дальше на первый план выходит организация бизнес-процессов, от которой и зависит успех проекта:
Если планируются собственные доработки, важно с самого начала поставить строгое условие — никаких правок в ядре, никаких патчей и хаков, только модули, работающие через API, предусмотренное разработчиками. Этим вы избавите себя от массы проблем, самая страшная из которых — потеря простоты обновления и совместимости с базовой версией, а как следствие, вынужденное принятие на поддержку собственными силами всего кода Moodle, а не только нескольких небольших плагинов.