Интернет-сервис подбора мероприятий

Размещено на http://www.allbest.ru/

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

1 АНАЛИТИЧЕСКИЙ ОБЗОР

1.1 Обзор существующих решений

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

1.3 Рекомендательные системы

1.3.1 Стратегии формирования рекомендаций

1.3.2 Фильтрация на основе содержимого

1.3.3 Коллаборативные рекомендательные системы

1.3.4 Рекомендательные системы, основанные на знаниях

1.3.5 Гибридные рекомендательные системы

1.4 Библиотеки для систем рекомендаций

1.4.1 Сводная таблица для сравнения библиотек

1.5 Выбор библиотеки для построения рекомендаций

1.6 Обзор алгоритмов Lenskit

1.6.1 Item-item коллаборативная фильтрация

1.6.2 User-user коллаборативная фильтрация

1.7 Выбор алгоритма для реализации рекомендательной системы

1.8 Организация совместной работы

1.9 Планирование разработки

1.9.1 Управление проектом с помощью YouTrack

2 ПРОЕКТИРОВАНИЕ СЕРВЕРНОЙ ЧАСТИ

2.1 Описание концептуальной архитектуры сервиса

2.2 Обзор открытых API для получения событий

2.2.1 Портал открытых данных Минкультуры России

2.2.1 VK API

2.3 Подготовка инфраструктуры

3 ПРОЕКТИРОВАНИЕ ANDROID ПРИЛОЖЕНИЯ

3.1 Выбор минимальной версии API

3.2 Проектирование архитектуры приложения

3.3 Проектирование пользовательского интерфейса

4 РЕАЛИЗАЦИЯ ANDROID ПРИЛОЖЕНИЯ

4.1 Выбор среды разработки

4.2 Обзор используемых библиотек для Android

4.3 Использование API в клиентской части

4.4 Реализация авторизации клиента

4.4.1 Протокол Oauth

4.4.2 Google Sign-in

4.4.3 Авторизация с помощью Google Sign-In

4.5 Тестирование Android

4.5.1 Тестирование пользовательского интерфейса

5 РЕАЛИЗАЦИЯ РЕКОМЕНДАТЕЛЬНОЙ ПОДСИСТЕМЫ ДЛЯ МЕРОПРИЯТИЙ

5.1 Серверная часть

5.2 Работа с LensKit

ЗАКЛЮЧЕНИЕ

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

ПРИЛОЖЕНИЕ



ВВЕДЕНИЕ

Актуальность темы исследования: современный человек не хочет тратить много времени на поиск развлечений. Каждый день обновляются афиши кинотеатров, театров, проводятся концерты, организуются встречи по интересам, тренинги, тематические вечеринки, появляются акции в кафе и магазинах и т.д. Информация о мероприятиях рассредоточена по различным источникам - социальным сетям, сайтам кинотеатров и т.д., это вносит сложность и увеличивает время поиска. К тому же, человек, зачастую, сам не знает, чего хочет. Встаёт необходимость рекомендации от некоторой незаинтересованной стороны.

Одной из функциональных возможностей сервиса по подбору мероприятий является рекомендация потенциально интересных мероприятий пользователю.

Актуальность работы заключается в агрегации информации с различных источников мероприятий и применении прогнозирующих алгоритмов в сфере мероприятий для формирования неизвестных предпочтений пользователя.

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

Целью ВКР является разработка интернет-сервиса по подбору мероприятий.

В соответствии с указанной целью в работе сформулированы и решены следующие задачи:

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

2. Исследованы различные источники мероприятий, их API.

3. Изучены методы построения прогнозов в рекомендательных системах.

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

5. Спроектирована и реализована серверная часть сервиса, а также клиент на Android. мероприятие библиотека алгоритм серверный

Объектом исследования является обоснованный подбор мероприятий и выдача рекомендаций.

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

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

Использование результатов работы: android-приложение находится на стадии бета-тестирования, оно было отправлено на участие в конкурсе IT-планета и получило диплом в номинации «Разработка мобильных приложений».

Апробация полученных результатов. Предлагаемые решения и результаты магистерской работы отправлены на национальную научно-практическую конференцию «Актуальные проблемы науки и практики в различных отраслях народного хозяйства» (Пенза, 28-29 марта 2018).

Android-приложение было отправлено на участие в конкурсе IT-планета и получило диплом в номинации «Разработка мобильных приложений».

Основные научные результаты, выносимые на защиту:

1. Программное обеспечение, решающее поставленную задачу.

2. Алгоритм коллаборативной фильтрации, адаптированный для конкретного случая - выдачи рекомендаций по подбору мероприятий.

По теме диссертации опубликована 1 печатная работа -

Каляшов Г. А., Кудряшов А.А. РАЗРАБОТКА РЕКОМЕНДАТЕЛЬНОЙ СИСТЕМЫ ДЛЯ МЕРОПРИЯТИЙ. - «Актуальные проблемы науки и практики в различных отраслях народного хозяйства» (Пенза, 28-29 марта 2018)

