Кроме того, нам по сути похуй на поиск по коду, мы бы хотели искать по dependencies graph — т.е. нам нужно просто знать с какими фреймворками работал программист и вместо того, что бы искать и парсить каждый манифест файл, было бы неплохо просто иметь древовидный граф, на котором показано какой разраб что использовал
а зачем вообще поиск для этого - вроде все языки хранят зависимости в well-defined файле, а-ля packages.json dependencies.txt packages.config и т.д. т.е. вам надо забирать эти файлы и просто разбирать их. зачем поиск по GH вообще ?
СГ для такого сценария наверное не очень зайдет - вы же не будете выкачивать все репки с гитхаба... Если только сделать какие-то расширения, т.е. сг это тула для пользователя чтобы задекларировать в верифицируемом формате что вот я работал с такими стеками
а зачем вообще поиск для этого - вроде все языки хранят зависимости в well-defined файле, а-ля packages.json dependencies.txt packages.config и т.д. т.е. вам надо забирать эти файлы и просто разбирать их. зачем поиск по GH вообще ?
хмм, перечитал кусочек про манифест - мой вопрос неправильный =) А чем подход с манифестом не подошел ?
Потому что нам нужно найти на гитхабе другие манифест файлы в которых будет пересечение по фреймворкам — а отсюда и подходящих пользователей
Проблема в том, что сам рейт лимит на такой поиск у гитхаба очень низкий.... т.е. его достаочно для мвп, я нашел 200 разрабов готовых к найму, которые подходят по опыту для нас самих :)
хмм, перечитал кусочек про манифест - мой вопрос неправильный =) А чем подход с манифестом не подошел ?
Вот если бы все указания о зависимостях хранились не только в манифест файле, но еще в каком нибудь графе (т.е. буквально депенденси граф), то мы сможем искать по нему, а не по коду в целом
Потому что нам нужно найти на гитхабе другие манифест файлы в которых будет пересечение по фреймворкам — а отсюда и подходящих пользователей
Проблема в том, что сам рейт лимит на такой поиск у гитхаба очень низкий.... т.е. его достаочно для мвп, я нашел 200 разрабов готовых к найму, которые подходят по опыту для нас самих :)
но все же это эффективность поиска всего 10%
идея технически интересная (бизнес аспекты этого - отдельный вопрос), но почему бы вам не сделать копии этих файлов и накапливать их в вашей системе и составить такие профили проектов ну и "трекать" их лениво в режиме раз в день\неделю забрать статсы ? стеки проектов радикально не меняются (ну или это тогда другая репка обычно, v2) - это можно использовать.
идея технически интересная (бизнес аспекты этого - отдельный вопрос), но почему бы вам не сделать копии этих файлов и накапливать их в вашей системе и составить такие профили проектов ну и "трекать" их лениво в режиме раз в день\неделю забрать статсы ? стеки проектов радикально не меняются (ну или это тогда другая репка обычно, v2) - это можно использовать.
сейчас пока в кеше храним и можем писать в свою базу, но ето заплатка
в том смысле, что на графе мы сможем делать прыжки вместо того, что бы перебирать все таблицы такой поиск будет ощутимо быстрее
зачем перебирать таблицы , таблицы не нужны, можно хранить все в graph database или делать различные срезы данных и проекции в удобные базы\структуры для определенных задач, потом выкидывать их
Если хотите ускорить поиск - можно сделать блум фильтр и пофильтровать, отсеяв большинство запросов, которые вернут пустой результат (вообще не искать с сразу сказать - вы хотите "10x unicorn, вы никого не найдете с такими параметрами") а дальше уже построить какую либо систему для каскадного сужения поиска (если это ключевая проблема).