Ст преп каф сис прог. Антипов И. Г - korshu.ru o_O
Главная
Поиск по ключевым словам:
страница 1
Похожие работы
Ст преп каф сис прог. Антипов И. Г - страница №1/1




Санкт-Петербургский государственный университет

Математико-механический факультет

Кафедра системного программирования

РАЗРАБОТКА СИСТЕМЫ ПЕРСОНАЛИЗАЦИИ КОНТЕНТА ДЛЯ МОБИЛЬНЫХ КЛИЕНТОВ

Дипломная работа студента 545 группы

Зарубина Михаила Сергеевича



Научный руководитель

………………
/ подпись /

к.ф.-м.н., Кириллин В.А.

Рецензент

………………
/ подпись /

ст.преп. каф. сис. прог. Антипов И.Г.

“Допустить к защите”
заведующий кафедрой,

………………

/ подпись /



д.ф.-м.н., проф. Терехов А.Н.

Санкт-Петербург

2015

Saint-Petersburg State University

Mathematics and Mechanics Faculty

Software Engineering Department

Development of System for Personalised

Content Delivery on Mobile Clients

Graduate paper by

Mikhail Zarubin



Scientific advisor

………………

PhD. V.A. Kirillin

Reviewer

………………

Senior lect. I.G. Antipov

“Approved by”
Head of Department

………………

Professor A.N. Terekhov

Saint-Petersburg

2015

Оглавление


Оглавление 4

Введение 4

Постановка задачи 6

1. Обзор средств и подходов 7

2. Описание решения 8

2.1) Организация процесса разработки и тестирования сервера 8

2.2) Разработка архитектуры базы данных 12

2.3) Разработка протоколов общения сервера и клиентского приложения 12

2.4) Механизм выдачи персонализированного контента 17

2.5) Персонализированный учет статистики 20

2.6) Таргетированная выдача контента. 23

2.7) Система, позволяющая отслеживать ошибки приложений 26

Заключение 30

Список литературы 31




Введение


О предметной области:

Проект SmartKupon (c) - (www.smartkupon.ru) – это новый рекламный инструмент, который включает в себя бонусную программу и купоны в приложении мобильного телефона: в заведениях партнеров предъявляется бонусная карта SmartKupon, клиент получает за это бонусные баллы, а потом использует их для получения приятных сюрпризов.

SmatKupon – это система мобильного маркетинга, состоящая из трех основных компонент: клиентское приложение, сервер и валидатор (рис. 1).

Рис. 1


Клиентское приложение SmartKupon - это программа в мобильном телефоне, которая доступна для установки совершенно бесплатно каждому владельцу практически любого современного мобильного устройства. На данный момент она реализована для основных мобильных платформ: J2ME, iPhone, Android, Windows Mobile.

Серверная часть – это комплекс, состоящий из нескольких компонент, схематически изображенных на рис. 2.

Валидатор - устройство-приложение. Оно предназначено для считывания кода бонусной карты и начисления баллов клиенту, а так же погашения купонов.

Рис.2


Постановка задачи

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



В частности, стояли такие задачи:

  1. Организация процесса разработки и тестирования сервера.

  2. Разработка архитектуры базы данных.

  3. Разработка протоколов общения сервера и клиентского приложения.

  4. Механизм выдачи персонализированного контента.

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

  1. Персонализированный учет статистики.

В панели администратора должна быть возможность увидеть:
где, кто, когда и как узнал про мобильное приложение, смог ли его установить и воспользоваться им. Должна храниться полная история действий каждого пользователя и предоставляться маркетологам в удобном виде.

  1. Таргетированная выдача контента.

Пример: в первую очередь выдавать пользователю наиболее интересные лично ему предложения.

  1. Система, позволяющая отслеживать ошибки приложения клиента и просматривать историю всех операций каждого пользователя в отдельности.

Цель работы: Разработать серверную часть системы, реализовав вышеперечисленные пункты, и интегрировать ее с клиентским приложением.


1. Обзор средств и подходов