Структура и объём работы. Диссертация состоит из введения, пяти глав, заключения, библиографического списка и приложений.



1 Аналитический обзор

1.1 Обзор существующих решений

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

После анализа рынка приложений Google Play были выделены 3 существующие приложения, которые решают поставленную проблему:

KudaGo, достоинства:

· ежедневно пополняемая база событий;

· удобный UI.

Недостатки:

· ограниченный список городов (всего 16).

Афиша от Rambler.

Достоинства:

· возможность бронирования билетов на фильмы, концерты;

· рецензии и отзывы других пользователей;

· простота использования.

Недостатки:

· список мероприятий состоит в основном из фильмов, больше похоже на киноафишу;

Город Зовет.

Достоинства:

· большой список городов.

Недостатки:

· скудный набор мероприятий, ограниченный лишь одним источником - социальной сетью Вконтакте;

· неудобный UI.



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

Необходимо разработать ИС для сбора информации о мероприятиях из различных источников и предоставлению этой информации пользователю.

Сервис будет состоять из веб-приложения и клиента на Android. Основной задачей веб-приложения является сбор, хранение актуальных событий и предоставление API для клиентских приложений.

Требования, предъявляемые к разрабатываемой ИС:

· поддержка актуальной информации;

· возможность добавления новых источников мероприятий, т.е. система не должна быть привязана только к одному, нескольким источникам;

· предоставление API, позволяющего получать всю необходимую информацию о событиях;

· личный кабинет пользователя с возможностью сохранения понравившихся мероприятий;

· рекомендация мероприятий пользователю;

· все приватные данные клиента должны храниться в защищенном хранилище, и не передаваться по сети в открытом виде.

Отдельно к Android-приложению можно выделить следующие требования:

· удобный UI (Material Design);

· адаптивный UI - пользовательский интерфейс должен работать одинаково на устройствах с разным расширением экрана, и оптимизирован под большие экраны (планшеты), а также должен поддерживать альбомную и портретную ориентацию;

· поддержка Android устройств начиная с версии 4.1.



1.3 Рекомендательные системы

Это сервисы, которые на основе какой-либо информации о профиле пользователя предсказывают объекты (книги, фильмы, товары, новости, мероприятия), которые будут ему интересны.

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

Рекомендательные системы играют достаточно важную роль в работе многих известных сайтов. К примеру, Amazon.com, Netflix, YouTube, Yahoo, Tripadvisor, Last.fm и т.п..

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

1.3.1 Стратегии формирования рекомендаций

Можно выделить 4 основных вида рекомендательных систем:

1. Коллаборативная фильтрация.

2. Фильтрация на основе содержимого.

3. Системы, основанные на знаниях.

4. Гибридные системы.

Схематически классификация методов изображена на рисунке 1.1.



Рисунок 1.1 - Классификация методов формирования рекомендации

1.3.2 Фильтрация на основе содержимого

Рекомендательные системы с фильтрацией на основе содержания исследуют схожесть объектов, оцененных пользователем с

профилем пользователя.

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

Примером сервиса, использующего подобный алгоритм является Surfingbird. Её достоинств в том, что есть возможность рекомендовать веб-сайты новым пользователям без каких-либо оценок и подобной информации, основываясь только на данных профиля пользователя. Процесс сбора оценок и отзывов достаточно трудоёмок, но эти данные лучше всего помогают понять предпочтения клиентов. Недостаток подхода - невозможность системы рекомендовать новые объекты, которые не соотносятся с интересами пользователей, поэтому существует проблема поддержки связи с пользователем [2].



1.3.3 Коллаборативные рекомендательные системы

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

Рекомендации составляются индивидуально для каждого пользователя.

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

Можно выделить 3 подхода коллаборативной фильтрации: фильтрация, основанная на схожести пользователей (user-based), фильтрация, основанная на схожести объектов (item-based), и подход, с применением факторизации матрицы рейтингов.

1.3.4 Рекомендательные системы, основанные на знаниях

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

1.3.5 Гибридные рекомендательные системы

Эти системы сочетают в себе сразу набор рекомендательных алгоритмов. Сочетание нескольких методов может быть реализовано с применением ряда функций с различным поведением и свойствами. Пример такого подхода является алгоритм, представленный на конкурсе Netflix в 2009 году. Команда, занявшая первое место, предложила алгоритм, который является комбинацией 27и рекомендующих алгоритмов

1.4 Библиотеки для систем рекомендаций

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

Рассмотрим некоторые из них:

1. Apache Mahout.

2. RecommenderLab.

3. MyMediaLite.

4. Waffles.

5. Lenskit.

6. OpenSlopeOne

Apache Mahout - это открытая библиотека для машинного

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

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

MyMediaLite -- опенсорсное ПО, которое возможно использовать только в некоммерческих целях. Не нуждается в БД, реализует базовые типы рекомендующих алгоритмов. Реализована на языке C#.

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

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

OpenSlopeOne - реализация семейства алгоритмов коллаборативной фильтрации на PHP. Подходит для анализа различных предпочтений пользователей и генерации персональных рекомендаций.

