Автор оригинала: Thiago Garcia.
Вступление
Был четверг, а вручение премии “Оскар” должно было состояться в воскресенье. Возникла идея: можем ли мы выяснить эмоции людей в Твиттере во время вручения “Оскара” с помощью смайликов, чтобы Coca-Cola могла создавать собственные твиты? У меня было четыре дня, чтобы сделать это, и я это сделал. Вот как это было сделано, не потеряв ни одной ночи сна.
Я также многому научился из этого опыта, и именно поэтому я хотел написать об этом. Основными уроками были:
- Выбор правильных шагов имеет важное значение для своевременной доставки.
- Процесс разработки важнее кода.
- Никогда не предполагайте ничего, прежде чем приступить к выполнению задачи.
- Детские шаги. Гораздо проще сделать небольшой шаг назад в начале игры, чем после того, как вы потратили целую неделю на выполнение задачи.
В чем заключался вызов
Задача состояла в том, чтобы за крошечный промежуток времени создать данные-то есть эмоции твитов, основанные на смайликах, — и это должно было быть в режиме реального времени. Команда состояла из меня, занимавшегося бэк-эндом, и фронт-энд-разработчика, занимавшегося парным программированием.
Мы должны были подключиться к потоку Twitter, получить каждый твит в PT-BR об Оскарах, проанализировать его, обнаружить эмоции и отобразить на какой-то визуализации. Проект будет находиться в приборной панели военного зала Coca-Cola, чтобы все могли его увидеть.
Правильные шаги для достижения успеха
Мы начали с того, что у нас было больше страха и сомнений: анализ эмоций из твитов на основе смайликов. После этого мы сможем увидеть, каков следующий шаг.
Мы никогда не начинаем задачу, основываясь на предположениях, и это было очень важно для небольшого срока. Предположения могут сбить нас с толку и заставить развить множество несущественных вещей.
Отличный выбор, который мы сделали, заключался в разработке структуры сервера только после того, как точно поняли, как ведет себя API Twitter и насколько большим он может стать. В конце концов, он оказался не таким большим, как мы себе представляли, и один экземпляр Heroku мог справиться с потоком.
Я знаю, что страшно “тратить” время на тестирование и проверку вещей, когда у вас короткий срок, но это никогда не бывает пустой тратой времени. Поэтому пишите тесты, читайте документацию и пробуйте что-то, прежде чем приступать к выполнению задачи.
Наш стек
Мы использовали то, что мы регулярно используем. У нас не было времени на эксперименты, и из-за этого мы использовали Python и Django .
Python отлично справляется с NLP и имеет библиотеки , готовые помочь вам. Кроме того, многие исследователи данных используют его. Кроме того, я даже нашел некоторые фрагменты кода в Интернете, которые очень помогли!
Как я уже говорил, первым шагом всегда является лучшее понимание вашей проблемы. Мы начали с поиска, если кто-то уже сделал это, и, к счастью, мы нашли реализацию в Python, которая использовала Pandas .
Мы использовали эту библиотеку для подсчета общего количества вхождений каждого смайлика в тексте. С помощью этого мы могли бы преобразовать смайлики в эмоции, реализовав словарь “emoji to emotion”.”
Данные-а именно
После преобразования текста в эмоции с помощью смайликов следующим шагом было создание базы данных для него. Мы знали, что для этой задачи может потребоваться много графики, но у нас не было времени экспериментировать. Поэтому мы выбираем самый универсальный график в мире: гистограммы!
Было важно заранее спланировать диаграмму, чтобы мы могли увидеть, какую структуру данных лучше использовать. Таким образом, мы могли бы возложить на Python ответственность за сохранение данных с правильной структурой, а не делать это в JavaScript. D3.js построил бы графики в самый раз.
Веб-приложение
Мы уже знаем, как анализировать твиты и как мы собираемся их отображать, чтобы мы могли, наконец, начать наш проект Django.
Я решил использовать базу данных в качестве посредника между интерфейсом и потоком Twitter, чтобы мы получали твиты, анализировали их, сохраняли в базе данных, и наш API мог получать твиты оттуда.
Поскольку мы начали с конца, мы построили структуру данных, чтобы использовать запрос к базе данных для агрегирования данных. Тяжелая работа будет выполняться в базе данных, что намного быстрее, чем при использовании Python.
Структура данных
Поскольку мы выбираем гистограмму, наши данные в первую очередь должны представлять собой сводку общего количества смайликов в определенный момент времени. Это было что – то вроде этого:
{
'ANGRY': 4,
'LOVE': 10,
'HAPPY': 2,
...
}
Чтобы добиться этого, мы сохранили подсчет общего количества эмоций каждого твита, чтобы позже запросить их с помощью Django annotate и получить именно это. Важно отметить, что, поскольку нам нужно сделать это в относительно большой базе данных, использование db_index очень помогло нам!
Получение твитов
Мы использовали Tweepy для подключения к Twitter. Очень полезно иметь библиотеки, которые будут служить вам, особенно с хорошо известными API, потому что они решают некоторые сложные проблемы и предостережения.
В нашем случае, когда нам нужно было использовать Twitter Streaming API , lib был очень удобен, потому что нам не нужно было беспокоиться о поддержании соединения, знать, какая лучшая стратегия обработки твитов асинхронна, или выяснить лучший способ сделать это в Python и Django.
Все уже было на месте. Нам просто нужно было настроить команду Django, чтобы запустить то, что они называли Stream , и мы закончили.
Развертывать
Мы использовали Heroku для этого проекта, в первую очередь потому, что все другие проекты были там, и потому, что у нас не было команды DevOps.
Использование Heroku отлично подходит, потому что при необходимости проще масштабировать приложение или Postgres.
Развертывание там происходит быстро, а отслеживание метрик проще. Наша настройка состояла в том, что один рабочий запускал команду Django, а другой запускал веб-приложение. Легкий ветерок.
Большой день
В день вручения премии “Оскар” мы были расслаблены, потому что мы уже протестировали его с различными горячими трендовыми темами, и приложение работало гладко.
Результаты были впечатляющими — у команды была обратная связь в режиме реального времени о том, какое настроение было во время мероприятия.
Один конкретный случай был захватывающим: Леди Гага пела, и сначала песня была грустной, поэтому все тоже были грустными. Позже он повернулся, и эмоции на приборной панели сразу же сменились на счастливые. Было очень приятно видеть, что приложение работает в режиме реального времени.
От POC до продаж
После этого успешного эксперимента компания поняла, что у нее на руках ценный продукт, и начала показывать его другим потенциальным клиентам. Мне пришлось преобразовать приложение, предназначенное для работы с одним экземпляром Heroku без входа в систему, с определенными фирменными цветами и логотипом, в продукт SaaS.
Чтобы поддержать нынешний ажиотаж вокруг него, нашим первым шагом было превратить продукт в проект с белой этикеткой. Для каждого нового клиента мы создали совершенно новую ветвь Git и экземпляр Heroku с пользовательскими переменными ENV. Благодаря этому нам удалось продемонстрировать пользовательские экземпляры этого продукта многим клиентам и даже продать один из них.
Кстати, переменные ENV могут очень помочь в Heroku. Вы можете быстро изменить их с помощью интерфейса, который может изменить важные вещи в вашем приложении — в нашем случае цветовую гамму, название бренда и логотип.
После этого мы разделили проект на две части. Один из них-администратор, где пользователь вошел в систему и создал новый поиск, а другой-интерфейс и работник, подключенный к API.
Сложной частью было найти способ разделить конфигурации и рабочих, потому что теперь все “жестко закодировано” в Heroku ENV.
Административная часть превратилась в новый проект в Django, связанный с нашим ТАК. Это был простой CRUD, в котором пользователь может создать только один поиск.
Это ограничение было сделано для того, чтобы мы могли запустить раньше и выполнить часть экземпляра вручную, что означало, что каждый раз, когда клиент создавал новый поиск, мы получали электронное письмо с настройками для настройки и развертывания нового приложения Heroku для интерфейса и рабочего.
Тем не менее, мы знали, что у Heroku есть API, который мы могли бы реализовать позже, чтобы сделать все автоматическим, когда это необходимо.
Рабочий и внешний интерфейс были исходным проектом, но вместо того, чтобы получить конфигурацию из ENV, он получил конфигурацию из другого проекта через API. Единственным параметром в ENV был только что созданный клиентом идентификатор поиска.
Это соединение было через SSL и HTTP Basic. Во время разработки мы обнаружили, что разработка приложения с другим проектом в качестве зависимости была особенно важна.
Использование нескольких бэк-эндов
Одной из альтернатив решению зависимости между интерфейсным и административным приложением было использование некоторого решения для загрузки всей среды разработки в целом, но мне не понравилась идея добавления дополнительных вещей в этот проект.
Решение состояло в том, чтобы сделать два бэкенда, один из которых подключался к API и был по умолчанию для производства, а другой получал конфигурацию от ENV. Это хорошее решение, потому что Django уже использует что-то подобное для отправки электронных писем, например.
Такого рода решение необходимо подчеркнуть, потому что оно облегчило поддержание проекта в долгосрочной перспективе.
Вывод
Позже у продукта стало меньше запросов, и мы остановили разработку на этом этапе. Сохраняя все простым, я чувствую себя более комфортно, зная, что даже если продукт не преуспел в качестве SaaS, мы никогда не тратили больше времени и денег, чем необходимо.
Я надеюсь, что мой опыт поможет вам в ваших проектах.