Используемые технологии и окружение сервера:

  • СУБД – MySQL [20]

  • Система для проектирования баз данных MySQL Workbench [19]

  • Остальные компоненты, написанные на языке Java с применением библиотек Spring [24], основное взаимодействие идет через HTTP Servlet [21]

  • Контейнером сервлетов является Apache TomCat [22]

  • Взаимодействие с базой данных осуществляется посредством драйвера JDBC с применением фреймворка iBatis

  • Пользовательский веб-интерфейс реализован через JSP с применением технологии JSTL [23]

  • Логи сервера ведутся с помощью библиотеки log4j

  • Взаимодействие сервера с клиентом осуществляется через протокол, основанный на технологии XML, в качестве парсера и генератора используется Simple XML


2. Описание решения

2.1) Организация процесса разработки и тестирования сервера


  1. Программная и аппаратная составляющая

Любой сервер всегда состоит из аппаратной и программной части. Самое первое, с чем необходимо определиться, будут ли это облачные вычисления или своя машина, с которой вы вправе делать все, что угодно. Сейчас стали весьма популярны облачные серверы типа Amazon Web Services или Google App Engine. После изучения архитектуры всех крупных и популярных интернет сервисов [3] оказалось, что “облака” используются не в качестве основных серверов бизнес-логики, а только как хранилища больших объемов пользовательских данных, таких как изображения или видео файлы. Поэтому было решено использовать свою машину. В большинстве случаев выбор аппаратной части завит только от количества доступных ресурсов, поэтому то, как производился выбор серверной машины, рассматриваться в работе не будет.

Software составляющая:

Основываясь на обзорах операционных систем [1], в качестве серверной ОС был выбран Linux Debian [2]. После изучения преимуществ виртуализации [4] было принято решение отказаться от использования напрямую аппаратных средств. По завершении анализа виртуальных машин [5] была выбрана OpenVZ [6]. Основная особенность OpenVZ – это виртуализация на уровне операционной системы [7]. За счет этого достигается максимальная производительность при виртуализации, и, согласно сайту OpenVZ, падение производительности составляет всего 1-3% по сравнению с обычными Linux-системами.

Организация виртуальных машин помогла с легкостью настроить 2 виртуальных сервера: сервер пользователей, на котором установлены последние стабильные версии системы SmartKupon, называемый в обиходе “релизным”, и сервер с полной копией окружения, на котором происходит тестирование при разработке – “тестовый”.



  1. Организация коллективной разработки

В наше время при разработке любого крупного программного продукта не обойтись без использования систем управления версиями [10]. Только возникает вопрос, какую систему выбрать, ведь их в данный момент существуют десятки. По завершении анализа наиболее популярных систем [11] была выбрана SVN [12]. На протяжении долгого времени нас она полностью устраивала. Но в связи с особенностями разработки в нашем проекте, в какой-то момент возникли трудности по причине того, что некоторые разработчики работают на нескольких компьютерах: рабочем, домашнем и ноутбуке. Соответственно, чтобы перенести код с одной машины на другую, приходится делать commit в SVN и последующий update. Казалось бы, это нормальный процесс, и все именно так и делают. Но иногда возникают проблемы такого рода: разработчик устроил большой “рефакторинг” на работе, так что у него перестал собираться проект, но сейчас нет времени все это исправить и он хочет перенести все изменения к себе на ноутбук, не делая commit некомпилирующегося кода в общий репозиторий. Конечно, можно сделать себе отдельную ветку, а после внесения исправлений произвести ее слияние с основной, но тогда возникает такая неприятная вещь, как ручной merge. Чтобы таких проблем приходилось решать как можно меньше, было решено перейти на распределённую систему управления версиями файлов, выбор остановился на GIT [13]. Там эта проблема решается таким образом: если необходимо перенести код с одной машины на другую без внесения изменений в центральный репозиторий, то можно сделать commit и push на другую машину. Эта практика оказалась очень удобной в таких ситуациях.

  1. Непрерывный контроль качества

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

Т.е. возникает необходимость в регрессионном тестировании [14]. По завершении анализа современных средств тестирования [15] был выбран Apache JMeter [16], т.к. он имеет возможность подключать большое количество плагинов, в частности, драйверы JDBC для MySQL, имеет встроенный язык, совместимый с JavaScript и средства для проведения нагрузочного тестирования [17].