1.4.1 Сводная таблица для сравнения библиотек

Чтобы сравнить между собой описанные выше программные средства для работы с рекомендательными системами сведем все данные о них в сводной таблице.

Таблица 1 - Критерии оценки библиотек открытого доступа

Библиотека, критерий оценки	Mahout	RecommenderLab	MyMediaLite	Waffles	Lenskit	OpenSlopeOne
Последняя версия	0.12.0	0.2	3.11		2.2.1
Поддерживается на данный момент	Да	Да	Да	Да	Да	Да
Рабочая платформа	JVM	Windows	.NET	Linux, Mac, Windows	JVM	Windows
Язык реализации	Java	R	C++	C++	Java	PHP



Продолжение таблицы 1

Поддержка языков	Java	R	C#, F#, Clojure, Python, Ruby	C++	Groovy, Java	PHP
Реализованные алгоритмы	Item-based, User-based CF, Matrix Factorization	Item-based, User-based CF	-	Neural network	Item-based, User-based CF, Matrix factorization, Slope-One	Item-based, User-based CF

1.5 Выбор библиотеки для построения рекомендаций

К библиотеки были сформированы следующие требования:

1. Opensource.

2. Поддержка Java.

3. Наличие готовых алгоритмов для item-based CF, user-based CF.

В этой работе будет использоваться Lenskit, т.к. в ней реализуются необходимые алгоритмы для коллаборативной фильтрации, а также имеется возможность гибкой настройки с помощью скриптового языка Groovy [3].

1.6 Обзор алгоритмов LensKit

Lenskit реализует несколько алгоритмов коллаборативной фильтрации, более подробно остановимся на двух из них.

1.6.1 Item-item коллаборативная фильтрация

Класс ItemItemScorer является основным элементов для реализации item-item CF. Его конфигурирование является основным способом настройки, имеется пара параметров, которые можно настроить:

· NeighborhoodSize - устанавливает, сколько соседей следует использовать для каждого предсказания;

· UserHistorySummazier - используется для извлечения векторов оценки из пользовательских историй.

Модель CF (матрица подобия) строится с помощью ItemItemModelBuilder, который также настраивается:

· ItemSimilarity - указывает функцию подобия, используемую для сравнения элементов. Реализация по умолчанию - ItemVectorSimilarity, которая использует VectorSimilarity для сравнения векторов оценки (рейтинга) элемента. По умолчанию это сходство с косинусом.

1.6.2 User-user коллаборативная фильтрация

Конфигурирование класса UserUserItemScorer является главной деталью для использования user-user CF.

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

1.7 Выбор алгоритма для реализации рекомендательной системы

Основываясь на результатах работы (Кожевникова А.М. Исследование моделей и алгоритмов рекомендующих систем) можно сделать выводы что наилучшей точностью рекомендаций обладает алгоритм, основанный на сходстве объектов (Item-Item), наилучший результат достигается при количестве соседей равному 20, но в то же время он показывает большее время работы по сравнению с алгоритмом, основанным на сходстве пользователей.

В виду описанных особенностей для дальнейшей реализации выберем item-item CF.



1.8 Организация совместной работы под проектом

Сервис разрабатывается командой из двух участников, каждый из участников описал в ВКР свою часть работы над проектом.

Для организации совместной работы над проектом используется распределенная система контроля версий Git. Применение Git обосновано рядом преимуществ перед остальными способами организации коллективной работы:

· сохраняется вся история изменений файлов, имеется возможность возврата к предыдущим версиям;

· автоматическая синхронизация и слияние изменений;

· работа с бинарными файлами большого объёма.

Git - распределенная система управления версиями, каждый разработчик имеет свой локальный репозиторий, и синхронизация между этими репозиториями происходит через центральное хранилище (общее) [4].

Типичный рабочий процесс можно представить следующим образом:

1. В локальных репозиториях создаются новые файлы, изменяются или удаляются существующие.

2. По завершении логического этапа работ возникает необходимость зафиксировать изменения (commit) и/или синхронизировать.

3. Файлы подготавливаются к коммиту.

4. Выполняется коммит.

5. Все закомиченные изменения загружаются в общее хранилище.

В качестве технической реализации Git был выбран Github, который является абсолютно бесплатным для проектов с открытым исходным кодом.

Для сервера и клиента на Android созданы репозитории на Github.

Разработка ведется на основе информации, требований, полученных из системы ведения изменений YouTrack.

YouTrack - онлайн баг-трекер и инструмент для управления проектами, задачами и Agile-процессами. Также является абсолютно бесплатным для команды до 10 человек.

Для коммуникаций в команде был выбран мессенджер Slack.

1.9 Планирование разработки

Разработка велась по методологии Scrum.

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

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

Бэклог -- это список всех необходимых работ. Есть два вида бэклогов: Product-бэклог и спринт-бэклог.

Product-бэклог -- это полный список работ, после реализации которых получается конечный продукт.

Спринт-бэклог -- это список работ, который команда планирует выполнить за спринт.

Задания в спринт-бэклог берутся из product-бэклога.

