компактный и понятный интерфейс, без шагов и капчи; нормальный редактор с подсветкой кода, а не просто textarea; сохранение бенчмарка, чтобы потом его можно было без труда найти, а также удаление (всякое бывает); возможность скачать бенчмарк и запустить его локально или через Node.js; возможность добавить в «Избранное»; другие ништяки.
А теперь самое интересное: где хранить исходники тестов? А результаты?
Где хранить исходники?
Если среди вас есть постоянные пользователи , то они помнят недавнюю историю, когда он был полностью недоступен именно по причине хранения кода и результатов прогона тестов. Так что задача сводилась к одному: как сделать так, чтобы ничего не хранить у себя, а переложить это на какой-нибудь сервис, а лучше на юзера? Ответ напрашивался сам собой: идеальное место для хранения исходников — , точнее . Он есть практически у каждого разработчика, и это решает сразу несколько поставленных задач:
хранение; нормальный поиск (по уникальному тегу); избранное; бонусом: история изменения тестов (diff) и fork’и.
У GitHub есть чудесный , это, наверное, одна из эталонных реализаций, также есть и для работы с Gist. Вопрос оставался за малым: как сохранить Gist от имени пользователя?
OAuth
Для авторизации GitHub предлагает использовать , это несложно, но требует минимального backend’а. Тут можно было пойти несколькими путями:
Найти какой-нибудь бесплатный хостинг или BaaS и развернуть там одно из open source решений для работы с GitHub. Воспользоваться сервисом , у которого есть приемлемый free-план.
Я выбрал , как очень простой и быстрый способ для начала работы, к тому же при необходимости от сервиса можно безболезненно избавиться. Плюс у него есть неплохая аналитика, простенькая для работы API и под любой сервис, в том числе и GitHub. А самый кайф, что для начала работы вам даже не нужно проходить нудную регистрацию, — просто нажимаете «Sign in with GitHub» и добавляете ключи от вашего приложения.
GitHub API
Следующий шаг — это написание обёртки для работы с GitHub API. И тут есть небольшой нюанс: я очень хотел лишний раз не дёргать OAuth.io, чтобы не выходить за лимиты free-плана. Как оказалось, GitHub позволяет обращаться к API неавторизованным, но такие вызовы жёстко лимитируются, поэтому метод получения Gist имеет достаточно нетривиальную логику:
Проверяем Runtime cache, если есть данные, отдаём. Если в есть данные о юзере, считаем, что он уже авторизован, вызываем получение токена через OAuth.io и делаем запрос к API. Если авторизация не прошла, отправляем запрос неавторизованным и надеемся, что лимиты ещё не исчерпаны. Если в ничего нет, делаем запрос как неавторизованный, в случае ошибки пытаемся авторизоваться через OAuth.io и повторить запрос уже как авторизованный.
Переводим это в код, посыпаем + и получаем вот такой метод: Где хранить результаты?
Если с исходниками я определился быстро, то вот с результатами не всё так просто. Не буду томить, просто перечислю решения, которые я знал на тот момент:
— BaaS, есть опыт использования, удобный JS SDK; — DaaS, микроскопический опыт использования, требуется JS-велосипед для работы; — DaaS+, опыта не было, есть JavaScript SDK и кое-что ещё ;).
Так как проект был экспериментальным, выбор пал на Firebase: кроме JavaScript API, он предлагал в два раза больше места, чем на том же MongoLab, — целый гигабайт.
На самом деле был ещё один вариант: localStorage/IndexedDB + . Идея заключалась в следующем: результаты прогонов храним в localStorage и если в онлайне есть ещё кто-нибудь, то синхронизируем данные :).
Итак, Firebase. Использовать его до безобразия просто, документация не врёт: . Это весь код, который мне пришлось написать для работы с Firebase, но самое классное, что событие обновления «узла» срабатывает всякий раз, когда кто-либо запускает бенчмарки, и вы прямо онлайн, без каких-либо F5 или cmd + r, получаете обновление графиков.
Дизайн
Эх, вот чего не умею, того не умею, поэтому всё выглядит так: Интерфейс максимально информативен, отображены основные важные параметры, справа от кода теста выводится результат прогона, после завершения теста строчки подсвечиваются соответствующим цветом, а под кодом строятся графики. Setup и Teardown вынесены в «уши» внизу экрана — решение спорное, но подходит для большинства задач. В итоге вся возможная информация умещается на одном экране.
Как можно заметить, в отличие от jsperf, у меня есть подсветка кода, для этого используется Ace.
— это чудесный инструмент для интеграции редактора кода в ваше приложение. Чтобы его использовать: Для прогона тестов используются и , графики рисую при помощи , так что результаты прогона и графики выглядят точно так же, как на jsperf.
Шаринг
Одна из фич — это шаринг теста, сейчас поддерживаются только Twitter и Facebook.
Тут особо нечего рассказывать: открываем popup с предустановленным текстом, а дальше пользователь сам решает, постить или нет.
Вот тут интереснее, хотелось не просто ссылку постить, а сразу график в ленту. У Google Visualization есть метод получения , а у FB — , осталось их подружить:
Для преобразования dataURI используем
И публикуем: Планы на будущее
Поддержка ES6. Подключение сторонних либ для теста. Комментарии к бенчмарку (поддержка Markdown). Просмотр ревизий и fork’ов.
Полный список используемых библиотек и полифилов
— — — dataURI в Blob — редактор кода ( + ) — детектор платформы, браузера и т. п. — запуск бенчмарков — сервис для работы c OAuth — NoSQL и — красивые алерты
Итог
Как видите, в настоящий момент можно собирать качественный прототип с помощью готовых решений и бесплатных платформ, затрачивая на это только своё время. А ведь это не просто экономия денег — это и экономия времени на выбор хостинга, установку, настройку необходимого софта и дальнейшее администрирование. Все эти проблемы исчезают, когда вы используете любой BaaS или DaaS — они дают вам готовое решение без головной боли. Плюс, если проект вырастет и окрепнет, вы всегда можете перейти на подходящий платный тариф или поднять точно такой же стек на своём хостинге.
Страница проекта:
Исходный код и задачи: