Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 5290 сообщений
Cообщения с меткой

mail.ru - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Приглашаем на Go Meetup 6 августа

Четверг, 28 Июля 2016 г. 20:22 (ссылка)





Приглашаем разработчиков, тимлидов и всех, кто так или иначе связан с разработкой на Go, принять участие в Go Meetup, который состоится 6 августа, в субботу, в московском офисе Mail.Ru Group. В программе встречи четыре доклада, подробности о них читайте под катом.



— «Внутренности Go», Вячеслав Бахмутов, Dropbox



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



— «Гигабайт JSON'а в секунду», Виктор Стародуб, Mail.Ru Group



Как написать самую производительную библиотеку для работы с JSON’ом на Go — easyjson. Спикер расскажет, как парсить и генерировать код на Go, поговорит о пользе и вреде reflection для сериализации и о микрооптимизациях, которые позволили обогнать альтернативы.



— «Встроенные БД в Go», Виталий Левченко, mc^2 software



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



— «Работа с Go из Python», Вадим Марковцев, source{d}



Возможность создавать динамические библиотеки появилась в Go относительно недавно, поэтому долгое время использовать Go-код в других языках программирования можно было только с помощью IPC. К счастью, теперь можно создавать биндинги с помощью cgo — интерфейса взаимодействия Go c традиционным userspace. К сожалению, пока существует достаточно мало успешных примеров. Цель доклада — рассказать о множестве подводных камней и трудностей в работе с cgo на примере использования go-git из Python. Спикер также расскажет о самом проекте go-git — клиенте Git, написанном на чистом Go, и о CFFI в Python.



Начало в 12:00. Адрес: Ленинградский пр-т, 39, стр. 79.



Для тех, кто не сможет присутствовать на встрече, будет организована онлайн-трансляция на IT.Mail.Ru, после — опубликована запись. Участие бесплатное, но регистрация обязательна. До встречи!

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/306652/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Как настроить расширяемую систему для регрессионного тестирования на телефонах: опыт мобильной Почты Mail.Ru

Пятница, 22 Июля 2016 г. 15:07 (ссылка)





Привет, Хабр! Сегодня я хочу рассказать, как мы построили с нуля гибкую и расширяемую систему для выполнения автотестов на Android-смартфонах. Сейчас у нас используется около 60 устройств для регрессионного тестирования мобильного приложения Почты Mail.Ru. В среднем они тестируют около 20 сборок приложения ежедневно. Для каждой сборки выполняется около 600 UI-тестов и более 3500 unit-тестов.



Автотесты доступны круглосуточно — они экономят очень много времени тестировщиков и позволяют нам выпускать качественное приложение. Без них мы бы тестировали каждую сборку 36 часов (с учетом ожидания) или примерно 13 часов без ожидания. Вместе со сборкой, актуализацией переводов, при рабочей загрузке агентов с автотестами тестирование в среднем занимает 1.5 часа, что ежедневно позволяет нам экономить недели работы тестировщиков.



Мы рассмотрим, как всё делать с самого начала тем, кто занимается написанием автотестов, а не инфраструктурой: начиная от покупки телефона, его перепрошивки и заканчивая созданием docker-контейнеров, внутри которых будет доступен телефон для автотестов.



Какие телефоны выбрать для автотестов на Андроиде?





Когда Android только-только становился популярным, у разработчиков тестов был выбор из двух зол: покупать дорогой зоопарк телефонов либо работать с медленными и глючными виртуалками. Сегодня всё несколько проще, на рынке появились дешёвые аппараты «эконом»-класса, а виртуальный Андроид обзавёлся образом для x86 и HAXM. Однако выбор всё ещё остался, многие предпочитают для автотестов виртуальные машины, но телефоны уже стали вполне доступной опцией даже для скромного бюджета на автотестирование. Так как же выбрать телефон для регрессионных автотестов и какое оборудование ещё нужно, чтобы всё вместе оно могло работать 24/7?



Рынок телефонов очень большой — глаза разбегаются. Какие же критерии выставить при выборе телефона? У меня после череды проб и ошибок вышел такой список (цену на аппарат опускаю, с ней, надеюсь, всё понятно):




  1. Есть возможность получить права root.

  2. Есть возможность анлока boot-раздела телефона.

  3. На телефоне стоит версия Андроида, максимально близкая к стоковой, или подобные можно установить (чтобы не пришлось лопатить кучу вариантов теста под разные интерфейсы).

  4. Оперативная память на телефоне желательно должна быть размером от 1 Гб (можно работать и на меньшей, но, даже если тесты написаны стабильно, различные проверки отображения «тяжёлых» объектов на телефоне с низкой оперативной памятью окажутся долгими).

  5. Совсем здорово, если у телефона будет долгий саппорт от производителя/пользователей, тогда у нас остаётся шанс продлить ему жизнь новыми версиями ОС.



Основная часть критериев достаточно прозрачна. Если окажется, что на телефоне что-то работает не так, то мы должны хотя бы иметь шанс заставить это работать сами. :) К сожалению, большая часть критериев — это не те вещи, о которых можно спросить продавца при покупке, поэтому в первую очередь наш путь лежит на forum.xda-developers.com и 4pda.ru/forum, где о рыночной модели можно узнать все подробности. Плюс ко всем перечисленным критериям, если модель уже долго продаётся, обращайте на форумах внимание на отзывы о браке и времени ресурса памяти и батареек, без них ваше устройство превратится в тыкву. Проблемы экрана, кнопок, корпуса, динамиков и прочего, что обычно интересует пользователя, вас, как правило, пугать не должны: телефон прекрасно будет работать с браком этих элементов, хотя всё зависит от специфики проекта.



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



1. Модель телефона имеет кучу региональных подвидов, при этом только на части из них можно получить рут или разлочить бутлоадер. Мало того что наткнуться на российский сертифицированный телефон в неофициальном магазине сложно — серые и белые телефоны выглядят одинаково, — так ещё и многие продавцы или их поставщики перепрописывают названия моделей, характеристики железа, регионы и даже версии операционных систем. Вполне возможен случай, когда внутри «Настроек» в Андроиде вы видите одну модель, внутри бутлоадера другую, а в шелле, когда набираете getprop и получаете айдишники, — третью. Просто телефон прошёл пару рук и пару регионов до вас. Сначала его хозяином был пользователь Веризона из Южной Дакоты, потом тот сдал его, в refurbished-состоянии аппарат как-то попал торговцу в Тель-Авиве, который его криво перепрошил на их версию операционной системы, а через ещё какое-то время телефон перекупил продавец в Москве, который уже стал продавать его как новый. Вам привозит его курьер, вы берёте в руки своё новое восьмиядерное перепрошиваемое российское устройство, не подозревая, что это шестиядерный залоченный региональный эксклюзив для контрактных пользователей оператора сотовой связи из США.





Элементы коробки и телефона с «современной» начинкой и высокой ценой, который по внутренним характеристикам оказался перепрошитой младшей моделью от AT&T



2. Один и тот же серийный номер. Здесь определить проблему попроще, но, к сожалению, даже официальные продавцы этим страдают, отсутствие серийного номера — это напасть многих бюджетных девайсов. Если при работе ваших автотестов используется adb, а к машине подключено несколько устройств, нужно либо переписывать код adb (так он увидит только один девайс), либо, если покупка совершалась по критериям выше, вписывать уникальный серийник самому.





Типичные значения серийников у бюджетных телефонов



3. Псевдослучайный MAC-адрес у Wi-Fi-модуля после перезагрузки телефона. Это была довольно серьёзная проблема, потому что мы узнали о ней, когда я убедился, что «всё хорошо», телефон нам подходит, и мы заказали 20 штук точно таких же. :) В процессе работы автотестов телефоны иногда перезагружаются, через какое-то время тесты начали падать из-за отсутствия доступа к сети по Wi-Fi, хотя всё при этом выглядело нормально: соединение с сетью было и после включения/выключения Wi-Fi-модуля всё работало корректно. Просто после ребутов в какой-то момент у пары телефонов оказывался одинаковый MAC, Wi-Fi-точка доступа же пускала только последний присоединившийся. На тех телефонах, где в итоге генерился MAC-адрес, я, к сожалению, не нашёл, пришлось в загрузочном разделе поместить скрипт, который устанавливал его насильно на уникальный.





Телефон демонстрирует чудеса spoofing’а из коробки



Тем не менее, если соблюдать при выборе телефона перечисленные выше критерии, эти проблемы не должны быть фатальными — всё это можно исправить руками и заставить телефон работать как нужно.



Кроме телефонов, для запуска автотестов понадобится сам компьютер и USB-хабы, тут тоже есть несколько нюансов. Постоянно работающим телефонам нужно хорошее питание (минимум 0,5 А на устройство, лучше больше), многие хабы на рынке идут со слабыми адаптерами и никак не рассчитаны на то, что в каждый порт будет подключён постоянно работающий телефон. С планшетами ещё сложнее, девятидюймовые планшеты при постоянной работе разряжаются, экран слишком большой, приходится выбирать из семидюймовых. Из практики у нас вышло, что на адаптер в 4 А можно подключить 6–7 телефонов (в зависимости от их загрузки работой), т. е. большая часть многопортовых хабов с характеристиками типа «адаптер на 3 А, 20 USB-портов», мягко говоря, бесполезны. Самые крутые — серверные решения, но цена у них зашкаливает, так что ограничимся пользовательским рынком. Чтобы телефоны не разряжались, стоит брать хабы на четыре порта с питанием в 3 А, либо хабы на шесть портов с питанием на 4 А. Если есть хабы с хорошим питанием, но с большим количеством портов, — часть портов можно просто не использовать.



Готовим телефон к работе



