В своей замечательной книге «Как работает Google» Эрик Шмидт объясняет, насколько удивительны вещи в эпоху Интернета:
Слияние трех мощных технологических тенденций коренным образом изменило правила игры в большинстве отраслей. Во-первых, Интернет сделал информацию бесплатной, обширной и повсеместной - практически все находится в сети. Во-вторых, мобильные устройства и сети сделали широко доступными глобальный охват и постоянное подключение. В-третьих, облачные вычисления предоставили практически безграничные вычислительные мощности и хранилище, а также множество сложных инструментов и приложений для всех по недорогое, с оплатой по факту.
В моем рассказе показан пример использования обширных общедоступных данных и бесплатных облачных вычислений, чтобы получить интересное представление о мире программного обеспечения с открытым исходным кодом.
Люди находятся в Facebook, а разработчики с открытым исходным кодом находятся на Github, где более 12 миллионов компьютерных фанатов ежедневно вносят свой вклад в более 30 миллионов проектов. Большая часть этого сообщества использует JavaScript - самый популярный язык программирования на Земле - для написания кода и Диспетчер пакетов узлов для его распространения. Экосистема NPM довольно удобна в том смысле, что мгновенно предоставляет разработчикам массу инструментов и библиотек, позволяющих быстро начать работу или не так много;); в любом случае новый проект javascript в настоящее время начинается с пары команд: npm init и npm install ‹список модулей›. Указанные модули загружаются из репозитория npm на локальный компьютер и затем могут использоваться в коде нового проекта. В репозитории размещено более 250 тысяч пакетов повторно используемого кода, а веб-сайт npm предоставляет статистику наиболее зависимых, основанную на количестве загрузок за последний день / неделю / месяц. Однако эти числа кажутся метрикой тщеславия, потому что пакет загружается каждый раз, когда кто-то обновляет или устанавливает зависимости проекта. Есть ли другой метод ранжирования репозиториев npm? Вот о чем эта история!
Летом 2016 года Github и Google сделали открытые данные доступными для всех в BigQuery, вот ошеломляющие цифры:
Этот набор данных размером 3 ТБ + представляет собой самый крупный выпущенный на сегодняшний день источник активности GitHub. Он содержит полный снимок содержимого более чем 2,8 миллиона репозиториев GitHub с открытым исходным кодом, включая более 145 миллионов уникальных коммитов, более 2 миллиардов различных путей к файлам и содержимое последней версии для 163 миллионов файлов, все из которых доступны для поиска с помощью регулярные выражения.
И можно запросить эти данные с помощью Google Computing Power бесплатно, если вы не превысите бесплатную ежемесячную квоту (что случилось со мной). Именно об этом говорил Эрик Шмидт в своей книге. Теперь давайте проверим, как мы можем ранжировать репозитории npm, используя содержимое файлов github с открытым исходным кодом!
Чтобы выполнить шаги, показанные ниже, я вошел в Google Cloud Console, создал новый проект под названием GithubDataQueries, затем открыл Github Public DataSet, переключился на мой проект и создал набор данных NpmStat, при этом указать соответствующий интерфейс выглядит так:
Проекты, использующие npm, сохраняют информацию о пакете, включая список зависимостей, в файле с именем package.json, поэтому давайте выберем эти файлы из таблицы github_repos.files и сохраним результаты в новой таблице для дальнейшего использования:
О скольких файлах мы здесь говорим? Давайте проверим это, получив количество строк во вновь созданной таблице NpmStat.package_json_files:
Итак, в данных с открытым исходным кодом более 8 миллионов файлов package.json. Обратите внимание на скорость выполнения этих запросов! Это возможно только потому, что мы используем самый мощный в мире вычислительный механизм. Но теперь давайте выберем и сохраним в новой таблице содержимое файлов package.json:
Обычно файл package.json содержит 2 типа зависимостей, я называю их средой выполнения и временем разработки: последние обычно требуются для запуска тестов или создания документации, а первые необходимы для фактического использования пакета в вашем коде. Вот пример из одного из моих проектов:
Следующий запрос выбирает списки зависимостей среды выполнения из содержимого файлов package.json с помощью простого регулярного выражения, затем разделяет их с помощью разделителя «,» и, наконец, удаляет версию репозитория, создавая плоский список имен репозиториев npm, найденных в проекты с открытым исходным кодом в Github:
SELECT Substr(dep, 1, instr(dep, ":") — 1) FROM(
SELECT Split(deps, ",") dep FROM(
SELECT Regexp_extract(content, r'\"dependencies\"\s*\:\s*\{([^}]*)\}') deps FROM [githubdataqueries:NpmStat.package_json_content]))
Вот и все, теперь мы можем ранжировать репозитории, используя частоту использования имени репозитория в файлах package.json:
Вот 10 лучших репозиториев:
Сравним с статистикой npm (порядок слева направо, сверху вниз)
Результаты близки, что ожидаемо, но все же они отличаются, например, подчеркивание занимает 4-е место в списке npm, но его даже нет в топ-10 в нашем списке (фактически, оно 12-е)! Используя ту же технологию, можно рассчитать PageRank репозиториев npm, а затем построить Google npm, как это звучит!
Хотя расчеты и результаты, которые я использовал, могут показаться не очень полезными, они демонстрируют занимательный (надеюсь) пример использования общедоступных данных и дешевых облачных сервисов для получения количественных показателей различных аспектов цифровой жизни. Я продолжу исследовать мир javascript-проектов с открытым исходным кодом и поделюсь новой историей, как только найду что-нибудь интересное!