Для скорейшего понимания разработчиками того, какие тесты не прошли проверку, было решено автоматизировать процесс непрерывного контроля качества. Изучив различные серверы непрерывной интеграции, нашли решение похожей задачи на примере Hudson [18]. Решающим фактором для внедрения данного сервера стало наличие к нему плагина для JMeter. Теперь, когда разработчик добавляет новый код в репозиторий, Hudson автоматически создает новую сборку и запускает все тесты. В случае провала успешных ранее тестов разработчику отправляется отчет на электронную почту, в котором указывается номер теста и ревизии. Это позволяет разработчикам в кратчайшие сроки обнаружить и устранить допущенные ошибки.


  1. Регулярный выпуск релизов

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

2.2) Разработка архитектуры базы данных


В качестве СУБД была выбрана MySQL [20]. Для разработки схемы базы данных используется утилита MySQL Workbench [19]. База данных, как и весь проект, разрабатывается итеративно. Т.е. новые таблицы создаются по мере их необходимости. Один из самых важных моментов – понять, что следует хранить в базе данных, а что лучше хранить в другом месте, например, в файловой системе. Изначально было принято решение хранить все картинки в базе данных в виде полей типа BLOB, что позволяет гарантировать целостность данных и упрощает процесс переноса релизной базы на тестовые серверы, т.к. при копировании исключается возможность потерять какие-либо файлы. Однако практика показала, что данное решение является неэффективным из-за медлительности работы массовых запросов на файлы больших размеров к базе данных по сравнению с аналогичными запросами к файловой системе. Поэтому было решено хранить в базе данных только оригиналы изображений и MD5 хеши на их копии с другими размерами, а сами копии хранить в файловой системе.

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

Более детально ознакомиться с основной схемой базы данных [8] можно в Приложении 1.

2.3) Разработка протоколов общения сервера и клиентского приложения

Система SmartKupon разработана по классической архитектуре клиент-сервер, т.е. сервер отправляет ответ только в случае, когда клиент посылает запрос. Весь протокол реализован на XML. Все запросы имею одинаковые заголовки вида:


...



А все ответы имеют заголовки вида:

...



Сервер поддерживает передачу данных со сжатием с использованием стандарта gzip. Если клиент поддерживает сжатие, для включения сжатия ответов сервера необходимо добавить в запрос следующий заголовок:
Accept-Encoding: gzip

При этом в соответствии со стандартом HTTP клиент обязан проверить, что полученное содержимое сжато прежде, чем его распаковывать. Для этого служит заголовок ответа сервера:

Content-Encoding: gzip

Как показала практика, за счет применения сжатия объем трафика уменьшается на порядок. Но лучше всего подвергаются сжатию запросы от клиента, содержащие логи приложения, их получается сжимать в ~50раз.


Для выполнения всех необходимых задач были реализованы следующие виды запросов:


  • Регистрация

  • Отложенные запросы

  • Синхронизация

  • Запрос купона

  • Запрос карты лояльности

  • Запрос картинки купона или бонусной карты

  • Действия кнопок

  • Обновления

  • Пинг

  • Запрос ресурса

  • Отправка логов

  • Комбинированные запросы

  • Ошибки

Для примера рассмотрим запрос регистрации:


Запрос:










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


Ответ:


Сервер в ответ присылает клиенту его номер в системе, именуемый public-id. Этот номер необходим для осуществления некоторых операций с лицевым счетом клиента. В частности, при возникновении каких-то проблем именно этот номер нужно сообщать при запросе в техническую поддержку.
При тестировании корректности ответов сервера применяются XML схемы. Так выглядит XML схема ответа на запрос регистрации:
 

-

-

-

 

 

 

 

 

 

 


 


 

Чтобы лучше понять специфику клиентского приложения, рассмотрим алгоритм работы клиента на примере запроса синхронизации:

Запрос:




 

 

 

 

 




















 













 


