2014年11月30日 星期日

不關心政治的懲罰,就是被糟糕的人統治-柏拉圖

        得知選舉結果後,內心很激動.台灣真的能不靠抹黑和樁腳固票來取得人民的支持與認同(一方面也是對方太差啦).

        這次選舉很不一樣,過去大家都說政治很黑暗,不要碰,自己也對這種鬧劇或只是權貴集團的遊戲沒什麼興趣,但這次身邊很多認識的人都投入了選戰之中,無論是幫忙的義工,或是本身就是參與者.第一次有哪麼多出身背景相似(就是沒什麼背景)的人,投入到政治之中,的確認政治離我們更近了一點,有機會看到那一點共同的未來.很高興大家的熱情與付出都有了結果,雖仍有不完滿,但也大大超出了我們自己原本的想像.

        民主政治不需要神人,而是需要公民的共同參與,除了手上那張選票之外,平日的監督更是必要,只有親自參與政治,才有機會創造自己的未來.

        最後廣告一下,公民除了有選舉權之外,也有罷免權,但是台灣罷免的條件反比選上難難難上許多,有興趣的人可以看看目前最大的O2O遊戲網站Appendectomy Project 割闌尾計畫,找回公民應有的權力.


2014年11月28日 星期五

Step by Step 使用github參與專案流程(下)- ISSUE,PR,and CI


        當我們把修改後的檔案push上之後,就可以對原始的來源發PR(Pull Request).但是在發PR之前,先回過頭來說一下要從哪邊開始參與專案.參與專案通常可以分成幾種狀況,一種是自己發起,二是別人發起但是你是主要的參與者,三是周邊的參與者.如果你是前兩種狀況,那麼對於專案本身都會比較了解,知道要開發什麼功能,或是要改什麼東西.但是如果是周邊的參與者,通常不太可能一開始就跳下去做什麼重大的功能開發,而是從一些例如bug或是小功能著手.

2014年11月23日 星期日

Step by Step 使用github參與專案流程(上)- fork, clone, and sync


        封面這隻章魚貓大家應該都不陌生,就是coding界的facebook--github的代表圖案.Github相關教學網路上已經很多了(最近最推薦這篇:連猴子都學得會的github),所以我就不再多介紹一些基本功能,而是從實戰角度來看如何透過github來參與線上專案.以下都拿我所參與的專案為例,這是一個源自於Google Cloud的開發專案,貢獻的規範相對嚴謹,可以學到很多管理或是參與專案的技巧.

2014年11月22日 星期六

[R] 當Text Mining專案完成度達到99%之後...


       先前接下了一個號稱完成度99%的專案,只剩下一個小bug解決好就可以上線...故事由真人真事改編.故事背景是有個利用R來做text mining(文本分析)的專案要上線,這個專案使用了tm package和segmentCN兩個標準的配備(可以參考:[R] TEXT MINING(文字探勘、文本分析練習)).原本剩下這1%的問題在於開發環境和上線環境不同,導致結果的不一致.這個問題在當初我就有寫篇專文[R] tm package version 0.6 大解析(text mining文字探勘套件)來處理這個問題(使用了非常瑣碎的爛方法...有更好的方法請跟我說Orz).今天的故事是從這邊接下去開始...

2014年11月20日 星期四

[Apache Spark][基本架構] RDD特性(一)

        
        
        萬丈高樓平地起,要熟悉Spark就得熟悉RDD,要熟悉RDD,就是要看Doc.延續著上一篇:[Spark][基本架構] 關於RDD中的不可變性(immutable),說到當我們對RDD做運算時,其實都會產生不同的RDD.RDD的官方文件(http://spark.apache.org/docs/latest/api/scala/index.html#org.apache.spark.rdd.RDD)一開始說到這些不同的RDD都共同擁有五個特性:

2014年11月18日 星期二

[Apache Spark][教學] 不要隨便Collect RDD!


        先講結論:如果你的RDD很大,千萬不要隨便Collect.原文出處為http://databricks.gitbooks.io/databricks-spark-knowledge-base/content/best_practices/dont_call_collect_on_a_very_large_rdd.html.只說Collect會將所有元素複製到單一台機器上,但是沒說清楚為什麼會發生這種現象.

[Apache Spark][基本架構] 關於RDD中的不可變性(immutable)


        剛開始接觸RDD時,會覺得RDD是一個裝資料的貨櫃(Container).再多瞭解一點後,才發現RDD更像裝洋片的太空包對不起我肚子餓了).貨櫃和太空包的差異在於:貨櫃可以裝不同的東西,把東西拿出來再擺回去,但是當洋芋片裝到太空包後,如果要吃或分裝,就得把太空包拆開.

