誤刪 npmrc 解決方法之一

今天腦殘，把 npmrc 的內容全砍光，因為我發現有個 private registry 還是連到前公司，但是 server 是掛掉的狀態，所以就...，因為每次 npm i  都有 error log，一定得把那個 private registry 移出我的 rpmrc，一個快速，dd指令立刻存檔，就掰了...

so，搶救 npmrc 的內容，主要是有個 //registry.npmjs.org/:_authToken=XX 這個 token 要補回來。(我都不知道幾百年沒登入 npm 了，就算到登入後到 https://www.npmjs.com/settings/tokens 頁面，也是看不到 token)

其實 token 只要下 npm login，重新利用 cli 登入 npm 就行，他會自己幫你把 npmrc 的  token 補回來。

npm login 需要補登帳號, 密碼, 以及 email，所以要記得你當初註冊 npm 的資訊，忘記的話就要找回密碼了。

Android 的 SharedPreferences 學習筆記

Android 的 SharedPreferences 是一種提供 App 儲存少量資料的物件。要使用 SharedPreferences 需要 import android.content.SharedPreferences;

SharedPreferences 是用 Key, Value 的方式組成，就像我們在使用 NoSQL 一樣，key 就是鍵名，value 就是值，下面介紹增修刪讀一個 SharedPreferences 的方式 (其實就只是參考官方文件)。

建立 SharedPreferences 物件

在一個 APP 使用 SharedPreferences 儲存資料，首先要先建立起 SharedPreferences 的物件:

getSharedPreferences 變數名稱  = getSharedPreferences(String name, int MODE);

// Example 建立名為 pref 的 SharedPreferences 物件
SharedPreferences pref = getSharedPreferences("dialogAppFile", MODE_PRIVATE);

getSharedPreferences 有兩個參數，getSharedPreferences(String name, int MODE);

第一個參數  name 型別為 String，表示檔名，SharedPreferences 會去找符合檔名的 ShredPreferences，假如檔名不存在，那麼他會當你在使用 editor (SharedPreferences.edit()) 而且 commit (意思就是送出更新或是建立 key 值) 的時候建立。

因為 SharedPreferences 是 XML 檔的格式，所以只需要帶入檔名，副檔名就不需要了。

附帶一提，這裏的 Editor 是指 SharedPreferences 的 Editor 物件，要先拿到這個物件，才能寫入資料到 ShredPreferences，下面在 "寫入資料到SharedPreferences" 地方會再提到，只要先知道如果檔案不存在，它也會在操作 commit 時建立。

第二個參數雖然是 int 型別，但是值是預設的幾種常數在使用， 這裏的 MODE 指的是 operation mode，設定這個檔案的存取權限的意思，預設會是 MODE_PRIVATE (真正儲存的值是 0)。

幾種 MODE:
* MODE_PRIVATE: 只有自己這隻 APP(應用程式) 才能存取。
* MODE_WORLD_READABLE: 所有應用程式都可以讀取。(這個常數會在 API level 17 被棄用 This constant was deprecated in API level 17.)
* MODE_WORLD_WRITEABLE: 所有應用程式都可以寫入。(這個常數會在 API level 17 被棄用 This constant was deprecated in API level 17.)

所以，通常我建立的 key 值可能只跟我正在開發的 APP 有關，就可以使用 MODE_PRIVATE，也就是只有該應用程式才可以存取。


讀取/寫入資料到 SharedPreferences

假如你正在開發一支手機遊戲，你可以會希望記錄使用者目前玩到的關卡到  SharedPreferences 裡面，所以當 user 開啟 APP 時，我們會從 SharedPreferences 拿出他上一次的紀錄，當然當使用者玩到升級的時候，也就要更新 SharedPreferences 的關卡紀錄，所以，關卡紀錄就是一個 key，儲存的是當下的關卡等級。

由這段描述，先去思考怎麼拿 key 值出來。讀取資料比寫入, 移除還要容易一點，因為寫入移除資料還需要額外呼叫 Editor 物件，讀! ，只要有建立 SharedPreferences 物件，直接使用 getkey的資料型別(key值, 預設值) 就行！

假設我當初存在 SharedPreferences 的關卡等級型別是 String，key 是 gameLevel，那麼拿取 gameLevel 的方法會像:

SharedPreferences pref = getSharedPreferences("dialogAppFile", MODE_PRIVATE);
String gameLevel = pref.getString("gameLevel", "no value");

因為 gameLevel 的型別是 String，所以要用  getString(...)，假如今天存的是 int，就會是 getInt(...)，所以這邊的 get 有很多種 case，端看當初進去的型別是什麼。

ex: getBoolean, getFloat, getInt, getLong, getString....

第二個參數我帶入 no value，表示沒有取得到 gameLevel 這個 key 的值的話，預設回傳值就是 no value。


再來介紹寫入
寫入，寫入資料到 SharedPreferences 需要額外建立 Editor 物件:

Editor 變數名稱 = SharedPreferences 物件名稱 .edit();

SharedPreferences pref = getSharedPreferences("dialogAppFile", MODE_PRIVATE);
SharedPreferences.Editor editor =  pref.edit();

上面這一段，建立 Editor 物件並儲存在名為 editor 的變數。

用建立好的 editor，呼叫 putkey的資料型別(key值, 值)，你可以一次 put 好幾組想要儲存的 key，但是 put 只是建立 key，並沒有真的儲存的動作，真正的儲存還要呼叫 commit()。

假如我要建立 username, nickname 的 key:

// put 只是寫入，並沒有真的儲存
editor.putString("username", "win wu");
editor.putString("nickname", "小win");
/*  要呼叫commit 才是真的儲存，在這邊 commit，會一次儲存前面的put  也就是 username, nickname 都會在 commit 的時候儲存  */
editor.commit();

然後要把 username 拿出來就用 getString(...):

String username = pref.getString("username", "no name");
// log 出 username 的值
Log.d("WINWU_APP_LOG", username);

假如，一直針對同一個 key 做 put，就會蓋掉舊的 (前提是記得 commit)。其實 put 也有更新的意思。


移除 Key 值
移除 key 一樣需要 Editor 物件來操作，你可以使用 remove("key值")。

editor
    .remove("username")
    .commit();
String username = pref.getString("username", "名字已不存在");
Log.d("WINWU_APP_LOG", username);

清除全部的資料
其實看到現在會發現，只要需要更動到 SharedPreferences 檔案的內容，都需要使用 Editor 物件，所以目前也只有讀取 key 值用不到 Editor。

清空 preferences 檔案裡面的 key，呼叫 clear() 然後再 commit() 就行。

editor
    .clear()
    .commit();

我的 SharedPreferences 存在哪裡?
利用程式操作 SharedPreferences 其實是有點空虛，但確實真的有這個檔案存在，格式為 XML，你可以開啟 Android Device Monitor，然後點選 File Explore，通常應用程式的資料會放在 data/data 資料夾底下，接著尋找應用程式的 applicationId 取名的資料夾。

[在 Android Studio 靠右邊的這一顆可以開啟 Android Device Monitor]

[找到 File Explore]

SharedPreferences 就放在應用程式的資料夾底下 shared_prefs/preFile.xml。

你沒有辦法直接夠過 device monitor 開啟這個檔案，但你可以把它匯出來看看，右上角找一下 icon，有個 pull a file from device。

這是 SharedPreferences  xml 的樣子，你會看到你儲存的 key 值:

End~

[筆記] 手機 APP 畫面的分類

今天大概翻了一下一本跟 app ui/ux 有關的書，筆記一些東西，因為在 google 的過程中發現有些東西我蠻想記錄下來的 :P 不過 UI 元件我沒有特別紀錄，因為 ios 跟 android 還是有點差別，要寫的話就要分開紀錄了。


手機 APP 畫面簡略來分，可分為 :
(1) 起始畫面
(2) 主畫面
(3) 列表頁
(4) 詳細頁面
(5) 其他，像是登入畫面, input 畫面, 管理畫面...

(1) 起始畫面，以使用場景來看有
- Splash
App 準備啟動時的畫面 (但其實有時候 app 載入很快的話，你可能看不到，我曾經有朋友跟我分享過他接過一個 app，對方不管怎樣都希望載入 app 時出現 splash... XD)

想看一些 splash 畫面: http://www.mobile-patterns.com/splash-screens

-Walk-Through 逐一介紹畫面:
walk through 漫步的意思，通常這個畫面出現在你第一次開啟該 app 時才會看到，主要是導覽你關於該 app 的一些介紹。有點類似 web 的 slideshow，一張一張的刷掉，然後就會退出，讓你正式的開始用該 APP。

想看一些 walk through 的設計: Walkthrough UI Design 

- Coach Mark 教練標記
教練標記我覺得跟 walk throught 很類似，只是他把你的視覺帶到更實際的界面上引導你，什麼地方或是什麼按鈕可以發生什麼樣的事情。

想看一些 Coach Mark 的畫面: http://www.mobile-patterns.com/coach-marks

- Empty Data Set 空資料狀態
沒有資料時的畫面樣式。

想看一些 Empty Data Set: http://www.mobile-patterns.com/empty-data-sets

(2) 主畫面
嚴格來說主畫面才是整個 app 的重頭戲，而起始畫面可能不一定是必要，看情況，有些時候有，也許對使用者體驗會蠻好的。主畫面是 App 的門面，也會擺放其他操作的 UI 元件，像 navigation...。

(3) 列表畫面
列表畫面是最常看到的畫面，大部份的資料都會比列表作為呈現，只是 UI 設計不同。列表畫面最常見的例子有:   搜尋結果, timeline 顯示, 訊息紀錄, 簡訊紀錄,  媒體相簿。

列表畫面的一些 sample: http://www.mobile-patterns.com/lists

(4) 詳細畫面
詳細畫面通常都是 user 操作流程最底 (或者說步驟比較深) 的畫面，但詳細畫面也很重要，因為這個畫面往往才是 uesr 一直想知道的內容。說起來也蠻有趣的，有一種目的地是在最深處，可是要怎麼讓 user 走到對的地方，這就跟 app 的流程設計跟引導設計比較有關係 :)

詳細畫面的 sample: http://www.mobile-patterns.com/detail-views

IOS 與 Android 的 Design Guide
IOS 的 design principle
Android 的 design principle


APP 的 UI 怎麼優化
這我沒有特別的想法(也許我想的是錯的)，但我覺得不能說是優化，先想著什麼東西很多餘，像是避免混淆使用者的元件應該都要拔掉或是換掉。(比方說用第三方免費的 icon，但是 icon 沒有用對，或是表達的意思不夠清楚)。

整個打掉重新設計也是一種方法....。

說到這也有個小故事，上個禮拜跟一個做 app 的朋友團隊聊天，大家在設計 app 的時，總是會不小心把 web 有的功能也都放到 app 的設計裡去，然後變成煩惱生煩惱，本來只是一行字的東西，變成一個 icon，最後變成一個 icon 點了之後要出現 menu...，捨去法好像在設計 content 很多的題目上好像真的很難 XDD