Запрос синхронизации является самым основным в работе клиента: если не удается выполнить этот запрос, то дальнейшая работа приложения становится невозможной, т.к. тут передается информация обо всех ресурсах, необходимых клиенту. В шаблоне запроса, который приведен выше, показано, что запрос синхронизации клиент отправляет уже не первый раз, т.к. у него уже есть небольшой список купонов и бонусных карт. Основная идея запроса синхронизации заключается в том, чтобы сообщить серверу состояние клиентского приложения, а сервер “подумал”, что необходимо изменить у клиента, и отправил ему всю необходимую информацию. Самый простой способ, с помощью которого можно понять состояние клиента, - это передать информацию обо всех ресурсах на сервер. Но этот вариант не эффективен, т.к. влечет большие затраты по трафику. Для устранения данного недостатка было решено группировать ресурсы в блоки и ввести понятие версии ресурса. Поэтому в запросе синхронизации передается только информация о версии ресурса (например, купона) или версии блока (например, категории). Т.е. клиент передает версии всех ресурсов, которые у него имеются, сервер “смотрит”, какие из них обновились, и отправляет обновленные данные о ресурсах, которые клиент должен запросить в следующий раз. Чтобы понять механизм синхронизации более детально, нужно обратиться к схеме, изображенной в Приложении 2.

2.4) Механизм выдачи персонализированного контента


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

Для того чтобы реализовать данную возможность, сервер должен “уметь” следующее:



  • Различать клиентов и хранить данные о состоянии приложения клиента

  • Определять характеристики мобильного устройства (например, разрешение экрана)

  • Сжимать изображения JPEG компрессором

  • Хранить сжатые изображения

Для определения характеристик мобильного устройства клиент отправляет на сервер свое разрешение экрана в запросе регистрации. Эти данные сохраняются в таблице Client_Hardware в соответствующих полях (см. Рис 3).



Рис. 3


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

Помимо изменения размеров изображения есть еще одна немаловажная задача: сжатие изображения. Она возникает из-за необходимости в экономии трафика на мобильных устройствах. В стандартных Java библиотеках есть только методы для сохранения jpeg в 100% качестве. Но если сжать изображение в 85% качества, то на глаз разница будет практически не заметна, а объем уменьшится в 1,5 – 2 раза.

Для автоматизации этого процесса была найдена утилита GraphicsMagick [9]. Пожалуй, самая простая и более-менее точная характеристика этого приложения будет, если назвать его “консольный PhotoShop”, распространяемой под лицензией, совместимой с GPL.

При изучении формата JPEG было обнаружено, что в файлах содержится “ненужная информация”, а именно ICC-профили и Exif данные (см. табл. 1).



Маркер

Байты

Назначение

Комментарии

APPn

0xFFEn

Задается приложением

Например, в Exif JPEG файле используется APP1 маркер для хранения метаданных, расположеных в структуре, основанной на TIFF.

COM

0xFFFE

Комментарий

Содержит текст комментария.

Таблица 1

Программы типа PhotoShop добавляют в каждый файл свой ICC-профиль и Exif данные. Предполагается, что эти данные способствуют правильной передаче цветов изображения. Но большинство современных приложений просто игнорируют эти данные, т.к. используют свои собственные профили, и тем более это игнорируется на мобильных устройствах. Иногда размер этих кусков достигает нескольких десятков килобайт. Поэтому решено было провести эксперимент, насколько меньше будет размер файла изображения, если из него удалить все “ненужные” данные. Эксперимент проводился на разных файлах, результаты были примерно одинаковы. Ниже будет приведен пример с одним файлом.

По статистике самый популярный размер изображений, используемых в системе SmartKupon, составляет 300x360 пикселей, поэтому за основу взяли именно такое изображение (см. рис. 4а).










Рис. 4а

Рис. 4б

Рис. 4в

Рис. 4г

В таблице 2 приведены данные по различным методам сжатия. Сами сжатые изображения ничем не отличаются в визуальном представлении, т.к. имеют одинаковую степень сжатия (см. рис. 4). Оригинальное изображение было создано в PhotoShop и сохранено в 100% качестве.







Размер в пикс.

Качество

Объем

Рисунок

Оригинал

300x360

100%

177Кб



ACDSee

300x360

85%

61Кб



PhotoShop

300x360

85%

114Кб



GraphicsMagick

300x360

85%

35Кб



Таблица 2
Как видно из таблицы, при использовании GraphicsMagick можно достичь уменьшения объема файла в 2-5 раз. Это становится возможным, если в GM настроить удаление всех “лишних данных”, таких как профили и Exif.

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



2.5) Персонализированный учет статистики

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


Основные типы действий, которые учитываются в статистике:
Ввод суммы sum при предъявлении Бонусной карты

Открытие взятого купона couponId

Отклонение взятого купона couponId

Переворот купона или бонусной карты cardId

Предъявление купона couponId

Нажатие кнопки «Как проехать?» купона couponId

Выбор точки проезда outletId в экране «Как проехать?» купона couponId

Нажатие кнопки “i” купона couponId

Нажатие кнопки “О заведении” купона couponId

Взятие купона couponId

Выбор на карте точки продажи outletId

Выбор станции метро metroStationId

Выбор категории categoryId

Ввод промо-кода promoCode

Каковы же основные области применения данной технологии:


  1. Автоматизированный механизм нахождения наиболее интересных (и наименее интересных, соответственно) рекламируемых товаров и услуг для целевой аудитории. Т.е. на основании собранной статистики автоматически строятся таблицы с данными о том, какие категории предложений больше всего интересуют пользователей. Какими чаще всего пользуются, о каких заведениях больше всего читают подробную информацию, в каких местах люди чаще всего открывают приложение SmartKupon и т.п. А так же автоматически подбираются наиболее интересные предложения для данного конкретного пользователя. Более подробно алгоритм будет изложен в пункте Таргетированная выдача контента.

  2. Просмотр индивидуальной статистики для каждого пользователя. Очень часто маркетологи сталкиваются с проблемами:

-Почему одно рекламное предложение было мене эффективно, чем другое?

-Почему одно заведение привлекает гораздо больше людей, нежели другое? и т.п.

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

- пользователь открыл купон №1

- в течение 3 секунд пользователь смотрел картинку купона №1

- пользователь открыл купон №2

- в течение 5 секунд пользователь смотрел картинку купона №2

- пользователь открыл купон №3

- в течение 15 секунд пользователь смотрел картинку купона №3

- пользователь нажал на кнопку “Подробнее о заведении” и смотрел на экран в течение 53 секунд

- пользователь нажал кнопку “Взять” купона №3

- пользователь предъявил купон №3


Если бы не было механизма учета такой статистики, то мы бы узнали только, что пользователь предъявил купон №3. Несомненно, это говорит о том, что купон №3 заинтересовал пользователя, а купоны №1 и №2 нет. Но это не дает никакого ответа на вопрос “Почему?”. Возможно, пользователь даже и не видел купоны №1 и №2. А с помощью данного механизма можно получить полную картину событий на основе статистики его действий делать выводы о привлекательности того или иного предложения для конкретного пользователя.

  1. Механизм выявления ошибок в приложениях. Часто бывают ситуации, когда в клиентском приложении возникают ошибки, о которых разработчики узнают только после обращения клиента с жалобой. Бывают ситуации, когда не понятно, как воспроизвести ошибку. Данный механизм позволяет разработчику повторить ситуацию, произошедшую в мобильном приложении клиента. Для этого ему достаточно открыть записи о действиях пользователя и, отслеживая последовательность действий в хронологическом порядке, выполнять те же действия на своем телефоне. В некоторых случаях это позволяет выявить сложно воспроизводимые ошибки в течение нескольких минут.



2.6) Таргетированная выдача контента.

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


Алгоритм сбора предпочтений клиента:

Константы

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


CATEGORY_START_PRIORITY = 50;
COUPON_START_PRIORITY = 0
CATEGORY_TAKE_PRIORITY_INCREMENT = 0.05
CATEGORY_LOOK_PRIORITY_INCREMENT = 0.025
COUPON_DECLINE_PRIORITY = -10
CATEGORY_DECLINE_PRIORITY_DECREMENT = 0.05
MERGE_INTERVAL = 5


Необходимые данные:

  1. Категории:
    Примеры категорий: Ресторан, Кафе, Бар, Фастфуд
    Тип заведения: Дешёвый, Недорогой, Средний, Недешёвый, Дорогой и другие…

  2. Для каждой категории, для каждого купона, для каждого клиента необходимо хранить число, обозначающее приоритет этой категории.

Таблица приоритетов:

PriorityID

Priority

CouponID

ClientID

CategoryID

int

float

int

int

