ПМО ИУС — Автоматизация и разработка IT-инфраструктуры

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

Начальные условия

Прежде всего следует напомнить о том, какой мир был в то время. Так, в 2003-2005-м году Интернет не был таким доступным как сейчас — только dial-up за по нынешним меркам бешеные деньги со скоростью 2кб/с и постоянными обрывами связи. Возможности использования готовой SQL-БД резко ограничены как в силу отсутствия подходящих пакетов, так и потенциальной необходимостью переездов между серверами с соответствующим бюрократическим сопротивлением. HTML был максимум XHTML'ом, набирающим обороты. JavaScript максимум что делал, это проверял поля формы на правильность количества букв полей с диагностикой только через alert. Из web-языков царствовал PHP, его планомерно покусывал Perl, Java существовала в виде экзотических апплетов.

Что касается организационной части, то в этом плане картина для нас уже выглядела древней. Абсолютное большинство операций по выдаче заданий, контролю выполнения, предоставления информации в удобном виде, какой-либо автоматической обработки — не существовало. Преподаватели давали нам лабораторные в методичках, а индивидуальные задания в отдельных бумажных листочках. Многообразие вариантов представлялось собой максимум вариант номер N, иногда один из 2-4-х прямым текстом, иногда таблица, в которой студент номер N выбирает набор параметров в N-й строчке таблицы. Кроме этого, было много бумажной работы — мы многие отчеты либо писали вручную, либо печатали на одном на всю группу принтере, потом эти тонны бумаги куда-то надо было сдавать. Если обратить внимание, то на все это уходила уйма времени.

В течение последних лет в группах до сих пор постоянно на первых занятиях были студенты, которые приносили тетрадки для лабораторных работ (чтобы туда писать), и ещё много кто переписывал задания себе куда-то. Очень часто приходилось объяснять, что сервер доступен из любой точки БелГУТа, задания никуда не пропадут, можно быстро будет собрать отчет и вся бюрократия в электронном виде. На основании этого делаю вывод, что скорее всего со степенью автоматизации в ВУЗе все так же плохо, а студенты во время учебы зачастую занимаются переписыванием и перепечатыванием.

Когда информация о процессе выполнения работ собирается в одном месте, то появляются возможности делать над ней что-либо. Например, если мы смотрим в бумажный журнал, то можем посмотреть, сколько отличников а сколько двоешников в этой или этой группе, сколько было пропусков, сколько народу выполнило курс, провести какие-либо сравнения и т.д.. С точки зрения такой коллекции информации максимум что было, это преподавательский журнал. Единственный пример который мы видели другого плана — у Харлапа С.Н. в курсе ПМО МПС вся информация собиралась в Excel-табличке, которую потом можно было через FTP в R/O посмотреть. Но даже в таком варианте чувствовались плюсы — файл по сети можно забрать и посмотреть из сети, данные самые последние, можно смотреть всем и подумать над происходящим всем (преподавателю, студенту, декану, …).

Первый сезон

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

В это время Сергей Зобов выбивает и создает наш сервер кафедры, обеспечив стабильную и от-администрированную рабочую станцию, на которой размещается ряд ресурсов. Сначала это были странички, но по мере степень наполненности и сложность исполнения возрастала. Но в любом случае у нас появилась аппаратно-программная платформа, на которую можно было ориентироваться.

Было понятно, что если что-то делать в качестве предоставления информации, то нужно это делать на вебе. В то время веб эволюционировал быстро (что сейчас происходит не знаю), — браузеры и платформы были разными и жили каждый своей жизнью, кроме того, какие из новых фич станут стандартными было не понятно. Ко всему прочему война браузеров была и у нас в Университете — на ВЦ на старых машинах жил IE, на новых жестко прописанная админами Opera непредсказуемой версии, в аудиториях нашей кафедры была демократия и возможность выбора, а в оставшейся части ВУЗа — самый настоящий заповедник гоблинов. Поэтому те вещи, которые делались в первый год были пилотно-экспериментальными и мы быстро пришли к идеям пуленепробиваемого веб-дизайна (минималистичность самых стабильных фич, работающих везде независимо от всего).