Планирование спринта проходит в виде совещания, на котором присутствует вся команда.

1.9.1 Управление проектом с помощью YouTrack

Задачи на спринт берутся из бэклога, длительность спринта -- 2 недели. При создании задачи помимо названия и описания указывается приоритет, исполнитель и подсистема (android или backend).

Рисунок 1.2 - Создание задачи

Задача может находиться в 4х состояниях, при создании она имеет состояние «Открыта», после того как участник группы берет задачу в работу, она переходит в статус «В работе», после выполнения всех работ задача переходит в статус «Готово», после проверки сделанного задача переходит в конечный статус «Проверена».

На рисунке 1.3 изображена доска с задачами 2-го спринта.

Рисунок 1.3 - Доска задач

Burndown-диаграмма для 2-го спринта:



Рисунок 1.4 - Диаграмма сгорания



2. Проектирование серверной части

2.1 Описание концептуальной архитектуры сервиса

Разрабатываемый сервис может иметь довольно сложную структуру.

На первом этапе необходимо создать максимально простой сервис, имеющий реальную ценность для конечного пользователя, так называемый MVP. Минимально-жизнеспособный продукт (minimal viable product, MVP) в данном случае представляет собой мобильное или web-приложение, способное по некоторым фильтрам (город, время, возраст и категория) подобрать интересные пользователю мероприятия. При этом должен существовать механизм автоматического заполнения базы данных сервиса мероприятиями из внешних источников. Сервис в данном виде не имеет конкурентных преимуществ, но уже может быть использован.

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

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

В общем виде архитектура сервиса имеет структуру, изображенную на рисунке 2.1.

Внешняя система мероприятий - любой существующий агрегатор мероприятий, например «Вконтакте», Яндекс.Афиша, Рамблер.Афиша, сайты кинотеатров и др. Поддержка каждой внешней системы мероприятий осуществляется через адаптер-наполнитель - специализированный программный модуль, призванный решать две задачи: интеграцию с внешней системой и сохранение полученных данных в БД сервиса. Задача подключения новой внешней системы связана с созданием нового модуля-адаптера.

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

Для аутентификации клиента используются внешние провайдеры аутентификации («Вконтакте», «Facebook», Twitter, Google и др.).

Рис. 2.1 - Архитектура сервиса

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

Серверная часть разрабатывается на языке программирования Java 8. Данный язык широко используется для написания web и корпоративных приложений высокой сложности.

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

В разрабатываемой системе можно выделить несколько приложений.

API интерфейс (eventsApi) - серверное приложение предоставляет REST сервисы. Приложения-клиенты (android, IOS, WinPhone клиенты или web-сайт) посылают Http запросы к серверу в едином формате. Серверное приложение обрабатывает запросы, выполняет необходимые операции по чтению из базы данных и обработке и отдаёт ответ в виде json-объекта.

Адаптер-наполнитель (приложение для наполнения базы данных мероприятиями (eventsFiller)).

Необходимо, чтобы каким-то образом мероприятия попадали в базу данных сервиса. Эту задачу должно решать отдельное приложение-шедулер, которое будет с определённой периодичностью выполнять запросы к внешним системам для получения мероприятий. Затем должны происходить обработка, фильтрация и конвертация полученных мероприятий для сохранения в БД. Целесообразно создавать свой eventsFiller для каждой внешней системы, поскольку каждая внешняя система независима и имеет свои особенности. Приложение для построения рекомендаций - система будет использовать алгоритмы для определения предпочтений пользователей. Приложения-анализаторы будут призваны решать проблемы классификации, кластеризации и анализа данных.

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

Таким образом, на данном этапе серверная часть приложения представляет собой два исполняемых war-приложения, предназначенные для установки на сервер приложений, и один переиспользуемый jar модуль. В перспективе будут появляться приложения-анализаторы, а также приложения-наполнители базы данных.

2.2 Обзор открытых API для получения событий

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

2.2.1 Портал открытых данных Минкультуры России

Портал Минкультуры России предлагает разработчикам воспользоваться открытый программный интерфейс, с помощью которого можно автоматизировать получение и обновление событий [13].

API платформы открытых данных Минкультуры России:

· представляет собой RESTfull API поверх HTTP(S),

· дает доступ исключительно на чтение, во всех запросах используется HTTP метод GET,

· использует JSON как формат ответа сервера по умолчанию.

API платформы предоставляет метод events для получения мероприятий в сфере культуры. Пример получаемого ответа приведен в приложении 1.

Таблица 2 - Описание основных параметров ответа

Параметр ответа	Описание
nativeId	Id исходной системы
modified	Дата изменения
data.general.name	Мероприятие
data.general.shortDescription	Краткое описание
data.general.ageRestrciction	Возрастное ограничение
data.general.isFree	Бесплатное
data.general.price	Стоимость посещения
data.general.start	Дата начала
data.general.end	Дата окончания
data.general.category.name	Категория
data.general.organization.name	Организация
data.general.organizeraPlace.name	Место проведения

2.2.2 VK API

