MetaTest

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

Главная страница

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

Мы сразу заметили, что в системе есть несколько ролей, у которых совсем разные цели и задачи. А так как сама система еще не была определена до конца, то нужно было заранее заложить механизм прав доступа. Лучше всего подходил классический паттерн Access Control List – где пользователи обладают ролями, а роли распоряжаются ресурсами. Это оказалось удачным решением, ведь добавление новых возможностей в процессе разработки легко было согласовать с системой доступа.

Когда была готова первая версия, заказчик решил расширить область применения системы. Теперь она должна была работать не внутри одной компании, а быть облачным продуктом для многих компаний. И еще раз нас выручила система ролей, достаточно было перераспределить уже размеченные ресурсы и добавить роль «Супер-администратора».

На данном этапе уже было понимание того, как должна работать система.

Прохождение теста

Отчет по тесту

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

Обмен сообщениями

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

Редактирование шаблона отчета

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

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

После некоторых размышлений мы решили написать особый язык конструктора отчетов, т.н. DSL (Domain Specific Language). За основу мы взяли шаблонизатор Twig, ведь в первую очередь язык был нужен для создания документов. Twig с одной стороны является полноценным языком с условиями, циклами и переменными, с другой – абсолютно безопасен и его шаблоны не имеют доступа к основному коду. Чтоб сделать его настоящим DSL мы добавили в Twig функции вывода графиков, таблиц и статистических расчетов. Также для каждого отчета уже были доступны переменные с наиболее часто используемыми данными – средним, дисперсией, списком ответов и т.п.

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

В итоге получился стабильный сложный по сути, но простой в управлении продукт. Своими главными достижениями мы считаем грамотное выяснение деталей процесса тестирования до написания кода (т.н. Requirements Specification) и удачное решение с конструктором шаблонов.

Tagfly

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

Заказчик хотел получить возможность гибко настраивать выдачу, так чтоб в разных категориях/станах можно было сортировать статьи по разным критериям и даже вставлять наборы других статей для рекламы, подмешивая их в основную выдачу. Это все должно было выглядеть, как лента Pinterest. Помимо статей в качестве блоков может выступать реклама или специальные блоки. Мы долго ломали голову, как это сделать и пришли к идее специального языка описания выдачи. Достаточно простого, чтоб с ним справился администратор сайта, и достаточно богатого, чтоб реализовать задачу выше. С чем-то похожим мы уже сталкивались в другом проекте «MetaTest», где нужен был гибкий конструктор отчетов.

Вот пример настройки выдачи в категории «Франция» 

и то, что получается на выходе

Вторым китом была система поиска туров, которая позволяет искать быстрее, чем остальные сайты. Сайт делает поиск сразу по широкому запросу, поэтому дополнительные запросы-уточнения происходят мгновенно для пользователя. Например, для поиска для туров в конкретный отель система не будет делать дополнительные запросы к оператору, как на других сайтах. Вы просто ставите птички, вбиваете названия, меняете «звездность» отеля, и т.п., а выдача справа меняется меньше, чем за секунду. 

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

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

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

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

Нам оставалось только подключить онлайн-оплату, продумать интерфейс с точки зрения удобства пользования. Мы добавили в проект социальные элементы: лайки, комментарии, рейтинг, статьи пользователей.  Чтобы показать отзывы об отелях мы сделали смешанную выдачу: часть отзывов мы берем из внешних источников и добавляем к ним отзывы, которые пользователи оставляют на нашем сайте. Еще пару мелочей вроде возможности автоматически создавать рекламные посадочные страницы прямо из админки и версия 1.0 была готова.

«TagFly» получился интересным проектом, как для нас – в плане решенных инженерных задач, так и для пользователей, которые получили возможность еще проще путешествовать.

Playmusics

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

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

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

Однако затем пришла мысль, что все можно сделать проще. Мы попробовали использовать АПИ ВКонтакте для поиска и фильтровать данные с помощью lastFM. Вконтакте возвращает название трека и автора,  и далее система  пытается найти исполнителей в lastFM. Если находит, то  добавляет биографию и афишу, поднимая результат в выдаче.  Если автор трека не найден, такой трек выводится внизу списка в категории «Другое». Таким образом, мы получаем группировку без семантического запроса. Оставался вопрос, насколько будет хороша такая группировка и можно ли будет легко исключить ошибки и опечатки, ведь музыку ВКонтакте загружают обычные люди, и одна и та же группа может называться по-разному.

схема работы со своей базой

в итоге сделали проще

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

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

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

создаем новый плейлист

загруженный плейлист

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

общий вид сайта

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

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