Программный инструментарий также был не ясен (ввиду малого опыта в вебе). И на начальном этапе, например, эта табличка генерировалась с помощью EXE-программы на Pascal'e, данные для генерации вводили преподаватели (как набор флагов сдал-не сдал) методом редактирования файла удаленно с доступом по FTP. Кроме того, форма подачи несколько раз изменялась.

Приблизительно в это время я создаю сайт Гомельского Айкидо (все полностью, клиент-сервер, частично дизайн, форма подачи материала, … согласуя только содержимое и дизайн с руководителем объединения; до настоящего времени сайт функционирует на этой системе). Сайт несколько раз переписывался, начиная от набора страниц и заканчивая внутренним движком с файловой БД, полным разделением «данные→форма представления→оформление на устройстве» (на языке веб-разработки можно описать как «только полезная информация→HTML→HTML+CSS», наверно есть какой-то известный паттерн по этому поводу (; ), со своими внутренними велосипедами (свои счетчики, лента новостей, под-движки для фото-галерей, функциональности для статей, подсистема для создания меню и др..). В какой-то момент времени я взял то, что было сделано для сайта и фактически сделал форк на отдельную ветку.

Сейчас смотрю на сохраненные данные и исторически вижу, что уже во втором сезоне работы со студентами у нас было сделано многое для сервера ПМО ИУС и автоматизации процесса — переход всего на веб клиент-сервер нашего интРАнета.

Технические подробности

Основные функциональные вещи обеспечивала серверная часть, собранная на Perl'е. Выбор обусловился тем, что совсем рядом существовало две системы, написанные Максимом Кузьмичем тоже на Perl'e (система для автоматизации проведения олимпиад по программированию и система автоматизации тестирования студентов).

В качестве самого нижнего уровня для сайта и системы сервера ПМО ИУС использовалась мною написанная файловая БД. Такой выбор был сделан потому, что файловая БД менее независима от хостинга, не требует дополнительных ресурсов, легко перемещаема и редактируема с ориентиром на то, что будет справляться со своими задачами при небольших нагрузках. Не знаю как сейчас, но в то время с SQL-серверами были проблемы (на том же хостинге они стоили приличных денег).

Файловая БД позволяла создавать сущности в виде реляционных таблиц, в которых все данные представлялись в виде строк (потому что на Perl'ах все есть строка и типизация приводилась в конечном счете к ней). При этом имелась обязательное наличие PK (2NF) и было собрано ряд функций (такие как поиск поля, замена поля, получение содержимого таблицы в скрипт, сохранение изменений, кэширование таблиц находящихся в работе, работа в R/O не требующая синхронизации одновременно запущенных скриптов). Запускаемые скрипты при этом уже работали с непробиваемым слоем, под которым находились данные на диске.

Рядом с файловой БД находилась система по автоматизации предоставления материалов на сайте. Данная система использовала информацию из БД как опорную, по запросам пользователя выдавала уже веб-содержимое, обеспечивала поддержку взаимодействия с клиентом (cookie, регистрации и пр.) и как любая уважающая себя CMS, занималась управлением ресурсами сайта (общая система с хранением страниц, изображений, ссылок, менюшек, опций и пр., + функциональность к этому).

Данного собранного каркаса оказалось достаточно, чтобы за год взлететь и обеспечить базовую организацию всей информации курса (когда две большие разницы — информация в e-виде и способна быть извлечена и обработана программно, или она в чем-то, что читаемо только человеком). Далее на основании этого все данные, относящиеся к рабочему процессу (литература, задания, результаты, темы зачетов, контрольные сроки и т.п.) переместилось на сервер. В качестве примера автоматической обработки — генерация различных форм отчетов (таблиц рекордов, контрольных сроков и др.).

Архитектура и развитие

Глядя сейчас на историю могу сказать, что с точки зрения архитектуры сложилось все удачно. Угадалось то, что архитектура как таковая была очень минималистичной, т.е. не было жестких функциональных правил, а базовые сущности (что в БД, что в веб-движке) были простыми и легко поддающимися под любые запросы. Особенность последующих лет заключалась в том, что все, что над таблицами данных (интерфейс пользователя, веб-представление, формы генераторов, системы обработки запросов от студентов и преподавателей и др.), несколько раз переписывалось по причине того, что «No project manager plan survives contact with the development». Как только мы внедряли какой-либо вариант системы, то через месяц становилось понятно, что в ней есть существенные недостатки, которые выявлялись только после внедрения, когда конечные пользователи пробовали с этим что-то делать, а мы за этим наблюдали.

Если для типичных действий получается так, что делается 5 кликов по разным точкам, и понимаешь, что это можно-лучше сделать за 1-2, то это лучше исправлять. Если 5 из 10 человек регулярно не находят что-то, то с этим надо что-то делать. Если при каком-либо действии делаются ошибки, то надо организовать действие так, чтобы пользователь их делал намного реже, а лучше чтобы это контролировала автоматика.

Примечание к предыдущему абзацу — как организовывать этот процесс, важность конечного пользователя и зачем все это надо (я встречал всего пару человек, которые действительно как-то это понимают, и это — не программисты вообще) лучше всего видел в курсе Human Computer Interaction, рекомендую, достаточно посмотреть видео-лекции).

Прошло где-то 3 итерации, при которых существенно переписывалось почти все. Каждая из итераций — один семестр-год, так как когда процесс запущен, то что-то менять череповато. За один цикл обучения собирался список и в дальнейшем пересборка под новые изменения. Какая бы не была верхнеслойная архитектура, она отправлялась в мусорку. Важной и стабильной оказалась только самая нижняя часть системы — её универсальность, адаптивность, простота исполнения и прозрачность.

Финализация

Общий эволюционный процесс вышеописанного фактически остановился где-то в 2007-2008. Пилить систему было куда и зачем — фиксация удобной архитектуры, создание системы не только для себя но и для других (это отдельный большой кусок работы), куча фич вида отослать новые задания студентов на e-mail. Но в это время состав программистов курса на кафедре сокращается втрое, соответственно падает сила обратной связи и разнообразие опыта. Кроме того я сам перехожу на full-time в «Интервэйл» и ресурсы остаются только на поддержание системы.

К слову говоря, в свое время сайтовый фреймворк был переведен с Perl+FileBD на Java+SQL, но опять же, развитие потеряло свое поступательное движение.

ПМО ИУС — Развитие и общая тематика

О последующем периоде до настоящего времени писать проще, так как ведение курса и ответственность за него перешла на меня.

2005-2007

В это время Сергей Зобов переходит на другую дисциплину, а к ПМО ИУС официально подключается Максим Кузьмич, так как он в это время был в магистратуре. Где-то в течение этого времени периода плюс минус год всем курсом занимаемся мы втроем — я, Максим и Андрей Логвиненко. Отличительной особенностью этого времени является то, что все мы уже являлись программистами со значимым опытом, и при этом стиль работы каждого из нас определялась индивидуально — мы только обменивались идеями, согласовывали материалы лекций и темы лабораторных, а форма организации, индивидуальные задания и многое другое уже решалось каждым по-своему. И хочу сказать, она была существенно разной.

2008-2013

Не затрагивая изменения внутренностей курса, в первом году (плюс минус) покидают кафедру Максим Кузьмич и Андрей Логвиненко. Как результат из программистов остаюсь только я, и вести в таком ключе становится сложнее, так как такого рода курс требует серьезной подготовки. Система отношений в преподавательском составе дисциплины меняется из тройки независимых к чему-то более похожему на маленькую иерархию. Нагрузку на весь поток я взять не в состоянии, как результат за мной остаются лекции и 1-2 подгруппы микропроцессорщиков (это треть факультета, более ориентированного на микроэлектронику), остальными занимаются те, на кого удобнее на кафедре распределить нагрузку. Олимпиадное движение в это время затухает и расстворяется за отсутствием кого-либо, этим занимающегося. Над курсом я проводил ещё эксперименты и попытки улучшения, а также изменения содержимого для движения в ногу со временем, но стало понятно, что ресурсы уже не те.

Тематические изменения

В первом же году (2005) стали очевидными несколько проблем, которые стали понятны только к концу семестра. Первая из них — оставшийся материал и лабораторные по алгоритмам, которые коррелировали с тем, что мы знали и изучали на олимпиадном программировании. Так 3-я л.р. представляла собой работу с рекурсией, и как показала практика, для большинства студентов это оказалось слишком серьезным барьером. Без посторонней помощи его не преодолевал фактически никто, а для совместного решения необходима была кропотливая индивидуальная работа. Такая же история с графами, до которых дошли единицы. Поэтому их прохождение шло с существенными временными и моральными потерями, так как осваивание абстрактных вещей давалась с трудом. В связи с этим после первого же года были исключены все лабораторные работы с алгоритмами в пользу облегчения курса и большего уклона к ООП. Параллельно у нас был неофициальный кружок (в то время его организацией, автоматизацией, сервером, заданиями и прочим занимался Максим Кузьмич), который как раз посещали те, кто готовился к олимпиадам, и соответственно те способные студенты, которые потенциально хорошо могли освоить алгоритмизацию, при желании делали это там.

Вторая проблема заключалась в том, что лекции были больше теоретическими, о программной инженерии вообще, и поэтому слабо коррелировали с лабораторным курсом. Года 3 это существенно ощущалось и лекционный материал каждый год перерабатывался, более менее устаканившись к 2008-2009.

Существенным изменением, повлиявшим на весь курс, явился принцип общего проекта, который я различными способами старался усилить все время. Смысл его заключался в том, что цепочка лабораторных работ представляла собой единое целое, как проект, который постоянно нужно дорабатывать. Только первая лабораторная работа делалась с нуля, остальные — это изменения из предыдущей. Такой принцип работал сразу в нескольких положительных моментах. Во-первых, многие действия можно было вынести как повторяющие, и это усиливало закрепление материала. Например, со второй лабораторной все работы должны были быть оформлены строго по правилам оформления и собрана документация Doxygen. На каждой сдаче это строго контролировалось, поэтому студенту приходилось в случае лени переформатировать всю работу, писать комментарии и пересобирать Doxygen, и часто это приводило к пониманию того, что лучше оформлять правильно все сразу. После внедрения Subversion каждая лабораторная — отдельный commit, выделение тега, что тоже приводило к закреплению навыка. После внедрения Google Test — каждый раз написать тесты для новой функциональности, проверить, и только потом пускать класс в рабочую среду.

Следующее изменение — объединение нескольких тем в одну лабораторную работу. Л.р. становилась больше по объему, но при этом уменьшалось само количество лабораторных работ. Это раза в 2 снизило издержки по сдаче-приему-бюрократизации процесса (интересно, но эта идея была впервые озвучена деканом в процессе разбора полетов).

В один момент времени студент не мог работать больше, чем над двумя лабораторными работами, и это контролировалось автоматической системой выдачи заданий. Сначала были открыты только 1 и 2 работа, 3-я закрыта. Если студент сдавал полностью 1ю или 2ю, то открывалась 3я. И т.д. (идея взята с курса коллеги по кафедре Бориса Френкеля). Правило было жестким, и, таким образом, если студент ничего не сдавал весь семестр, то он не мог попытаться принести и сдать сразу все л.р.. Это все понимали, и оно давало ощутимый эффект.

В общем случае предыдущее нововведение являлось частью принципа, который когда-то нам озвучил Сергей Харлап, заключавшийся в максимальном переносе работы студента конца семестра (сессии, зачетной недели) в основное время. Смысл этого был в том, что невозможно чему-либо существенному научиться в короткие сроки. Что-то сделать (именно что-то, на что-то отдаленно напоминающее), списать, выучить на день, но не научиться. Элементы данного принципа внедрялись на всех уровнях. Например хорошим примером являлся Иван Матылицкий, который сдал все работы где-то за 1-1.5 месяца и был освобожден от посещения занятий. Остальная группа смотрит на это и понимает, что это возможно, и что это принципиально отличается от того, чтобы просиживать занятия.

По темам добавились абстрагирование, полиморфизм, инкапсуляция, среда RAD (построение GUI интерфейса), STL (алгоритмы и структуры данных), вернулись исключения. Первые 3-4 года существовал XML+HTML+CSS (общие принципы на 1.5 лекции и 1 л.р., разбор понятий validation, well-formed; XML; CSS; DTD). Была попытка внедрения л.р. по шаблонам (templates в C++), но оказалась неудачной в силу неусваивоемости и тотальной списываемости. Весь курс был обернут под SVN, Doxygen, Google Test, а также переведен на несколько проектов (несколько branches/tags с подключением через externals, об этом подробнее позже).

Изначально как основную среду мы использовали C++ Buidler. Основная причина — низкий порог вхождения для неподготовленных людей. Жестко недекларировалось (хотите приносите в VS, хотите хоть в Qt), но за все время все, кто хотел принести в чем-то другом, так этого и не сделали. Стартовали мы с C++ Builder 6.0, потом был 2007, 2009, и последний переход на XE2 — это был первый из билдеров, на котором скомпилировался Google Test, так как эмбакадеровцы меньше стали заниматься самодеятельностью и приблизились вплотную к VC.

ПМО ИУС — Становление

Начальное состояние

В то время, когда я учился в БелГУТе, то проходил этот курс (2000 год) и тогда он включал в себя ~ следующее содержание:

Базовая графика в C++

Нарисовать фигуру на экране с помощью графики CGI.

Интерфейсы управления мышь и клавиатура

Нарисованной фигурой управлять с помощью клавиатуры (по стрелкам) и мыши.

Базовые вопросы ООП: классы и объекты

Создать класс и объект, среда — Borland C++ 3.11.

Наследование

Создать два класса с наследованием друг от друга и продемонстировать результат.

Перегрузка операторов

Для существующего класса осуществить перегрузку операторов.

Полиморфизм

Только теоретически.

Дисциплину длительное время вел Семенюта А. Н.. В какой-то момент у него произошел конфликт с кем-то в университете и он ушел в другой ВУЗ (МИТСО).

В этот момент курс оказался в подвешенном состоянии, и его взял вести с условием только на один год Харлап С.Н.. Только после этого он был передан Андрею Логвиненко (потому что аспирантам первого года обучения не пристало вести лекции).

2003-2004

Лекции и содержание курса взял на себя Андрей Логвиненко. К ведению лабораторных подключился я и Сергей Зобов. По инициативе заведующей нашей кафедры Рязанцевой Н.В. одна из дисциплин на потоке была ликвидирована и по часам передана в ПМО ИУС, что расширяло общий объем где-то в 1.5 раза.

В это время было понятно, что содержание курса не изменялось лет 10, и с этим нужно было что-то делать. Но в какую сторону и что делать уже определялось нами. На содержимое больше всего повлияло то, что во-первых, Андрей в то время уже работал в «Интервэйле», и во-вторых, мы значительно были задействованы в олимпиадном движении (ACM), и все это наложило свой отпечаток.

В курс была введена тема о необходимости оформления кода и придерживания какого-либо стандарта. Для этого был фактически осуществлен copy-paste того, что на тот момент использовалось в «Интервэйле» — страница по ссылке являлась руководством по оформлению кода, а информация давалась как есть без какой либо адаптации.

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

К содержимому лабораторных добавились потоки (iostream), блочная работа с файлами (fstream, чтение-запись блоками), конструкторы-деструкторы, перегрузка операторов, ассоциативные контейнеры, исключения, изучение одного и того же на C++ и Java для сравнения, HTML 4.0.

По большому счету темы л.р. не были каким-либо образом систематезированы — на тот момент фактически брались известные из практики вещи и внедрялись в качестве тем и работ. При чем без понимания возможностей студентов, потому половину работ в срок выполняли единицы, а весь курс не выполнил никто (состояние потока за 1-2 недели до зачётов — запасная ссылка). До тем Java, исключений, HTML никто не добрался.

2004-2005

В следующем году были учтены многие ошибки, содержание курса было модернизировано, добавились темы работы с графами и рекурсии, форматированного ввод-вывода на C++ с созданием своих манипуляторов, динамических структур данных, убрана Java и исключения.

С результативностью получилось уже лучше (резервная ссылка).

Такие результаты обусловлены многими причинами. Нами начались использоваться инструменты автоматизации — мною была разработана веб-система выдачи заданий, предоставления студентам информации курса и автоматического генерирования результатов (которая эволюционировала до настоящего времени), а Максим Кузьмич разработал систему тестирования (вопрос-ответ-результат для проверки знаний по л.р. или курсу) — она в ПМО ИУС использовалась где-то 2-3 года, а на другой дисциплине (ПМО МПС) используется до сих пор.

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

Самой главной причиной улучшений в этом и последующих годах являлся человеческий фактор и накопление педагогического опыта. Это большое число различных моментов, о которых сложно узнать или понять, ни разу с этим не столкнувшись. Абстракции — для опытных и профессионалов, само обучение начинается с конкретики. Первое приближение самое важное, а в нём детали совершенно не нужны, важна только ключевые идеи. Люди разные, и объяснять одно и то же одинаковым образом нельзя. Чтобы научиться чему-то принципиально важному, его нужно повторять и повторение внедрять в курс. Если сказать, что л.р. можно сдавать до зачета в любое неважно-какое-время, то они и будут сдаваться в самый последний момент. Заставить и продавить — можно, но может получиться так, что факел у этого человека уже никогда не зажжется и программирование останется страшным кошмаром. …

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

Кафедра — все

Где-то на этой или следующей неделе заканчивается мой трудовой договор на кафедре «МТ и ИУС» БелГУТ'а, и в моем сознании он последний. Может быть будет что-то частичное, вида прочитать отдельную лекцию, вести кружок или отдельная роль дипломного руководителя.

Преподаванием начал заниматься с 2003-го года, во время обучения в магистратуре. С этого времени на кафедре занимался только одним предметом (ПМО ИУС — это С++/ООП, или просто продвинутое программирование) — подробнее позже.

Первые два года это были только ведение лабораторных, но с 2005-го года мне был передан весь курс, и при этом расширен по предоставляемому объему по часам (поток более 100 студентов, 1 семестр, 36 часов лекций, 52 часа лабораторных). До настоящего года через меня прошло 10 потоков (в один из был перевод дисциплины с 3-го на 2-й курс, соответственно 2 раза за год) и ~ 10 дипломников.

Преподавания на полную ставку у меня за все это время не было, нагрузка была где-то немногим более 0.5 ст. в начале и в дальнейшем плавно уменьшалась до 0.25. Получалось так, что сначала мы занимались разработкой «i-Пути» + аспирантура, а с 2006-2007 года я начал работать в «Интервэйл». Тот опыт, который получался, автоматически влиял и транслировался на сам курс.

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

В самом начале все было здорово и интересно — когда с Андреем Логвиненко, Сергеем Зобовым и Максимом Кузьмичем все вместе формировали курс. В дальнейшем все шло более по накатанной и после ухода коллег и ухудшения политической ситуации содержать все это стало намного сложнее.

Хочу сказать и говорю отдельное спасибо потоку, являющемуся выпуском 2009-го года. Без вас мое преподавание закончилось бы на лет 7 раньше.

MyZeo is «out of business»

Судя по всему, компания MyZeo (о которой было от меня пара сообщений) где-томесяц назад прекратила свое существование и вышла из бизнеса.

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

Для меня основную функцию Myzeo выполнил, но сам факт удручает.

В общем же случае на свете уже есть и другие системы, позволяющие делать что-то подобное. При чем как более сложные (с видеокамерами, снятием ЭЭГ, …), так и попроще (небольшой датчик движения).