因為要做一個Demo，資料來源GitHub上所有Star過20的專案。但是呢，GitHub唉！擁有千萬數量級別倉庫的大型基佬交友社群唉！符合條件的就有33萬條記錄唉！所以就想把這次開發經歷記錄一下。想做到的最終目標是10個爬蟲併發爬取專案；

爬蟲的程式碼就不發了，網上一搜一大把，使用python3，用到的包有json、bs4、urllib；

2017年9月14日11點38分

爬蟲開發記錄：
開發進度：完成getRepo部分的框架
所遇問題：
1）GitHub search api 只能提供前1000條可訪問記錄；
2）GitHub api 對訪問請求進行限制，對為驗證請求提供10times/min，對驗證請求提供30times/min；
解決方案：
1）I.縮小查詢範圍，可能存在的問題，導致倉庫結果無序；
2）I.使用Basic Authentication, OAuth, or client ID and secret等方法進行驗證，II.若使用併發爬蟲導致請求量過大將使用python迴圈list解決（II待驗證）

先記錄到這裡，下午對爬蟲進行修改，解決search api的請求限制問題。

2017年9月19日14點33分

爬蟲開發記錄：

對於search api的提供限制問題，通過對stars範圍進行切分，獲得一組結果值小於等於1000的url列表。

關於2）I，在url後面新增&access_token=……

所遇問題：

當爬取每個庫的stargazer時，會出現某一頁卡死，程式不會繼續向下run的情況；

2017年9月20日16點21分

所以目前針對以上提到的問題，我現在能想到的是使用多執行緒，差不多5~10個爬蟲進行資料爬取，來提高爬取效率以及實現爬蟲的超時重連。

2017年10月24日00點33分

關於之前的併發問題，發現如果直接使用scrapy爬倉庫，不對速度加以限制的話，很容易就會讓token“超速”，所以暫時還是老老實實的用自己嬰幼版爬蟲爬吧，等之後把scrapy吃透，可以自行定製的時候，可以用在beta版上；

在Linux不熟的時候遇到了一個很“神奇的”問題：“nohup command &”之後，退出遠端連線後，再次連線時會出現command掛掉的情況。解決方案是，輸入命令列之後，exit退出，而不是直接關閉連線。很神奇。感謝大佬

之後可以去嘗試使用screen，據說功能比nohup強大得多。