Бизнес, который может полностью функционировать без своего владельца в России очень скоро избавляется от своего владельца. Поэтому вряд-ли стоит стремиться к автономии большей, чем продолжение исполнение текущих заказов и подключения новых типовых клиентов, да и невозможно бОльшее в малом бизнесе: как я написал, руководитель здесь является «универсальным сотрудников», другой такой сотрудник малому бизнесу просто не по карману, а специализация требует гораздо бОльшего штата, тогда можно нанять отдельного юриста, маркетолога, сисадмина, аккаунт-менеджера, специалиста по кадрам и кучу других.
Ну а в философском смысле, ничто в мире не приносит пассивого дохода, даже недвижимость и акции дешевеют и саморазрушаются, если за ними не следить.
Делал бы карьеру наемного сотрудника — это надежнее, рост быстрее, меньше стрессов и волнений. А главное — каждый год есть 28 дней отпуска, в которые можно выключить телефон и не доставать ноутбук.
Вы еще не видели других систем, особенно коммерческих, которые «коммивояжеры» носят по ректорам по лимону за штуку: многие из них похожи на системы складского учета с возможностью выкладывать файлики :)
Это вопрос к разработчикам сторонних плагинов вопросов, почему они поленились написать код работы с резервными копиями. Из базовой версии должно всё бекапиться. А то что в базовую версию не входит каждый ставит на свой страх и риск, потому что любой может написать плагин и никто ему не указ, можно и на своём сайте выложить.
Принцип стандарта SCORM заключается в том, что пакет общается с JavaScript из основного окна браузера, который установила система и который умеет сообщать системе результат. Учитывая, что бОльшая часть вычислений проходит на клиенте, сомневаюсь, что хоть какую-то безопасность можно обеспечить. Есть секьюрные браузеры для тестирования, но они тоже имеют смысл только на машинах, которые можно контролировать.
Про ЭД напишу обязательно, если после сегодняшнего поста останется возможность еще что-то писать :))) Тут как в CS — не успел оглянуться, и ты — труп :) Сколько лет читал Хабр, а не думал, что тут такие порядки :)
В зачаточном оно было 12 лет назад, когда выбирали между fle3 и «Доцентом», а сейчас уже зрелая стадия у рынка. Я бы не ждал чего-то координально-нового, разве что изобретут совершенно новую концепцию обучения, простую и изящную, не похожую на всё, что было до этого.
На мой взгляд, Moodle на его поле «не переиграешь»: это старый, хорошо развитый, очень распространённый проект, в него очень много вложено и этого нельзя сбрасывать со счетов.
Самописные решния здесь не имеют шанса — существуют, пока нужны их авторам, при таком же массовом распространении на них бы плевались во-много раз больше.
Все эти 1001 конторы, которые кормятся с Moodle — если они официальные партнеры, они отчисляют 10% с доходов на содержание основной команды разработчиков, которые продолжают допиливать Moodle, чтобы он нравился пользователям (насколько это возможно сделать). Это симбиоз. За счет этого фонд Moodle получает достаточное финансирование, чтобы регулярно выпускать новые версии, улучшать систему. Ну, насколько это возможно.
Единственный шанс для начинающих с нуля («гаражных») проектов — это изобрести совершенно новую концепцию, которая позволяет делать то же самое и даже лучше, но на 1-2 порядка проще устроена. Вся наша технология так развивается: те же паравозы в самом конце были вершиной инженерной мысли, а потом бац — электровозы, электромотор, редуктор и всё. Дальше снова усложнение.
Максим, я отвечаю на комменты, чтобы помочь решить проблемы с Moodle для тех, кто в этом нуждается и чтобы дополнить полезность статьи полезностью рецептов из комментариев. Устраивать здесь холивар в мои планы не входит. Убеждать, что Moodle — истина в последней инстанции — тоже. У меня и самого к разработчикам масса вопросов.
Я могу только попробовать подсказать как быть с тем, что есть. Тем более, что как вы сами сказали, лучшего ничего нет.
По опыту, действительно серьезные вещи правят быстро. Разумеется, обычно не в тот же день, но в ближайшем релизе, иногда даже в ближайшем еженедельном обновлении.
Есть одна хитрость — мигрируйте на новую ветку не с основной волной, а чуть позже, когда в ней выйдет хотя бы 1, лучше 2-3 минорных релиза.
С мелочами, да, иногда багрепорты через 2-3 года закрывают со словами «старая версия не поддерживается, в новой не актуально». Впрочем, это еще благополучно для проектов такого масштаба. В коммерческих вообще ответа не добьешься.
Про масштабирование из коробки — гляньте в статистику количества пользователей сайтов. Им это как-то не мешает. Кеширование обращений к БД — есть, хранение сессий в базе — есть. В большинстве случаев этого больше, чем достаточно. Slave DB еще вопрос, прибавит производительности или убавит, всё-ж в Moodle пользователи постоянно что-то меняют и добавляют, там такого перекоса между записью и чтением нет.
Конкретно с количеством недель — это было сделано специально: курсы с бОльшим количеством секций слишком тяжелы, их нужно дробить используя механизм мета-курсов. Впрочем, в версии 2 этот параметр настраивается из админки.
То, что можно сделать через API гораздо шире, чем может сперва показаться. Например, есть механизм подключения файлов с патчами при вызове определенных скриптов — и всё без правки ядра.
По поводу правок ядра — к сожалению, особенно начинающие разработчики не делают это с должной аккуратностью и «вежливостью» — они вгрызаются в чужой код зубами, и начинают его рвать, как бультерьеры и когда приходит время обновиться, становится понятно, что не то что перенести, даже вычленить их правки из кода на сервере (про GIT они могли и не слышать) не представляется возможным. Вот если нет должного опыта работы с чужим кодом из крупных, развивающихся другой командой проектов, то лучше совсем запретить правки, иначе возможные проблемы превысят всю возможную и невозможную пользу от правок.
Всем не угодишь. Что одним удобно, другим — ад. Хорошо, когда с сообществом разработчиков можно держать контакт, присылать им патчи или потихому дописав для себя аддон (даже не обязательно править ядро, для разработчиков оставлено очень много «ручек», за которые можно схватиться). Это улучшает обратную связь и система не содержит вещей, которые не удобны вообще всем. Но, конечно, под каждого отдельного пользователя никакое ПО не подгонишь.
Многим идея с кнопкой «редактировать», которая позволяет редактировать материалы на той же странице и в том же виде, как их видят студенты. Всяко-удобнее, чем идти в отдельную админку и править там, или править материал локально и загружать в виде scorm-пакета.
Про приаттаченные студентами домашние работы — это просто различия в практике работы, как её понимаете вы (скачать, проверить, записать в табличку, залогиниться и выставить результаты) и как её понимают разработчики (открыл работу, кликнул по ссылке, скачалось, открылось в дефолтном редакторе, посмотрел, написал отзыв, поставил оценку, закрыл). К тому же, дописать скриптик, который выплюнет все файлы задания в zip-архиве — несколько строк, поспрашивали бы на форуме на официальном сайте — может у кого-то уже есть.
Формат бекапов Moodle состоит из двух частей: базовую структуру генерирует сам Moodle, а данные каждого плагина через API по специальным правилам сохраняет и читает плагин. Поэтому единой документации формата быть просто не может — установили себе сторонний плагин, и он добавил свою часть. Можно, конечно, её игнорировать просто. Вообще, если уж вы решились работать с форматами бекапов, то просто посмотрите названия тегов, почитайте рекомендации для разработчиков плагинов по сохранению и восстановлению данных своих плагинов — этого достаточно, чтобы разобраться.
Есть три варианта:
1. Использовать SCORM. Это ведь не просто стандарт запаковки html и картинок в zip-архив, существенная часть стандарта посвящена общению контента из пакета с LMS для сохранения результатов.
2. Есть плагин, разработанный Дмитрием Пыпыниным из Новосибирского Педагогического: moodle.org/mod/data/view.php?d=13&rid=2493&filter=1
3. Используйте протокол IMS LTI
Честно-говоря, сходу даже не могу вспомнить, где там все перечисленные ужасы UI, о которых Вы пишите. По-опыту, многие заказчики любят уродовать свой Moodle, выпиливая всю навигацию и элементы интерфейса, до которых могут дотянуться и устанавливая некачественные, но крайне «креативные» шаблоны оформления. Причем делают это либо из предположения о низком уровне способностей пользователей (запутаются), либо из традиционного «огородить, потому что не положено» :) Код Moodle открыт и сложно сказать, чистая ли система перед вами или модифицированная.
Moodle — очень распространённая система, у неё широкое сообщество, которое напрямую связано с процессом разработки. Совсем уж неудобных вещей там просто не может быть. Я видел довольно много других продуктов — в большинстве UI был в разы хуже.
Что касается разработки с 2002 года — разные свистелки и мигалки, обеспечивающие современность интерфейса не самое главное преимущество среды дистанционного обучения. Главное — как система делает свою работу: функциональная мощность, гибкость, стабильность развития и открытость для интеграции Moodle превышает практически все коммерческие и некоммерческие аналоги, которые я видел. К тому же, уже давно есть версия 2, интерфейс которой выглядит гораздо современнее и поддерживает AJAX-овские штучки, которые, впрочем, очень часто отключают за ненадобностью или по перечисленным в первом абзаце причинам :)
Если напишите здесь, или где-то еще — киньте ссылочку, пожалуйста.
В мае планируем международную конференцию по Moodle в Железноводске — если это как-то связано с вашей деятельностью, можете в виде дистанционного доклада статью оформить и поучаствовать или приезжайте — в мае в Минеральных Водах замечательно :)
А они разве есть, кроме 137 приказа Минобра? Максимум, скорм частично перевели и приняли — так он в Moodle поддерживается.
Все остальные стандарты касаются не ПО, а бизнес-процессов и материалов, тут система в стороне.
По поводу скудной информации: если электронный журнал ведётся как дополнительный, то так и будет — никому не охота вбивать лишние данные. В законе о госуслугах прописано, что в журнале должны отображаться оценки, посещаемость и домашние задания — вся остальная информация выводится по желанию разработчиков журнала и администрации школы.
Информация должна стать более полной и обширной, когда школа полностью перейдет на ведение электронного журнала: юридических препятствий для этого нет, некоторые школы уже полностью отказались от ведения бумажного журнала. По закону, в бумажном виде школа обязана хранить только ведомости, текущие оценки и посещаемость можно хранить в электронном виде.
С дневниками сложилась довольно любопытная ситуация: за внедрение «своего» решения сейчас бьются коммерческие поставщики (зарабатывающие на смс-ках и допуслугах для родителей) и ведомственные решения, созданные (или купленные) за казённый счет, разработчики которых заинтересованы в продолжении финансирования. Государство, как ни странно, проявило мудрость и самоустранилось: «Пусть расцветают сто цветов» — в госуслугах прописан минимум требований для интеграции с любыми решениями, а вот прокуратура радостно потирает руки, придумывая трактовки закона о персональных данных.
Ну а в философском смысле, ничто в мире не приносит пассивого дохода, даже недвижимость и акции дешевеют и саморазрушаются, если за ними не следить.
Вы еще не видели других систем, особенно коммерческих, которые «коммивояжеры» носят по ректорам по лимону за штуку: многие из них похожи на системы складского учета с возможностью выкладывать файлики :)
Про ЭД напишу обязательно, если после сегодняшнего поста останется возможность еще что-то писать :))) Тут как в CS — не успел оглянуться, и ты — труп :) Сколько лет читал Хабр, а не думал, что тут такие порядки :)
Самописные решния здесь не имеют шанса — существуют, пока нужны их авторам, при таком же массовом распространении на них бы плевались во-много раз больше.
Все эти 1001 конторы, которые кормятся с Moodle — если они официальные партнеры, они отчисляют 10% с доходов на содержание основной команды разработчиков, которые продолжают допиливать Moodle, чтобы он нравился пользователям (насколько это возможно сделать). Это симбиоз. За счет этого фонд Moodle получает достаточное финансирование, чтобы регулярно выпускать новые версии, улучшать систему. Ну, насколько это возможно.
Единственный шанс для начинающих с нуля («гаражных») проектов — это изобрести совершенно новую концепцию, которая позволяет делать то же самое и даже лучше, но на 1-2 порядка проще устроена. Вся наша технология так развивается: те же паравозы в самом конце были вершиной инженерной мысли, а потом бац — электровозы, электромотор, редуктор и всё. Дальше снова усложнение.
Я могу только попробовать подсказать как быть с тем, что есть. Тем более, что как вы сами сказали, лучшего ничего нет.
Есть одна хитрость — мигрируйте на новую ветку не с основной волной, а чуть позже, когда в ней выйдет хотя бы 1, лучше 2-3 минорных релиза.
С мелочами, да, иногда багрепорты через 2-3 года закрывают со словами «старая версия не поддерживается, в новой не актуально». Впрочем, это еще благополучно для проектов такого масштаба. В коммерческих вообще ответа не добьешься.
Про масштабирование из коробки — гляньте в статистику количества пользователей сайтов. Им это как-то не мешает. Кеширование обращений к БД — есть, хранение сессий в базе — есть. В большинстве случаев этого больше, чем достаточно. Slave DB еще вопрос, прибавит производительности или убавит, всё-ж в Moodle пользователи постоянно что-то меняют и добавляют, там такого перекоса между записью и чтением нет.
Конкретно с количеством недель — это было сделано специально: курсы с бОльшим количеством секций слишком тяжелы, их нужно дробить используя механизм мета-курсов. Впрочем, в версии 2 этот параметр настраивается из админки.
То, что можно сделать через API гораздо шире, чем может сперва показаться. Например, есть механизм подключения файлов с патчами при вызове определенных скриптов — и всё без правки ядра.
По поводу правок ядра — к сожалению, особенно начинающие разработчики не делают это с должной аккуратностью и «вежливостью» — они вгрызаются в чужой код зубами, и начинают его рвать, как бультерьеры и когда приходит время обновиться, становится понятно, что не то что перенести, даже вычленить их правки из кода на сервере (про GIT они могли и не слышать) не представляется возможным. Вот если нет должного опыта работы с чужим кодом из крупных, развивающихся другой командой проектов, то лучше совсем запретить правки, иначе возможные проблемы превысят всю возможную и невозможную пользу от правок.
Многим идея с кнопкой «редактировать», которая позволяет редактировать материалы на той же странице и в том же виде, как их видят студенты. Всяко-удобнее, чем идти в отдельную админку и править там, или править материал локально и загружать в виде scorm-пакета.
Про приаттаченные студентами домашние работы — это просто различия в практике работы, как её понимаете вы (скачать, проверить, записать в табличку, залогиниться и выставить результаты) и как её понимают разработчики (открыл работу, кликнул по ссылке, скачалось, открылось в дефолтном редакторе, посмотрел, написал отзыв, поставил оценку, закрыл). К тому же, дописать скриптик, который выплюнет все файлы задания в zip-архиве — несколько строк, поспрашивали бы на форуме на официальном сайте — может у кого-то уже есть.
1. Использовать SCORM. Это ведь не просто стандарт запаковки html и картинок в zip-архив, существенная часть стандарта посвящена общению контента из пакета с LMS для сохранения результатов.
2. Есть плагин, разработанный Дмитрием Пыпыниным из Новосибирского Педагогического: moodle.org/mod/data/view.php?d=13&rid=2493&filter=1
3. Используйте протокол IMS LTI
Moodle — очень распространённая система, у неё широкое сообщество, которое напрямую связано с процессом разработки. Совсем уж неудобных вещей там просто не может быть. Я видел довольно много других продуктов — в большинстве UI был в разы хуже.
Что касается разработки с 2002 года — разные свистелки и мигалки, обеспечивающие современность интерфейса не самое главное преимущество среды дистанционного обучения. Главное — как система делает свою работу: функциональная мощность, гибкость, стабильность развития и открытость для интеграции Moodle превышает практически все коммерческие и некоммерческие аналоги, которые я видел. К тому же, уже давно есть версия 2, интерфейс которой выглядит гораздо современнее и поддерживает AJAX-овские штучки, которые, впрочем, очень часто отключают за ненадобностью или по перечисленным в первом абзаце причинам :)
В мае планируем международную конференцию по Moodle в Железноводске — если это как-то связано с вашей деятельностью, можете в виде дистанционного доклада статью оформить и поучаствовать или приезжайте — в мае в Минеральных Водах замечательно :)
Все остальные стандарты касаются не ПО, а бизнес-процессов и материалов, тут система в стороне.
Информация должна стать более полной и обширной, когда школа полностью перейдет на ведение электронного журнала: юридических препятствий для этого нет, некоторые школы уже полностью отказались от ведения бумажного журнала. По закону, в бумажном виде школа обязана хранить только ведомости, текущие оценки и посещаемость можно хранить в электронном виде.
С дневниками сложилась довольно любопытная ситуация: за внедрение «своего» решения сейчас бьются коммерческие поставщики (зарабатывающие на смс-ках и допуслугах для родителей) и ведомственные решения, созданные (или купленные) за казённый счет, разработчики которых заинтересованы в продолжении финансирования. Государство, как ни странно, проявило мудрость и самоустранилось: «Пусть расцветают сто цветов» — в госуслугах прописан минимум требований для интеграции с любыми решениями, а вот прокуратура радостно потирает руки, придумывая трактовки закона о персональных данных.