English
资源说明：Живая речь - инструменты для разработки пособий.
#"Редактор Live" Админская панель (веб) для редактирования сущностей предметной области в базе данных. Предназначение **редактора** - автоматизация и упрощение редактирования БД, сохраняя её целостность, поддерживая её соответствие внешним функциональным требованиям и органичениям. Разделы обучения: 1. Уроки -- теоретические сведения об изучаемом языке и упражнения к ним (можно не делать это упражнение в уроке, а просто дать ссылку на интерактивное с POST передачей параметров, которое подходит текущему уроку). Это обычные упражнения как в учебниках, выполняемые как правило при помощи ручки и бумаги. После выполнения можно посмотреть ответ. 2. Контрольное упражнение -- тестирование, неинтерактивное упражнение для подведения итогов по уроку. 3. Книги -- текст со вставками, при нажатии на которые можно посмотреть значение слова и послушать его произношение. Нажимаемые добавляется в общий словарь пользователя, отображаются справа. 4. *Интерактивные упражнения*, тесты -- выбор слов по их звучанию (с картинками), ответы на вопросы, соотнесение слов их значению, рисование иероглифа 5. Видео на китайском с Youtube с интерактивными субтитрами. При нажатии на иероглиф в субтитрах, иероглиф добавляется в словарь неизвестных слов пользователя, этот словарь отображается справа, новые слова вверху - иероглиф, произношение, перевод, кнопка для проигрывания звука (в дальнейшем эта информация будет включена в общую статистику по изучению иероглифов пользователя для использования в частоте встрече иероглифа в упражнениях). 6. Аудирование -- диалоги, песни, и т.п. на изучаемом языке и в виде аудиофайлов. Принцип тот же, что и в **видео**. По сути **видео** и **аудирование** включают в себя готовый элемент **книги**. Рабочее название полного пособия по китайскому - **"Живая Речь: китайский язык"** (лат.: **"LiveChinese"**) В каждом разделе редактора нужен элемент для просмотра. При нажаии на кнопку "Просмотр" , открывается отдельное окно с работающим упражнением. Всё что редактируется должно при бекапе и в осстановлении полностью вернуться к состоянию на момент бекапа. Изменения в систему накатываем с помощью скриптов, автоматически: [Continuous integration](http://en.wikipedia.org/wiki/Continuous_integration) ###Выходной формат данных имеет следующую структуру:  ##Об элементах модуля Далее будем называть слоем (layer) совокупность, состоящую из вышеперичисленных элементов. Модулем или пакетом (package) будем называть один слой или совокупность слоёв в виде файла. Основными особенностями рассматриваемого модуля является 1. переносимость 2. возможность неоднократной установки с разнородным содержимым 3. возможность содержать несколько уроков 4. универсальность: служит как для обновления учебной базы, так и для обновления LivePlatform. Под __LivePlatform__ следует понимать платформу для распространения пособий. Включает систему покупки и обновления, сбора статистики, а также является навигационным приложением -- через него можно получить доступ к остальным частям пособия. Чаще LivePlatform будем называть основным приложением. ###Рассмотрим требования к каждому элементу слоя: ####0. Общие требования В слое может находиться один элемент. Обеспечение надёжной защиты слоя и единства с основным приложением. Другими словами, элементы слоя нельзя запустить вне LivePlatform, по крайней мере пользователю. Пользователь должен пройти базовый минимум упражнений -- предполагается интерактивных -- чтобы открыть доступ к следующему уроку, и следовательно, зависимым от него элементам. Дополнительный (бонусный) элемент независим от урока и доступен пользователю всегда. Некоторые одинаковые элементы могут использоваться в разных уроках. ####1. Lessons (Уроки) Содержит теоритические сведения. Это в основном текстовая информация сопровождающаяся картинками. В процессе прохождения урока могут встречаться слова для запоминания, для которых необходимо дать перевод и произношение. Для наглядности допускается использование большого количества картинок. Одному уроку может сопоставляться неограниченное количество единиц других элементов, с другой стороны -- в слое может находиться только 1 урок. ####2. Exercises (Упражнения) Предполагается неограниченое количество упражнений к одному уроку. Должны присутствовать ответы к упражнениям. Никаких других требований к упражнениям не предъявляется. ####3. Books (Книги) При нажатии на новые слова можно посмотреть значение слова и послушать его произношение. Допускается наличие картинок -- это даже необходимо, ведь книжки с картинками всегда интереснее. Предполагается учить читать пользователя постепенно, чтоб в каждой новой *"книге"* пользователь узнавал только небольшое количество новых слов -- иначе полтекста придётся выделять как новые слова. Одинаковые книги могут использоваться в разных уроках. ####4. Interactive Exercises (Интерактивные упражнения) Приложение на Java, запускаемое только из основного приложения. Зависимы от уроков -- так как обязательны для перехода на следующий урок. Одинаковые упражнения могут использоваться в разных уроках, но с разными параметрами -- например, если пользователь в уроке 1 проходит упражнение на запоминание буквы *А*, передаём в упражнение параметр *-А*, если в уроке 2 на запоминание *Б* -- передаём *-Б*, в уроке 3 -- весь алфавит, передаём -- *-весь* и т.п. ####6. Videos (Видеоуроки) Обучающее видео с субтитрами, паузой, перемоткой -- качество видео не должно быть слишком маленькое -- мы выпускаем только качественную продукцию -- и не должно быть слишком большим -- слишком качественное видео повредит переносимости модуля. Видеоуроки независимы от уроков -> могут выступать в виде бонусного содержимого. Одинаковые видеоуроки могут использоваться в разных уроках. ####6. Audio (Аудирование) Аналогично видеоурокам. А также может использоваться для задания фоновой музыки и звуков. ####7. Application (Приложение) Это самый полиморфный элемент. Он может представлять собой: + игру -- дополнительное (бонусное) содержимое в виде интерактивного упражнения не связанного с конкретным уроком; + обновление главного приложения; + рекламный банер; + что-нибудь ещё. ###О реализации требований Теперь, когда собрана вся необходимая информация о составляющих частях, можно перейти к реализации модуля. Как следует из определения, модуль поставляется одним файлом. Он может представлять собой определённый архив, данные в который запаковывает LiveToolKit, а распаковать может только LivePlatform. Вся последующая информация о реализации модуля представлена в виде схемы базы данных на вышеприведённом рисунке. Для начала рассмотрим общие идеи, а затем перейдём к конкретному примеру реализации на рисунке. ####0. Общие cведения Защиту модуля можно организовать реализовав его или его содержимое в качестве базы данных. Также можно использовать шифрование. Слой может не содержать уроков, в этом случае элементы в нём не связаны с уроками и считаются бонусными. В модуле представлено много разнородной информации большого объёма, откуда появляется вопрос эффективно ли хранить элементы в БД? и в БД какого типа: реляционные или NOSQL, MongoDB в частности? какие элементы лучше не хранить в БД? ..и т.п. ####1. Lessons (Уроки) Поскольку не все элементы зависимы от урока, неправильно было бы оперировать другими элементами только относительно уроков. Каждый урок может содержать много картинок для наглядности, поэтому лучше хранить их отдельно от БД. Картинки вне БД необходимо будет пересохранить в виде файла в байтовом потоке (либо использовать шифрование), чтобы не дать доступ к ним графическим редакторам вне основного приложения. Текстовую информацию в уроке удобно хранить в виде html-текста. ####2. Exercises (Упражнения) Каждая "стопка" упражнений используется как правило для одного урока и маловероятен повтор упражнений в разных уроках. Поэтому упражнения можно жёстко привязать к урокам. На уровне БД -- это сделать поля в одной таблице. ####3. Books (Книги) Вывод значения нового слова и его произношение можно реализовать при помощи html- либо своих тегов. Другой способ -- использовать компоненты GUI Java более эффективно. Толи в SWING, толи в SWT был такой компонент -- веббраузер (в другой либе похожий по функционалу richedit), он может одержать инфу форматированную в html-тегах. Если такой компонент может ещё и javaScript исполнять -- цены ему не будет. Вывод значения нового слова и его произношение на javaScript-е не составит особых проблем. Картинок в книгах будет не много. поэтому их можно хранить в БД либо на жёстком диске без необходимости шифрования. Можно дать пользователю возможность просмотреть все доступные книги. ####4. Interactive Exercises (Интерактивные упражнения) Если есть возможность использовать JavaScript, то код программы можно хранить в бд и, когда надо, запускать в компоненте браузера в LivePlatform по вызову пользователя. Если же JavaScript не вариант, то можно посредством вызова определённых параметров запускать упражнение. Другой вариант -- использовать архитектуру клиент-сервер. В этом случае упражнение-клиент будет передавать даннные на форму LivePlatform-серверу. Эти данные можно использовать для отрисовки упражнения в определённой форме в LivePlatform. ####6. Videos (Видеоуроки) Качество 480 HD вполне подойдёт. Можно сделать так, чтобы пользователь имел возможность просмотреть все доступные видеоуроки, в том числе и бонусные. Для этого дополнительно надо будет предоставить краткую информацию о видео в сплывающей подсказке. ####6. Audio (Аудирование) Формат MP3 вполне подойдёт. Можно сделать так, чтобы пользователь имел возможность просмотреть все доступные аудиофайлы, в том числе и бонусные. Для этого дополнительно надо будет предоставить краткую информацию о аудио во всплывающей подсказке. ####7. Application (Приложение) Если приложение может содержать всё, что угодно, то порядок работы с его формами должен быть определён, и быть, по возможности, одинаковым для всех форм. ## Пример с рисунка Чем дальше в лес, тем больше дров: рассмотрим схему реализации более пристально на примере базы данных на рисунке. БД спроектирована в основном для переноса инфы в основную программу. Она напоминает солнышко -- в центре находится таблица Elements, в которой все элементы являются внешними ключами. И её "лучи" в виде связей направлены к ключевым полям других таблиц. Всей этой идилии мешает пара связей между Lessons и Books, Lessons и Interactive Exercises. Эти связи показывают зависимость интерактивных упражнений и книг от уроков. Таблица __*Elements*__ представляет собой то, что называется слоем. В диалоговом окне создания нового модуля, мы выбираем начальное количество слоёв в модуле (потом при необходимости можно добавить больше слоёв) и содержимое каждого слоя. Эта информация отражается в рассматриваемой таблице. Если рассмотреть таблицы группы *А* и таблицу *Elements*, то станет ясно, что связи между *Elements* и *Books*, *Elements* и *Intearactive_Exercises* лишние. Фактически эти связи используются для доступа к интерактивным упражнениям и книгам напрямую, как к элементам слоя. Эти связи поддерживают семантический смысл слоя в БД -- показатель наличия элементов и навигация по элементам через интерфейс слоёв. Таблицы в БД разделены на три группы по степени свободы (или степени зависимости) относительно таблицы уроков: А -- элементы зависимы от таблицы уроков. Их нельзя создавать не указав к какому уроку они относятся В -- элементы частично зависимы от таблицы уроков. Если урок не создан (в текущем слое), то эти элементы считаются бонусными. В противном случае -- они привязаны к уроку (в текущем слое) С -- элементы -- в данном случае только Application -- не зависимы от слоя. Есть ли, нет ли урока (в данном слое), элементы этой категории могут быть включены в слой. Они функционируют как бонусное содержимое или как другой описанный ранее объект Application. ###Зависимости со стороны LivePlatform Положим, на локальном ПК установлена LivePlatform в папку __*home*__. Для того, чтобы обеспечить возможность в разных уроках использовать видео, аудио и т.п. будем хранить материалы одного типа в одной папке. Пусть все материалы курса хранятся в папке __*data*__, тогда в папке __*home\data\lessons*__ хранятся уроки, __*interactive*__ -- интерактивные упражнения, __*audio*__ -- для аудиофайлов и __*video*__ -- для видеофайлов. Также в основном модуле необходима своя БД. Назовём её _*platformBD*_. О принципе действия такой структуры поговорим далее. Сейчас стоит отметить только, что хранение однотипной информации в одном месте позволяет избежать её дублирования. ###Разбор полётов Нетрудно заменить. что все таблицы, заисключением *Elements*, имеет примерно одинаковую структуру: + ключ (ID) -- первичный ключ, никак по другому это поле не используется + поле данных (Data) -- представляет собой основные данные, семантический смысл которых следует из названия таблицы + попе параметров (Param) -- дополнительные сведения об объекте; на первый взгляд, бесполезное во многих таблицах поле -- но это только пока не знаешь как его использовать Рассмотрим структуру и функционирование каждой таблицы. ####Lessons (Уроки) В этой таблице хранятся уроки и обычные упражнения. В поле параметров можно хранить ответы на упражнения. Пользователь, например пишет ответ в поле ввода, этот ответ сверяется с правильным, и результат проверки выводится на экран. Если необходимо мометить какие-то слова в уроке, эти слова тоже можно хранить в поле параметров. или хранить не сами слова а определённые теги, которые бы, например, показали что для определённого слова в тексте урока нужно вывести перевод во всплывающей подсказке и т.п. При установке модуля, в папку *Lessons\lesson_name* копируется приведенная на рисунке БД -- она выстумает как хранилище уроков, а в папку *Lessons\lesson_name* -- изображения в уроках и упражнениях. У уроков есть определённый порядок, который создаётся с целью постепенного обучения пользователя. Поэтому ID имеет здесь глобальное значение. Другими словами, если в одном модуле созданы уроки с ID 1-5, то в следующем модуле следующие 5 уроков будут иметь ID 6-10. Для указания LivePlatform в каком модуле какие уроки находятся, в *platformBD* необходимо отправить инфу об уроках в устанавливаемом модуле, а также названия уроков -- для вывода списка всех уроков, и может быть, краткую информацию об уроках -- для той же цели. Возможна ещё такая ситуация: мы выпуcтили модуль, в котором содержится только уроки. Через некоторое время мы хотим дополнить их упражнениями и другим материалом. В этом случае когда основное приложение обнаружит совпадение ID, записанных *platformDB* и отправленных с нового модуля, LivePlatformмодуль будет работать в режиме обновления -- она дополнит старый модуль информацией с нового. Это позволит при проектировании нового модуля поля Data оставить пустыми. Впрочем обновление материала следует продумать отдельно. ####Books Текст книги хранится в БД, картинки -- отдельно. При установке модуля картинки будут скопированы в *Lessons\lesson_name\books* -- изображения для книг. Определение новых слов, планируется использовать по html-тегам в тексте книги. Не вижу надобности здесь использовать поле Param. Однако если оно понадобится, добавить его не составит труда. Также как с таблицей уроков, необходимо отправить информацию о книгах в *platformBD* для отображения пользователю списка всех книг (название книги, к какому уроку принадлежит). Если бы книги хранились вне БД, то можно было б реализовать возможность использовать одну и ту же книгу в разных уроках -- однако в этом пока нет необходимости. ####Exercises_Interactive (Интерактивные упранения) Хранятся вне БД, при установке модуля копируются в папку *interactive* -- и в последствии запускается оттуда. В поле Data пишется название модуля либо краткая информация о нём. которая будет отображена в сплывающей подсказке или как краткое описание. Во втором случае названия модуля можно получать из названия файла. В Param хранятся параметры запуска данного модуля. В *platformBD* необходимо отправить информацию о каждом упражнении: название, краткая информация, какому уроку принадлежит -- для отображения списка упражнений. Основное приложение запускает упражнение, и посколькоку LivePlatform имеет постоянную свзь со своей БД *platformDB*, то параметры запуска упражнения можно также отправить в *platformDB* и запускать упражнение минуя чтение параметров с БД модуля. ####Video/Audio (Видеоуроки/Аудирование) Аудио и видеофайлы используется одинаковым способом: хранятся вне БД, при установке модуля копируются соответственно в *video* и *audio*. В Data последовательно содержится названия аудио/видео файлов в данном слое, а в Param -- краткая информация о каждом файле, которая будет отображена в сплывающей подсказке или как краткое описание. В *platformDB* отправляется информация для отображения списка всех аудио/видео файлов -- название, краткая информация и к какому уроку принадлежит (либо пометить как *бонусное содержимое*, если аудио/видео является бонусным) Еще Param можно использовать по-другому:задать в нём время начала и окончания воспроизведения файла, чтобы проиграть только часть файла. В этом случае совокупность видео/аудио файлов можно объединить в один соответственно видео/аудио файл. ####Application (Приложение) Этот полиморфный товарищ содержит в своих полях информацию в зависимости от формы. общим для всех форм данного элемента будет: + В одном слое можно содержать несколько приложений, но они должны быть только одного типа + Data -- список названий файлов, Param -- список параметров запуска для каждого приложения Ранее мы выделяли формы: 1. игру -- дополнительное (бонусное) содержимое в виде интерактивного упражнения не связанного с конкретным уроком; 2. обновление главного приложения; 3. рекламный банер; Рассмотрим поля таблицы и поведение системы в соответствии с выделенными формами: 1. Data -- на первой строчке тег *GAME* для идентификации типа приложения. При установке модуля, игры как и интерактивные упражнения, копируются в папку *interactive*, а в *platformBD* помечаются как бонусные. Также в *platformBD* отправляется информация о названии игры и о краткая информация 2. Data -- на первой строчке тег *UPDATE*. Зпускается при завершении установки модуля -- когда все другие елементы обработаны -- и выполняет обновление. В *platformDB* отправляется информация об обновлении 3. Data -- на первой строчке тег *BANNER*. При установке модуль копируется куда-нибудь откуда не догадаешься удалить. В *platformDB* ничего не отправляется -- по крайней мере для пользователя. Впринципе есть возможность хранить в одном слое приложения разного типа, но это будет противоречить и без того нарушеным в данной БД концепцияп БД. ####Об особенностях Почти вся информация копируется в *platformDB* поскольку приведенная на рисунке БД спроектирована для переноса информации к основному приложению. Таким образом, в БД остаётся только текстовая информация в виде уроков, упражнений и книг, которую также можно переместить в *platformDB* чтобы полностью расстаться с БД модуля -- это придаст единоначалие всем данным. С другой стороны, можно усложнить БД модуля и хранить всю информацию о слое в ней, а в *platformDB* передавать только сведения об уроках -- это позволить каждому урока работать с зависимыми данные в своей локальной среде, но будут накладные расходы когда необходимо работать со всеми данными -- например, выводить списки элементов. Если же оставить как есть, то в *platformDB* нужно отослать только данные о выводе в списках, и распаралеливать, например, места когда считывается названия совокупности аудио/видео файлов (Data) и их краткая информация (Param). Некоторые таблицы требуют отдельно поде *Name*. ##То о чём мы не говорим В этой статье описано рассказано о семи элементов слоя, а в мокапсах описано 8. Есть ещё особенный элемент о котором мы не говорим, пока не говорим, в силу сложностей с его реализацией. Didactics units (Дидактические единицы или ДЕ или DU) -- справочная информация по фонетике, синтаксису, морфологии и др. изучаемого языка. Это важная часть пособия, особенно потому как в учебникех по восточным языка такого деления не проводится. Если мы реализуем ДЕ -- большой плюс нам будет. В большей степени это зависит от лингвиста-составителя учебника. С технической сторны тоже ксть свои сложности. Самый простой способ реализации ДЕ -- поместить инфу в соответственные разделы в БД модуля. Однако нормальные герои всегда идут в обход: можно попробовать буквально собрать ДЕ из уроков. Схема примерно следующая: + Составляется урок, лучше несколько уроков + Составитель уроков разбивает информацию на определённые подзаголовки, некоторые из них могут быть не видны для пользователя -- например, Синтаксис. Однородные члены предложения + Затем он же тегирует полученные подзаголовки html либо своими определённными в LiveToolkit тегами -- например, "/<"DE ID=Syntax Title="Синтаксис. Однородные члены предложения">...."\<"/DE>" + LiveToolkit впоследствии при нажатии по волшебной кнопке генерирует ДЕ. ##Эпилог Поздравляю всех кто дочитал до конца! Вы сделали это, вы на себе испытали мощь LiveSDK! Был бы рад услышать как эту систему можно упростить в 10 раз без потери мощности и гибкости инструментария. Давайте поднимем эту софтину! Гайд по ЛайвТулКит бай Linx/Creative Works.
本源码包内暂不包含可直接显示的源代码文件，请下载源码包。