這一兩年寫 Web 的心得: 好像越來越多人喜歡把 Mobile Web 設計得很像 APP，但好像也有人喜歡把 APP 的感覺做成 Web...，覺得有點奇妙... 說不出哪裡奇妙。不知道有沒有發案主連自己做的 app 是真 App 還是 web  包起來的 app 都不知道。只能說我覺得這個市場有點複雜....有點奇妙...

參考連結:

http://www.appdesignserved.co/  一些 app 的設計，看了眼睛會很舒服 :D 或是去看 behance~

https://medium.com/sketch-app-sources

我最近看的一本書: Android App 程式設計教本之無痛起步

這本書的詳細資訊 (博客來)。

* 閱讀天數: 約 13 天吧!，一天不超過6小時。
* 購買時間: 1月初。
* 學習 Android 最麻煩的地方: 建置環境! (<- 如果連 JDK, android studio 都弄不起來就不用玩了...)
* 學習建議: 就算有 android 模擬器還是不夠，建議還是要有 android 的手機在身邊用。

其實我離職的這段時間真的是很盡情地看書，看了一點 Java 的皮毛就來看這本書。不過，這本書真的非常基本，但它的書名已經很童叟無欺了 :)，真的是很無痛，也很好上手 (跟著步驟做，你不太有機會走丟，但是有些 typo 的地方，你可能要自己認的出來比較好...)，只是說如果要再更精深一點，只看一本絕對不夠。另外前面幾章節的重點複習跟練習能做就做瞜。

適合沒有學過 Android，但是你有其他程式語言的基礎，我覺得這本書是不錯的入門，書本的教學方式比較小單元為主，一個功能或是主要的大方向都會稍微帶過。

後面章節簡短複習 Java 的附錄我覺得蠻實用的，另外 Android Stiduo 的介紹寫得不錯。

模擬器的話，在 window 上好像要多安裝一些東西，但是因為我是 Mac... 所以我沒感覺...

大概是這樣。我還有買另外一本書，用來增加對 Android 的深度跟廣度用 XD... 應該說學到基礎的 android 對我的好處在於了解一些 android app 元件的專有名詞(因為我覺得這個很重要)，就好比 PM 要出去談 case，看到 UI 總是要能夠想像一下怎麼用一些 app 開發的名詞跟工程師溝通一樣。另外我只是很想感受一下刻 Android App 的 UI 的感覺 (只是目前還沒有嘗試到而已... 有點可惜XD 但也沒這麼強)。


這本書對我影響的地方...:
* android studio 的 auto complete 以及一些自動 import 的功能，都好方便，突然覺得 sublime... 好像少了什麼 XD 但是有時候 render XML 的時候卡卡的...
* 加強我對 Java 的一些觀念，像是 overloading, constructor的定義以及原來 @Override 是有意義的 :P。
*  申請 Android Developer (嚴格來說應該是『Google Play 開發人員』)要繳 25 塊美金。( 這跟 ios 上架的價位差好多啊 ... )

如果你想學 android 的一些的資源:
1. Coursera 上面有 android 的免費課程
2. udacity 也有免費課程
3. 比較有耐心的話就看文件摟! Android Developer




-end~

Samsung Galaxy S6 edge 使用三個月的心得

這支手機我用了快三個月才寫文，用過才寫得出東西啊.. XD

文章故意寫個開箱圖，因爲我不太會寫文 XD 只好放放照片過過癮。iphone5 我用了兩年多，碰上續約可以剛好換支手機，被店員慫恿後，決定換個 Android 系統玩玩看。定價大約要 26000 其實不比 iphone 便宜，當初買的時候也被身邊朋友噓了好久...

[Android] 筆記 手機上測試自己的 APP

本篇撰寫時的 Android Studio 為 1.5.1 版。

在開發 Android 時，測試 APP 的方式有兩種 (1) 在 android studio 時透過 AVD 執行/模擬 APP(AVD, Android Virtual Device  android 模擬器) (2) 在手機上測試自己的 APP
此篇文章暫不討論 (1) AVD 的方式。在手機上測試自己的 APP，有兩個方式:

(一) 手機 USB 接上電腦
(二) 是透過 apk 檔直接在手機上安裝應用程式並執行(透過 email 寄信)

不論 1, 2 都請你先把你手機上的『開發人員選項』打開，並且要勾選 USB 偵錯的項目。(至於怎麼開你可能要去 google 一下，以我來說是找到手機的設定的地方，在 Android 版本號的地方按七下。)

這張圖是已經開啟開發人員選項選單畫面，模式狀態請為『開』。

並且授權 USB 偵錯。

(一) 手機 USB 接上電腦
用 USB 測試的話，如果是 window 作業系統還要另外安裝手機 USB 的驅動程式 (Mac 我忘記要不要裝了 sorry ... )，如果你接上去 USB 然後 run APP 的時候沒有抓到你的 device，那可能真的要裝一下了...

安裝 USB 驅動的話請參考這篇 OEM USB Drivers。
假如你裝好了，就把你的手機以及 usb 接上電腦，在 Android Studio 的地方，執行 `run APP`。

這時候 Android Studio 會先問候你的手機是否允許偵錯:

像我的手機是三星的，在透過允許偵錯之後，你才能在 Device Chooser 找到三星的手機，假如你按取消，或是沒有回應，則選不到這個選項 (state 會變成 offline):

選擇我的手機之後，按下 OK 就能在手機上模擬 app 了。


(二) 是透過 apk 檔直接在手機上安裝應用程式並執行(透過 email 寄信)
假如你的 usb 偵錯一直有失敗，那另一種方式就是把整個 app 的 apk 檔寄給自己，透過手機收 emai 的方式把 apk 下載下來。

至於 apk 檔在哪裡呢，尋找目錄底下，他在 app/build/outputs/apk/app-debug.apk

你可以把這個 apk 複製出來，換個檔名。另外如果你有修改 app 的程式，也請記得重新 build 專案才會同步這個 apk。

使用你的 email 把這個 apk 夾帶在信件中，寄給自己，然後透過手機收信，並下載 apk，流程如下:

如果未曾允許過的話要記得允許安裝的權限，安裝完成後就會在手機的 APP 列表找到他。

[Android 筆記] 設定 ImageView 的圖檔來源

在 Android 顯示圖片，如果是用自己客製的圖片，檔案要放在 app/res/drawable/ (以 Anrdoid 的目錄來說) 底下。(檔名切記不能用中文字)

新增 ImageView 的方式從 Widget 拖到畫面你要擺置的地方: (在此使用 AndroidStudio)

接著選擇圖片的來源，src 怎麼填呢？
(1) 如果是你是用自己提供的圖片，那就是 @drawable/圖檔名稱不含副檔名
(2) 如果你是用系統預設的圖片，那就是 @android:drawable/XXXX  (ex: @android:drawable/sym_action_email)

通常如果是選擇系統預設圖片不會自己手 key src 的屬性，你可以用介面選取。

你可以點擊剛剛新增的 ImageView 打開編輯視窗，在 src 的地方選取 "..." 打開資源介面去找你的檔案:

選擇你的圖檔: (基本上選取自己新增的圖片，路徑從 Project 的 Tab 開始找; 反之如果是要系統預設的圖片，用 System 的 Tab 開始找)

以我這張圖片來說，我的檔名是 test.jpg，這個 ImageView 的 src 屬性是 @drawable/test (@drawable/檔案名稱不含副檔名)。

另外也能透過 coding 的方式設定 ImageView 的顯示圖片 (資源)，Example:

// 宣告 ImageView
ImageView img1 = (ImageView) findViewById(R.id.XXXX);

// 範例: 如果是要設定內建的圖片
img.setImageResource(android.R.drawable.顯示內建圖片的名稱);

// 範例: 如果是專案自己的圖片
img.setImageResource(R.drawable.圖檔名稱不含副檔名);

假如是要讀取手機的相簿，請另外參考 setImageBitmap()。


圖片的 Visibility 屬性
ImageView 可透過 visibility 設定圖片的可視程度:
* visible 可視 (預設情況)。
* gone 看不到，也不會佔空間。
* invisible 看不到，但是會佔住原本擁有的寬高屬性。

程式設定 visibility 則是 setVisibility(參數)。參數可以是 VIEW.VISIBLE, VIEW.INVISIBLE, VIEW.GONE。



* 關於 Android ImageView 官方文件
* 圖片的顯示大小用 width, height 控制，值可以指定 dp 值或是 wrap_content, match_parent。
* 圖片的縮放規則則是要參考 scaleType，但要注意有些屬性值可能會裁切到原圖的顯示範圍。

元旦三天連假讀的三本書

1. 從0到1：打開世界運作的未知祕密，在意想不到之處發現價值
2. Melody的幸福3元素：閉嘴、放空、微笑
3. 喬志先生愛情處方箋

[CSS] 用 transform scale 針對 input checkbox 放大

左一: safari / 中間:  Chrome / 後: Firefox

今天在製作一個 checkbox 時，為了在手機版上方便點擊，刻意想要把它放大。

就以放大三倍來說，就是 scale(3):

這段都沒問題，我只是想說， transform 的表現在 safari 沒有用，如上圖你可以看到，還是一樣小顆，甚至他只有在 :active 時才會放大，也是一個很詭異的行為。
在 Stackoverflow 也有人跟我有一樣的問題，原因是在 webkit 下要用 3d transform 去處理這個放大的效果。

後來我就把 webkit 那一段改成 scale3d:

文章中也有參考的link，可以去詳讀看看
http://stackoverflow.com/questions/31843647/webkit-css-transforms-scaling-doesnt-work-on-retina-mac-if-the-scale-factor-is
有更好的方式也可以留言跟大家分享一下，感謝! :D

[讀書心得] SCM 軟體配置管理

書名: SCM 軟體配置管理  作者: 董越

這三天把這本書看完了，我大概 brief 一下每章的一點筆記就好，其實主要是書已經在身上，寫太多出來也沒有太大的必要 XD 大家有興趣再去看看書吧 :D (新年新希望難道沒有一年要看幾本書的目標嗎?! :P)

SCM 是 Software Configuration Management 的縮寫，書中翻為軟體設定管理，簡單的說就是對一個不斷演化的軟體資產做管理，主要有兩個方向，一是針對資產做管理以及儲存，二是適當的控制軟體的品質，像是關注於軟體的整合。

比較精確的定義要參考 IEEE-STD-610，或是你可以參考本書本書的ch01。