[Apache Spark][開發] 避免使用GroupByKey


        雖然spark速度很快,但是沒有好好tuning還是沒辦法發揮它應該有的速度.避免使用GroupByKey牽涉到Spark底層處理資料時的方式.原始的文章和圖片皆來自Avoid GroupByKey,只有改成自己的範例.

[Scala][Spark] 型態抹除(it is eliminated by erasure)

        之前python玩習慣了,在定義function的輸入變項時,不用特別去注意輸入變項是什麼型態,反正不管什麼型態的變項丟進來,python都會去執行程式,直到出現錯誤才會跳出.但是在scala這樣強型態的語言中,程式會在編譯階段就先定義輸入與輸出變項的型態,如果出現型態錯誤就無法繼續編譯.這樣的差異讓我在設計第一個總和的function就撞牆了.

2014年11月15日 星期六

[Scala][教學] Call by Name or Call By Value?

        今天再看scala的教學課程看到的小觀念,記錄下來怕以後搞混。Scala再讀入參數的時候有兩種方式,預設是call by value,但是也可以改成call by name。兩者的差異在於:

Call by Value(default,透過x: Int的方式設定):呼叫函數的時候一併將值讀入。
Call by Name(透過x: => Int的方式設定):當函式碰到值的時候才去取值。

2014年11月13日 星期四

商業力 X 分析力 X 技術力 = 資料科學家三元素


        資料科學家是近幾年出現的名詞(但是實際上已經存在於好幾百年),像是這篇“搶佔2013全球最性感行業”,以及曾經寫過的“資料科學家 vs 資料工程師“,甚至很誇張的”美企業搶資料科學家,兩年資歷年薪上看30萬美元“,讓很多人對資料科學家抱持的不同的幻想,在一般介紹資料科學的投影片中,最常出現的是下面這張圖:

2014年11月9日 星期日

[Apache Spark][教學] 應用IDEA以及Scala於Spark程式開發(圖多)


        俗話說,工欲善其事,必先利其器,對於程式開發者來說,有個好的IDE介面絕對能大幅增加開發速度以及減少不必要的錯誤.先前在玩Spark的時候([Spark] 建立第一個RDD物件,體驗in Memory Computing的威力)是使用python,自然就是以Ipython notebook為首選,可以很方便的測試和操作RDD物件.但是因為Spark的原生語言其實是Scala,python在一些功能的支援上目前還趕不上Scala,所以目前選擇Scala作為開發Spark的主要工具.

2014年11月4日 星期二

[Algorithm] Stochastic gradient descent(梯度下降法)作為Online Learning Model(即時訓練模型)(二)


        昨天最後我們停在Cost Function,再複習一下他的樣子:
θ為迴歸係數,要求得θ的最小值,也就是求上述Cost Function的最小值,統計上的做法就是直接將上述式子對每個係數做偏微分=0就可以計算出θ.這個方法完全沒錯,但是今天我要介紹的SGD是另外一種概念.

[Algorithm] Stochastic gradient descent(梯度下降法)作為Online Learning Model(即時訓練模型)(一)


        因為數學不好,所以網誌成立以來一直沒有碰觸演算法相關的議題,但是隨著要分析的對象越來越複雜,可用變項指數成長,建模的時間也呈倍數縮短的情況下,還是要回到分析的根本--也就是數學模型來尋找突破的方法,所以開始認真的研讀演算法,這也是給予自己未來的目標,希望更深入的去了解常用的演算法.