Социальная сеть vk.com предоставляет открытое API для получения событий [14]. События в контексте vk.com - это тип сообщества, группы, поэтому для поиска событий используется метод groups.search, который осуществляет поиск сообществ по заданной подстроке, ниже представлено описание этого метода.

Таблица 3 - Описание запроса groups.search

Параметр запроса	Описание
q	Текст поискового запроса
type	Тип сообщества. Возможные значения: event, page, group. Для поиска событий будем использовать event.
country_id	Идентификатор страны.
city_id	Идентификатор города.
future	Значение 1 - предстоящие события. Учитывается только при передаче в качестве type значения event.
sort	· 0 -- сортировка по умолчанию; · 1 -- сортировка по скорости роста; · 2 -- сортировка по отношению дневной посещаемости к количеству пользователей; · 3 -- сортировка по отношению количества лайков к количеству пользователей; · 4 -- сортировка по отношению количества комментариев к количеству пользователей;
offset	Смещение, необходимое для выборки определённого подмножества результатов поиска. По умолчанию -- 0.
count	Количество результатов поиска, которое необходимо вернуть. По умолчанию - 20.

В результате запроса приходит JSON, содержажий число результатов в поле count (integer) и массив объектов group в поле items. Для примера выполним запрос c параметрами q - Вологда, type - event, полученный результат:

{"response": {

"count": 844,

"items": [{

"id": 162817993,

"name": "Руки Вверх | Вологда| 7 июня | ДС "Вологда"",

"screen_name": "rukivverh_vologda",

"is_closed": 0,

"type": "event",

"is_admin": 0,

"is_member": 0,

"photo_50": "https://pp.userap...EGZwTG-ew.jpg?ava=1",

"photo_100": "https://pp.userap...HIWVpICjE.jpg?ava=1",

"photo_200": "https://pp.userap...O-VGa4R5o.jpg?ava=1"

}, {

"id": 112527909,

"name": "Фестиваль водных фонариков - Вологда",

"screen_name": "vmeza_vl_v",

"is_closed": 0,

"type": "event",

"is_admin": 0,

"is_member": 0,

"photo_50": "https://pp.userap...Hn2l0XaFI.jpg?ava=1",

"photo_100": "https://pp.userap...3ewfeO30A.jpg?ava=1",

"photo_200": "https://pp.userap...ydFSyJtcE.jpg?ava=1"

}, {

"id": 163959287,

"name": "Элджей / 26 апреля / ДС "Вологда"",

"screen_name": "lj_vologda",

"is_closed": 0,

"type": "event",

"is_admin": 0,

"is_member": 0,

"photo_50": "https://pp.userap...lngCek11o.jpg?ava=1",

"photo_100": "https://pp.userap...J6H4ah-28.jpg?ava=1",

"photo_200": "https://pp.userap...bHyI1jCjU.jpg?ava=1"

}] }}

2.3 Подготовка инфраструктуры

Для функционирования сервиса необходима надёжная вычислительная среда. Недостаточно локального развёртывания приложений, поскольку необходима их непрерывная работа. Среда должна соответствовать требованиям надежности, масштабируемости, гибкости и функциональности. Для развёртывания разрабатываемого сервиса как комплекса приложений была выбрана платформа Amazon.

Платформа Amazon Web Services предоставляет облачные вычислительные ресурсы как ряд сервисов. Имеются удобные инструменты для облачных вычислений, хранения информации, баз данных, разработки, настройки безопасности, аналитики, мобильной разработки и так далее. Особенность данной платформы в том, что объём любых предоставляемых ресурсов может масштабироваться почти без ограничений. Пользователь платит только за те ресурсы, которые использует.

Для целей ознакомления с платформой и разработки Amazon Web Services предоставляют год бесплатного использования определённого набора ресурсов, а именно:

1. Amazon EC2 - масштабируемый объем вычислительных ресурсов в облаке.

· 750 часов в месяц использования инстанса t2.micro с Linux, RHEL или SLES;

· 750 часов в месяц использования инстанса t2.micro с Windows.

Например, вы можете исполнять 1 инстанс в течение 1 месяца или 2 инстанса в течение половины месяца.

2. Amazon S3- это объектное хранилище, оснащенное простым веб-интерфейсом. Сервис позволяет хранить любой объем данных и извлекать данные через Интернет, где бы вы ни находились. Amazon S3 обеспечивает надежность на уровне 99,999999999 % и возможность масштабирования более чем на триллионы объектов по всему миру.

· 750 часов использования микроинстанса Amazon RDS db.t2 в одной зоне доступности;

· 20 ГБ хранилища БД: любое сочетание универсальных томов (SSD) и магнитных томов

· 20 ГБ для резервных копий (магнитное хранилище RDS; операции ввода-вывода для универсальных томов (SSD) дополнительно не оплачиваются)

· 10 000 000 операций ввода-вывода.

3. Amazon RDS: Управляемый сервис реляционных баз данных для MySQL, PostgreSQL, MariaDB, Oracle (с поддержкой собственных лицензий) и SQL Server.