Ch02 基本的版本控制
* 即使只有一個人，也要做 SCM
* 防止版本覆蓋: 如果你仔細去細想，在多人開發軟體的時候，同一隻檔案被同時修改的機率非常高，因此防止檔案被別人覆蓋，是很重要的議題。
當然，不同的版本控制工具各有不同的處理方式，第一種是串列的方法，類似我們寫程式處理的 quene 啦，就是當有人要拿檔案去修改，該檔案就會被 lock 住，但是這雖然是一種方法，可是對開發效率來說是偏低的，因為如果檔案一直 lock 住，表示其它的開發人員只能乾等。這種防止覆蓋的方法的版本控制工具的一個例子是 Visual SourceSafe (縮寫 VSS，微軟出的古老版版本控制工具)。

第二種方法是平行，平行的處理手法解決了串列的問題，就是允許多人同時修改同一個地方，在做合併時，工具會判斷什麼時候需要合併，合併哪些東西，大部份情況是可以自動合併的 (像 git 的 auto-merge)，不能的時候就會叫你人工合併 (類似 conflict)。這類的版控工具，像是耳熟的 Subversion(SVN), GIT, ClearCase(CC, 同時支援串列跟平行的方法，是 IBM Rational 出品的商用軟體設定管理工具)。

書本有列一些市面上的版控系統，很多我也沒聽過 XD，但是後面幾個章節主要都是拿 svn, git, ClearCase 來比較，有 ClearCase 的原因我想大概是因為書中有提到他的市佔率蠻高的，老實說我不知道台灣有哪些公司有用到..?! 知道的朋友可以幫忙舉例一下 XD

不同的工具做類似事情的行話不太相同，像是:
* SVN 用 check out, commit, update...etc
* git 用 pull, fetch, merge, add, commit, push..etc
* ClearCase 用 check out, check in... 恩..ClearCase 我覺得比較複雜一點，但是我沒機會接觸到所以沒有特別去記，看看就過去了... 。

假設企業要導入 SCM，也要有人出來處理工具的選擇, 教育訓練, 制定開發流程等等。這也是 SCM Engineer 的工作之一~ 類似的職稱有 CM (簡稱配管), 或是設定經理 (Configuration Manager)。 一樣.. 我也不知道台灣有沒有這樣的缺 ?!  SCM Engineer 我是沒聽過耶 =="(我果然是井底的青蛙)...


Ch03 當代的版本控制方法
* 變更集合的概念 (或是變更套件  change set, change package)
* 小單位的修改就可以交付程式碼，盡量不累積
* 修改前先以拿到最新版的程式碼開始，或是反方向處理，在自己的工作區域修改後常常去更新 Repo 最新程式碼回來，在 git 是指 pull,  在 ClearCase 是指 Rebase。


Ch04 關注整體品質
* 這章主要在提整合。Intergration 主要的使命就是把產品的各部分合在一起，並且保障產品還是可以運作的情況，而不是每個模組, 單元都各自在特定的環境下可以運轉。因為每個地方都是正確的情況下，並不能確保整合在一起後就是正確的。

* 4.2 保障交付的品質: 關於這點，有幾個方向可以努力，一就是寫測試，單元測試與 TDD 是個很好的方法，再來是 Peer Review，或是 Code Inspection (現在很多 Peer Review 工具都有跟版本控制整合，像是 github 上就有幾套，只是大部份都要付費。在我任職過的公司 urAD 曾經對某專案做過 Code Review，還蠻有趣的，每個人都要針對同事發的 pull request 做 review)。還有 Pair Programming，目的也是加強程式品質。

上述的幾個方法，都是靠人來完成，當然也有方法，不是靠人來幫忙達到品質的把關，像是靜態程式分析 (Statis Program Analytics)，利用類似的工具發現程式碼的錯誤等等。畢竟有人就有可能有疏漏, 也有可能有犯錯的機會，所以利用一些工具來相輔相成幫助軟體的品質更好。


Ch05 從原始程式碼到執行中的程式碼
* 軟體的建構有兩種，全量建構 Full Build 以及增量建構 Incremental Build，主要指的是編譯連結的過程。 全量是從頭開始，重新編譯每隻檔案，比較耗時。增量主要是找有差異的重新建構，較快但有風險，相較之下比較沒這麼可靠。不過這個我體會不深，我寫的語言幾乎是不太需要編譯的 XDDD

Ch06 邁向持續整合
* 持續整合: 整合可以更頻繁，也就應該要更頻繁。如果能夠收到工程師的 commit 就開始進行整合是最好，通常也是會寫個 hook，當有人 commit 的時候就去跑 ci。
* 越大的專案，越能夠從持續整合中看到明顯的成效。 (但越大的專案要做持續整合也越難...)。
* CI 的工具有，像是有名的 Jenkins, 或是 CruiseControl (這個我就沒聽過了... )


Ch08 管理文件
* 軟體設定管理當然不只管軟體，也管文件。
* 軟體寫給機器看，文件寫給人看。
* 檔案的命名應該要加上版本號，另外也建議使用具有版本控制功能的文件管理工具。
* 不同文件可能會有保密的不同層級，應該要在文件附註這些資訊。


Ch09 
* 第九章都在講跟 bug 有關的，主要是也提到幾個 Defect Tracking System 缺陷追蹤系統，(Bug 的學名就叫做缺陷)。工具很多像是 Bugzilla, Redmine, Mantis, Trac, BugFree, ClearQuest (IBM Rational 出品的), JIRA。
JIRA, Redmine 我都用過，還蠻喜歡 JIRA，但是商用都是要付費的。
* 對於 bug 的描述一定要做到可以讓開發人員及 QA 可以做到複現，包含遇到的情況, 當時的作業環境。


Ch10
第十章在講遇到 Feature 時的處理方式，另外也提到 Scrum, FDD 等。

