# Github連擊 [TOC=2,3] ## 100天 我也是蠻拼的，雖然我想的只是在Github上連擊100~200天，然而到了今天也算不錯。  Longest Streak `在停地造輪子的過程中，也不停地造車子。` 在那篇連續沖擊365天的文章出現之前，我們公司的大大([https://github.com/dreamhead](https://github.com/dreamhead))也曾經在公司內部說過，天天commit什么的。當然這不是我的動力，在連擊140天之前 - 給過google的`ngx_speed`、`node-coap`等項目創建過pull request - 也有`free-programming-books`、`free-programming-books-zh_CN`這樣的項目。 - 當然還有一個連擊20天。 對比了一下365天連擊的commit，我發現我在total上整整多了近0.5倍。  365 Streak 同時這似乎也意味著，我每天的commit數與之相比多了很多。 在連擊20的時候，有這樣的問題: *為了commit而commit代碼*，最后就放棄了。 而現在是`為了填坑而commit`，為自己挖了太多的想法。 ### 40天的提升 當時我需要去印度接受畢業生培訓，大概有5周左右，想著總不能空手而歸。于是在國慶結束后有了第一次commit，當時旅游歸來，想著自己在不同的地方有不同的照片，于是這個repo的名字是 [onmap](https://github.com/phodal/onmap)——將自己的照片顯示在地圖上的拍攝地點(手機是Lumia 920)。然而，中間因為修改賬號的原因，丟失了commit。 再從印度說起，當時主要維護三個repo: - 物聯網的CoAP協議 - [一步步設計物聯網系統](https://github.com/phodal/designiot)的電子書 - 一個Node.js + JS的網站 說說最后一個，最后一個是練習的項目。因為當時培訓比較無聊，業余時間比較多，英語不好，加上聽不懂印度人的話。晚上基本上是在住的地方默默地寫代碼，所以當時的目標有這么幾個: - TDD - 測試覆蓋率 - 代碼整潔 這也就是為什么那個repo有這樣的一行:  Repo Status 做到98%的覆蓋率也算蠻拼的，當然還有Code Climate也達到了4.0，也有了112個commits。因此也帶來了一些提高: - 提高了代碼的質量(code climate比jslint更注重重復代碼等等一些bad smell)。 - 對于Mock、Stub、FakesServer等用法有更好的掌握 - 可以持續地交付軟件(版本管理、自動測試、CI、部署等等) ### 100天的挑戰 (ps:從印度回來之后，由于女朋友在泰國實習，有了更多的時間可以看書、寫代碼) 有意思的是越到中間的一些時間，commits的次數上去了，除了一些簡單的pull request，還有一些新的輪子出現了。  Problem 這是上一星期的commits，這也就意味著，在一星期里面，我需要在8個repo里切換。而現在我又有了一個新的idea，這時就發現了一堆的問題: - 今天工作在這個repo上，突然發現那個repo上有issue，需要去修復，于是就放下了當前的代碼。 - 在不同的repo間切換容易分散精力 - 很容易就發現有太多的功能可以實現，但是時間是有限的。 - 沒有足夠的空閑時間，除了周末。 - 希望去尋找那些有興趣的人，然而卻發現原來沒有那么多時間去找人。 ### 140天的希冀 在經歷了100天之后，似乎整個人都輕松了，畢竟目標是100~200天。似乎到現在，也不會有什么特殊的情懷，除了一些希冀。 當然，對于一個開源項目的作者來說，最好有下面的情況: - 很多人知道了這個項目 - 很多人用它的項目。 - 在某些可以用這個項目快速解決問題的地方提到了這個項目 - 提了bug、issue、問題。 - 提了bug，并解決了。(ps:這是最理想的情況) ## 200天的Showcase 今天是我連續泡在Github上的第200天，也是蠻高興的，終于到達了:  Github 200 days 故事的背影是: 去年國慶完后要去印度接受畢業生培訓——就是那個神奇的國度。但是在去之前已經在項目待了九個多月，項目上的挑戰越來越少，在印度的時間又算是比較多。便給自己設定了一個長期的goal，即100~200天的longest streak。 或許之前你看到過一篇文章[讓我們連擊](https://github.com/phodal/github-roam/blob/master/chapters/12-streak-your-github.md)，那時已然140天，只是還是渾渾噩噩。到了今天，漸漸有了一個更清晰地思路。 先讓我們來一下ShowCase，然后再然后，下一篇我們再繼續。 ### 一些項目簡述 上面說到的培訓一開始是用Java寫的一個網站，有自動測試、CI、CD等等。由于是內部組隊培訓，代碼不能公開等等因素，加之做得無聊。順手，拿Node.js +RESTify 做了Server，Backbone + RequireJS + jQuery 做了前臺的邏輯。于是在那個日子里，也在維護一些舊的repo，如[iot-coap](https://github.com/phodal/iot-coap)、[iot](https://github.com/phodal/iot)，前者是我拿到WebStorm開源License的Repo，后者則是畢業設計。 對于這樣一個項目也需要有測試、自動化測試、CI等等。CI用的是Travics-CI。總體的技術構架如下: #### 技術棧 前臺: - Backbone - RequireJS - Underscore - Mustache - Pure CSS 后臺: - RESTify 測試: - Jasmine - Chai - Sinon - Mocha - Jasmine-jQuery 一直寫到五星期的培訓結束， 只是沒有自動部署。想想就覺得可以用github-page的項目多好~~。 過程中還有一些有意思的小項目，如: ### google map solr polygon 搜索 [google map solr polygon 搜索](http://www.phodal.com/blog/google-map-width-solr-use-polygon-search/)  google map solr 代碼: [https://github.com/phodal/gmap-solr](https://github.com/phodal/gmap-solr) ### 技能樹 這個可以從兩部分說起: #### 重構Skill Tree 原來的是 - Knockout - RequireJS - jQuery - Gulp  Skill Tree 代碼: [https://github.com/phodal/skillock](https://github.com/phodal/skillock) #### 技能樹Sherlock - D3.js - Dagre-D3.js - jquery.tooltipster.js - jQuery - Lettuce - Knockout.js - Require.js  Sherlock skill tree 代碼: [https://github.com/phodal/sherlock](https://github.com/phodal/sherlock) #### Django Ionic ElasticSearch 地圖搜索  Django Elastic Search - ElasticSearch - Django - Ionic - OpenLayers 3 代碼: [https://github.com/phodal/django-elasticsearch](https://github.com/phodal/django-elasticsearch) #### 簡歷生成器  Resume - React - jsPDF - jQuery - RequireJS - Showdown 代碼: [https://github.com/phodal/resume](https://github.com/phodal/resume) #### Nginx 大數據學習  Nginx Pig - ElasticSearch - Hadoop - Pig 代碼: [https://github.com/phodal/learning-data/tree/master/nginx](https://github.com/phodal/learning-data/tree/master/nginx) #### 其他 雖然技術棧上主要集中在Python、JavaScript，當然還有一些Ruby、Pig、Shell、Java的代碼，只是我還是習慣用Python和JavaScript。一些用到覺得不錯的框架: - Ionic: 開始Hybird移動應用。 - Django: Python Web開發利器。 - Flask: Python Web開發小刀。 - RequireJS: 管理js依賴。 - Backbone: Model + View + Router。 - Angluar: …。 - Knockout: MVV*。 - React: 據說會火。 - Cordova: Hybird應用基礎。 還應該有: - ElasticSearch - Solr - Hadoop - Pig - MongoDB - Redis ## 365天 給你一年的時間，你會怎樣去提高你的水平？？？  Github 365 正值這難得的sick leave（萬惡的空氣），碼文一篇來記念一個過去的366天里。盡管想的是在今年里寫一個可持續的開源框架，但是到底這依賴于一個好的idea。在我的[Github 孵化器](http://github.com/phodal/ideas) 頁面上似乎也沒有一個特別讓我滿意的想法，雖然上面有各種不樣有意思的ideas。多數都是在過去的一年是完成的，然而有一些也是還沒有做到的。 盡管一直在Github上連擊看上去似乎是沒有多大必要的，但是人總得有點追求。如果正是漫無目的，卻又想著提高技術的同時，為什么不去試試？畢竟技術非常好、不需要太多練習的人只是少數，似乎這樣的人是不存在的。大多數的人都是經過練習之后，才會達到別人口中的“技術好”。 這讓我想起了充斥著各種氣味的知乎上的一些問題，在一些智商被完虐的話題里，無一不是因為那些人學得比別人早——哪來的天才？所謂的天才，應該是未來的智能生命一般，一出生什么都知道。如果并非如此，那只是說明他練習到位了。 練習不到位便意味著，即使你練習的時候是一萬小時的兩倍，那也是無濟于事的。如果你學得比別人晚，在**很長的一段時間里**(可能直到進棺材)輸給別人是必然的——落后就要挨打。就好像我等畢業于一所二本墊底的學校里，如果在過去我一直保持著和別人(各種重點)一樣的學習速度，那么我只能一直是Loser。 需要注意的是，對你來說考上二本很難，并不是因為你比別人笨。教育資源分配不均的問題，在某種程度上導致了新的階級制度的出現。如[我的首頁](https://www.phodal.com/)說的那樣: **THE ONLY FAIR IS NOT FAIR**——唯一公平的是它是不公平的。我們可以做的還有很多——**CREATE & SHARE**。真正的不幸是，因為營養不良導致的教育問題。 于是在想明白了很多事的時候起，便有了Re-Practise這樣的計劃，而365天只是中間的一個產物。 ### 編程的基礎能力 雖說算法很重要，但是編碼才是基礎能力。算法與編程在某種程度上是不同的領域，算法編程是在編程上面的一級。算法寫得再好，如果別人很難直接拿來復用，在別人眼里就是shit。想出能work的代碼一件簡單的事，學會對其重構，使之變得更易讀就是一件有意義的事。 于是，在某一時刻在Github上創建了一個組織，叫[Artisan Stack](https://github.com/artisanstack)。當時想的是在Github尋找一些JavaScript項目，對其代碼進行重構。但是到底是影響力不夠哈，參與的人數比較少。 #### 重構 如果你懂得如何寫出高可讀的代碼，那么我想你是不需要這個的，但是這意味著你花了更多的時候在思考上了。當談論重構的時候，讓我想起了TDD(測試驅動開發)。即使不是TDD，那么如果你寫著測試，那也是可以重構的。(之前寫過一些利用Intellij IDEA重構的文章：[提煉函數](https://www.phodal.com/blog/intellij-idea-refactor-extract-method/)、[以查詢取代臨時變量](https://www.phodal.com/blog/intellij-idea-refactor-replace-temp-with-query/)、[重構與Intellij Idea初探](https://www.phodal.com/blog/thoughtworks-refactor-and-intellij-idea/)、[內聯函數](https://www.phodal.com/blog/intellij-idea-refactor-inline-method/)) 在各種各樣的文章里，我們看到過一些相關的內容，最好的參考莫過于《重構》一書。最基礎不過的原則便是函數名，取名字很難，取別人能讀懂的名字更難。其他的便有諸如長函數、過大的類、重復代碼等等。在我有限的面試別人的經歷里，這些問題都是最常見的。 #### 測試 而如果沒有測試，其他都是扯淡。寫好測試很難，寫個測試算是一件容易的事。只是有些容易我們會為了測試而測試。 在我寫[EchoesWorks](https://github.com/echoesworks/echoesworks)和[Lan](https://github.com/phodal/lan)的過程中，我盡量去保證足夠高的測試覆蓋率。  lan  EchoesWorks 從測試開始的TDD，會保證方法是可測的。從功能到測試則可以提供工作次效率，但是只會讓測試成為測試，而不是代碼的一部分。 測試是代碼的最后一公里。所以，盡可能的為你的Github上的項目添加測試。 #### 編碼的過程 初到TW時，Pair時候總會有人教我如何開始編碼，這應該也是一項基礎的能力。結合日常，重新演繹一下這個過程： 1. 有一個可衡量、可實現、過程可測的目標 1. Tasking (即對要實現的目標過程進行分解) 1. 一步步實現 (如TDD) 1. 實現目標 放到當前的場景就是： 1. 我想在Github上連擊365天。對應于每一個時候段的目標都應該是可以衡量、測試的——即每天都會有Contributions。 1. 分解就是一個痛苦的過程。理想情況下，我們應該會有每天提交，但是這取決于你的repo的數量，如果沒有新的idea出現，那么這個就變成為了Contributions而Commit。 1. 一步步實現 在我們實際工作中也是如此，接到一個任務，然后分解，一步步完成。不過實現會稍微復雜一些，因為事務總會有搶占和優先級的。 ### 技術與框架設計 在上上一篇博客中《[After 500: 寫了第500篇博客，然后呢?](https://www.phodal.com/blog/after-500-blogposts-analytics-after-tech/)》也深刻地討論了下這個問題，技術向來都是后發者優勢。對于技術人員來說，也是如此，后發者占據很大的優勢。 如果我們只是單純地把我們的關注點僅僅放置于技術上，那么我們就不具有任何的優勢。而依賴于我們的編程經驗，我們可以在特定的時候創造一些框架。而架構的設計本身就是一件有意思的事，大抵是因為程序員都喜歡創造。(ps:之前曾經寫過這樣一篇文章，《[對不起，我并不熱愛編程，我只喜歡創造](https://www.phodal.com/blog/sorry-i-don't-like-programming/)》) **創造是一種知識的再掌握過程。** 回顧一下寫echoesworks的過程，一開始我需要的是一個網頁版的PPT，當然這類的東西已經有很多了，如impress.js、bespoke.js等等。分析一下所需要的功能：markdown解析器、鍵盤事件處理、Ajax、進度條顯示、圖片處理、Slide。我們可以在Github上找到各式各樣的模塊，我們所要做的就是將之結合在一樣。在那之前，我試著用類似的原理寫（組合）了[Lettuce](https://github.com/phodal/lettuce)。 組合相比于創造過程是一個更有挑戰性的過程，我們需要在這過程去設計膠水來粘合這些代碼，并在最終可以讓他工作。這好比是我們在平時接觸到的任務劃分，每個人負責相應的模塊，最后整合。 想似的我在寫[lan](https://github.com/phodal/lan)的時候，也是類似的，但是不同的是我已經設計了一個清晰的架構圖。  Lan IoT 而在我們實現的編碼過程也是如此，使用不同的框架，并且讓他們能工作。如早期玩的[moqi.mobi](https://github.com/echoesworks/moqi.mobi)，基于Backbone、RequireJS、Underscore、Mustache、Pure CSS。在隨后的時間里，用React替換了View層，就有了[backbone-react](https://github.com/phodal/backbone-react)的練習。 技術同人一樣，需要不斷地往高一級前進。我們只需要不斷地Re-Practise。 ### 領域與練習 說業務好像不太適合程序員的口味，那就領域吧。不同行業的人，如百度、阿里、騰訊，他們的領域核心是不一樣的。 而領域本身也是相似的，這可以解釋為什么互聯網公司都喜歡互相挖人，而一般都不會去華為、中興等非互聯網領域挖人。出了這個領域，你可能連個畢業生都不如。領域、業務同技術一樣是不斷強化知識的一個過程。Ritchie先實現了BCPL語言，而后設計了C語言，而BCPL語言一開始是基于CPL語言。 領域本身也在不斷進化。 這也是下一個值得提高的地方。 ### 其他 是時候寫這個小結了。從不會寫代碼，到寫代碼是從0到1的過程，但是要從1到60都不是一件容易的事。無論是刷Github也好(不要是自動提交)，或者是換工作也好，我們都在不斷地練習。 而練習是要分成不同的幾個步驟，不僅僅局限于技術： 1. 編碼 1. 架構 1. 設計 1. 。。。