Как искать проекты на github

Как искать альфу на Github

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

Даже не разбираясь в коде, в contracts стоит обратить внимание на 3 вещи: (1) последняя активность на странице, (2) вкладка Issues и (3) вкладка Pull requests. Это позволит понять, происходило ли что-то с проектом за последнее время.

В данном случае, просматривая Pull requests, мы видим, что есть недавняя активность в ветке testnet, которая в настоящее время сливается с мастер-веткой. Вероятно, это означает скорый запуск.

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

Теперь давайте рассмотрим пример запуска продукта на примере Dopex.

Судя по всему, все действия по запуску продуктов DPX попадают в раздел dopex-io/sdk. Если мы перейдем к Pull requests → Open, то увидим, над чем в настоящее время работает команда. Ниже приведены файлы, которые были изменены, что позволяет предположить названия запускающихся продуктов (Atlantic Puts, Long Perp Strategy).

Судя по коду, стратегия Long Perp является интеграцией Dopex и GMX, где они предложат «страховку для перпов» для деген-трейдеров GMX через путы Atlantic. Наш поиск позволяет предположить, что запуск этого продукта состоится довольно скоро. Если вы видите, что какая-либо ветка кода сливается с мастер-веткой, то запуск, скорее всего, не за горами.

Копание в ветках (Branches) — еще один способ найти хорошую информацию об изменениях проекта. Если вы посмотрите на github Sushiswap и отфильтруете по веткам, вы сможете найти код их кроссчейн-продукта sushixswap.

Можно заметить, что коммит слияния кода SushixSwap с мастер-контрактами Sushi датируется 11 июля, то есть это можно было заметить за две недели до публичного анонса.

Другой способ заглянуть под капот проектов — проверить активность отдельных разработчиков. Это можно использовать как для оценки общей активности, так и для того, чтобы собрать воедино все интересные обновления кода. Вы можете найти людей, работающих над проектом, во вкладке People:

Также можно просмотреть всех, кто публиковал пул-реквесты и коммиты в проекте:

На странице разработчика можно увидеть его недавнюю активность. Также Github предоставит вам своего рода тепловую карту активности за последний год:

Рекап и выводы

Когда у вас есть шорт-лист проектов для ресёрча, лучше всего работает связка Discord + Github. Если вы в курсе того, на каких обновлениях фокусируется сообщество и команда, это поможет вам определиться, что именно искать на Github. Большое количество активности в репозитории может говорить о том, что ожидаемое обновление находится в разработке. Также можно попытаться подтвердить это самостоятельно, просмотрев недавнюю активность отдельных разработчиков, различные ветки их Github, а также вкладки Issues и Pull requests.

Gagarin Crypto | Канал | Чат | Twitter

Как искать интересные проекты на GitHub?

Изучаю программирование. Хотел бы почитать коды действующих проектов, понаблюдать за разработкой со стороны. Наверно самый популярный сейчас хостинг для проектов с открытым исходным кодом это GitHub. Но поиск на этом сайте крайне неудобен. Также существенный минус, что нет каталога проектов по категориям (как на sourceforge). В итоге сайт, хоть и хвастается показателем в 8,6М проектов, воспринимается как большая свалка. Где и как искать проекты? Интересуют небольшие разработки на языке Си, архитектуру которых можно осмыслить одному человеку и потренироваться в программировании на форке.

• Вопрос задан более трёх лет назад
• 28739 просмотров

Поиск похожих проектов на GitHub

Гитхаб — прекрасный сайт. Но представьте, что вы нашли проект А, и хотите узнать какие еще существуют похожие проекты. Как быть?

Именно с таким вдохновением уселся я разбирать API GitHub’a. Спустя пару недель свободного времени вот что получилось:

Для большинства проектов находится пара действительно интересных предложений. Вот несколько примеров: angular.js, front end bookmarks, three.js

Основная идея для построения рекомендаций — «Разработчики которые поставили звездочку этому проекту, также поставили звездочку. ». А детали идеи, ее недостатки и ссылка на код — ниже.

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

Идея для старта

Давай проанализируем всех фолловеров проекта А, посмотрим какие другие проекты они фолловят, и выберем наиболее часто повторяющиеся проекты? Увы, этот подход провалился с треском: среди результатов поиска рекомендаций на первые места зачастую выходят самые популярные проекты, но не обязательно имеющие отношение к текущему. Весь GitHub влюблен в Bootstrap — самый популярный проект на сегодня.

Сколько весит общая звезда?

Проект A — всего 100 звезд
Проект B — всего 200 звезд
Проект C — всего 1000 звезд

Допустим сто одних и тех же разработчиков поставили звездочку проекту А и B, и сто одних и тех же разработчиков поставили звездочку проекту А и С. Какой проект B или С будет более близким проекту А? Очевидно — B. Половина его фолловеров следят за проектом А. Лишь 10% последователей C заметили проект A.

Как же можно обобщить три переменные в одну формулу похожести? Думал я медленно и идея рассмотреть процент общих звездочек от суммарного числа звезд обоих проектов пришла не сразу:

similarity = 2 * shared_stars_count / (project_a_stars + project_b_stars)

Формула дает очень неплохие рекомендации. Как я узнал позже от Камерона Девидсона, эта формула была выведена в 1946-м году, двумя ботаниками (это не попытка оскорбить кого-либо, они действительно были специалистами в ботанике): Соренсеном и Дайсом.

Проблемы API

К сожалению у GitHub’a отсутствует bulk API, позволяющий одним запросом достать информацию обо всех фолловерах проекта. Ко всем неудобствам ограничение в 5 000 запросов в час делает анализ проектов невыносимо долгим. Адди Османи предложил ограничиться анализом лишь нескольких сотен последователей. Экспериментально, если выбрать случайных 500 последователей проекта — результат рекомендаций не ухудшится.

Метрику сходства проектов для случайных N последователей проекта A я переписал так:

alpha = N/project_a_stars
similarity = 2 * N / (alpha * (N + project_b_stars))

Такая формулировка делает проекты с примерно одинаковым числом звезд более близкими друг другу и неплохо отсеивает шум от популярных проектов.

К сожалению даже при N = 500 время постройки анализа одного проекта занимает около семи минут.

А что если вычислить все похожие проекты заранее?

Рекомендация работает неплохо для проектов с 200+ звездами. Но сколько таких проектов на GitHub’e? Как оказалось, чуть больше семи тысяч (на момент написания кода было около 7 300).

Написав паука для поиска ников всех фолловеров популярных репозиториев, я обнаружил около 457 115 уникальных пользователей :). Теперь для каждого пользователя нужно достать его любимые проекты. Но сколько это может занять времени? Даже при очень пессимистичной оценке в 300 звездочек на фолловера, учитывая ограничение на 5 000 запросов в час, пришлось бы «копать» гитхаб 11 суток без остановки.

11 суток не так и много для хобби, да? Задача хорошо распределяется, потому если у вас есть добрый друг, готовый поделиться своим токеном на гитхабе, то можно справиться за неделю! В тот же вечер появился паук для сбора любимых проектов фолловеров.

Весело шурша сеткой, время от времени часто спотыкаясь о баги, два паука насобирали необходимые данные за… 4 дня. Как оказалось, в среднем один пользователь гитхаба дает 22 звездочки. Лишь 0.02% пользователей дали больше 600 звезд. Потому при безупречной работе пауков можно было бы построить всю необходимую базу за пару суток.

Бесполезный факт

На GtHub’e больше всего ников начинается на букву ‘s’. За ними идут пользователи на ‘m’ и на ‘a’. Ники на заглавную ‘Q’ встречаются реже, чем ники на цифру 2:

В облако
Результат работы пауков я загрузил на S3. Все современные браузеры распознают CORS, потому обычным ajax запросом можно достать необходимый js файл с рекомендациями. Если вычисленных рекомендаций для проекта не существует в облаке, сайт перейдет в режим онлайн-постройки рекомендаций. Аутентифицируйтесь на гитхабе, чтобы получить большую квоту. Промежуточные данные сохраняются в локальный IndexedDB, потому можно возобновить индексацию даже после закрытия страницы.

Код
Если вы, дорогой хабрачитатель, знаете как можно улучшить рекомендации — я с огромным удовольствием! Код сайта доступен здесь: anvaka/gazer.

Ставьте звездочки проектам, которые вам нравятся — это делает приятно не только авторам репозиториев, но и может помочь другим разработчикам найти нужные проекты :).

Спасибо огромное, что дочитали до конца :)!

• github
• javascript
• recommender system

• Веб-разработка
• Open source
• JavaScript

Как принять участие в работе Open Source проектов на GitHub. Краткое руководство для начинающих

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

Адаптированный перевод статьи The beginner’s guide to contributing to a GitHub project . Здесь приведены только общие рекомендации по работе с Open Source из визуального интерфейса GitHub. Обязательно ознакомьтесь с README выбранного вами проекта для уточнения деталей.

Шаг 0: Выберите проект

На эту тему очень много статей. Мы будем считать, что вы уже выбрали проект и решились на свой первый шаг. Для примера используется работа над реальным PR в проект Хекслет Sicp .

Шаг 1: Создайте рабочую копию на своем компьютере

Прежде всего, вам нужен локальный форк проекта, поэтому нажмите кнопку «Fork» в GitHub.

Это создаст копию репозитория в вашем аккаунте на GitHub. При переходе в вашу копию проекта вы увидите, откуда он был форкнут:

Теперь вам нужна локальная копия, найдите «SSH clone URL» — справа, вверху.

Используйте эту ссылку для клонирования проекта на ваш компьютер с помощью терминала. Если вы не знаете, как им пользоваться — на Хекслете есть большой курс по базовым командам в командной строке.

$ git clone git@github.com:AABur/hexlet-sicp.git 

Результат будет выглядеть примерно так:

Перейдите в директорию нового проекта:

$ cd hexlet-sicp 

