Меня зовут Максим Роньшин. Я создал несколько десятков программных продуктов и сервисов, создал и наладил производство оборудования, создал несколько компаний. Я – создатель. Я умею делать то, что нужно конкретным клиентам, умею решать их проблемы и строить бизнесс-процессы.

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

При этом многие проекты – это готовые бизнесы. Целью данного блога является рассказать всем об этих проектах с целью найти партнеров, инвесторов или клиентов. Кому-то я могу дать права на реализацию, кому-то готовый бизнес под ключ. А кто-то, возможно, захочет развить данные идеи.

Mobilensurer - Заметка о технологиях

Требования к проекту (как они были сформированы до начала проекта)

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

1. Текстовое поле (фамилия, имя, т.п.)

2. Сумма в гривнах (валюте)

3. Выбор одного из предопределённых вариантов (фиксированные суммы страхования, фиксированные периоды страхования)

4. Логические значения (включено/выключено)

Многие из этих полей были логически связаны друг с другом (к примеру, какие-то опции могут быть доступны только при определённых значениях других опций)

Пользователь должен был иметь возможность создать набор страховых полисов для их последующей отсылки на сервер компании через HTTP или e-mail (SMTP)

Клиентская программа должна поддерживать возможность работы в on-line, с периодическим подключением к on-line и off-line:

●       on-line (постоянный или с периодическим подключением) - программа должна была остылать данные на сервер через HTTP или SMTP

●        и off-line - отсылка полисов на сервер должна была происходить при участии человека - программа должна была записать zip-файл на сменный носитель, человек должен был загрузить этот файл на сервер через web-интерфейс

Программа должна была уметь генерировать отчёты в формате MS Excel и MS Word.

Основными требованиями к реализации программы были:

1. Небольшой размер. В идеале программа должна была в упакованном виде помещаться на дискету (1.44Mb)

2. Возможность работы на слабых компьютерах и устаревших ОС Майкрософт: Windows 98, Windows 95

3. Расширяемость - возможность легко добавить поддержку новых форм сбора данных.

Техническое решение

Для обеспечения максимальной гибкости при сохранении небольшого размера программы было выбрано следующее решение:

1.     Ядро программы пишется на нативном языке (C++) без использования дополнительных фреймворков.

2.     Поскольку требования работы под ОС отличные от MS Windows не стояло, практически весь UI программы был сделан при помощи MSHTML. Фактически, ядро программы не содержало кода связанного с UI. Вместо этого сразу же в основном окне  поднимался IE ActiveX, которому на вход подавалась HTML-страница которая и отображала пользовательский интерфейс. Достоинства такого решения:

a.     Интерфейс пользователя создавался при помощи HTML/CSS и JavaScript, что дало возможность быстро прототипировать внешний вид приложений. К тому же, это дало возможность использовать существующие решения которые были разработаны для Web-приложений.

b.     IE установлен практически на всех ОС Майкрософт, начиная с Windows 95. Для корректной работы наша программа требует наличия IE 5.01, найти компьютер под управлением Windows без IE 5.01 или выше практически невозможно, да и в этом случае IE 5.01 ставится на компьютер за считаные минуты. Теоретически, можно было обеспечить поддержку IE начиная с 4.0 - но это потребовало бы дополнительных усилий и было признано нецелесообразным.

c.      Размер ядра программы (С++ - кода) получился очень небольшим. HTML содержит достаточно средств для создания UI, в итоге размер exe-файла составил около 1Мб, размер HTML/CSS/JS варьировался в зависимости от количества и сложности форм для данного конкретного заказчика, но в среднем редко превышал в сумме 1Мб.

d.     Программа не требовала инсталляции (и прав администратора) и могла быть запущена из любого каталога.

3.     Для хранения данных форм был выбран формат XML. Как альтернативы ему рассматривалось хранение данных в базе (но наличие даже небольшой встроенной базы данных класса SQLite увеличило бы размер EXE-файла минимум на 50%, к тому же при фатальных программных или аппаратных сбоях на стороне клиентов восстановление данных из XML выглядело куда более простой задачей чем восстановление данных из базы) и хранение данных в формате JSON (было отклонено поскольку подавляющих преимуществ JSON перед XML не имеет, при этом файл с данными форм был предназначен для импорта различными системами сборами данных - а импорт из XML поддерживается чуть лучше чем импорт из JSON).

4.     Формат XML также был использован для хранения “входных данных” форм (т.н. “справочников”) - к примеру, список вариантов сумм страхования и т.п.

5.     Поскольку бОльшая часть данных и кода программы была доступна на диске в виде XML и JS файлов встала задача защиты от злоумышленника. Злоумышленник мог изменить XML-файл вручную или изменить JS файл меняя логику работы программы. Чтобы избежать такой ситуации, все XML и JS файлы которые загружались программой были подписаны. Для каждого файла при загрузке вычислялся его хэш (использовалось MS Crypto API) и этот хэш сверялся с хранимым в начале файла. Если хэш не совпадал, программа сообщала о проблеме и прекращала работу.

6.     Программа поддерживала автоматическое обновление как XML/JS скриптов так и EXE-файла. Для этого при каждой загрузке файлов с данными форм на сервер запускалась проверка наличия более свежей версии.

7.     Формирование отчётов в MS Excel и MS Word (а позже и в аналогичные программы Open Office). Для того чтобы сделать эти отчёты максимально гибкими, была применена следующая схема:

a.     Шаблон представлял из себя обычный файл MS Excel/MS Word

b.     В тех ячейках MS Excel (для MS Word их аналогом были закладки “bookmarks”) куда требовалось вставить реальные данные в шаблоне стоял JS код со специальным префиксом. Префикс использовался для поиска JS кода, после чего он обрезался и JS код запускался на выполнение. Это позволяло обращаться к любым данным формы, выполнять над ними арифметические операции или операции со строками и т.п. После выполнения JS кода полученный результат вставлялся в ту же ячейку.

c.      Для поддержки OpenOffice была использована та же схема. OpenOffice для Windows тоже позволяет обращаться к своим из JS, но имеет абсолютно другой API. Для того чтобы работать единообразно с MS и OpenOffice было создано внутреннее JS API которое скрывало разницу в реализации доступа к файлам различных офисных пакетов. В итоге один и тот же шаблон отчёта можно было использовать как с OpenOffice так и с MS Office

Перспективы развития, или современный вариант решения той же задачи

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

При относительно небольшой цене они обеспечивают мобильность и наличие как минимум периодического подключения к интернет.

Вот то как видится современное решение этой же задачи:

Web-приложение с возможностью работы offline. Современные браузеры (WebKit, Mozilla, последние версии IE или старые версии с установленным плагином Google Gears) поддерживают т.н. AppCache который позволяет приложениям запускаться даже если подключения к интернету нет. Ещё одна технология которая делает возможным работу в off-line - это возможность сохранения данных на стороне клиента (Client-sidedatastorage). В сумме они дают возможность создавать “гибрид” впитывающий в себя лучшие стороны Web-приложений (возможность работы с широкого спектра устройств с различными ОС, остутствие этапа установки приложения) и клиентских приложений (возможность работы без доступа к интернет). Огромным плюсом такого подхода является то что единожды созданное приложение позволит работать пользователям с практически любого современного устройства поддерживающего доступ в интернет: Android-smartphone, Android-планшет, iPhone/iPod, iPad, нетбуки, десктопы.

Для серверной части интересным решением мог бы стать Google App Engine - большим её преимуществом видится бесплатность для небольших приложений сочетающаяся с высоким показателем uptime.

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer