ClassCard

  • ClassCard - фирма-разработчик системы сервисов, основанных на использовании бесконтактных RFID карт. Система ориентирована на учебные заведения, но может использоваться и в других сферах.
  • Carddex - разработчик оборудования, используемого в системе ClassCard.
  • УЭШКА - торговая марка системы ClassCard для школ.

Моим первым заданием была разработка драйвера для устройства, которое подключается через USB как виртуальный COM-порт, с доступом через сеть. То есть, приложение не может с ним работать напрямую, как с COM-портом, поэтому COM-порт шарится в сеть и приложение работает с ним через сеть. Так были разработаны первые компоненты DataPort и заготовки для CarddexLib.

Далее, я занимался разработкой Web-API сервисов для приема платежей, интеграции с другими системами (Qiwi, Cyberplat, «Виртуальная школа»), кросс-доменной авторизации. Использовал Python, Tornado.

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

Дорабатывать кассирку приходилось непосредственно в школе. Я подключил к кассирке WiFi-точку и сел с ноутбуком в углу зала, так чтобы видеть происходящее возле кассы. При этом у меня был удаленный доступ к кассирке, я видел ее экран и логи. За пару перемен, наблюдая за действиями кассира и просматривая логи в реальном времени были выявлены и исправлены некоторые серьезные проблемы.

Кассирка была написана на Дельфи и работала только под Windows, а запускали ее на Linux под эмулятором Wine. Это влекло некоторые трудноустранимые проблемы в работе с оборудованием, поэтому решено было переписать ее на чем-то кроссплатформенном. Попробовал Python с QT, это вполне реально, но у питона есть проблемы с многопоточностью и не хватает готовых решений для печати и работы с оборудованием. Попробовал Lazarus - оказался на удивление хорош и постоянно улучшается. Еще ни разу не жалел о выборе. Переписал кассирку, она стала кроссплатформенной и отлично работает на Cubieboard (Linux, ARM). Но есть проблема с тем, что для ARM нет клиента Oracle, поэтому пришлось обращаться к базе данных не напрямую, а через Web-API. Впрочем, можно использовать кроссплатформенный OCILib.

Для оперативного отслеживания состояния устройств понадобилась система мониторинга. Из готовых выбрал NetXMS, испытал ее, но развертывать не стал - это задача для техподдержки и сисадминов. Сам же написал агента - программу, которая работает как сервер Syslog, принимает сообщения от разных устройств, выделяет в них сообщения об ошибках. В дальнейшем агент совершенствовался - добавлялись разные настройки, задания, действия.

В качестве эксперимента написал на Лазарусе систему управления турникетами по образу и подобию имевшейся. И внезапно она пригодилась, поступил заказ на автономный СКУД. После недолгих доработок, получилась простая автономная СКУД для КПП, со своей базой данных - KPPLite.

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

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

Помимо вышеперечисленного, были экспериментальные работы разной степени завершенности по разным направлениям - GPS-трекер для учеников, web-интерфейсы для оборудования, программы для тестирования и настройки оборудования, демонстрационные программы.

Comments