Как мы пытались разобраться в носимых данных…

Некоторый контекст…

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

Мы начали с простого требования…

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

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

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

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

И, наконец, Земля продолжала настаивать на вращении - мы должны были покрыть и это ...

Приставка

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

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

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

  1. Обработка даты сложна
  2. Обработка даты и времени сложнее
  3. Обработка даты и времени, включая часовые пояса - да, даже сложнее
  4. Обработка даты и времени, включая часовые пояса и учет смещения летнего времени - как вы уже догадались, даже сложнее и не дает мне «Давай пока пропустим летнее время»
  5. Дополнительные очки домового для обработки даты и времени, включая часовые пояса и учет смещения летнего времени в тот день, когда происходит переход на летнее время (я слышу ваши крики в Интернете, если вам приходилось сталкиваться с этой проблемой раньше)

Кроме того, в фактическом дне всего 23 часа 56 минут и 4 секунды, и не забывайте, что время от времени добавляются дополнительные секунды, но я отвлекся.

Сценарии тестирования

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

Виды деятельности

  • Короткие всплески, т. Е. Получение стакана воды, подход к чьему-то столу.
  • Короткие прогулки vs длинные прогулки, обед, романтическая прогулка по пляжу
  • Различия в беге, полные 5K, пробежки, прогулки, интервалы, публикация 5K раз на Facebook
  • Вождение в машине, езда на велосипеде, беговая дорожка, тренировка в спортзале, селфи с зеркалом в Instagram

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

Предупреждение: скучный серьезный раздел…

Местоположение телефона - телефон с устройством во время действий по сравнению с телефоном, который не дотянулся до устройства во время действий и синхронизировался после их выполнения.

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

  • 1 день
  • 1 неделя
  • 1 месяц

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

  • 2-минутные интервалы
  • 5-минутные интервалы
  • Почасовые интервалы
  • Суточные интервалы

Вернуться в режим развлечения…

Манипулирование активностью устройства

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

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

Однако наш победитель с одним конкретным приложением, сидя в кресле и возясь с настройками приложения, мы получили от 2500 фактических шагов до 91510 шагов, зафиксированных приложением в течение часа - ПРИЯТНО, именно то, что мы искали.

Отслеживание

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

Что касается охвата, то 100% покрытие само по себе является ошибкой - да, код покрыт, но как узнать, что реализация верна - наличие 100% не означает, что ваш материал будет работать. Мы «просто хотели правильно синхронизировать шаги». Типичная проблема программной инженерии - дело не в умении писать код, а в понимании сложных проблем, абстрактном мышлении и правильном выборе для технического удовлетворения требований.

Немного о том, почему это было так сложно

Предупреждение: здесь много технического жаргона ... Рекомендуемая фоновая музыка - JT / Cry me a River или кто-то, играющий на самой маленькой скрипке в мире.

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

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

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

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

Некоторые поставщики предоставляют вам часовой пояс региона / региона (Olson / Eggert), некоторые смещения по Гринвичу, некоторые просто UTC, некоторые в часовом поясе текущего пользователя (и не учитывают изменения часового пояса пользователя в определенные периоды - да ладно нам), а некоторые может даже дать вам различия в часовых поясах для разных запросов.

Еще один нюанс был связан с различиями в часовом поясе пользователя и часового пояса данных при отправке запросов. То, что мы назвали «Разрывом в запросе данных в формате UTC». Хотя некоторые поставщики возвращают данные об активности в формате UTC, запрос на получение данных основан на часовом поясе текущего пользователя (так что представьте, что часовой пояс пользователя меняется в тот же день). Это привело к разрывам в формате UTC при определенных условиях, что потребовало от вас, возможно, запроса «2 дня с зонированием по времени пользователя», чтобы получить доступ к эквиваленту «одного дня в формате UTC».

В конце концов, не все так просто ...

Withings - Особое внимание

Особая благодарность компании Withings (теперь Nokia Health). Я не могу достаточно хвалить эту компанию.

Нам очень повезло, что мы связались с Withings в идеальное время - мы хотели переключиться на коннектор OAuth2.0 и спросили, есть ли у них какие-либо планы - они работали над этим !!! - мы напрямую связались с разработчиком и связались через Skype, Майами - Париж, вместе проработали пару недель. Они были настолько невероятны, что не только включили наши отзывы о некоторых изменениях, но и в конечном итоге создали настраиваемую конечную точку для удовлетворения наших требований - поскольку это Интернет, я не хочу использовать имена, поэтому Джон Смит в Париже - вы удивительно, и ваша помощь и поддержка навсегда останутся в памяти.

Заключение

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

Оценить требуемые усилия довольно сложно, но мы можем разделить одну меру. Наша окончательная инфраструктура для обработки шагов для поставщиков требует в общей сложности почти 40 различных таблиц - да, почти 40 таблиц для создания 1 итоговой таблицы, которая содержит шаги, по пользователям, в почасовом сегменте времени, в UTC, с часовым поясом пользователя и устройством ... FYI его веб-масштабы тоже не волнуйтесь.

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

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

Но подождите, это еще не все !!!

На этом этапе наша пользовательская история «Как пользователь я хочу отслеживать свои шаги», похоже, завершилась.

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

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

Теперь нам пришлось учитывать MTTD - «Максимальная дельта путешествия во времени», означающая, насколько быстро человек может путешествовать во времени на основе наших текущих доступных технологий (исключая космические путешествия, извините, сотрудники НАСА на МКС, ваши «шаги» не считать). В конце концов, MTTD был требованием, чтобы повлиять на нашу «скорость механизма правил шагов» - то есть при обнаружении определенных условий в данных наша скорость замедлялась при выполнении правил шагов до тех пор, пока «время не догнало».

Закаленные в боях, уверенные, со 100% покрытием кода, мы разработали наш план действий, так как понятия не имели, что каждый из провайдеров будет делать с этим вариантом использования. Мы упаковали чемоданы, взяли с собой все наши устройства, забронировали рейс из Майами в Сан-Франциско, конечно, с островными местами, чтобы мы могли перемещаться в полете, чтобы отслеживать шаги, и продолжили свой путь. Но мы оставим это для другой статьи - следите за обновлениями.

TL; DR: синхронизировать шаги сложно, мммк