int

  1. Начальный приоритет: CategoryPriority = CATEGORY_START_PRIORITY

  2. Для каждого купона хранится его приоритет.
    AprioriCouponPriority – float

  3. Начальный приоритет: AprioriCouponPriority = COUPON_START_PRIORITY

Алгоритм построения списка купонов

  1. Вычисления приоритета купона для каждого клиента:

CouponPriority = [Sum(i=1 to n) (CategoryPriority_i)] / n + AprioriCouponPriority, где n – количество категорий у данного купона.

  1. Сортируем по убыванию по CouponPriority массив всех купонов (переменная AllCoupons).

  2. Генерируем массив случайной выборки купонов (алгоритм генерации ниже) (получаем переменные RandomCoupons – выборка случайных купонов, и NormalCoupons – оставшиеся купоны).

  3. Объединяем массивы NormalCoupons и RandomCoupons по правилу:

вначале MERGE_INTERVAL купонов из NormalCoupons, потом 1 купон из RandomCoupons.

Алгоритм построения случайной выборки

  1. Вычисляем длину массива случайно выбранных купонов (RandomCoupons): AllCoupons.Length / MERGE_INTERVAL

  2. Вычисляем длину массива оставшихся купонов (NormalCoupons): AllCoupons.Length – RandomCoupons.Length

  3. Генерируем RandomCoupons.Length различных случайных чисел в промежутке от 0 до AllCoupons.Length. Т.е. каждому купону сопоставим случайное число.

  4. Элементы с этими номерами переводим в массив RandomCoupons в полученном порядке.

  5. Остальные купоны переводим в массив NormalCoupons, не меняя их порядка.

Реакции на действия клиента

  1. Клиент посмотрел оборотную сторону купона:
    Для всех категорий, которые есть у купона, CategoryPriority *= (1 + CATEGORY_LOOK_PRIORITY_INCREMENT)

  2. Клиент взял купон себе:
    Для всех категорий, которые есть у купона, CategoryPriority *= (1 + CATEGORY_TAKE_PRIORITY_INCREMENT)

  3. Клиент нажал копку купона "Мне это не интересно" :
    Для всех категорий, которые есть у купона, CategoryPriority *= (1 – CATEGORY_DECLINE_PRIORITY_DECREMENT)
    AprioriCouponPriority -= DECLINE_COUPON_PRIORITY

Данный алгоритм показал довольно неплохую эффективность на тестовых данных. Его основные преимущества – быстрое обучение и хорошие показатели по выбору актуальных предложений. Но при долгом и интенсивном использовании приложения возникает эффект “ненужной памяти”, т.е. возникает ситуация, когда пользователю показываются одни и те же предложения, которые он уже видел. А у новых предложений, которые только что появляются в новых категориях, получается более низкий приоритет и они сразу не показываются пользователю. Поэтому в качестве временного было принято решение с течением времени постепенно понижать приоритеты у старых предложений.

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

2.7) Система, позволяющая отслеживать ошибки приложений

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

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

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



  1. В базу данных были добавлены необходимые таблицы ClientError и ClientHistory (рис. 5).

  2. В протокол сервера клиентского приложения добавлены соответствующие запросы (см. пример на рис. 6).

  3. В панель администратора добавлен интерфейс для удобного и быстрого отображения нужной истории (см. пример на рис. 7 и рис. 8).

  4. В сервер клиентского приложения добавлен модуль оповещения разработчиков по e-mail об ошибках.



Рис.5


Рис. 6

Рис. 7

Рис. 8


Как работает эта система в комплексе

Во время использования мобильного приложения все основные функции записываются в журнал логов. Сообщения в логах имеют несколько уровней важности, например: error, warning, debug, verbose. Если происходит какая-то внештатная ситуация, то в лог записывается сообщение с уровнем важности error, и диспетчер логов понимает, что нужно отправить всю историю на сервер. Если отправить логи на сервер сразу не удалось, то они сохраняются в память и будут отосланы при следующем подключении к сети интернет. Если логи были успешно отправлены, то на этом миссия клиентского приложения заканчивается, и сервер начинает обрабатывать логи. Все сообщения сохраняются в соответствующих таблицах в БД ClientHistory и ClientError (рис.5). Если в логах были найдены сообщения приоритета error, то сервер оповестит нужного разработчика по e-mail. Как это происходит: сервер знает, кто из разработчиков отвечает за каждую мобильную платформу и знает его e-mail (Пример: J2ME – Иванов, iPhone - Петров). При получении лога с приоритетом error текст данного сообщения вставляется в письмо и добавляется ссылка на веб-интерфейс панели администратора вида