* Scrum 是敏捷開發的一種方法，用一種反覆運算, 增量為主的特點來開發軟體。 這裏的增量指的是 Enhancement 代表一些小小的功能請求，想在原有的程式加上一些功能。 (我也打算看一下 Scrum 的書，如果有推薦的書目也歡迎留言推薦給我，謝謝 ! :D )

* 除了可以用 Scrum 來管理這種一個一個的 Feature 之外，也可以用 FDD 也就是特性驅動開發 (Feature Drive Development) (wiki)，FDD 也是一種敏捷開發方法，我有找到一篇文章有興趣可以看看: David Ko的學習之旅 - Feature Driven Development 簡介。
(不過...  FDD 我比較少聽到 XD，大部份聽到 Scrum 比較多)

FDD 對於 Feature 的週期是兩週內完成，Scrum 的週期單位是用一個 Sprint (衝刺) 來算的，通常是 15-30 天，長度由開發團隊決定。

* 在瀑布模型下管理 Feature，要注意一旦決定要執行的計畫就不要去更改他了。(瀑布下要減少變更, 變更是不能夠隨意的發生，但不是指完全不行)

其實我覺得增加 Feature 在大型專案上比較麻煩，因為要往上通報，由主要 Leader 決定開發這個 Feature 的成本是否有意義，因為會影響時程, 開發人力，實際對 user 的方便性跟效益是否是值得的? 會不會引發後續的其他 issue 跟 maintain 時程, 以及相對應的測試 code 都要修改。

* 書中有提到可以成立變更控制委員會 (Change Control Board, CCB)，由一群人來決定是否要執行某個 Feature(我個人覺得有這種會議如果遇到很麻煩的 Feature 應該很容易開的沒完沒了 XDD )。

* Feature 的處理流程，應該要依照 Feature 的程度而有所劃分，並不是所有的 Feature 都要經過嚴格的管理。


CH11
11章在講學院派對 SCM 的理論。讀起來比較悶，感覺很像在唸考試的東西 XD 其實主要在講 CMMI 啦

* SCM 主要由四大部分組成:
1. 設定識別 (Configuration Identification, CI)
2. 設定控制 (Configuration Control)
3. 設定報告狀態 (C... Status Report)
4. 設定稽核 (C.... Audit)


後面章節的我就先不寫了，但都是在講 SCM 在實際場景的舉例，嘻! 有興趣知道可以買回家看看 :) 總之我是覺得，看這種書很快樂 XD 雖然實際上在工作不一定都能用到或是親生經歷，但是知道有什麼方法就夠了(工作與團隊之間，不同階段有不同挑戰)。

2015 Summary，每年最後一篇網誌，總是一些流水帳....

心情
2015 年的心情算是中下吧，總結一句話就是燒錢的一年，忙忙碌碌，最後好像也搞得自己一場空?! 也許是短時間內看不出成果吧 反正都過去了，也差不多迎接新的開始，要認命一點。

(攝於成都 天府廣場站)

旅行
今年去了三個國家，都不敢說自己是出去開拓視野，因為真的是出去玩 XD
* 美國-舊金山
* 日本-北九州
* 中國-成都 (現在想起來遊記還沒發佈，晚點再來整理 :P)

出國玩還蠻開心的，越來越能夠獨立的做一些事情，不過三次出國還好有都朋友幫忙，不然我可不敢一個人出國 XD  2016 年我還想要再去 1-2 個國家玩玩 :P 現在最想去的是英國吧(但是要存很多很多錢...)...

戰果
2015 在公司做些什麼我就不多說了XD，我也不能說 :D 科科。
在公司學到最多的應該是測試，接觸到 travis 的感覺很新鮮，剛開始動不動就會想要去等結果 XD，但是我寫得很爛啦 XD 很不熟其實...，還是要感謝公司同事的包容跟教學相長 XD (天吶我好官腔!!!)

2015 年的閒暇時間，總共完成 14 個專案，其中 1 個是跟新加坡人合作 UI 設計，3-4 個主要以前端切版與 RWD 為主，剩下的則為 Full Stack 狀態，開發主要還是以 PHP 為主，有些專案是我 standalone，有些是跟別人一起，coding 的對象都是比我強的人，覺得小有成就感~，只有一個案子很可惜，我跟一個很棒的 team 合作，但是成果最後 fail 了 :'(。

前端常用的整合工具，目前還是離不開 gulp 的生態，還有我也沒有追上 react，倒是 PHP 經歷 laravel 4 -> Laravel 5 的過程學到很多，對 class, interface, trait 的用法比較懂了。

說不上離開前端這個領域很遠，只是在實作上，真正應用在可以客戶所追求的地方上，我確實也無法用這些這麼潮的框架...(時間上也沒有這麼閒可以一直追新東西)，客戶多半要的是穩定，可以好找到人接手的環境跟技術。當然，有一種夥伴也會要求我用新的東西，通常那種就不是普通的合作對象，而是對方自己就是 coder XD，不過這種合作以我的狀況我是不太愛接觸(既然是閒暇時間就想做一些有把握的事)。

我現在覺得在 blog 上寫的好像很簡單似的，可是想起一些過程還算是歷歷在目的，有些情況也是很有壓力... 像是第一次接觸用 Laravle 做多國語系，串接臉書 API 做 tag 朋友, 發文功能，這些看似很平常的功能，當這些事情全部落在我一個人手上時，處處都有細節要處理。默默的開始假裝自己是半個 PM，假如一個專案上線扣除臉書 api 審核的時間，以及被退回的時間大概還剩幾天可以開發, 測試之類的。偶爾也成為朋友想要發包網站出去時的半個顧問職，朋友嘛 :) 出一張嘴的工作當然隨時都能聊聊 XD (逃)