· 750 часов использования микроинстанса Amazon RDS db.t2 в одной зоне доступности;

· 20 ГБ хранилища БД: любое сочетание универсальных томов (SSD) и магнитных томов;

· 20 ГБ для резервных копий (магнитное хранилище RDS; операции ввода-вывода для универсальных томов (SSD) дополнительно не оплачиваются);

· 10 000 000 операций ввода-вывода.

Иными словами, бесплатно предоставляются экземпляр виртуальной машины под управлением ОС Linux/Windows с управлением по протоколу SSH, СУБД MySQL, PostgreSQL, MariaDB, Oracle (с поддержкой собственных лицензий) и SQL Server и несколько других сервисов.

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



3. ПРОЕКТИРОВАНИЕ ANDROID ПРИЛОЖЕНИЯ

3.1 Выбор минимальной версии API

Платформа Android постоянно развивается, появляются новые возможности, упрощающие жизнь разработчикам. Чтобы включить новые возможности для разработки под более старые платформы создаются библиотеки поддержки (Support library). Но с выходом всё более новых версий становится сложнее поддерживать более старые, поэтому возникает вопрос: какую минимальную версию SDK выбрать для разработки приложения?

На официальном сайте Android представлена следующая статистика:

Рисунок 3.1 - Статистика использования версий Android

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



3.2 Проектирование архитектуры приложения

Архитектура Android является фреймворк-ориентированной (framework-based), в противовес вольной (free-style) архитектуре.

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

Разделение ответственности, которое подразумевается Android-фреймворком, выглядит так:

· модель - любой POJO-класс;

· представление - это XML-шаблон (layout);

· fragment или activity выступает в роли контроллера/презентера.

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

Так как все эти элементы сильно связаны, их становится очень трудно поддерживать и ещё сложнее тестировать.

Для решение вышеописанных проблем было решено придерживаться паттерна MVP при дальнейшей разработке.

В MVP приложение разделяется на следующие части:

1. Model -- представляет из себя точку входа к данным приложения (часто на каждый экран своя модель). При этом особой разницы откуда данные быть не должно -- данные сетевых запросов или данные взаимодействия пользователя с UI (клики, свайпы и т.д).

2. View -- представляет из себя класс, устанавливающий состояние UI элементов.

3. Presenter -- устанавливает связь между обработкой данных, получаемых из Model и вызовом методов у View, реализуя тем самым реакцию UI компонентов на на данные. Методы Presenter вызываются из методов жизненного цикла activity/fragment.

Model, view, presenter должны представлять из себя интерфейсы для большей гибкости модификации кода.

Рисунок 3.2 - Паттерн MVP

3.3 Проектирование пользовательского интерфейса

Одним из основных требований к пользовательскому интерфейсу является следование принципам Material Design.

Material Design - это правила и принципы для создания адаптивного и отзывчивого UI, разработанные Google для унификации интерфейсов продуктов и сервисов. Материальный дизайн используется полноценно в ОС Android, начиная с версии Lollipop.

Для оценки будущего UI было решено разработать прототип.

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

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

Для прототипирования использовалась платформа Proto UI, которая позволяет создавать интерактивные прототипов, и добавлять симуляция основных пользовательских действий. Готовый прототип можно тестировать на реальном мобильном устройстве или в браузере.

Результаты прототипирования приведены в приложении 2.



4. реализация Android приложения

4.1 Выбор среды разработки

На данный момент существуют три популярные IDE под Android:

1. Eclipse;

2. Intellij IDEA;

3. Android Studio.

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

Eclipse - это бесплатная среда разработки, на данный момент у неё есть следующие преимущества:

· официальная русификация документации;

· хорошая производительность на слабых компьютерах;

· большое число дополнений (модулей);

Eclipse была популярна раньше, но в связи с выходом Android Studio Google перестала поддерживать IDE Eclipse как основную среду для Android.

Intellij IDEA - разработка компании JetBrains. Эта среда обладает мощным движком и большими возможностями. Если сравнивать Intellij IDEA и Eclipse, то первый вариант является предпочтительным, так как у этой среды есть много преимуществ, к примеру:

· более удобный UI;

· наличие рефакторинга;

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

Android Studio - молодая и стремительно развивающаяся разработка Google, в основе которой используется Intellij IDEA. В настоящий момент это официальная среда программирования под Android. Основные особенности Android Studio:

· расширенный редактор макетов: способность работать с UI компонентами при помощи Drag-and-Drop, функция предпросмотра макета на нескольких конфигурациях экрана;

· cборка приложений, основанная на Gradle;

· различные виды сборок и генерация нескольких .apk файлов;

· рефакторинг кода;

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

В виду описанных выше особенностей для дальнейшей разработки приложения под ОС Android в качестве среды разработки будет использоваться Android Studio.

4.2 Обзор используемых библиотек для Android

Retrofit - библиотека упрощающая работы с Rest API, которая умеет выполнять запросы к API в отдельном потоке и автоматически конвертирует JSON в java объекты. Endpoint описывается в виде интерфейса, методы которого помечаются аннотациями @GET, @POST и т.д.

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