http://web-site.ru/admin/clienthistory.jsp?ClientID=2&Period=Count&Count=100

Перейдя по ссылке (см. пример рис.8), разработчик может подробно ознакомиться со всеми действиями пользователя и понять, из-за чего произошла такая ошибка.



Заключение


Результатом данной дипломной работы стала реализация серверной части системы Smartkupon с перечисленным ниже функционалом и интеграция ее с клиентским приложением.

Автором дипломной работы было выполнено следующее:



  1. Налажен процесс разработки и непрерывного тестирования сервера.

  2. Разработана архитектура базы данных.

  3. Разработана спецификация протокола общения сервера и клиентского приложения, а также запрограммированы основные запросы.

  4. Реализован механизм выдачи персонализированного контента, а именно произведена интеграция с GraphicsMagick.

  5. Введен персонализированный учет статистики. Т.е. разработаны таблицы в БД для хранения информации и реализована поддержка в протоколе для сбора статистики.

  6. Разработан алгоритм для таргетированной выдачи контента.

  7. Налажена система, позволяющая отслеживать ошибки приложений.

Помимо всего этого стоит отметить, что SmartKupon является готовым продуктом, которым можно воспользоваться, зайдя на сайт www.smartkupon.ru и скачав клиентское приложение. Данное приложение использует сервер, в котором уже реализованы и отлажены все компоненты, описанные в данной дипломной работе. Так же стоит отметить, что автор продолжает работать над своим проектом. Несмотря на полноценность текущей реализации, есть много способов что-то улучшить, например, увеличить скорость работы и добавить новую функциональность.



Список литературы





  1. Обзор дистрибутивов Linux http://linuxos.com.ru/directory.htm

  2. Debian http://www.debian.org/index.ru.html

  3. Insight IT Масштабируемость http://www.insight-it.ru/masshtabiruemost/

  4. Преимущества виртуализации http://xgu.ru/wiki/Преимущества_виртуализации

  5. Сравнение виртуальных машин http://ru.wikipedia.org/wiki/Сравнение_виртуальных_машин

  6. OpenVZ http://ru.wikipedia.org/wiki/OpenVZ

  7. Виртуализация на уровне операционной системы http://ru.wikipedia.org/wiki/Виртуализация_на_уровне_операционной_системы

  8. Нормальная форма http://ru.wikipedia.org/wiki/Нормальная_форма

  9. GraphicsMagick Image Processing System http://www.graphicsmagick.org/

  10. Система управления версиями http://ru.wikipedia.org/wiki/Система_управления_версиями

  11. CVSComparison http://wiki.opennet.ru/CVSComparison

  12. SVN http://ru.wikipedia.org/wiki/Subversion

  13. GIT http://ru.wikipedia.org/wiki/GIT

  14. Регрессионное тестирование http://ru.wikipedia.org/wiki/Регрессионное_тестирование

  15. Load and Performance Test Tools http://www.softwareqatest.com/qatweb1.html#LOAD

  16. Apache JMeter http://jakarta.apache.org/jmeter/

  17. Нагрузочное тестирование http://ru.wikipedia.org/wiki/Нагрузочное_тестирование

  18. Непрерывная интеграция на примере Hudson http://habrahabr.ru/blogs/testing/108928/

  19. MySQL Workbench http://ru.wikipedia.org/wiki/MySQL_Workbench

  20. MySQL Documentation - http://dev.mysql.com/doc/

  21. JSR-000154 JavaTM Servlet 2.5 Specification

http://jcp.org/aboutJava/communityprocess/mrel/jsr154/index.html

  1. Apache Tomcat Documentation - http://tomcat.apache.org/tomcat-5.5-doc/index.html

  2. OReilly Head First Servlets and JSP - http://www.torrentdownloads.net/searches/OReilly.Head.First.Servlets.and.JSP.2nd.Edition.Mar.2008.pdf

  3. Spring Documentation http://www.springsource.org/documentation