學習
除了年初的 Bing Ad,  Google Analytics 證照之外，剩下的就是拿了五門 Coursera 課程，還有在五倍紅寶石講了6次的 Basic JavaScript (雖然我也不知道講得好不好 XD)

Coursera 的 R Programming 我上了兩次，作業沒時間寫，就沒畢業，好難過 QQ

研討會的話也常跑中研院，只是多半都是跟資料科學有關，Data Science 是離我很遠的世界 (遠目)，很遙遠但是可以刻意接觸他，反正很多事都不是一蹴可幾 (我說了成語了嗎?!)，我也不是主要靠資料科學吃飯，只是還有興趣就多聽聽，研討會的價位都算便宜了


目標
年末年初，我過的日子多半是看一些跟軟體開發有關的書，不管是把規模做大的書，還是整合工具的介紹，測試等等的。心中是有想做的事情，只是還想保留一下，因為很多事都不確定。我想我是個怪咖吧... 也許是自己快要 26 了，有點小緊張，我喜歡默默地去做一些往目標走的事情，等做到了再來說，科科 :P

新年快樂啦

我終於看完大話重構了...

之前一直看到朋友在 FB 牆上推薦這本書，買了 2-3 個月，這週終於把他看完了，適合有 coding 經驗的人，有一定的工作經驗，書本的範例讀起來會更有感覺，而且會默默地(也沒有真的到多默默啦... 畢竟目錄也有寫 :P)大概瞭解到幾種設計模式，像是 SRP, OCP, AOP, DIP, 橋接, 策略, 命令, 裝飾者模式~

最有感觸的段落是:
* 如何解決繼承氾濫
* 減少使用 if else 的幾個方法


封面講的重構七步驟其實就是:
1. 拆分大函數 (大函數是罪惡根源 XD) (Extract Method)
2. Extract Class
3. 提高程式的復用率 (DRY, 抽方法, 抽類別, 封裝, 抽取父類別)
4. 找出可擴展點 (幾個方法: OCP, hooks, AOP)
5. 降低程式依賴度 (工廠, 依賴反轉, 橋接, 策略, 命令, 組合, 裝飾者)
6. 分層 (比方說 web 是有幾種層次, MVC 層, BUS 層, DAO層等等)
7. 領域驅動設計

老實說，第9章我自己是看得很吃力，講的那幾個模式 (橋接, 策略, 命令, 裝飾者)，我有點不知道如果是 php 會怎麼實作(也許我應該去讀一下 PHP設計模式那本書)... 然後書中的範例主要都是用 java 的 Spring 框架，用了一堆 <Bean>  也是開始會有點亂掉 ><。然後 OCP 本來覺得沒有這麼複雜，看了第九章之後，慢慢 fadeOut 了~ 可能我要再過一段時間再回來看這本書吧... 等級沒這麼高，還需要時間培養一下...


最終的重點就也是那些網路上大神的常談:
1. 有時候無招勝有招，學了 Design Pattern 不一定要急著用在自己的專案上，主要還是要考量情況
2. 沒有人可以一次重構就到位，小碎步前進
3. 重構是一種習慣，重點在於你有沒有這樣的意識


看完之後，確實手癢癢，可是主要是如果有人帶你學這些，會更快，我也希望我早點遇到一個可以教我 refactor 我的程式碼的人。以重構七步驟來說，1-3 step 都曾經在工作上有前人的教導我才慢慢起步。

(我是很想學重構，也算有興趣，只是時程有壓力的話，我承認還是拋開我的羞恥心了...，客戶是我的老大)

Meteor 安裝 jQuery validation

用 meteor 指令安裝 jQuery Validation(套件網址)

指令:
meteor add themeteorchef:jquery-validation


用法:
一樣參考套件網址，主要有兩種做法，一個是把驗證的設定寫在 input 的 attribute 裡面，像是 <input type="text" name="name" class="required"> ，但是一樣要用 js 去呼叫 validation 執行($("XXXX").validate())。

另一做法是把驗證的規則寫在 validate 的 options 裡面。像是:

基本上做法一,二都會在 onRender 的地方呼叫。
記得也要把 submit 那顆按鈕的預設行為取消 (submit preventDefault 那一段)，不然也許邊驗證時也早就 redirect 到 action 出去的頁面了 XD。

樣式改寫 for Bootstrap:
因為 jQuery Validation 在驗證到錯誤或是未填的 input 時，會在 input 附近塞入 error message，但是預設的樣式並不符合 bootstrap 的樣式，像是:

為了讓錯誤的樣式符合 bootstrap 的樣子，要改寫一下 jQuery Validation 的 setDefault 的一些 method，像是 highlight, unhightlight...，但是因為整個網站下，有很多頁面只要有用到 jquery validation 的地方都必須要改寫驗證，為了節省一直複製貼上這一段到每一個頁面/template 的 onRender 去，所以我把這段改寫放到 Meteor.startup 的 function 去(我在根目錄下新增一個 startup.js 來擺這段 code):

改寫後，暫時符合預期:

其實在網路上有找到兩個解法，這個是我用起來比較順的，只是寫出來分享一下而已，也不知道好不好~自己斟酌摟 :P。

參考:
http://jsfiddle.net/m2o6c2vj/3/
http://stackoverflow.com/questions/18754020/bootstrap-3-with-jquery-validation-plugin