Теперь необходимо установить связь локальной копии с оригинальным проектом, чтобы вы могли получать изменения основного проекта и вносить их в свою локальную копию. Сначала перейдите по ссылке в оригинальный репозиторий — она помечена как «forked from» в верхней части страницы GitHub. Это вернет вас на главную страницу проекта на GitHub, где вы сможете найти «SSH clone URL» и использовать его для создания новой связи, которую мы назовем upstream.

$ git remote add upstream git@github.com:Hexlet/hexlet-sicp.git 

Теперь ваша локальная копия проекта связана с двумя репозиториями на GitHub:

1. origin, который указывает на ваш форк проекта на GitHub. Вы можете читать его, и писать в этот репозиторий.
2. upstream, который указывает на GitHub-репозиторий основного проекта. Этот репозиторий можно только читать.

Шаг 2: Заставьте его работать на вашей машине

Теперь, когда у вас есть исходный код, запустите его на своем компьютере. Надеюсь, в файле README или INSTALL этих проектов будет документация, как это сделать.

Если у вас все работает, но документация неясна, то улучшение этого раздела должно стать вашим первым PR в проекте. Это одновременно и самый простой и полезный способ войти в проект!

Шаг 3: Сделайте что-нибудь полезное

Это самый приятный этап — внести свой вклад в проект. Начните лучше c исправления ошибки, которая вас раздражает. Либо найдите подходящую в трекере проблем проекта — « Issues ». Если вы не уверенны, с чего начать, многие проекты используют ярлык «good first issue» (или его разновидность), чтобы указать, что эту проблему может решить даже новичок в проекте.

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

Ветвление

Важное правило — размещать каждую часть разработки в отдельной ветке. Изучите, какая модель ветвления используется в проекте. Если в документации бранч-стратегия не описана, посмотрите, как называются уже существующие ветки. Вы можете назвать свою ветку как угодно, но важно, чтобы она была осмысленной. Названия веток типа «feature», «bugfix», «hotfix», «update» с указанием на то, что меняется — это лучший вариант.

В нашем примере мы исправляем README.md, поэтому мы создадим ветку readme-update:

$ git checkout main $ git pull upstream main && git push origin main $ git checkout -b readme-update 

В первую очередь мы убеждаемся, что находимся на _ main_-ветке. Затем команда git pull синхронизирует нашу локальную копию с основной веткой проекта, а команда git push синхронизирует ее с нашим форкнутым проектом на GitHub. Наконец, мы создаем новую ветку readme-update.

Теперь вы можете заняться устранением проблемы.

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

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

Убедитесь, что вы коммитите логичными блоками. Каждый коммит должен быть обоснованным. Прочитайте статью Как правильно составлять описания коммитов и почему это важно.

Шаг 4: Создайте Pull Request

Чтобы создать PR, вам нужно отправить ветку в ваш форк на GitHub, а затем нажать несколько кнопок на GitHub.

Чтобы отправить новую ветку:

$ git push -u origin readme-update 

В результате будет создана ветка в вашем проекте на GitHub. Флаг -u связывает эту ветку с удаленной, так что в будущем вы сможете просто набрать git push origin в терминале.

Вернитесь в браузер и перейдите к вашему форку проекта (в нашем примере это будет выглядеть вот так , и вы увидите, что ваша новая ветка появилась в верхней части с удобной кнопкой «Compare & pull request»:

Нажмите эту кнопку!

Если вы видите выделенную надпись, как показано ниже:

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

На этой странице убедитесь, что «base repository» и «base» указывает на правильный репозиторий и ветку. Затем дайте хорошее, краткое название вашему запросу и объясните, почему вы его создали в поле описания. Добавьте соответствующие номера проблем, если они у вас есть.

Ниже в примере выполнена работа с веткой Master, но вам для работы с Хекслетом нужно работать с веткой main.

Если вы прокрутите страницу немного вниз, вы увидите diff с вашими изменениями. Дважды проверьте, что он содержит то, что вы ожидаете.

Как только вы будете уверены, нажмите кнопку «Create pull request» и все — готово.

Шаг 5: Проверка разработчиками проекта

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

Как участвовать в Open Source проектах Хекслета: На Хекслете есть множество Open Source проектов разной сложности — нам всегда нужна помощь разработчиков для развития этих сервисов.

Итоги

Главные этапы работы в Open Source:

1. Форкни проект и склонируй его на свой компьютер.
2. Установи связь с основным репозиторием проекта (upstream remote) и синхронизируй с ним локальную копию.
3. Создавай локальный бранч для каждого логического блока работы.
4. Внеси изменения, создавай хорошие описания коммитов и читай файл CONTRIBUTING, если он есть.
5. Синхронизируй изменения со свом форком (origin remote).
6. Создай Pull Request на GitHub.
7. Отвечай на все замечания, полученные в ходе код-ревью.

Дополнение от переводчика

Оригинальная статья была написана в 2015 году. С тех пор вышла GitHub cli, и в git появились новые команды. Теперь эти шаги можно сделать ещё проще.

1. gh repo fork Hexlet/hexlet-sicp
2. git switch -c readme-update
3. Тут делаем полезные изменения
4. git push -u origin readme-update
5. gh pr create —title «update README.md» —body «Slightly updated Russian README»
6. Тут ревью кода и успешное принятие вашего PR