За ночь я сделал веб-сайт, который позволяет людям находить срочные запросы
В августе 2018 года наводнение опустошило штат Керала. Прямо пострадала одна шестая его населения. Штату нанесен имущественный ущерб на сумму 3 миллиарда долларов.
Я Арнав, 18-летний парень из Бангалора, который закончил школу в марте этого года. Во время наводнения я наткнулся на Проект спасения Кералы. Это было движение разработчиков-добровольцев, решающих технические проблемы, связанные с наводнением в Керале, с помощью Интернета.
Сайт оказывал важные услуги. Он собирал просьбы о помощи от пострадавших. Это помогло волонтерам и спасателям найти их и найти лагеря для оказания помощи. Он предоставил визуализацию для сил реагирования на стихийные бедствия.
Изучая проект на GitHub и Slack, я обнаружил конкретную проблему, которую, как мне казалось, могу решить.
Слишком много запросов
После массового наводнения, которое случается раз в 100 лет, поступило большое количество просьб о помощи.
Я наблюдал за поступлением новых запросов каждый раз, когда обновлял конечную точку API на сайте спасения. Когда я впервые обнаружил это, я потратил почти полчаса, просто читая запросы людей.
Они огорчали. Запросы о стариках, больных и раненых, беременных и младенцах. Некоторые сообщают о том, что здания находятся на грани обрушения или наводнения. Некоторые были от людей, живущих в других местах, не имевших возможности связаться с родственниками в Керале.
Но самые неприятные были среди множества запросов, которые не казались немедленными или по которым было мало данных.
И это были только те, что были на английском. Я не мог читать запросы, написанные на малаялам (языке штата Керала).
Это заставило меня задуматься: как расставляются приоритеты запросов? Я поспрашивал. Конечно, люди заметили, что это реальная проблема.
Осмысление данных
Я придумал два подхода к выяснению срочности запросов.
Обработка естественного языка (NLP)
Такие слова, как «Срочно», «Младенец», «Беременная» или «В ловушке» указывают на срочность и могут использоваться для классификации запросов.
Но с данными было несколько проблем: запросы были на английском и малаялам. Иногда малаялам писали английским алфавитом.
Многие писались в спешке.
Некоторые предлагали сначала переводить запросы на английский, прежде чем применять НЛП. Но перевод идет с потерями, и я был уверен, что это не сработает.
И, наконец, я почувствовал, что срочность во многом зависит от контекста. Сможет ли НЛП с этим справиться? Существующий анализ настроений может сказать вам, является ли текст положительным, отрицательным, счастливым или грустным. Но это не показатель срочности.
А разрабатывать новую модель не было времени. Особенно с учетом языковой проблемы.
Краудсорсинг
Я был уверен, что люди найдут время добровольно, чтобы определить срочные запросы.
Они будут разбираться в информации, предполагающей срочность, в которой компьютеры не умеют.
Я представил себе веб-сайт, который будет получать и отображать запросы с веб-сайта спасения. Добровольцы оценивали срочность по шкале от несрочная до критическая ( значения от 0 до 3) с возможностью выбора спама (–1). Они могли пропускать запросы, если не знали языка.
Итак, я приступил к работе.
Реализация
Сначала я подумал о том, чтобы встроить функцию краудсорсинга в keralarescue.in
Проект был с открытым исходным кодом. Многие создавали отдельные, но связанные инструменты на одной платформе. Для меня было разумно встроиться прямо в это.
Но у меня были некоторые опасения:
- Я не был уверен, сработает ли эта идея. Я не хотел оставлять мертвым грузом платформу, от которой многие зависели.
- Платформа была написана на Django с использованием PostgreSQL. Я мало знаком с ними, и я не хотел экспериментировать-учиться.
- Система обзора помешала бы быстрой итерации.
Поэтому я решил создать свой инструмент независимо от основной платформы.
Если бы это сработало, я бы попросил их объединить мои данные. Если не получилось? Эх.
Полуночное масло
Было уже около часа ночи. Я поставил цель запустить свой сайт в течение пяти часов, чтобы он был готов, когда люди проснутся.
Моя идея заключалась в том, чтобы использовать конечную точку API из keralarescue.in для отображения запросов помощи. Конечно, я кешировал его со своей стороны, чтобы не перегружать основной сайт.
Я начал разрабатывать платформу. Я начал с создания моделей данных. Затем я работал над функциями и конечными точками API. Наконец, я начал работу над интерфейсом. Мой стек включал Firebase и VueJS для быстрого прототипирования.
Я планировал использовать доверительные интервалы Вильсона для оценки результатов. (Используется для сортировки по достоверности на Reddit). Они лучше простых средних, поскольку учитывают количество оценок.
Но я очень торопился, поэтому решил реализовать это позже. Без данных это было бесполезно.
«Простота» - клише. Но я обнаружил, что это работает. Казалось, что ситуация улучшилась, когда я убрал сложность. Я написал простые модели данных. Я отказался от reCAPTCHA и аутентификации, полагая, что не буду привлекать злонамеренных пользователей.
Примерно к 8 утра мой прототип был готов. И я был готов заснуть. Я разместил ссылку на GitHub и лег спать сразу после первого просмотра страницы в Google Analytics.
У меня не было проблем с засыпанием.
Привлечение людей на борт
У меня были пользователи.
Проснувшись в полдень, я прежде всего проверял аналитику. ~ 30 посещений. В настоящее время у меня есть два пользователя. Из штата Керала. Вау.
Отзыв был положительным. И я собрал довольно много данных. Я продолжал улучшать свою платформу в течение дня.
- Я отказался от спама. Я узнал, что люди не знали, какие запросы были спамом. Многим не хватало информации. Это могут быть вполне обоснованные запросы от людей, которые спешат, или людей, которые плохо разбираются в технологиях.
- Я реализовал счет Уилсона. Я создал конечную точку API, которая вернула значение достоверности от 0 до 1 на основе всех собранных на данный момент оценок пользователей. Идея заключалась в том, чтобы keralarescue.in использовал эту конечную точку для периодического обновления своего набора данных. Значение можно использовать для сортировки и поиска наиболее срочных запросов.
- Я добавил страницу для отображения срочных запросов. Я хотел как можно скорее сделать этот инструмент полезным.
Около 16:00 я решил объявить об этом на Slack и Github.
Это оказалось переломным моментом, и в течение следующих нескольких часов на сайте было 20–30 пользователей онлайн. Они были со всей Индии, а также из США. Пользователи из Кералы продолжали работать до поздней ночи, сортируя запросы в 2 часа ночи.
Я заметил, что люди выполняли запросы на оценку медленнее, чем я ожидал.
На следующий вечер я узнаю почему.
Группа сортировки
К следующему дню я закончил большую часть работы по разработке. Многие люди начали связываться со мной. Им понравился мой проект - особенно простой интерфейс.
Вечером я получил DM в Твиттере от человека по имени Нишант, в котором он спрашивал, можно ли использовать мой веб-сайт для сортировки запросов. Нам позвонили, и я рассказал, как толпа может помочь определить срочность запросов.
Он добавил меня в группу из ста человек в WhatsApp. Оказывается, эти великие люди использовали мой веб-сайт совершенно по-другому.
Они активно обзванивали тех, кто обращался с запросами, и получали свежую информацию о своей ситуации. Они оценивали срочность не на основе текстового содержания, а на основании фактического разговора с затронутыми людьми. WOAH.
Я понял, что моя база данных содержит более ценную информацию, чем я думал. Мы напрямую помогали волонтерам добираться до жертв. Сообщения с благодарностью за мою работу катились в мой телефон.
Потеря источника данных
Еще в основном проекте люди готовились к большому событию. Правительство Кералы собиралось публично объявить о сайте спасения. Ожидалось интенсивное движение.
Основной веб-сайт предоставлял множество функций. Тепловые карты запросов, пожертвований, лагерей помощи, координации волонтеров, объявлений, вы понимаете суть.
У меня возникло серьезное уважение к команде разработчиков, потому что, когда на сайт попал трафик, они в одночасье работали над его масштабированием.
Казалось, все работает, за исключением одного: они отключили конечную точку API, от которой я зависел.
Теперь я знал, что конечная точка, которую я использовал, не масштабируется. Он вернул сразу все запросы. К концу своего срока службы он возвращал набор данных размером 10 МБ. Это было сделано для разработки, а не для промышленного использования.
К счастью, на моем сайте уже был механизм кеширования, поэтому он оставался работоспособным.
Я связался с командой. Они строили альтернативу. Но им еще многое нужно было построить, поэтому я старался не торопиться.
Мой сайт продолжал работать без проблем, а группы сортировки (к этому моменту их было несколько) продолжали работать, хотя и без новых данных.
Новые особенности?
На этом этапе я начал думать о способах улучшения.
Непосредственной проблемой стал приток больших объемов новых данных, когда стал доступен альтернативный маршрут. А какие еще улучшения я могу сделать?
Продумал некоторые особенности.
- Когорты по времени: назначьте определенный процент пользователей, которые будут обрабатывать только самые новые запросы. Аналогичным образом назначьте пользователей разделам старых запросов.
- Фильтры Блума: они позволяют эффективно проверить членство в наборе. Я мог бы использовать фильтры Блума для множества вещей: убедиться, что мы исчерпали все запросы, и ограничить повторные посещения.
- Обновления статуса: я мог бы создать функцию, позволяющую людям обновлять статус запросов. Это была банальная сборка, и люди ее просили. Но люди, работающие над основной платформой, сказали мне, что они ее уже строят.
- Веб-узлы: я мог передавать новые запросы на веб-сайт в режиме реального времени по мере их поступления. В сочетании с обновлениями статуса и временными когортами мы будем получать подробную информацию о запросах, как только они поступят.
У меня было много конкурирующих идей, и я не знал, какие из них можно реализовать вовремя, чтобы они были полезными.
Заворачивать
Конечная точка API вернулась на следующий день. Теперь он был разбит на страницы, возвращая 300 запросов за раз. Я быстро написал сценарий для загрузки и обслуживания локального кеша с использованием нового API.
Количество звонков и сообщений, которые я получал, достигло нового максимума. Это была новая территория, на которую раньше никто не работал. Со мной связались разработчики, работающие над основной платформой. Они работали над интеграцией краудсорсинговых данных - как рейтингов срочности, так и обновлений статуса, которые мы собирали.
Когда день закончился, люди из сортировочных групп почувствовали сдвиг.
Большинство жертв, которым они звонили, недавно сообщили о спасении. Оказывается, начались спасательные операции на земле.
Это были отличные новости. Около 5 утра мне позвонил Нишант. Он был в контакте с правительственными чиновниками, курировавшими спасательные операции. Мы упаковали данные с веб-сайта и электронных таблиц и передали их.
Пока я пишу это, жертвы наводнения были спасены и отправлены в лагеря для оказания помощи. Возникают новые проблемы, связанные с логистикой между лагерями и прибытием помощи со всей страны.
Уроки
- Простота. Многие люди писали мне, что им понравился мой сайт. Я не дизайнер, но мое решение упростить UX помогло людям быстрее освоиться.
- Вычисления дешевы. Все это размещено на Google Cloud Platform. Это стоило мне меньше доллара, покрываемого моими кредитами уровня бесплатного пользования. Если бы я знал, насколько это дешево, я бы создал приложение с тяжелой нагрузкой на серверную часть.
- Вращение: я бы хотел полностью перейти на платформу подробной сортировки. Добровольцы придумали временное решение, но, оглядываясь назад, я бы предпочел поставить платформу с этими функциями.
- Сети важны: люди хотели помочь. Первоначальная группа из 30 человек выросла за два дня до группы из 230 человек, когда люди звали своих друзей и знакомых. К нам присоединились люди из Кералы, остальной Индии и со всего мира.
Я встретил много замечательных людей. Я многому научился, как в технике, так и в других сферах. При всем этом самым невероятным ощущением было пребывание на одной волне с тысячами других людей.
Если моя работа заслуживает статьи, то проект, в котором я участвовал, заслуживает книги.
Что касается меня, я связываюсь с людьми, участвующими в ликвидации последствий стихийных бедствий, чтобы учиться на их опыте и знаниях.
Еще немного обо мне: у меня не хватает года, чтобы углубиться в криптоэкономику. Навыки веб-разработки я приобрел еще в 10 классе, когда проводил хакатон в школе.
Я подумываю о разработке проекта на основе этого, но с учетом многих других идей, которые с тех пор были у меня и моих друзей.
- Энн Томас, волонтер из групп сортировки, написала о своем опыте здесь
- Спасибо доктору Харикришнану, доктору Нишанту, Аджиту Чандрану, Прасаду Пиллаи, которые помогли организовать сортировочные группы