讓 Meteor 在換頁時頁面定位到最上方

最近在用 meteor 搭配 iron-router 做一個 web 後台的雛形出來，但因為 meteor 的設計還蠻特別的，所以有些行為跟一般做換頁的網頁效果不太一樣，主要是比較像是 Single Page Application，你在換頁的時候感受不到瀏覽器有在重新 loading 的感覺，所以換頁時，你的 viewport 可能會停留在上一頁的看到的地方，為了不讓 user 感到困擾(<- 視頁面情況..)，在 github issue 上面找到一個解法，要在 iron-router 的 filter 加上一個方法，這個方法用來讓頁面捲到最上方，然後把這個方法掛在 Router 的 onAfterAction。


(＊ 我的 meteor 版本是 Meteor 1.2.1)

那一串 github issue 有很多討論，但是我是用這個方法。
有成功拉，好險好險 :)

2015 年末的小認真之 Coursera 上上課

人生啊...

課程

(1) Courser 的延世大學 - Big Data, Cloud Computing, & CDN Emerging Technologies

12 月最先開跑的學習是關於 IoT 的一些基本觀念，首先上的課程是 Coursera 延世大學的 Big Data, Cloud Computing, & CDN Emerging Technologies，這真是一門基礎到不能再基礎，而且濃縮所有基本觀念的課程，w1 真的就是在講一些 big data，w2 是 Hadoop 的基本觀念，是有稍微提到 YARN, 還有一點點 RDBMS，w3 就是 CDN 的觀念跟這個產業的幾個公司，大概知道一下那個市場範圍在哪裡，但是光看課程是感受不出技術上的難度跟落實的難度有多複雜啦，anyway 我只是有時間的時候當作影集在看，題目也蠻簡單的，有認真上一定 pass. 雖然我最後只拿80分結業，汗顏 XD

哦對了老師好像是韓國人?!，雖然我覺的老師的英文腔調很特別，不過聽到 w2 就習慣了啦 :D
老實說這種基礎觀念的課程不拿專項課程真的很可惜，不過就看我時間，其實我是很想整個專項都拿下來。哎，循序漸進嘛... 資質卑劣.. 太難的我也不懂啊

(2) Coursera 杜克大學 Java Programming: Solving Problems with Software

Duke 大學的 Java 課程很有條理，我覺得蠻推薦的，而且這門課超級不太 web，但很有新鮮感。Duke 設計這門課程還寫了一個叫做 BlueJ 的工具，上課講 code 都是用這個工具，我是覺得蠻適合 Java 新手，是還蠻厲害的!

week1 教你用 java 去選取圖片，然後針對圖片做簡單的影像處理，像是灰階, 或是 RGB 中間兩個色系互換之類的，聽起來很難但真的... 不難 QQ w2 開始就有點複雜了..。

w2 課程是要教你在 DNA 的 String 找出基因，但其實就是在教 String 的操作啦! 但我覺得上起來相對蠻悶的 XD 有點難，w2 後面段是要教你爬網頁的 html 的內容，像是找出幾個 link，哪些 link 是 https 結尾等等。

w3 是 CSV 檔案的處理，上這堂課才知道 CSV 是一個 standard XD (IETF RFC 4180: comma separated values)，然後用 apache CSVParser 這個 lib 去練習寫 CSV Parser。

anyway... 我還在修，但我覺得我不會 pass

(3) Coursera 約翰霍普金斯大學 A Crash Course in Data Science

Executive Data Science 數據科學管理專項課程是最近才看到的課程，比較輕鬆引導式的方式，我還差三門要上，現在就只有上 Cash Course in Data Science 跟如何建立 Data Science Team，但這門課很基礎，所以，想知道什麼就自己去看看好了，課程很短。


(4) Coursera 約翰霍普金斯大學 Building a Data Science Team

如何建立資料科學團隊，這是接續上一堂的課程，看完之後覺得... 哎呀 台灣有幾家注重資料科學團隊的公司?! 有幾家願意投資時間做資料科學的?! 因為做資料科學是很有挫折的事情。也許花個一年半載的，才有機會發現有 value 的東西，可是願意讓這種團隊在公司待個一年半載才看到成果的公司，少之又少的 feel~ 錢跟時間都要燒得起QQ。我是覺得跟公司文化有很大的關係(不確定? 只是覺得...)


(5) Coursera 倫敦大學 & Goldsmiths, University of London  的 Introduction to Meteor.js Development

在過去一年曾經整年都在用 node.js 寫 web application，只不過用的是超輕量的 koa.js，在過去用 node.js 的期間常耳聞 Meteor 這個 framework，但就是台灣用的人太少了 (->也許是我朋友太少!?)  剛好趁這個機會探探 meteor 的用法。

上這門課只是開開眼界，多看看不同 framework 的做法，至於好不好很難評論，一個 framework 就是一種生態， by case 你會有你想選擇的 best one, 也沒有好不好的問題。

結論就是 Meteor 跟 MongoDB 是蠻搭的，只是我手邊沒有案子可以玩這種架構。上完的心情就是我很愉快但是 see you next time.  真的想不出拿時候用的到，maybe 做個網站或是 app 的 prototype 會有機會。


目前生活總結
本來正在寫 PHP，後來劈腿 Java，還跟 node.js 繼續曖昧，現在處在一個很亂的關係當中

很窮但很快樂.  希望心想事成!

現在還有幾堂課正在上，有什麼心得就再說啦! 考驗我的意志力