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

Практическое занятие «Поиск open-source проекта»

Чтобы проникнуть в мир API документации, нам нужно подумать о примерах API документации в нашем портфолио. Портфолио является ключом к работе технического писателя API документации. Без портфолио, содержащего убедительные примеры, будет сложно найти работу по документации API.

Избегаем “Уловки-22”

Предположим, у нас нет опыта работы с API документацией, но мы пытаемся получить работу техписателя API документации. Работодатели будут готовы не обращать внимания на опыт, если мы сможем продемонстрировать примеры написания документации API. Но как мы получим примеры описания API без API-документации? И без примеров API документации как мы можем получить желаемую работу? Это может показаться невозможной ситуацией.

Обойти эту “Уловку-22” очень просто: создаем примеры документации API с помощью проектов с открытым исходным кодом, в которые мы внесли свой вклад. Вот где пригодится данное практическое занятие.

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

Поиск опен-сорс проекта с API

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

Поиск подходящего проекта может быть сложной задачей, но он важен для вашего портфолио и вашего успеха в проникновении в мир документации API. К счастью, почти все проекты с открытым исходным кодом используют GitHub, и GitHub предоставляет различные теги для документации и «help wanted» для привлечения добровольцев. (Задача настолько распространена, GitHub предоставляет советы по поиску проектов с открытым исходным кодом.)

Идеальный опен-сорс проект должен отвечать следующим критериям:

проект содержит API (не нативную библиотеку API или какой-либо другой инструмент разработчика, который не является API);
проект нуждается в документации API;
проект не должен быть настолько технически сложным, чтобы вы не могли его изучить. (Если вы уже знакомы с языком программирования, вы можете ориентироваться на проекты, ориентированные на этот язык.);
Проект должен быть активным, с недавними коммитами.

��‍�� Практика: Поиск проекта с необходимостью документирования API

Для поиска нужного проекта:

Открываем расширенный поиск GitHub
Скроллим экран и ищем раздел Issues Options. В поле With the labels вписываем help wanted . Это стандартный тег, который команды используют для привлечения добровольцев в свой проект (но некоторые команды, которым нужна помощь, могут его и не использовать). Скроллим вверх и замечаем, что надпись: «Требуется помощь» автоматически заполняется в поле Advanced Search.
В поле Advanced Search добавляем ключевые слова documentation и api перед тегом help wanted

Нажимаем кнопку Search и видим результат.

В полученном списке можно поискать проект REST API (а не API нативной библиотеки, такой как Java API). Есть ли проекты, которые выглядят интересными или перспективными? Если так, отлично. Если нет, добавляем ключевые слова и продолжаем искать.

Если поиск на GitHub не дал подходящих проектов, можно поискать на следующих ресурсах:

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

После выбора проекта пометим следующее:

Задействован ли REST API в проекте?
Как в проекте помечены проблемы, связанные с документацией? Например, используется ли в нем ярлык «документация»?
Определяем текущее состояние документации проекта: является ли она надежной, скудной, обширной, есть она вообще?
Насколько активен проект? (Какова частота коммитов?)
Сколько участников в проекте?

Примечание: Пока не нужно связываться или взаимодействовать с командой. Мы просто собираем информацию и анализируем потребности в документации здесь.

Понимание типа API, используемого в проекте

Во время поиска проекта API, нужно понять, что существует множество различных типов API. Многие из API-интерфейсов, с которыми мы работаем, могут быть исходными библиотеками API, которые не используют веб-протоколы для выполнения запросов и ответов (как это делают API-интерфейсы REST), а скорее подключают к проекту библиотеки для конкретного языка. Если кажется, что API фокусируется на определенном языке, а документация API выглядит автоматически, скорее всего это исходная библиотека API.

С другой стороны, если документация проекта содержит основные разделы конечных точек — это API REST.

Содействие потребует навыков работы с Git

Прежде чем вносить свой вклад в опен-сорс проект, нужно понять основной процесс Git Pull request. Для понимания рабочего процесса Git возможно придется освоить инструкции Git или вот Git на русском. Но лучший способ изучения Git, это активная практика в реальном проекте.

Не будем отвлекаться сейчас на Git. Можно будет изучить его уже на практике. Пока же просто ищем проект.

Не недооценивайте свои писательские навыки

Можно подумать, что слишком рано думать о присоединении к проекту, не говоря уже о внесении вклада в проект документации API, особенно когда мы только учимся этому. Когда мы взаимодействуем с командой разработки опен-сорс проекта, можно чувствовать страх, что нет навыков программирования. Однако не стоит недооценивать нашу роль в качестве автора документации (независимо от вклада). Проекты с открытым исходным кодом частенько сильно страдают от паршивой документации.

Неполная или устаревшая документация является распространенной проблемой, наблюдаемой 93 процентами респондентов, однако 60 процентов участников говорят, что они редко или никогда не вносят свой вклад в документацию.

Также посмотрим Open source documentation is bad, but proprietary software is worse Мэтта Асаи. Мэтт выделяет результаты документации того же опроса GitHub:

