誤刪 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 雖然實際上在工作不一定都能用到或是親生經歷，但是知道有什麼方法就夠了(工作與團隊之間，不同階段有不同挑戰)。