Retrolambda - библиотека, позволяющая использовать лямбда-выражения, появившиеся в Java 8, т.к. платформа Android еще не расчитана на последнюю версию Java.

Библиотека Dagger реализует паттерн Dependency Injection

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

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

Библиотека Moxy реализует паттерн MVP для Android, предоставляя реализации Presenter и View.

4.3 Использование API в клиентской части

Для работы с Rest API в Android используется библиотека Retrofit. Для удобства работы с Retrofit создан базовый класс для всех рест-сервисов - RestService, в котором происходит конфигурация клиента Retrofit, указывается ссылка на сервер, версия API, а также различные адаптеры для преобразования JSON в java-объекты.

Все классы, которые реализуют взаимодействие по REST, наследуются от класса RestService. Более подробно рассмотрим реализацию API для работы с событиями, в таблице 4 представлено описание API, в приложении 3 представлены интерфейс и java-класс, реализующие данное взаимодействие.

Таблица 4 - Описание API для работы с событиями

Метод	Описание	HTTP метод	Параметры
getPosts	получение списка событий	GET	offset - смещение, count - количество событий
getPost	получения события по id	GET	id - идентификатор события
rateUp	оценка события	POST	token - токен пользователя

4.4 Реализация авторизации клиента

4.4.1 Протокол OAuth

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

Общая схема работы приложения, использующего OAuth, такова:

1. Получение авторизации.

2. Обращение к защищенным ресурсам.

Результатом авторизации является access token -- некий ключ (обычно просто набор символов), предъявление которого является пропуском к защищенным ресурсам. Обращение к ним в самом простом случае происходит по HTTPS с указанием в заголовках или в качестве одного из параметров полученного access token'а.

При использовании Oauth авторизации пользователь не передает свой логин и пароль к защищенным ресурсам напрямую в приложение. Поэтому:

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

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

4.4.2 Google Sign-in

Google Sign-in - это безопасная система авторизации. Google Sign-In - функционал, который позволяет веб и мобильным разработчикам обеспечивать вход пользователей в приложения через Google+. Подобно Facebook Connect, Google+ Sign-In обеспечивает единый вход для сайтов и мобильных приложений, предоставляя им доступ к социальному графу пользователей [19].

4.4.3 Авторизация с помощью Google Sign-In

Процесс аутентификации выглядит следующим образом:



Рисунок 4.1 - Процесс аутентификации

Ниже приведена реализация аутентификации пользователя в приложении Android с помощью Google Sign-in:

// Конфигурация sign-in для запроса ID пользователя, эл. почты и профиля.

GoogleSignInOptions gso = new GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_SIGN_IN)

.requestEmail()

.build();

mGoogleApiClient = new GoogleApiClient.Builder(this)

.enableAutoManage(this, this)

.addApi(Auth.GOOGLE_SIGN_IN_API, gso)

.build();

// Обработка нажатия на кнопку авторизации

Intent signInIntent = Auth.GoogleSignInApi.getSignInIntent(mGoogleApiClient);

startActivityForResult(signInIntent, RC_SIGN_IN);

// Обработка ответа от Google Sign-In

@Override

public void onActivityResult(int requestCode, int resultCode, Intent data) {

super.onActivityResult(requestCode, resultCode, data);

if (requestCode == RC_SIGN_IN) {

GoogleSignInResult result = Auth.GoogleSignInApi.getSignInResultFromIntent(data);

if (result.isSuccess()) {

GoogleSignInAccount acct = result.getSignInAccount();

// Информация о пользователе

mFullName = acct.getDisplayName();

mEmail = acct.getEmail();

}

}

}

4.5 Тестирование Android

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

Рассмотрим процесс тестирования с UIAutomator более подробно. Также

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



4.5.1 Тестирование пользовательского интерфейса

UIAutomator разрабатывается корпорацией Google и поставляется вместе с Android SDK. Android SDK предоставляет следующие инструменты для поддержки автоматизированного функционального тестирования пользовательского интерфейса:

· UIAutomatorviewer -- графический инструмент для распознавания компонентов пользовательского интерфейса в Android приложении;

· UIAutomator -- библиотеки Java API, содержащие методы для создания тестов пользовательского интерфейса.

В приложении 4 приведены два скрипта для тестирования приложения: запуск приложения и открытие поста с детальной информацией о событии.



5. реализация рекомендательной подсистемы для мероприятий

5.1 Серверная часть

Для каркаса веб-приложения будет использоваться Spring Boot, который позволяет достаточно быстро создать полноценное Spring-приложение. Основные особенности Spring Boot

· возможность создания stand-alone приложений;

· встроенный Tomcat или Jetty;

· быстрый старт, многие библиотеки уже будут подключены платформой.

Spring платформа подключает все необходимые зависимости для работы с REST, JSON и т.п., избавляя от ручного добавления зависимостей. API приложения на данный момент достаточно простое, основной метод /recommendations реализуется в контроллере следующим образом:

@RequestMapping(value = "/recommendations", method = RequestMethod.POST)

public ResponseEntity<RecommendationResponse> buildRecommendations() throws IOException {

RecEngine recEngine = new RecEngine();

List<Recommendation> recommendations = recEngine.run();

return new ResponseEntity<>(new RecommendationResponse(recommendations), HttpStatus.OK);}

В POST запросе необходимо передать идентификатор пользователя, спецификация ответа с данными рекомендаций представлена в таблице 5, а сам ответ в приложении 5.



Таблица 5 - Параметры ответа на запрос рекомендаций

Параметр	Описание
recommendations	список рекомендаций
eventId	идентификатор события
name	название события
score	рейтинг события

Рекомендации пересчитываются один раз в сутки.

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

5.2 Работа с LensKit

Библиотеку LensKit можно подключить, добавив maven зависимость в pom.xml своего проекта.

Чтобы использовать LensKit для начала нужно настроить алгоритм. Это заключается прежде всего в выборе нужных компонентов и их настройке с помощью LenskitConfiguration, groovy-скрипт настройки item-item CF представлен в приложении 5.

Для работы LensKit необходим источник данных (DAO), сконфигурировать его можно следующим образом:

StaticDataSource data = StaticDataSource.load(recData.getDataFile());

Далее необходимо загрузить конфигурацию алгоритма Lenskit, которая описана в grovy-скрипте:

config = ConfigHelpers.load(new File("etc/item-item.groovy"));

Теперь необходимо создать объект LenskitRecommenderEngine, передав ему конфигурацию и DAO, он вычислит матрицу подобия и реализацию рекомендательного движка, который её использует:

LenskitRecommenderEngine e = LenskitRecommenderEngine.build(config, dao);

Полный код настройки и получения рекомендаций приведен в приложении 6.



ЗАКЛЮЧЕНИЕ

Основные результаты и выводы:

1. Исследована проблема выбора досуга, а также существующие решения на рынке, решающие эту проблему, особое внимание уделено минусам существующих решений, на основе которых были сформированы конкурирующие преимущества.

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

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

4. Исследованы способы построения рекомендательных систем для подбора потенциально интересных мероприятий.

5. Рассмотрены различные библиотеки и фреймворки, реализующие прогнозирующие алгоритмы. Для построения рекомендательной системы выбрана библиотека Lenskit.

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

7. Реализован сервис - серверная часть и клиент на Android, занимающийся подбором мероприятий.

Дальнейшие направления развития:

1. Использование новых API c открытыми данными, увеличение источников событий, мероприятий.

2. Охват большей аудитории путем реализации клиентских приложений под другие платформы.

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

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



СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. DeveloperWorks [Электронный ресурс]: инф.-справ. система. - Режим доступа: https://www.ibm.com/developerworks/ru/library/os-recommender1/index.html.

2. Gediminas Adomavicius and Alexander Tuzhilin. Toward the next generation of recommender systems: A survey of the state-of-the-art and possible extensions. Knowledge and Data Engineering, IEEE Transactions on, 17(6):734-749, 2005.

3. LensKit [Электронный ресурс]: Документация. - Режим доступа: https://www.ibm.com/developerworks/ru/library/os-recommender1/index.html.

4. GitHub [Электронный ресурс]: Википедия. - Режим доступа: https://ru.wikipedia.org/wiki/GitHub.

5. Nathan Srebro, Tommi Jaakkola, et al. Weighted low-rank approximations. In ICML, volume 3, pages 720-727, 2003

6. Emmanuel J Cand`es and Benjamin Recht. Exact matrix completion via convex optimization. Foundations of Computational mathematics, 9(6):717-772, 2009.

7. Xiaotian Jiang, Zhendong Niu, Jiamin Guo, Ghulam Mustafa, Zihan Lin, Baomi Chen, Qian Zhou. Novel Boosting Frameworks to Improve the Performance of Collaborative Filtering. Journal of Machine Learning Research : Workshop and Conference Proceedings volume 29, pages 87-99, 2013

8. Francesco Ricci, Lior Rokach, Bracha Shapira, Paul B Kantor. Recommender systems handbook. 2011

9. James Bennett and Stan Lanning. The netflix prize. In Proceedings of KDD cup and workshop, volume 2007, page 35, 2007.

10. Overview (Java Platform 8) [Электронный ресурс]: Java™ Platform, Standard Edition 8API Specification. - Режим доступа: https://docs.oracle.com/javase/8/docs/api/.

11. Apache Maven [Электронный ресурс]: Википедия. - Режим доступа: https://ru.wikipedia.org/wiki/Apache_Maven

12. Афиша мероприятий России [Электронный ресурс ]: офиц.сайт. - Режим доступа - https://www.culture.ru/afisha/russia.

13. Открытые данные министерства культуры [Электронный ресурс]: офиц.сайт. - Режим доступа: http://opendata.mkrf.ru/.

14. Open API | Разработчикам [Электронный ресурс]: документация по использованию открытого API Вконтакте. -Режим доступа: https://vk.com/dev/openapi/.

...