93% респондентов скрежетали зубами от некачественной документации, но также признались, что практически ничего не сделали для улучшения ситуации. … Если вы считаете, что глубокая потребность в документации побудит большее количество разработчиков внести свою лепту и помочь, вы ошибаетесь: 60% разработчиков не могут потрудиться представить документацию.

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

Автору курса хорошо знакомо значение роли документации из его личного опыта написания документации для опен-сорс проектов. В какой-то момент, прежде чем сосредоточить свою энергию на этом курсе по API, он написал несколько руководств для документации по Jekyll. Том Джонсон добавил инструкции, которые включали много нового контента, и даже добавил раздел Tutorials.

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

Поэтому нужно быть уверенным в ценности, которую мы можем внести в опен-сорс проект. Мы создаем необходимую документацию для проекта.

Дополнительное чтение

Дополнительные материалы к изучению:

Справочник по GitHub Pull Request доступен в разделе Процесс Pull request на GitHub

Русские Блоги

Навыки расширенного поиска на Github для программистов

Нажмите выше " Школа программирования ", выберите как" Установить звезду ”

Качественные изделия с доставкой немедленно!

Автор: Juefei

juejin.im/post/5e3d01c56fb9a07c91100801

У многих мелких партнеров часто возникает такая путаница. Я прочитал много технических учебных документов, книг и даже видео. Я хочу попрактиковаться, поэтому я открыл GitHub и хотел найти проект с открытым исходным кодом, чтобы изучить и получить практический опыт в этом проекте. . В это время многие мелкие партнеры столкнутся с проблемой: «Я не могу искать, как мне это найти?», И в конце концов сможет только сдаться.

Я считаю, что прочитав эту статью, вы сможете узнать, как точно искать проекты на GitHub.

Компонент проекта с открытым исходным кодом

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

name: название проекта

description: краткое описание проекта

Исходный код проекта

README.md: Знакомство с деталями проекта

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

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

Как искать

Так как же искать?

Предположим, мы хотим найти React сейчас, я считаю, что большинство мелких партнеров напрямую вводят в поле поиска: «React», а затем нажимают Enter, вы обнаружите, что ситуация выглядит следующим образом:

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

в соответствии с name искать

Найдите проекты, которые содержат React в названии проекта:

Получите следующие результаты:

Как видите, все эти результаты поиска — это проекты с ключевым словом React в названии проекта, но проектов по-прежнему много.

Теперь давайте ограничим

Например, я могу точно указать звездное число проекта больше 5000+:

Результаты поиска становятся более точными мгновенно, и теперь на выбор доступно всего 114 элементов. Конечно, мы обычно не устанавливаем количество звезд так высоко, как правило, установка 1000 почти такая же.

Читать:

Как загрузить несколько детальных картинок в битрикс

Таким же образом мы можем искать по количеству вилок:

Вы обнаружите, что результаты становятся все более точными!

в соответствии с README Искать

Найдите в README.md проекты, содержащие React:

Результатов так много, поэтому давайте ограничим количество звездочек и вилок:

Результаты поиска были точными сразу до 90. В этот раз вы перейдете к выбору проекта, это станет намного проще.

в соответствии с descriptin искать

Предположим, теперь мы хотим узнать о проектах микросервисов, мы ищем проекты, которые содержат микросервисы в описании проекта:

Результатов так много, что мы добавим несколько условий фильтрации:

language: python означает, что мы ограничиваем язык питоном, посмотрим, как это получится:

Результаты поиска намного точнее.

Если в этих проектах мы хотим найти проекты, которые были обновлены недавно, то есть время обновления является самым последним, мы можем сделать это:

нажата:> 2020-01-01 означает, что мы ограничили время последнего обновления проекта до 2020-01-01, давайте посмотрим, каков результат:

Результатов поиска всего 8, и эти проекты относятся к наиболее активным, так что меня больше не запутает.

подводить итоги

Ладно, подведем итоги. Мы хотим вести точный поиск, не более чем добавление условий фильтрации.

in: name xxx // поиск по названию проекта

in: readme xxx // поиск по README

in: description xxx // поиск по описанию

Итак, здесь мы можем добавить условия фильтрации

stars:> xxx // количество звезд больше, чем xxx

forks:> 3000 // Количество вилок больше xxx

language: xxx // язык программирования xxx

нажато:> ГГГГ-ММ-ДД // Время последнего обновления больше, чем ГГГГ-ММ-ДД

Выше приведены несколько советов по точному поиску проектов на GitHub, надеюсь, это поможет вам!

Интеллектуальная рекомендация

Реализация JavaScript Hashtable

причина Недавно я смотрю на «Структуру данных и алгоритм — JavaScript», затем перейдите в NPMJS.ORG для поиска, я хочу найти подходящую ссылку на библиотеку и записывать его, я могу исполь.

MySQL общие операции

jdbc Транзакция: транзакция, truncate SQL заявление Transaction 100 000 хранимая процедура mysql msyql> -определить новый терминатор,Пробелов нет mysql>delimiter // mysql> -создание хранимой .

Используйте Ansible для установки и развертывания TiDB

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

Последняя версия в 2019 году: использование nvm под Windows для переключения между несколькими версиями Node.js.

С использованием различных интерфейсных сред вы можете переключаться между разными версиями в любое время для разработки. Например, развитие 2018 года основано наNode.js 7x версия разработана. Тебе эт.

Шаблон проектирования — Создать тип — Заводской шаблон

Заводская модель фабрикиPattern Решать проблему: Решен вопрос, какой интерфейс использовать принципСоздайте интерфейс объекта, класс фабрики которого реализуется его подклассом, чтобы процесс создания.

Поиск по GitHub: как найти репозитории, нужный код или разработчика?

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

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

Поиск кода или разработчика по GitHub

Искать разработчика или нужный код можно разными путями. Например , разработчиков можно искать на специализированных сайтах по поиску работы, таких как hh.ru. Когда нужен код, можно воспользоваться специальным форумом или попросить помощи у других программистов. Но и в том и в другом случае очень правильно будет вести поиск по GitHub, ведь это один их тех ресурсов, где сконцентрированы лучшие программистские умы.

Поиск кода или репозитория по GitHub

in:name — поиск по имени репозитория, то есть искомые слова буд у т искаться в наименовании репозиториев;
in:description — поиск по описанию репозит о ри я н а совпадение указанных слов поиска именно в описании;
in:readme — поиск по файлам README;
repo:owner/name — поиск по точному совпадению имени репозитория.

по размеру репозитория;
по количеству подписчиков;
по количеству вилок;
по количеству звезд;
по дате создания;
по дате последнего обновления;
по используемому языку программирования;
по теме;
по количеству тем;
по лицензии;
по видимости репозитория;
по наличию проблем с репозиторием;
по возможности оказать спонсорскую помощь;
и др.

Поиск разработчиков по GitHub

Поиск по ключевым словам. К примеру, если вам необходим python-разработчик, то введите в поиске слово «python».
Поиск по языкам программирования, которым и должен обладать искомый разработчик. Введите в поисковой строке любой язык программирования , и GitHub выдаст вам результат.
П оиск по технологиям. Работает так же, как и с языками программирования : просто введите название необходимого фреймворка, который не является самостоятельным языком программирования.
Искать по активности программиста. Обычно этот вид поиска осуществляют, когда уже нашли список потенциальных кандидатов, допустим , по языку программировани я . Далее в качестве фильтра можно отсеять тех, кто давно не проявлял активность на GitHub.

Заключение

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

С поиском кода вроде все ясно, поэтому сложностей возникнуть не должно. Тем более раз вы ищите код, то вы в не м к ак миниму м р азбираетесь. Сложнее с поиском разработчиков, потому что на GitHub очень много «пустышек», которые просто будут отнимать у вас время.

Мы будем очень благодарны

если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.

Хочу контрибьютить в опенсорс: с чего начать и как искать проекты на GitHub

Разработчица Вики Коблински поделилась в блоге рекомендациями, как начать участвовать в проектах с открытым исходным кодом. Не все решаются начать делать это, например, из-за лени или потому что большинство крупных опенсорс-проектов имеют крутые кривые обучаемости и попросту могут оттолкнуть новичка.

Основная цель открытого исходного кода — создать доступное и ценное программное обеспечение (ПО), с которым сможет работать каждый. Разработчики могут найти множество личных выгод от участия в подобных проектах. Например, отточить технические навыки, развить навыки межличностного общения и попрактиковаться в предоставлении и получении обратной связи.

Изучите культуру опенсорс-проектов

Вы решили, что хотите стать участником такого проекта, но не уверены, что у вас достаточно знаний. Вики Коблински заметила, что у успешных проектов с открытым исходным кодом — самые дружелюбные сопровождающие и сообщества. Они полны энтузиазма и активно привлекают новичков. Часто такие сообщества активны в Twitter, Slack, Discord или на другой платформе, к которой может присоединиться любой желающий и напрямую поговорить с сопровождающими проекта.

Многие крупные сообщества с открытым исходным кодом имеют собственные принципы и правила, одно из главных среди них — «не быть придурком». В целом же новичков в проект принимают очень радушно.

Найдите подходящую площадку

Один из лучших способов найти подходящий проект — посмотреть на ПО с открытым исходным кодом, которое вы уже используете. Отличными кандидатами могут быть инструменты, пакеты, фреймворки или языки, с которыми вы регулярно работаете. Чтобы узнать, является ли проект открытым, важно:

Проверить его лицензию;
Убедиться, что проект активно поддерживается;
Узнать, закрываются ли в нем пул-реквесты;
Дают ли сопровождающие обратную связь.

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

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

Внесите первый вклад

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

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

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

Как только будете уверены, что решили проблему, отправляйте пул-реквест. Найдите в проекте файл «CONTRIBUTORS.md». В нем содержится инструкция о том, как правильно отправлять пул-реквест, также на GitHub есть чек-лист с рекомендациями. Обязательно сделайте обратную ссылку на исходный тикет. Сопровождающий может запросить изменения или обсудить их перед тем, как пул-реквест будет принят, — это нормально.

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