Давайте для примера возьмём одну модель телефона, решим одну из проблем его операционной системы, а дальше попробуем собрать эти устройства в примитивный тестовый стенд для автотестов. Телефон сам по себе дешёвый и хороший, но с некоторыми недостатками (описанными выше). В частности, у этих телефонов одинаковый iSerial, adb видит только одно устройство. :( Совсем везде на телефоне его менять не будем, но сделаем так, чтобы adb отдельные телефоны отличал.



Для этого нам нужно будет перепрошить у телефона boot-раздел и установить на устройстве кастомный раздел восстановления — так вы сможете уберечься от неудачных экспериментов. У наших телефонов стоит МТ6580, т. е. процессор фирмы Mediatek, значит, для перепрошивки можно использовать SP Flash Tool. Ещё нужны готовый образ recovery.img и scatter-файл устройства. Почти для всех устройств их можно найти в интернете, на тех же самых ресурсах XDA и 4PDA, но при желании recovery можно перекомпилировать для своего устройства, взяв за основу TWRP, а scatter-файл создать самому. В любом случае берём наши готовые файлы и перепрошиваем:







После установки раздела восстановления сохраните через него бэкап boot-раздела и переместите его к себе на машину, обычно в этом разделе располагаются конфигурационные файлы ОС. Чтобы захардкодить свой iSerial, нужно распаковать образ загрузочного раздела телефона, это можно сделать с помощью Android Image Kitchen. Запускаем unpackimg.sh и получаем распакованный образ в папке ramdisk:







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







Находим файл, где устанавливается серийный номер ${ro.serialno}, и заменяем его на свой номер, например 999222333019:



find ramdisk/ -maxdepth 1 -name "init.mt*" -exec sed -i 's/${ro.serialno}/999222333019/g' {} +


Запаковываем образ обратно с помощью repackimg.sh, перекидываем его на телефон и устанавливаем с помощью кастомного рекавери. Теперь adb будет отличать устройства, нам остаётся включить режим разработчика на телефоне и разрешить debug в меню разработчика. Любые подобные проблемы можно решать точно таким же путём, практически всё в телефоне можно перепрошить или поправить, если этого потребуют задачи тестирования.



Настройка тестовой машины



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



При заказе/сборке машины, к которой будут подключены телефоны, есть специфика. Кроме стандартных HDD/RAM/CPU, нужно обратить внимание на количество USB-контроллеров на материнской плате и поддерживаемый протокол USB. Телефоны, работающие на USB 3.0 (xHCI), могут существенно ограничить максимальное количество устройств на машине (обычно 8 на контроллер, в итоге 16 устройств на машину с двумя контроллерами), поэтому стоит проверить, есть ли возможность его отключить и использовать только EHCI. Такие опции есть в биосе или ОС, лучше всего насильно отключить xHCI в биосе, если вам не нужны высокоскоростные устройства.



Создаём контейнер для телефона



Если нужно, чтобы слейв / агент системы интеграции работал с отдельным телефоном, то их следует как-то разделить. У нас агенты запускаются в отдельных docker-контейнерах, каждому из которых доступно по одному устройству, — так мы можем распределять задачи в CI на отдельные устройства, а точнее на их возможности (например, контейнер с планшетом может выполнять тесты, для которых требуется широкая диагональ экрана, а контейнер с телефоном — тесты, для которых нужна возможность принимать SMS-сообщения). Пример установки и настройки системы на Ubuntu описан далее. Устанавливаем сам Docker:



sudo apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D
echo 'deb https://apt.dockerproject.org/repo <версия ubuntu> main' >> /etc/apt/sources.list.d/docker.list
sudo apt-get update
sudo apt-get install docker-engine


В качестве сторадж-драйвера будем использовать overlayFS (работает быстрее дефолтного):



echo 'DOCKER_OPTS="-s overlay"' >> /etc/default/docker


Создаем dockerfile, из которого будем делать образы. Добавим в него Android SDK:



FROM ubuntu:trusty
ARG DEBIAN_FRONTEND=noninteractive

RUN apt-get update -y && \
apt-get install -y software-properties-common && \
add-apt-repository ppa:webupd8team/java -y && \
apt-get update -y && \
echo oracle-java8-installer shared/accepted-oracle-license-v1-1 select true | /usr/bin/debconf-set-selections && \
apt-get install -y oracle-java8-installer && \
apt-get remove software-properties-common -y && \
apt-get autoremove -y && \
apt-get clean
ENV JAVA_HOME /usr/lib/jvm/java-8-oracle
ENV ANT_VERSION 1.9.4

RUN cd && \
wget -q http://archive.apache.org/dist/ant/binaries/apache-ant-${ANT_VERSION}-bin.tar.gz && \ tar -xzf apache-ant-${ANT_VERSION}-bin.tar.gz && \ mv apache-ant-${ANT_VERSION} /opt/ant && \ rm apache-ant-${ANT_VERSION}-bin.tar.gz

ENV ANT_HOME /opt/ant
ENV PATH ${PATH}:/opt/ant/bin

ENV ANDROID_SDK_VERSION r24.4.1
ENV ANDROID_BUILD_TOOLS_VERSION 23.0.3

RUN dpkg --add-architecture i386 && \
apt-get update -y && \
apt-get install -y libc6:i386 libncurses5:i386 libstdc++6:i386 lib32z1 && \
rm -rf /var/lib/apt/lists/* && \
apt-get autoremove -y && \
apt-get clean

ENV ANDROID_SDK_FILENAME android-sdk_${ANDROID_SDK_VERSION}-linux.tgz
ENV ANDROID_SDK_URL http://dl.google.com/android/${ANDROID_SDK_FILENAME}
ENV ANDROID_API_LEVELS android-15,android-16,android-17,android-18,android-19,android-20,android-21,android-22,android-23
ENV ANDROID_HOME /opt/android-sdk-linux
ENV PATH ${PATH}:${ANDROID_HOME}/tools:${ANDROID_HOME}/platform-tools
RUN cd /opt && \
wget -q ${ANDROID_SDK_URL} && \
tar -xzf ${ANDROID_SDK_FILENAME} && \
rm ${ANDROID_SDK_FILENAME} && \
echo y | android update sdk --no-ui -a --filter tools,platform-tools,${ANDROID_API_LEVELS},build-tools-${ANDROID_BUILD_TOOLS_VERSION}

###Добавим файл системы интеграции, это может быть слейв дженкинса, агент Bamboo и т. п., в зависимости от того, с чем вы работаете
ADD moyagent.sh /agentCI/


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



docker build .


Теперь у нас есть образ с Android SDK, осталось сделать так, чтобы он видел только одно устройство. Для этого будем цеплять его через симлинк c помощью udev:



echo ‘"SUBSYSTEM=="usb", ATTRS{serial}=="$DEVICE_SERIAL", SYMLINK+="androidDevice1"’ >> /etc/udev/rules.d/90-usb-symlink-phones.rules


Вместо $DEVICE_SERIAL вписываем наш свежепрошитый серийник. Перезапускаем определение правил устройств:



udevadm control --reload
udevadm trigger


Теперь в пути /dev/androidDevice1 у нас будет симлинк на устройство, осталось передать его в контейнер при запуске:



docker run -i -t --rm --device=/dev/androidDevice1:/dev/bus/usb/001/1 android-docker-image:latest adb devices


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



docker run -i -t --rm --device= /dev/androidDevice1:/dev/bus/usb/001/1 android-docker-image:latest /bin/sh /agentCI/moyagent.sh


Кстати, ключ --device стал работать с симлинками относительно недавно (master-ветка на Гитхабе), до этого приходилось генерить из симлинка realpath c помощью скрипта и уже его передавать Докеру, так что если у вас не выходит подключение устройства, то добавьте в udev в параметр RUN+= такой скрипт:



realpath /dev/androidDevice1 | xargs -I linkpath link linkpath /dev/bus/usb/010/1


После этого в старых версиях Docker добавить телефон можно так:



docker run --privileged -v /dev/bus/usb/010/:/dev/bus/usb/100/ -i -t  android-docker-image:latest adb devices


Всё, можно подключать свой слейв к системе интеграции и работать с ним.



Заключение



Физические мобильные устройства в системе интеграции рано или поздно появляются у любого более-менее крупного проекта на Андроиде — неизбежно возникают необходимость покрытия ошибок, нестандартные тестовые случаи или просто фичи, которые требуют реального устройства. Кроме всего этого, устройства не используют ресурсы ваших серверов, так как процессоры и память у них свои, а хост для телефонов не должен быть супермощным, «домашний» десктоп со всем этим вполне справится. Соизмеряйте плюсы и минусы, считайте, что выгоднее, — наверняка в вашей системе автоматизированного тестирования есть место реальным устройствам. Желаю вам поменьше багов и побольше тестового покрытия. :)
Original source: habrahabr.ru.

https://habrahabr.ru/post/306236/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Из песочницы] MLBootCamp «Оценка производительности». Очень простой и быстрый вариант решения

Пятница, 22 Июля 2016 г. 08:56 (ссылка)

В этой заметке хочу поделиться своей идеей решения задачи MLBootCamp «Оценка производительности» от Mail.ru. Главное достоинство этого способа — в его простоте и скорости выполнения скрипта. И хотя он не сможет соревноваться в точности с победителями соревнования (мои поздравления!), но может оказаться полезным на практике, если несколько десятых процента не являются критичными, или отправной точкой для дальнейшего развития. Скрипт написан на R.





1. Загрузка и подготовка данных



Коротко о соревновании, вот как поставлена задача:

«Мы предлагаем вам научить компьютер предсказывать, сколько секунд будут умножаться две матрицы размера mxk и kxn на данной вычислительной системе, если известно, сколько решалась эта задача на других вычислительных системах с другими размерами матриц».



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



А теперь немного подробнее. В обеих выборках для каждого наблюдения имеется 951 признак. Первые три из них это размерности умножаемых матриц, остальные — параметры систем, на которых проводились измерения. Оказывается, что если отбросить параметры умножаемых матриц, то в тренировочной выборке 92 уникальных конфигурации использовавшихся вычислительных систем, т.е. оставшиеся 948 параметров имеют всего лишь 92 комбинации. Заменив эти 948 параметров одним, идентификатором конфигурации, мы получим, что в наших данных всего лишь 4 признака для каждого наблюдения. Подготовим данные для дальнейшей работы добавив еще произведение всех размеров матриц. Теперь в данных есть признаки, m, k, n, m*k*n и conf (идентификатор компьютера). Также, тренировочная выборка содержит целевую переменную time — время, за которое было выполнено умножение матриц.



library(quantreg)
library(dplyr)


# загрузка исходных данных
y <- read.csv('y_train.csv')[,1]
X.train <- read.csv('x_train.csv', stringsAsFactors = FALSE)
X.test <- read.csv('x_test.csv', stringsAsFactors = FALSE)


# создадим таблицу с уникальными конфигурациями
X.all <- rbind(X.train, X.test)
X.uni <- unique(X.all[,4:951])
# создадим датафрейм с уникальными конфигурациями и вектор с их именами
X.uni <- cbind(conf=paste0('conf', formatC(1:nrow(X.uni), 2, flag = '0')), X.uni)
confs <- unique(X.uni$conf)


# разметим тренировочную выборку именами и выкинем все ненужные столбцы
# преобразуем целый тип к вещественным и добавим целевую переменную
cols <- c('m', 'k', 'n', 'conf')
X.train <- dplyr::inner_join(X.train, X.uni, by=colnames(X.uni)[2:ncol(X.uni)])[cols]
X.train[,1:3] <- lapply(X.train[,1:3], as.numeric) # int->numeric
X.train$mkn <- X.train$m * X.train$k * X.train$n
X.train$time <- y
# то же для тестовой выборки
X.test <- dplyr::inner_join(X.test, X.uni, by=colnames(X.uni)[2:ncol(X.uni)])[cols]
X.test[,1:3] <- lapply(X.test[,1:3], as.numeric) # int->numeric
X.test$mkn <- X.test$m * X.test$k * X.test$n




2. Предварительный анализ данных и выбор рабочей модели



Теперь можно посмотреть на данные и увидеть ожидаемую зависимость целевой переменной time от m*k*n. Например, конфигурация 39 (слева). Она хорошо аппроксимируется линейной регрессией. Однако, не для всех конфигураций линейная модель может дать хороший результат, например, конфигурация 11 (справа):



image




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



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

В R их можно найти в пакетах quantreg и MASS соответственно. Каждая из них имеет свои настройки, и/или более продвинутые вариации. Здесь эти методы использовались с параметрами по умолчанию. Вот как будет выглядеть график со всеми регрессиями для шумной конфигурации 11:



image




3. Обучение и тест моделей



Разброс значений целевой переменной варьируется в широких пределах для каждой из систем, поэтому напрашивается решение: обучить стек моделей, по одной на каждую конфигурацию. Пусть зависимость в каждой модели будет немного сложнее, а именно время затраченное от умножение матриц будет зависеть не только от произведения их размеров, но и от каждого из них в отдельности, т.е. time ~ m + k + n + mkn:



models <- list()
for (i in 1:length(confs)){
# выбор конфигурации
X.conf <- subset(X.train, conf==confs[i])
X.conf$conf <- NULL
# обучаем модель и добавляем ее в стек
fit <- rq(time ~ ., data=X.conf)
models[[confs[i]]] <- fit
}


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



y.test <- rep(1, nrow(X.test))
y.train <- rep(1, nrow(X.train))
# предсказания на тренировочной выборке
for (i in 1:length(confs)){
X.conf <- subset(X.train, conf==confs[i])
y.train[as.numeric(rownames(X.conf))] <- predict(models[[confs[i]]])
}
# предсказания на тестовой выборке
for (i in 1:length(confs)){
X.conf <- subset(X.test, conf==confs[i])
y.test[as.numeric(rownames(X.conf))] <- predict(models[[confs[i]]], newdata = X.conf)
}


В силу неидеальности исходных данных и, следовательно, полученных моделей в предсказанных значениях будут числа меньше 1, которые по условию задачи быть не должны. Здесь оказывается полезным воспользоваться предсказаниями на тренировочной выборке и заменить все неподходящие значения. Простым и эффективным методом является замена всех чисел, меньших определенной константы, отсечки, ей самой. На графике представлен график метрики (MAPE) в зависимости от значения отсечки cutoff. Горизонтальная линия — метрика без замены, вертикальная — отсечка, при котором метрика принимает наименьшее значение.



image




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



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



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



Тем не менее, алгоритм с выбором между квантильной и робастной регрессией для каждой конфигурации, показал результат MAPE=5.23% на публичном лидерборде. По итогам соревнования метрики нет, но на основе данных по кросс-валидации ожидается MAPE около 5.4%.



4. Заключение



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



По скромному мнению автора, использование квантильной (или другой, устойчивой к выбросам) регрессии для предсказания времени выполнения компьютерных экспериментов является весьма практичным, точным и куда менее вычислительно затратным, чем способ приведенный в статье к соревнованию, где использовались линейная регрессия с удалением значений (собственный велосипед?) и случайные леса.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/306198/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Юзабилити-тестирование: хотите ли вы узнать правду о своих пользователях?

Вторник, 19 Июля 2016 г. 16:11 (ссылка)



Общение с очередным респондентом. Кадр из к/ф Матрица (The Matrix, 1999)



Как вы знаете из наших прошлых постов, в Mail.Ru Group есть своя UX-лаборатория, которой более четырех лет. Сейчас в большинстве крупных IT-компаний либо уже есть направление UX-исследований, либо планируется его запуск. Наша лаборатория работает только с продуктами Mail.Ru Group, но мы решили сделать исключение и приоткрыли её двери для внешних компаний и проектов, знающих о ценностях UX-исследований, но пока не решившихся выделить бюджет на их проведение.



Для выбора внешнего «заказчика» мы распространили информацию о нашем конкурсном проекте в социальных сетях и устроили розыгрыш бесплатного юзабилити-тестирования. Победителем стала команда проекта service-centers.ru — это сайт для поиска и выбора сервисных центров по всей России.



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



1. Этапы проекта



1.1. Подготовка



1.1.1. Первая встреча с заказчиком



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



1.1.2. Результаты встречи



О продукте



Service-centers.ru позволяет владельцам/представителям сервисных центров (далее сокращенно — СЦ) разместить информацию о СЦ и заниматься их продвижением/популяризацией, а потребителям услуги найти СЦ, соответствующий их запросу.



Аудитория продукта



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




  • Владельцы/представители СЦ — владельцы СЦ или ответственные за продвижение СЦ и размещение информации о них.

  • Пользователи бытовой техники и электроники — любой человек, столкнувшийся с поломкой бытовой техники (далее сокращенно — БТ) и/или электроники.



По данным заказчика, среди пользователей сайта 80% мужчин и 20% женщин. Возрастной диапазон — от 28 до 35 лет.



Основной запрос заказчика



Основные пожелания заказчиков были зафиксированы и представлены четкими требованиями к проекту:




  • Получить информацию о том, как пользователи выбирают СЦ, на какие параметры ориентируются при выборе СЦ, на что обращают внимание.

  • Проверить, различаются ли поведение и критерии выбора СЦ у жителей Москвы и жителей регионов (например, Ростов-на-Дону и Казань).

  • Понять, насколько удобен стал сайт после редизайна для пользователей БТ и электроники.





Изменения в продукте



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



1.1.3. Планирование проекта



Предложение заказчику



Так как заказчик хотел не только выявить юзабилити-проблемы продукта, но и узнать о том, как представители ЦА выбирают СЦ и на что обращают внимание, к тестированию был добавлен блок интервью, позволивший собрать опыт респондентов, полученный ранее при столкновении с такой проблемой, как поломка бытовой техники или электроники.



По итогам встречи мы составили предложение по проекту:



Метод



Юзабилити-тестирование с элементами интервью (вводное интервью, задачи тестирования, моделирующие несколько ситуаций обращения в СЦ).



Респонденты



Заказчик был ориентирован на пользователей БТ и электроники, поэтому мы стали работать с этой частью пользователей сайта.



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



Критерии рекрутинга



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



«Опытные пользователи» — на бытовом уровне разбираются в ремонте БТ и электроники (могут собрать компьютер из комплектующих; разобрав электронику, понять, какая из запчастей вышла из строя); самостоятельно выбирают БТ и электронику; предпочитают самостоятельно разобраться в причине поломки.



«Неопытные пользователи» — не разбираются в ремонте БТ и электроники; не могут выбрать БТ и электронику самостоятельно и обращаются за помощью; не пытаются определить причину поломки самостоятельно.



В каждой группе половина респондентов была жителями Москвы и половина — жителями регионов (Казань и Ростов-на-Дону).
























Опытные Неопытные
Москва 2 респ.

2 респ.

Казань 1 респ.

1 респ.

Ростов-на-Дону 1 респ.

1 респ.



Задачи тестирования



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



Задачи, предлагаемые респондентам:




  • Свободный поиск СЦ — респондентам предлагалось найти СЦ для ремонта той вещи, которая ломалась у них последней.

  • Поиск крупного (сетевого) СЦ — респондентов просили представить, что их знакомый рассказал о том, как, сдав телефон в ремонт, не смог вернуть его. Респондента просили выбрать СЦ, которому, на их взгляд, можно доверять. Мы хотели проверить, какой из параметров будет ассоциироваться с надежностью СЦ.

  • Поиск авторизованного СЦ — респондентов просили найти СЦ, одобренный производителем сломанной вещи. Задание предлагалось в том случае, если ранее респондент не искал СЦ по этому параметру.

  • Поиск СЦ для срочного ремонта — респондента погружали в ситуацию, требующую срочного ремонта.



1.2. Что мы получили перед выходом на тестирования?



Респонденты



Критерии рекрутинга — четко сформулированные, согласованные с заказчиком и направленные в рекрутинговое агентство.



Расписание тестирований



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



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



Сценарий



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



Приглашение заказчика на просмотр сессий тестирования



Заказчика пригласили на просмотр тестирования. Представители заказчика могли вживую видеть работу респондентов и фиксировать возникающие затруднения.



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



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



1.3. Тестирование



Организация тестирования



Часть тестирований проходила в нашей лаборатории с использованием eye-tracking.



Респондентов из регионов тестировали удаленно. Для подобных случаев мы предпочитаем использовать GoToMeeting.



Ход тестирования, или какие проблемы бывают



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



Респонденты иногда:




  • не приходят — спасает запасной день тестирования;

  • сильно опаздывают — спасает большой перерыв между сессиями;

  • не понимают, на каком ПО будет проходить удаленное тестирование, — бывает, что перед тестированием у респондента нет под рукой компьютера, важно очень четко договориться;

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



Обработка результатов



При обработке полученных данных мы смотрели:




  • Есть ли какой-либо параметр, заметно влияющий на поведение пользователей при выборе СЦ, и/или параметры, на которые они ориентируются?

  • Из каких шагов состоит процесс подбора СЦ?

  • Какие параметры СЦ пользователи считают основными?



Также в отчете были представлены выявленные юзабилити-проблемы service-centers.ru.



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



2. Результаты



2.1. Результаты интервьюирования



Аудитория



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



Деятельность всегда разбита на три шага:




  • поиск информации в интернете;

  • звонок/консультация в СЦ;

  • принятие решения об обращении в СЦ.



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












Респонденты, относившиеся к группе «Опытные» Респонденты, относившиеся к группе «Неопытные»

  • Делают ставку на консультации в СЦ. Дотошно и тщательно расспрашивают о возможных причинах поломки.

  • Консультация по телефону в большей степени является проверкой СЦ и мастеров.

  • Меньше доверяют СЦ.

  • Обзванивают больше вариантов.


  • Больше ориентируются на внешние признаки (фотографии, внешний вид сайта, вежливость мастеров приемки во время телефонного разговора) и удобство расположения.

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



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



Параметры подбора СЦ



При рассказе респондентов об опыте подбора СЦ в интернете удалось зафиксировать параметры, на которые ориентируются пользователи.



Основные параметры подбора СЦ на сайтах:




  • вид техники — 5 из 8;

  • время работы — 4 из 8;

  • стоимость работ — 4 из 8

  • местоположение — 4 из 8

    (предпочитали СЦ рядом с домом или работой);

  • производитель — 3 из 8.



Дополнительные опции:




  • приятный сайт — 2 из 8;

  • специализация СЦ — 1 из 8.



Помимо основных параметров подбора, респонденты учитывают:




  • сроки ремонта — 7 из 8 (чаще, чтобы понять, когда они получат вещь назад; в случае если вещь нужна срочно, то уточняют, есть ли в СЦ опция срочного ремонта).



2.2. Результаты тестирования



По итогам тестирования были выделены основные блоки проблем service-centers.ru:




  • навигация;

  • фильтры и сортировка;

  • просмотр списка СЦ;

  • представление информации о СЦ;

  • проблемы карточки СЦ.



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



На сайте нет единого и универсального способа начать поиск сервисного центра



Посетителям предлагается воспользоваться строками поиска и разделами «Чаще всего в Москве ремонтируют» и «Самые популярные сервисные центры Москвы».







Почему это неудобно? Эти инструменты навигации хороши для решения конкретных задач и могут быть использованы как дополнительные.



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



Что же делали респонденты? Респонденты долго просматривали главную страницу перед тем, как перейти к поиску СЦ. В случае поломки вещей, не попадающих в категорию часто ремонтируемых, пользователи испытывали затруднения.



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



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



Разберем проблему из блока «Фильтры и сортировка».



Незаметна возможность просмотреть СЦ на карте



Вид опции «Просмотр на карте» до внедрения изменений:







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







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



* Блок фильтров визуально не выделен и сливается с фоном сайта. В результате блок фильтров не выглядит как инструмент, относящийся к списку СЦ, воспринимается как «шум» и игнорируется пользователями.



Наши рекомендации. Просмотр на карте, по сути, является не параметром фильтрации, а способом просмотра списка СЦ. Мы рекомендовали разместить этот функционал в начале списка. Например, в виде переключателя «Просмотр на карте» и «Просмотр списка».



Рассмотрим еще одну проблему, теперь из блока «Представление информации о СЦ».



Незаметна возможность посмотреть время работы СЦ



График работы СЦ появляется как всплывающая подсказка при наведении курсора на статус работы СЦ («Сейчас открыто/закрыто» и время закрытия/открытия).







Пользователям было неудобно ориентироваться по статусу работы СЦ. Чтобы выбрать время для визита в СЦ, важно знать, когда открывается и закрывается СЦ. Большинство респондентов не заметили возможность посмотреть график работы, наведя курсор на статус работы СЦ.



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



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



3. Итоги



Итогами нашей совместной работы стал усовершенствованный сайт service-centers.ru. Проект помог команде заказчика понять свою аудиторию, их поведение при поиске СЦ и приоритетные параметры подбора.



Классика тестов — заказчик понял язык, на котором говорит его аудитория, и смог адаптировать продукт под решение задач ЦА.



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



Хороший вариант для поиска эффективных решений — итеративные тестирования.
Original source: habrahabr.ru.

https://habrahabr.ru/post/305952/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

IoT-хакатон Mail.Ru Group и Intel 30–31 июля: теперь с сетями 6LoWPAN и LoRa

Пятница, 15 Июля 2016 г. 09:33 (ссылка)

Две недели назад мы уже приглашали всех желающих принять участие в хакатоне по теме «Интернета вещей», который пройдёт 30-31 июля в московском офисе Mail.ru Group — и научиться работать с такими современными IoT-платформами, как микрокомпьютеры Intel Edison и СУБД Tarantool.



С того момента мы получили множество заявок и описаний будущих проектов — от вполне конкретизированных до «сделаю что-нибудь крутое». Авторы многих из них планировали построить прототипы целых распределённых систем сбора и обработки данных — то есть, в общем, реализовать самые настоящие IoT-проекты с областью применения от «умного дома» до количественного земледелия.







Поэтому мы решили расширить круг оборудования, которое будет доступно участникам хакатона — и теперь в него войдут комплекты беспроводных модулей сети 6LoWPAN разработки компании Unwired Devices, которые в сочетании с Tarantool и Edison позволят осуществить всё, что бы ни задумали участники.



Итого, участникам хакатона будут доступны технологии:


  • Набор датчиков и управляющих устройств Unwired Devices для сети 6LoWPAN

  • Шлюз между 6LoWPAN и Wi-Fi на базе микрокомпьютера Intel Edison

  • Работающая на шлюзе СУБД Tarantool, обеспечивающая обработку и надёжную репликацию данных





Более того, хакатон посетят и представители венчурного инвестора — фонда CommIT Capital, принадлежащего компании «Ростелеком».



Подавайте заявки и приходите!



P.S. Что именно будет входить в наборы — под катом.







6LoWPAN — это одна из новейших сетевых технологий, разработанная специально для «Интернета вещей»; по сути, IPv6, адаптированный для физического уровня 802.15.4 — который, в свою очередь, адаптирован для низкоскоростных беспроводных сетей с небольшим размером типичного пакета данных и очень большим количеством устройств.



Кроме этого, на хакатоне будут представлены и модули связи для сетей LoRa (модель Unwired Range) — с радиусом действия до 30 км (прописью: тридцати километров) в прямой видимости, а также некоторые промышленные решения на базе этих технологий. Впрочем, с точки зрения работы с Tarantool большой разницы между LoRa и 6LoWPAN нет — Unwired Range и Unwired Mesh совместимы как по разъёмам, так и по API верхнего уровня, поэтому, отработав проект на одном типе модулей, можно без большого труда перенести его на другой.



С полным списком модулей комплекта Unwired Kit можно ознакомиться на сайте компании. Модули, входящие в стандартный набор для хакатона, перечислены ниже — но если мы увидим интересные проекты, для которых могут быть полезны иные модули или даже целые устройства, мы постараемся также их предоставить.



UMDK-EDISON





Модуль шлюза из сетей LoRa и 6LoWPAN в Wi-Fi. Благодаря высокой производительности и объёму памяти Intel Edison, это не просто транслятор пакетов между двумя различными средами — а полноценный сервер для обработки данных, полученных из IoT-сети, и управления ею. На Edison будет установлена СУБД Tarantool, делающая решение этих задач ещё проще и эффективнее.







Помимо собственно Edison, на модуле стоят двунаправленные трансляторы логических уровней TI TXB0108 и TXB0102 (GPIO Edison работают с 1,8 В, остальные модули набора — с 3,3 В), а наружу дополнительно выведены 8 GPIO и порт USB.



UMDK-RF/868





Радиомодуль сети 6LoWPAN для безлицензионного диапазона 868-869 МГц, использующий новейшее поколение чипов TI SimpleLink — CC1310. Дальность работы — до 200 метров в прямой видимости на полной скорости (50 кбит/с). К каждому радиомодулю можно подключить один или несколько датчиков и исполнительных устройств — сделанных как в собственном формате Unwired Kit, так и в формате Grove Starter Kit Plus.



UMDK-JTAG





Программатор с поддержкой JTAG (для модулей LoRa) и UART-загрузчика (для модулей 6LoWPAN). Позволяет быстро обновлять прошивки модулей — например, собрать из двух разных комплектов один большой, сменить радиодиапазон или добавить в прошивку готовый блок для поддержки нужного датчика при желании скомбинировать несколько датчиков на одном радиомодуле.



UMDK-THP





Высокоточный цифровой датчик температуры, влажности и барометрического давления — на базе чипов Sensirion SHT21 и STMicro LPS331AP. Пригодится как в «умном доме», так и, например, в поддержании климата в теплице.



UMDK-LIT





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



UMDK-SOIL





Емкостной высокочастотный датчик влажности и поверхностной температуры почвы. Не имеет электрического контакта с почвой, а потому, в отличие от распространённых датчиков электропроводности почвы, не подвержен коррозии. Рабочая частота 50 МГц позволяет минимизировать зависимость показаний датчика от солевого состава почвы.



UMDK-2AA





Модуль автономного питания с двумя батарейками формата «АА». Обеспечивает напряжение 5 В и позволяет включать модули UMDK-RF с датчиками вдали от розетки (если же розетка близко — UMDK-RF можно питать от любого зарядного устройства с разъёмом microUSB).



UMDK-2RDC





Два обычных реле постоянного тока. Используются высококачественные реле Omron G6D, рассчитанные на 5 А при 250 В переменного тока. Впрочем, если вам требуется коммутировать действительно мощную нагрузку — лучше выбрать модуль UMDK-1RAC со специальной схемой, устраняющей искрение контактов реле и снижающей пусковые токи.



UMDK-GRV





Модуль-переходник на датчики из набора Grove Starter Kit. Поддерживается большинство датчиков, способных работать от напряжения 3,3 В. Кроме того, к этому же модулю подключаются выносные датчики Unwired Devices — UMDK-ACC/T и UMDK-SOIL.



UMDK-ACC/T





Выносной датчик вибрации (гироакселерометр ST LSM6DS3) и поверхностной температуры (NXP LM75AD). Крайне полезен в задачах мониторинга состояния промышленного оборудования — например, по повышению температуры или амплитуды вибраций можно прогнозировать скорый отказ станка и планировать его обслуживание до того, как этот отказ случится.



O Tarantool





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



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



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



Oб Edison





Intel Edison — это мощная, сверхкомпактная, высокоинтегрированная «система на модуле», оснащённая процессором Intel Atom с частотой 500 МГц, 4 ГБ флеш-памяти, 1 ГБ ОЗУ и встроенными адаптерами Wi-Fi и Bluetooth. В системах «Интернета вещей» Edison может обеспечить великолепную производительность и широкие возможности по сбору и обработке данных на шлюзе между IoT-сетью и Интернетом — и всё это при крайне скромных размерах и энергопотреблении, позволяющем при необходимости питать Edison от аккумулятора.



Unwired Devices





Компания Unwired Devices специализируется на разработке и производстве современной электроники, в первую очередь, встраиваемых микрокомпьютерных и сетевых коммуникационных устройств. Cфера интересов компании включает технологии Интернета вещей, Wi-Fi и ячеистых сетей (mesh-сетей), сетей LoRa, продукты для автоматизации промышленного освещения, беспроводного управления и сбора данных, а также системы «умного» дома и «умного» офиса.



Unwired Kit — это набор электронных модулей, предназначенный для быстрой разработки устройств «Интернета вещей»: IoT-контроллеров и маршрутизаторов, ячеистых сетей, сетей LoRa большого радиуса действия, включающих различные типы датчиков, средств управления и исполнительных устройств. Помимо типовых модулей, в набор входят модули с такими широко используемыми в промышленных системах интерфейсами, как DALI, ШИМ 0-10 В или RS-485.



CommIT Capital





CommIT Capital – корпоративный фонд ПАО «Ростелеком». Цель «КоммИТ Кэпитал» — находить на рынке инновационные компании, чей бизнес комплементарен бизнесу телекоммуникационного оператора, и инвестировать в лучшие из них. Такие компании должны обладать уникальными компетенциями в своих областях и иметь высокотехнологичный продукт с экспортным потенциалом. В свою очередь, фонд помогает им развиваться и реализовывать синергии с «Ростелекомом».



Приоритетными направлениями для инвестирования являются компании, разрабатывающие продукты для сетевой инфраструктуры оператора и центров обработки данных. Не менее интересны решения корпоративного класса. Фонд также рассматривает проекты с новыми продуктами и услугами для конечных клиентов «Ростелекома» в сегментах B2C, B2B и B2G.



В портфеле фонда компания «Raidix» (разработчик систем хранения данных) и «Brain4Net» (решения для операторов и корпораций в области SDN & NFV).
Original source: habrahabr.ru.

https://habrahabr.ru/post/305506/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Тонкости подбора респондентов для UX-исследований

Вторник, 05 Июля 2016 г. 17:44 (ссылка)





Привет, Хабр! Меня зовут Наталия Спрогис, и я руковожу направлением UX-исследований в Mail.Ru Group. Сегодня я бы хотела поговорить о тех людях, без которых мы не могли бы помогать нашим проектам. Поиск участников UX-исследований — краеугольный камень успеха всего мероприятия. И, судя по количеству вопросов «А как вы ищете респондентов?», которые получают наши исследователи на любой конференции, актуальная тема. Давайте попробуем разобраться: кого нужно звать, сколько их должно быть и как их можно найти. Речь в первую очередь пойдет о рекрутинге для качественных исследований, в частности для юзабилити-тестирований.



Часть 1. Кого?



Кого пригласить на исследование?



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



Не отталкивайтесь от демографии. Часто, когда мы впервые работаем с каким-нибудь продуктом и обсуждаем с менеджером аудиторию для теста, получаем примерно такой портрет пользователя: «женщины 60%, преимущественно в возрасте 25–35 лет, пользователи Mail.Ru». Несмотря на то что это ценные и полезные данные, это не может быть профилем для исследования. Представьте, что мы решили протестировать дизайн страницы создания письма в веб-почте Mail.Ru. И позвали на тест пользователей, имеющих ящик на Mail.Ru, распределенных по полу и возрасту согласно данным статистики. Скорее всего, окажется, что кто-то из них вообще не пишет письма, а лишь получает рассылки, кто-то пользуется только мобильным клиентом, а у кого-то этот ящик не является основным. Опыт этих людей будет для нас бесполезен. Это не значит, что нужно вообще игнорировать знания о демографии, просто эти критерии не должны быть основными.



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




  • опытный пользователь;

  • пользователь с аналогичным опытом (конкурентный продукт или решение задачи каким-то другим способом);

  • неопытный пользователь.



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



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



Аккуратнее с неопытными пользователями. Часто нам важно увидеть, как с нашим продуктом взаимодействуют совершенно неопытные пользователи. Ведь этим мы имитируем момент первого знакомства с проектом новой аудитории. Так вот, «неопытную» аудиторию нужно подбирать тоже вдумчиво. В идеальном варианте это должны быть не просто люди, которые не пользуются текущим продуктом. А люди, у которых потенциально в нем есть потребность. Например, в свое время у нас сорвался тест регистрации в Одноклассниках. Участница отказалась от выполнения заданий. Выяснилось, что она сознательно не регистрируется ни в одной соцсети, так как боится контроля «Большого Брата», и не готова этого делать даже на тесте. Это, конечно же, крайний случай. Но если вы позовете людей, не имеющих вообще никакого интереса в предметной области, скорее всего, их выполнение заданий будет механическим. А значит, они принесут вам сильно меньше знаний. Например, для тестирования сервиса «Разбери ящик» в Почте Mail.Ru, позволяющего автоматически сортировать входящие рассылки, мы сознательно звали людей, страдающих от того, что их почта завалена многочисленными подписками. Пользователи разбирали собственные ящики, а не созданные для них тестовые. Поэтому мы на живых примерах видели, действительно ли сервис решает их проблемы с рассылками, а не просто проверяли механически понятность каждой формы.



Другие частые параметры. То, какие еще требования к участникам исследования у вас будут, всегда зависит от конкретных задач. Помимо опыта и демографии, часто встречается:




  • Мобильная платформа. При тестировании мобильных приложений и сайтов, даже если версия имеет единый интерфейс для разных платформ, важно протестировать ее на разных пользователях. Практика показывает, что очень часто проблемы на iOS и Android сильно отличаются, а пользователи этих платформ имеют разные навыки и привычки.

  • «Продвинутость». Еще лет пять назад мы использовали критерий «компьютерной грамотности» или «опыта в интернете» при рекрутинге на тестирование сайтов и сервисов. Сейчас средний уровень «опыта в интернете» вырос, если не считать совсем возрастную аудиторию. Поэтому при тестировании веб-сервисов мы этот критерий не учитываем. Но вопрос «продвинутости» актуален теперь для мобильных платформ, и мы часто включаем его в требования. Мы для себя привыкли условно продвинутыми считать тех пользователей, которые «умеют самостоятельно скачивать и устанавливать приложения».

  • «Хардкорность». Этот критерий всплывает при тестировании игр. Любой продюсер игры расскажет вам, что существуют казуалы, мидкорщики и хардкорщики. Сложность в том, что четкого определения, кто к какой группе относится, не существует. Поэтому для каждой игры приходится придумывать свои. Как правило, они складываются из часов, проводимых в игре, и предпочтений в аналогичных играх в жанре.



Тесты на друзьях и коллегах



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




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


  • Перекошенная лояльность. Опыт проведения тестов на сотрудниках нашей компании показывает, что они либо очень лояльны к родному продукту (рассуждая примерно так: «Ой, ну я знаю ребят из команды, они же очень старались. А это у них не работает, потому что это тяжело реализовать, в нашем проекте с этим тоже мучились»), либо, наоборот, оказываются излишне требовательны и придирчивы, ожидая от своих коллег самого лучшего. Похожая ситуация возникает с друзьями. Чтобы не обидеть нас, они могут стараться закрывать глаза на какие-то недостатки продукта. Или, наоборот, захотят помочь нам найти больше проблем и станут придираться ко всему подряд. Любой хороший UX-специалист, конечно же, помнит, что нужно смотреть на поведение, а не слушать слова пользователя. Но эти отзывы могут создать ложное впечатление у команды проекта, наблюдающей за ходом тестирования. И вам придется потратить много усилий, чтобы объяснить им, что излишне позитивное или негативное впечатление на тесте еще не значит такую же реакцию реальной целевой аудитории.

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



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



Часть 2. Сколько?



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



«Just a handful of users»



Гуру юзабилити Якоб Нильсен более 20 лет назад начал популяризировать идею, что для любого юзабилити-теста достаточно пяти человек (Jakob Nielsen and Thomas Landauer, 1993). Это утверждение прочно засело во многих головах. Кто-то начал всегда брать по пять человек, независимо от задачи. Другие стали скептически воспринимать все юзабилити-исследования, ведь они основываются на изучении такой маленькой выборки.



Давайте разберемся, откуда взялось волшебное число пять. Как показывает практика, после первых нескольких участников юзабилити-тестирования количество новых обнаруженных проблем снижается. Нильсен постулирует, что выборка из пяти человек позволяет обнаружить 85% проблем интерфейса (Why You Only Need to Test with 5 Users). То есть брать больше людей может быть просто нецелесообразно.



На самом деле те 85%, о которых говорит Нильсен, относятся к наиболее серьезным и частотным проблемам (число справедливо для проблем, затрагивающих 31% аудитории). Если мы возьмем любой интерфейс, то в нем, скорее всего, кроется ряд частотных проблем, с которыми сталкивается много пользователей (например, проблемы при регистрации в игре), а также разнообразные менее частотные, но, возможно, достаточно критичные проблемы. Например, проблемы, с которыми сталкивается 15% аудитории, на пяти людях будут обнаружены уже с вероятностью 50%. Увеличение размера выборки повысит шансы найти менее частотные проблемы. Джеф Сауро, активно занимающийся вопросами статистической значимости в юзабилити, подробно разбирает этот вопрос в своей статье Why you only need to test with five users (explained).



Несмотря на популярность утверждения о пяти респондентах, многие исследователи предпочитают брать больше участников исследования. Джеф Сауро в 2012 году провел опрос около сотни читателей своего блога. Он попытался выяснить, сколько респондентов в реальности приглашают на исследования в различных компаниях. Опрос показал, что более 81% исследований базируются на выборках больше, чем пять человек (медиана 10) (How many users do people actually test?).



От чего зависит количество людей



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



Когда нужно больше людей.




  • Разнообразие аудитории. В пять человек не включить разнообразия по опыту, предпочтениям, паттернам взаимодействия и даже демографии аудитории. А часто именно это дает нам больше знаний. Чтобы понять, сколько людей вам требуется, нужно сначала расписать все ваши требования к аудитории, а потом взять в каждой группе хотя бы по три человека. Самый простой пример: если мы хотим протестировать мобильное приложение, то нам нужны две группы по разным платформам (iOS и Android), а также две группы по опыту (новички и пользователи аналогичных приложений). Это уже дает нам 12 человек.

  • Объем тестируемого функционала. В рамках одного теста можно пройти ограниченное количество сценариев. Хороший тест длится обычно около часа. Можно мучить человека до двух часов, но это утомительно и малоэффективно. Поэтому если бы нам пришла задача «протестировать весь интерфейс ВКонтакте», то мы, очевидно, разбили бы проект на несколько «подтестов», так как нужно было бы смотреть и функционал ленты, и фотографий, и групп, и многое другое. Правильным решением стало бы включить во все тесты наиболее критичные сценарии, а остальные пустить в ротацию. Каждый из сценариев в ротации должны выполнить хотя бы три человека.

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

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



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



Мифы и страхи



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



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



Часть 3. Как?



Способы поиска



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



Специальные рекрутинговые агентства



Этот способ удобнее всего для самих исследователей, так как снимает с них массу головной боли. Однако и тут есть свои подводные камни. Во-первых, на него придется выбивать довольно большой бюджет, ведь работу агентства надо оплачивать. Кроме того, вы точно столкнетесь с проблемой «ходоков». Рынок маркетинговых исследований существует давно. И в этой отрасли сформировался целый пласт людей, которые пытаются зарабатывать на жизнь хождением на опросы, фокус-группы и т. д. Для этих людей самое главное — это получить вознаграждение. Часто они врут о своем опыте, чтобы подстроиться под квоты. А на самом тесте пытаются вести себя так, чтобы понравиться вам (и тогда вы позовете их еще раз). В результате они могут начать усиленно хвалить или усиленно ругать ваш продукт, ведь целей исследования они не понимают. Не так уж важно, каким образом они пытаются подстроить свое поведение. Главное, что оно становится неестественным. Способам бороться с этими людьми можно посвятить отдельную статью. Вот несколько советов:




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

  • Проверяйте ваше агентство. Даже хорошо себя зарекомендовавшие агентства иногда сотрудничают с непрофессиональными полевыми рекрутерами. Поэтому периодически стоит проверять, не появилось ли объявление о вашем исследовании с открытыми требованиями на специальных «опросных сайтах».

  • Проверяйте данные респондентов. По максимуму проверяйте потенциальных респондентов до теста. Если это пользователи вашего продукта, то просите заранее их аккаунт и смотрите, действительно ли их опыт соответствует вашим требованиям. Мы всегда проверяем активность пользователей нашей почты, игр или соцсетей. К нам на тестирование Одноклассников, например, пытались проникнуть люди, зарегистрировавшие аккаунт накануне.

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

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



Панели



Если вы делаете онлайн-исследование, вы можете обратиться к рекрутингу через панели. В этих сервисах есть огромный пул зарегистрированных пользователей, которые регулярно отвечают на онлайн-опросы или проходят онлайн-тесты. Ваша задача — составить скринирующий опросник, по которому будут набраны участники тестирования. Так же как и с агентством, важно хорошо составить набор этих вопросов, ведь участники панели тоже могут пытаться подстроиться под требования. Иногда полезно даже включать заведомо ложные варианты ответов (например, несуществующий продукт) и отсекать тех, кто его выбрал. Помните, что для участников панели ваше исследование — это почти работа. Ведь они проходят по несколько опросов в день. Среди этих пользователей также встречаются «халтурщики», которые пытаются «прокликать» ваш опрос и получить вознаграждение. Их можно вычислить по слишком высокой скорости выполнения заданий, отсутствию ответов на открытые вопросы и т. д. Несмотря на эти особенности, панели позволяют провести рекрутинг быстро, получить большую базу ответов и географический охват.



Самостоятельный рекрутинг



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




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

  • Группа в соцсети / форум проекта. Это лояльная аудитория, заинтересованная в улучшении продукта. Их часто легче пригласить, чем других ваших пользователей, и они даже могут быть готовы поучаствовать в исследовании бесплатно. Но надо понимать, что это будут достаточно продвинутые пользователи вашего продукта. Скорее всего, они наиболее требовательны из всех и могут просить вас о функционале, который не нужен большинству. Кроме того, здесь легче всего поймать «фриков». Целесообразность рекрутинга через форум/группу зависит еще и от проекта. Например, для игр форум — хорошее место для рекрутинга активных лояльных игроков. А вот в проекте Дети Mail.Ru мы столкнулись с тем, что пользователи форума мало проводят времени на основном сайте и могут нам помочь только в тестировании самого форума.

  • Почтовая рассылка. Вы можете отправить своим пользователям письмо — приглашение на участие в исследовании. Этот вариант хорош тем, что рассылку можно таргетировать по определенным критериям (активность в проекте, география и прочее). Постарайтесь сделать текст письма достаточно личным и неформальным, это увеличит количество откликов. Обычно мы в письме даем ссылку на онлайн-опрос, проверяющий, подходит ли человек по критериям, а в конце опроса предлагаем оставить контактные данные. Но будьте готовы к тому, что отклик будет небольшой (процент зависит от лояльности аудитории, но больше, чем на 2–3%, я бы не рассчитывала). Кроме того, даже оставившие телефон люди могут в итоге не согласиться участвовать. А согласившись, испугаться и не прийти на интервью. В первый раз мы сильно удивились, когда явка при такой форме рекрутинга составила порядка 50% из назначенных интервью.

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

  • Группы по интересам. В случае, когда у вас еще нет своего продукта или вам интересны пользователи конкурентов, вы можете пробовать рекрутировать респондентов в тематических сообществах и группах (с согласия их администрации). Например, для тестирования некоторых игр мы публиковали объявления на новостном проекте Игры@Mail.Ru или в группе C-c-combo Breaker ВКонтакте.

  • «Снежный ком». Этим методом ищут респондентов полевые рекрутеры агентств. Они спрашивают у людей, которых уже приглашали на исследования, нет ли у них знакомых, которые согласились бы также поучаствовать в подобном мероприятии. Для того чтобы этот способ работал как основной метод поиска, нужно иметь достаточно большую базу контактов и потратить очень много времени. Однако никто не мешает вам спрашивать людей, которых вы уже нашли, нет ли у них подходящих знакомых, и рекрутировать так дополнительных респондентов. Главное, удостоверьтесь, что они не будут друг другу рассказывать о том, что происходило во время исследования, чтобы не испортить вам результаты. Также знакомых людей плохо звать на одно исследование, если вы не просто тестируете продукт, а собираете данные о разных паттернах поведения. Например, учащиеся одной студенческой группы, скорее всего, расскажут вам примерно одно и то же о том, как они пользуются электронной почтой по учебе.

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



Полевой рекрутинг



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



Организационные моменты



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




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

  • Дополнительные проверки. Как уже говорилось в блоке про рекрутинг при помощи внешнего агентства, данные респондентов лучше проверять. Эта рекомендация применима при любом виде рекрутинга. Старайтесь максимально проверить, правду ли говорит этот человек о своем опыте, до теста. Любые проверки, которые вы можете сделать заранее (дата регистрации, активность), лучше сделать. Ведь, как мы знаем, «everybody lies».

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

  • «Осторожно, дети!» Если участники вашего теста младше 18 лет, вам необходимо письменное согласие их родителей на участие в тестировании. Согласовывать детали участия детей в исследовании всегда надо именно с родителями. Мы сталкивались с ситуациями, когда, придя на этнографическое интервью домой к подростку, обнаруживали, что родители не в курсе и против.

  • Попросить взять очки. Особенно это критично для айтрекинг-исследований. Многие люди пользуются очками только дома или на работе, а на исследование приходят без них. Человека, который носом упирается в экран, чтобы что-то рассмотреть, будет невозможно откалибровать для айтрекинга. Да и видеозапись лица респондента может получиться неудачной.

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



Заключение



Поиск респондентов для исследования — это всегда чуть ли не самая хлопотная часть всего мероприятия. Но это та часть, где точно нельзя «халтурить», и тот самый случай, где лучше меньше, да лучше. Совершенно нормально, когда исследователь стремится скинуть с себя заботы о договоренностях по времени и напоминания респондентам на секретаря или агентство. Но никогда не пренебрегайте этапом планирования того, кто вам нужен, и проверкой респондентов. И тогда ваши исследования принесут команде проекта новые знания.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/304720/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Разбор задач отборочного раунда RCC 2016

Среда, 29 Июня 2016 г. 18:27 (ссылка)





Завершился очередной — отборочный — раунд международного чемпионата программистов Russian Code Cup 2016. И по сложившейся традиции мы предлагаем вам ознакомиться с решениями задач, которые предлагались конкурсантам в последнем раунде. На этот раз задач было шесть, хотя на их решение по-прежнему выделялось два часа. За выход в следующий раунд сражалось 604 человека. RCC впервые проводится в том числе для англоязычных участников. Результат не заставил ждать — русскоговорящим программистам будет составлена серьезная конкуренция. В финал прошло 50 человек и из них 19 человек — не русскоговорящие участники. Среди финалистов представители России, Украины, Беларусии, Литвы, Словакии, Армении, Польши, Швейцарии, Финляндии, Японии, Китая, Южной Кореи.




  1. Контрольная работа

  2. Многоножка

  3. Двоичное дерево

  4. Пробирки и реактивы

  5. Размен денег

  6. Задача F



Задача А. Контрольная работа



Условие



Ограничение по времени 2 секунды

Ограничение по памяти 256 мегабайт



Скоро Коле предстоит писать важную контрольную, поэтому он решил тщательно подготовиться. Он выяснил, что у контрольной будет n вариантов, i-й из которых состоит из mi заданий, пронумерованных от 1 до mi. Для каждого задания каждого варианта Коля оценил время tij минут, которое займёт у него решение.



Во время контрольной он планирует решать задания строго в том порядке, в котором они расположены в варианте. Сдать работу надо не позже окончания контрольной, которая длится t минут. Конечно, Коля мог бы списать контрольную, но он считает, что это не очень правильно. Поэтому готов списать не более одного задания. На списывание любого задания он потратит t0 минут.



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



Формат входных данных



В первой строке находятся три целых числа n, t и t0 (1 <= n <= 100, 1 <= t <= 10 000, 1 <= t0 <= 100) — количество вариантов, продолжительность контрольной и время, которое Коля потратит на списывание задания.



В следующих n строках находится описание вариантов. Первое число mi (1 <= mi <= 100) — количество заданий в варианте i. Следующие mi чисел tij (1 <= tij <= 100) — время, которое Коля потратит на решение j-го задания i-го варианта.



Формат выходных данных



Для каждого варианта выведите на новой строке одно целое число — количество заданий, которые Коля успеет решить, если ему попадётся этот вариант.



Примеры



Входные данные

4 45 5

5 10 10 10 10 10

4 30 10 10 10

3 40 40 5

1 100



Выходные данные

5

4

2

1



Решение



Переберём префикс заданий, которые решит Коля. Найдём время, которое он потратит, если будет сам решать все задания, и максимальное время, которое он потратит на одно задание в таком случае. Понятно, что если он будет списывать, то списывать надо именно самое долгое задание из тех, что он делает. Тогда время, которое Коля потратит, равно S – max(0, M t0). Теперь найдём наибольший префикс, у которого это время не превышает t.



Задача B. Многоножка



Условие



Ограничение по времени 2 секунды

Ограничение по памяти 256 мегабайт



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



Каждый день Филя записывал себе в блокнот два числа — сколько левых и сколько правых ног использовала многоножка в этот день.



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



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



Формат входных данных



Входные данные содержат несколько тестовых наборов. В первой строке задано количество тестов t (1 <= t <= 10 000).

Каждый из тестов описывается следующим образом: в первой строке описания теста содержится число n (2 <= n <= 109) — суммарное количество ног многоножки, а во второй строке число m (1 <= m <= 105) — количество записей.



В следующих m строках содержатся по два числа li и ri (1 <= li, ri <= n) — количество левых и правых ног, используемых многоножкой в i-й день согласно записям Фили, соответственно.



Суммарное количество записей по всем тестам не превосходит 105.



Формат выходных данных



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



Примеры



Входные данные

3

4

3

1 2

1 3

1 4

2

2

2 2

1 2

5

4

1 4

2 3

3 2

4 1



Выходные данные

1 3

1 1

1 4



Решение



Чтобы решить эту задачу, можно отсортировать все записи по количеству левых ног. Дальше будем перебирать количество левых ног по возрастанию. Если левых ног li, то потенциально могут быть верными первые i записей, а все последующие записи точно неверны (за исключением количества ног, равного li).



Теперь нужно узнать, сколько записей из первых i будут верны. Запись c номером j <= i верна, если rj <= n – li. Нахождение всех таких rj является стандартной задачей и решается, например, деревом отрезков.



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



Задача C. Двоичное дерево



Условие



Ограничение по времени 4 секунды

Ограничение по памяти 256 мегабайт



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



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



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



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



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



Формат входных данных



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



Каждый из следующих t тестов описывается следующим образом: в первой строке описания теста дано одно целое число n (2 <= n <= 2 • 105) — количество вершин в дереве. В следующих n – 1 строках описания теста даны пары чисел ui, vi (1 <= ui, vi <= n) — номера вершин, соединённых i-м ребром. Гарантируется, что рёбра образуют дерево.



Гарантируется, что сумма чисел n по всем тестам не превосходит 2 • 105.



Формат выходных данных



Выведите ответ для каждого теста на отдельной строке.



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



Иначе выведите два целых числа — номер вершины, которую нужно выбрать корнем, и остаток от деления числа дней, которое потребуется Васе, на 109 + 7. Если есть несколько вершин, позволяющих выполнить задание в минимальный срок, выведите вершину с минимальным номером.



Примеры



Входные данные

3

3

1 3

3 2

4

4 2

3 2

3 1

5

1 2

1 3

1 4

1 5



Выходные данные

3 0

2 3

-1



Решение



Чтобы минимизировать количество дней, которые придётся потратить Васе, нужно минимизировать высоту итогового бинарного дерева — если глубина листа в итоговом дереве равна h, то Вася потратит 2h – 1 – n дней на то, чтобы подвесить необходимое число вершин.



Заметим, что если в дереве есть вершина степени больше 3, то задание выполнить не получится, — в полном бинарном дереве все вершины имеют не больше трёх соседей. Обратим внимание, что корень в ответе имеет ровно двух сыновей.



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



Задача D. Пробирки и реактивы



Условие



Ограничение по времени 2 секунды

Ограничение по памяти 256 мегабайт



Сегодня учитель химии дал Пете очень ответственное задание — разлить реактивы по пробиркам. В распоряжение ему предоставили n пробирок и m реактивов. Для каждой пробирки известны mini и maxi — минимальное и максимальное суммарное количество жидкости в миллилитрах, которое может в ней находиться, соответственно, а также номер реактива ci и число pi. Для каждого реактива также известно число vi — сколько миллилитров его есть у Пети. Учитель просит Петю разлить все реактивы так, чтобы в i-й пробирке как минимум pi процентов от всей жидкости, в ней находящейся, занимал реактив ci, а также чтобы в каждой пробирке были удовлетворены ограничения на mini и maxi. Все реактивы должны быть полностью разлиты. Будем считать, что никаких химических реакций и изменений объёма реактивов не происходит.



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



Например, в первом тестовом наборе из примера подойдёт следующий ответ:




  • В первую пробирку налить 3 миллилитра первого реактива и 2 миллилитра второго.

  • Во вторую пробирку налить 4 миллилитра третьего реактива и 1 миллилитр второго.

  • В последнюю пробирку налить 3 миллилитра четвёртого реактива и 1 миллилитр второго.



В этом случае все ограничения на mini и maxi выполняются, а также выполняются ограничения на проценты реактивов в пробирках: в первой пробирке 3/5 = 60% первого реактива, во второй пробирке 4/5 = 80% третьего реактива, а в последней пробирке 3/4 = 75% >= 70% четвёртого реактива. Также все реактивы полностью разлиты, поэтому все требования, данные учителем, выполнены и ответ верен.



Формат входных данных



Входные данные содержат несколько тестовых наборов. В первой строке задано количество тестов t (1 <= t <= 100).



Каждый из следующих t тестов описывается таким образом: в первой строке описания теста содержатся два числа n, m (1 <= n, m <= 105) — количество пробирок и реактивов соответственно.



В i-й из следующих n строк содержится четыре целых числа mini, maxi, ci, pi (1 <= mini <= maxi <= 105, 1 <= ci <= m, 1 <= pi <= 100) — минимальное и максимальное суммарное количество миллилитров жидкости, которое можно налить в i-ю пробирку, номер реактива и его минимальный процент содержания в пробирке соответственно.



В последней строке описания теста содержатся m целых чисел vi (1 <= vi <= 105) — количество миллилитров i-го реактива у Пети.



Гарантируется, что сумма n и сумма m во всех тестах не превосходит 105.



Формат выходных данных



Для каждого теста выведите ответ на него.



Если ответ существует, в первой строке выведите YES, а в i-й из следующих n строк выведите сначала число k — количество различных реактивов в i-й пробирке, а затем k пар положительных чисел id, v — номер реактива и его количество в пробирке. Если существует несколько ответов, разрешается вывести любой.



Если ответа на тест не существует, в единственной строке выведите NO.



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



Примеры



Входные данные

2

3 4

5 8 1 60

4 6 3 80

3 4 4 70

3 4 4 3

3 4

6 8 1 60

4 6 3 80

3 4 4 70

3 4 4 3



Выходные данные

YES

2 1 3.0000000000 2 2.0000000000

2 2 1.0000000000 3 4.0000000000

2 2 1.0000000000 4 3.0000000000

NO



Решение



Приведём конструктивный алгоритм в несколько этапов:




  • Если sum(mini) > sum(vi) — ответ NO.

  • Если sum(maxi) < sum(vi) — ответ NO.

  • Нальём в каждую пробирку minipi / 100 миллилитров реактива ci.

  • После этого для каждого реактива i отсортируем пробирки, для которых cj = i, по возрастанию pj и будем по очереди наливать в них оставшийся реактив номер i.

  • В каждую пробирку нальём ещё (maxj – minj) pj / 100 миллилитров i-го реактива или меньше, если он закончится.

  • Всё оставшееся от реактивов разольём по пробиркам любым способом: в i-ю пробирку суммарно можно налить любое количество жидкости, не превосходящее summaryi • 100 / pi (summaryi — суммарное количество жидкости в ней на текущий момент).

  • Если разлить не получилось и жидкость осталась — ответ NO.

  • Единственная оставшаяся проблема — в каких-то пробирках всё ещё может быть меньше mini миллилитров жидкости.

  • Для исправления этого в пробирке i сначала перельём из всех остальных пробирок j реактивы, отличные от cj, в i-ю пробирку, так, чтобы в j-й пробирке осталось хотя бы minj жидкости.

  • Если и этого не хватило, перельём из остальных пробирок j жидкость номер cj (теперь это не испортит условие на процентное содержание).



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

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



Задача E. Размен денег



Условие



Ограничение по времени 4 секунды

Ограничение по памяти 256 мегабайт



За свою долгую жизнь Боря собрал коллекцию из n монет. Он выложил все эти монеты в ряд. При этом i-я в ряду монета имеет номинал ai.



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



Боря хочет ответить на несколько запросов. В каждом запросе Боря хочет узнать, какую минимальную сумму он не сможет заплатить без сдачи, если он возьмёт все монеты с li-й по ri-ю. Более формально — он хочет найти такое минимальное натуральное число z, что нельзя выбрать подмножество монет с номерами от li до ri, суммарный номинал которых равен z.



Формат входных данных



В первой строке задано два целых числа n и m (1 <= n, m <= 150 000) — количество монет у Бори и количество запросов. В следующей строке задано n чисел ai (1 <= ai <= 109) — номинал i-й монеты.



В следующих m строках задано по два числа li и ri (1 <= li <= ri <= n) — описание запросов.



Формат выходных данных



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



Примеры



Входные данные

5 5

2 1 5 3 1

1 5

1 3

1 1

2 4

2 5



Выходные данные

13

4

1

2

11



Решение



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



Пусть на очередном шаге мы рассмотрели все монеты, стоимость которых не превышает X, и мы можем заплатить любую сумму до Y включительно. Пусть суммарная стоимость монет, каждая из которых стоит больше X, но не больше Y + 1, равна sum. Тогда если sum = 0, то Y + 1 мы не сможем представить с помощью этого набора. Иначе перейдём к состоянию, что рассмотрены все монеты, стоимость которых не больше Y + 1, и мы можем представить любую сумму до Y + sum включительно.



Заметим, что стоимость максимальной монеты, которую мы рассмотрели, растёт как минимум так же быстро, как числа Фибоначчи. Значит, этот процесс завершится за O(log Answer) итераций.



Чтобы решить исходную задачу, необходимо научиться находить сумму чисел, меньших X, на отрезке. Если делать это за O(log n), то можно решать задачу суммарно за O(m log n log Answer).



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



Задача F



Условие



Ограничение по времени 5 секунд

Ограничение по памяти 256 мегабайт



Гном Паша пишет отборочный раунд Gnome Math Cup. В качестве задачи F предложена следующая.



Дано n натуральных чисел a1, a2, ..., an и натуральное число d, требуется найти любой набор ненулевых целых чисел x1, x2, ..., xn, такой, что a1x1 + a2x2 + ... + anxn = d. Так как у гномов плохо с умножением и сложением, все числа d, ai не превышают 106, а числа xi должны быть от –106 до 106, но не равны 0.



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



Формат входных данных





Первая строка входных данных содержит t — количество тестов. Каждый тест задаётся двумя строками. Первая строка содержит два числа n и d (1 <= n <= 105, 1 <= d <= 106). Вторая строка содержит n чисел ai (1 <= ai <= 106). Сумма n по всем тестам не превосходит 105.



Формат выходных данных



Выведите ответ на каждый тест. Если искомый набор xi существует, то в первой строке выведите YES и во второй выведите любой подходящий набор. Иначе в единственной строке ответа на тест выведите NO.



Примеры



Входные данные

2

2 1

2 3

3 3

2 3 1000



Выходные данные

YES

2 -1

YES

503 -1 -1



Решение



Ответ NO бывает только в одном случае, когда d не делится на наибольший делитель всех чисел ai. В любом другом случае ответ всегда существует. Для начала мы научимся получать хоть какой-то ответ без ограничения на значения, предварительно поделив все ai и d на gcd(a1, ..., an). Если n = 1, то x1 = d/a1. В других случаях мы будем подбирать для каждого префикса [1, p] такие xi, p, что a1x1, p + ... + apxp, p = gcd(a1, ..., ap). Делается это индуктивным методом. x1, 1 = 1. Пусть мы уже нашли xi, p и хотим найти xi, p + 1. С помощью расширенного алгоритма Евклида мы находим s и t: s • gcd(a1, ..., ap) + tap + 1 = gcd(gcd(a1, ..., ap), ap + 1) = gcd(a1, ..., ap + 1). Тогда для i <= p xi, p + 1 = s xi, p и xp + 1, p + 1 = t. Получив xi, n, вычисляем xi = d/gcd(a1, ..., an)xi, n = dxi, n. Такое решение работает за O(n2), что не подходит под ограничения. Чтобы сократить время работы, мы выберем среди ai подмножество, у которого наибольший общий делитель такой же, как у всего множества, и такое, что нельзя уменьшить. Для этого мы будем перебирать от a1 до an и брать число в подмножество, если оно уменьшает количество различных простых делителей. Таким образом, выбранное подмножество содержит не более 7 элементов, так как максимальное количество простых делителей у числа, меньшего либо равного 106, равно 7. Для чисел из подмножества мы запускаем описанный алгоритм, а для чисел, не вошедших в множество, просто выставляем xi = 0.



Теперь алгоритм работает за O(n), но не выполняются условия, что xi по модулю не превышают 106 и среди них не должно быть нулей. Для этого опишем процедуру нормализации. Сначала выполним для xi первое условие. В первую очередь сделаем все xi для i > 1 неотрицательными и меньшими a1. Это делается простой операцией эквивалентного изменения: мы вычитаем из x1 kai и прибавляем к xi ka1, где k = (xi mod a1xi)/a1. Отметим, что результаты выполнения операции влезают в 64-битный тип данных, так как x1 по модулю не может превзойти |d – a2 x2 – ... – an xn| < 106 • 106 • 105. Теперь пройдёмся по всем xi, начиная со второго, до последнего и с каждым будем последовательно производить операцию: вычесть a1 из xi и прибавить ai к x1. Заметим, что существует i такое, что после применения операции к x1, ..., xi получилось 0 >= x1 >= –106. Пусть не существует такого i, тогда все xi стали отрицательными, чего случиться не могло, так как a1 x1 + … an xn даёт d, то есть положительное число. После того как мы научились получать |xi| <= 106, осталось сделать их ненулевыми. Разобьём все нули на пары, возможно кроме одного. В каждой паре i и j присвоим xi = aj и xj = –ai. У нас, возможно, остался единственный индекс p, для которого xp = 0. Мы рассмотрим несколько случаев:




  • Если существует xj, которое по модулю не равно ap, тогда мы применяем операцию: вычитаем sign(xj)ap из xj и прибавляем sign(xj)aj к xp.

  • Если же такого xj не существует, но ap <= 5 • 105, тогда к любому xj можно применить операцию: прибавить sign(xj)ap к xj и вычесть sign(xj)ap из xp.

  • В противном случае должно найтись aq, такое, что aq /= ap. Если такого не существует, то все ai = a1, а значит, из-за нормировки на наибольший общий делитель ai = a1 = 1 и должен был выполниться второй случай. Мы проводим операцию: вычтем sign(xj)ap из xq и прибавим sign(xj)aq к xp. После этого xq равно нулю. Но теперь, если n > 2, для q выполнится первый случай, а если n = 2, то для q выполнится второй случай, так как d = aq ap <= 106.



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



***

Чемпионат Russian Code Cup входит в число инициатив Mail.Ru Group, направленных на развитие российской IT-отрасли и объединённых ресурсом IT.Mail.Ru. Платформа IT.Mail.Ru создана для тех, кто увлекается IT и стремится профессионально развиваться в этой сфере. Проект объединяет чемпионаты Russian AI Cup, Russian Code Cup и Russian Developers Cup, образовательные проекты Технопарк в МГТУ им. Баумана, Техносфера в МГУ им. М. В. Ломоносова и Технотрек в МФТИ. Кроме того, на IT.Mail.Ru можно с помощью тестов проверить свои знания по популярным языкам программирования, узнать важные новости из мира IT, посетить или посмотреть трансляции с профильных мероприятий и лекции на IT-тематику.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/303216/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Приглашаем на IoT-хакатон от Mail.Ru Group и Intel 30–31 июля

Среда, 29 Июня 2016 г. 15:22 (ссылка)





Intel и Mail.Ru Group приглашают всех желающих принять участие в хакатоне, посвященном интернету вещей. Хакатон пройдет в московcком офисе Mail.Ru Group 30–31 июля 2016 года.



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



Над подобными вопросами мы и приглашаем вас подумать на хакатоне: найти уникальные способы решения задач промышленности, бизнеса и повседневной жизни, используя платформы Intel Edison и Tarantool. А мы обеспечим все условия и возможности для создания чего-то нового!



Что нужно для участия?



Главное — это идея IoT-решения, которую вы готовы реализовать, или прототип, который можно доработать. Вам не нужно знать, как готовить Intel Edison или Tarantool, — этому мы научим.



Каждой команде будет предоставлен комплект разработчика Intel IoT Dev Kit, включающий плату Intel Edison и набор сенсоров Grove Starter Kit Plus. Основной язык разработки — Lua, запущенный из-под Tarantool.



Чтобы зарегистрироваться, заполните форму. За две недели до мероприятия команды с наиболее интересными проектами получат приглашение на email.



Призы



Команды, представившие лучшие идеи и реализацию, получат от компании Intel подарочные карты Visa:




  • 1 место — 100 тыс. руб.

  • 2 место — 50 тыс. руб.

  • 3 место — 30 тыс. руб.



Каждая команда, занявшая призовое место, также получит плату Intel Edison и набор сенсоров Grove Starter Kit Plus.



O Tarantool



Tarantool — это универсальная IoT-платформа, которая представляет собой СУБД общего назначения с сервером приложений внутри. Tarantool предназначен для работы как на IoT-устройствах, так и в облаке, обеспечивая надежную синхронизацию между ними в обе стороны. Основная отличительная особенность Tarantool — то, что он очень нетребователен к ресурсам. Может работать на одном ядре процессора, даже очень медленном. Может работать начиная с нескольких мегабайтов памяти. Может хранить данные на медленном и ненадежном флеше, не убивая его при этом постоянными перезаписями (потому что Tarantool их вообще не делает). При этом он надежно сохраняет каждую транзакцию на диск или флеш. Tarantool Fibers идеально ложатся на логику работы с PIN, UART и т. п.



Для упрощения жизни мы сделали биндинг MRAA в Lua — на момент анонса готовится pull request. Lua binding лежит в моем репозитории, документация в процессе создания, любые вопросы по MRAA задавайте тут, в личку, на GH.



Кроме того, Tarantool умеет реплицировать все транзакции как между IoT-устройствами, так и в облако (на удаленный Tarantool, запущенный на серверах в дата-центре). Причем это master — master репликация в обе стороны. При необходимости вы можете высылать данные с локального Tarantool — прямо с устройства — куда угодно, в том числе в Твиттер, минуя облако.



Разрабатывая с использованием Tarantool как локальной платформы на IoT-устройствах, вы получаете одинаковое состояние системы на всех устройствах и на центральном сервере. Причем каждое устройство работает независимо с текущей копией данных даже при моргающем или неработающем доступе к интернету (при восстановлении доступа все данные моментально реплицируются в обе стороны). Кроме того, при отсутствии подключения к интернету вы можете реплицировать данные между устройствами через Bluetooth посредством Tarantool.



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

И вишенка на торте: написав функцию на Lua, вы моментально можете превратить ее в сервис внутри Tarantool. Вам нет необходимости локально ставить никакие серверы приложений. Ну и самое замечательное: так как Tarantool — это application server, вы можете поставить любую из имеющихся моделей прямо на устройство, к примеру http, pg и т. п., — и это все можно сделать в одно действие. А если вы установите еще и nginx с Tarantool-модулем в облако, то получите также REST API поверх Tarantool, а значит, сможете моментально автоматически получать данные с устройств.



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



Oб Edison



Intel Edison — это мощный модуль в компактном исполнении. CPU — двухъядерный Intel Atom 500 МГц, MCU — Intel Quark 100 МГц, 4 Гб флеш-памяти, 1 ГБ оперативки, может питаться от батареек или аккумуляторов, оснащен беспроводными интерфейсами (Wi-Fi и Bluetooth 4.0). Про работу с этой платой и проекты на ее основе написано много статей. Для начала советуем ознакомиться с этими материалами:





Tarantool + Edison



Мощный Edison и нетребовательный к ресурсам Tarantool создают идеальную связку для разработчиков, и, что самое главное, связка Edison + Tarantool позволяет разрабатывать быстро.



Для примера я и мой коллега решили пройти весь путь сами, так сказать, сделать свой «Hello, world». И вот что получилось: прототип системы безопасности. Как это было: с помощью Tarantool мы решили объединить устройство(а) и облако или другие устройства в кластер. После часовой дискуссии идея родилась сама: создадим распределенную систему безопасности. Коротко о проекте. Собираем с N устройств уровень света, уровень шума и т. д. Все эти показатели доставляются в облако. Если какой-то показатель больше X, то устройство начинает пищать и моргать. X должен настраиваться динамически, через WebGUI. Весь обмен данными происходит с помощью асинхронной master — master репликации. На это было потрачено часов шесть. И да, это прототип, не откалиброванный и т. п.



Ближе к дате проведения все участники получат дополнительные технические инструкции, чтобы быть полностью готовыми к хакатону. Также мы будем регулярно публиковать обучающие видео и материалы по Intel Edison, Yocto Linux и Tarantool в блоге Mail.Ru Group на Хабрахабре, Google-группе Tarantool и в группе Tarantool на Facebook.



Следите за новостями и готовьте интересные идеи!
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/304280/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Отчет с Moscow Data Science Meetup 27 мая

Пятница, 24 Июня 2016 г. 17:45 (ссылка)

image



27 мая в офисе Mail.Ru Group прошёл очередной Moscow Data Science Meetup. На встрече собирались представители крупных российских компаний и научных организаций, а также энтузиасты в области машинного обучения, рекомендательных систем анализа социальных графов и смежных дисциплин. Гости делились друг с другом своим опытом решения практических задач анализа данных. Предлагаем вашему вниманию видеозаписи и презентации трёх докладов, представленных на встрече.



Дмитрий Носов, Rambler&Co, H2O на Spark: как мы пили газировку и чуть не захлебнулись



H2O — интересная и многообещающая платформа машинного обучения. Она может порадовать аналитика скоростью работы с большими объемами данных, набором алгоритмов, наличием API для нескольких языков программирования, и, конечно же, красивыми и подробными отчетами по построенным моделям. H2O написана на Java, поэтому работает вездеTM, в том числе на кластере Spark. В докладе спикер поделился своим опытом использования H2O на Spark и YARN, а также причинами отказа от использования H2O в production-окружении, несмотря на все ее положительные качества.







Видеозапись выступления: it.mail.ru/video/724



Павел Филонов, «Лаборатория Касперского», Глубокое обучение и извлечение признаков в прогнозировании временных рядов



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







Видеозапись выступления: it.mail.ru/video/723



Александр Дьяконов, ВМК МГУ, Решение задачи Search Results Relevance (на платформе Kaggle)



Разобрана задача по определению релевантности поисковой выдачи, которая решалась на прошлогоднем «Практическом семинаре по АД kaggle». Был описан очень простой алгоритм, который не использует сложных методов анализа текстов, словарей и ансамблей алгоритмов, и который, тем не менее, смог попасть в десятку сильнейших среди более чем 1300 участников.







Видеозапись выступления: it.mail.ru/video/722
Original source: habrahabr.ru.

https://habrahabr.ru/post/303452/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Отчёт с Symfony Moscow Meetup 2 июня

Среда, 22 Июня 2016 г. 16:55 (ссылка)

image



В начале июня в офисе Mail.Ru Group прошла восьмая встреча сообщества Symfony Moscow Meetup — разработчиков на PHP/Symfony2. Здесь обсуждались вопросы разработки веб-приложений и смежные технологии, участники обменивались опытом и последними техническими новостями. Ну и, конечно, было много общения в неформальной обстановке. На встрече было представлено 4 доклада. Предлагаем ознакомиться с записями и презентациями выступлений.



Александр Лисаченко, Alpari



«Решение вопросов сквозной функциональности в приложениях»



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







Видеозапись выступления: it.mail.ru/video/715



Aлексей Медведев, Alpari



«Enterprise-инфраструктура менеджмента PHP-пакетов в рамках компании»



В докладе было рассказано, как в Альпари разворачивали локальную систему менеджмента пакетов на базе Composer, Packagist и git-фронтенда Gitweb; а также как работают с приватными пакетами и почему при сборке приложений зависимости никогда не выкачиваются напрямую с GitHub.



Кроме того, будет несколько слов о том, что находится под капотом у Packagist, когда, как и зачем его разворачивать у себя в компании, какие есть альтернативные Composer-репозитории пакетов и в каких случаях их удобно использовать.







Видеозапись выступления: it.mail.ru/video/716



Максим AloneCoder Попов, Mail.Ru Group



«Асинхронные запросы в MySQL или когда PDO становится мало»



В докладе было рассмотрено, зачем нужны и в чем преимущества асинхронных выборок из MySQL, а также как мы используем MySQLi и PDO вместе.







Видеозапись выступления: it.mail.ru/video/717



Руслан Ханов



«Контейнер сервисов — Что? Где? Когда?»



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







Видеозапись выступления: it.mail.ru/video/716
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/303868/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<mail.ru - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda