一般在設計 Activity 時，會設定 Activity 的佈景主題，也就是套用某一個特定的 Theme。如果今天在啟動 Activity 後想要動態調整 App Bar 的背景顏色，可以在另外指定 Activity 所套用的 Theme 後重新啟動 Activity。然而，這樣的程序只是為了換個顏色似乎有一點小題大作，所以在這篇文章中提供了另外一種不用重新啟動 Activity 的方法。
2016/8/4
2016/7/29
在可收合的 App Bar 中加入 Subtitle
可收合的 App Bar (以前叫 Action Bar 後來又一度改成 Tool Bar) 是 Android 平台上新推出的 Material Design 效果。要在開發的 App 中使用這個效果並不難，只要在最新的 Android Studio 中，於新增 Activity 時選擇【File -> New -> Activity -> Scrolling Activity】，並依照「Configure Activity」視窗的欄位填好內容，按下【Finish】按鈕，就可以有一個執行起來如下圖的畫面，頗為無腦。
2016/7/17
解析 Android 開發時的 SDK 版本參數設定
在開發 Android App 時，開發人員最容易出現困惑的地方之一應該是 compileSdkVersion、minSdkVersion 和 targetSdkVersion 這些參數的用途。對此，有 Google 內部的 Android 開發人員就這個議題寫了一篇文章：Picking your compileSdkVersion, minSdkVersion, and targetSdkVersion。在這裡會用不同的角度來說明這些參數的用途，希望能對大家在應用上有所幫助。
2016/6/25
2016/5/30
使用 PMP 的 EVM 追蹤軟體開發進度
軟體開發在追蹤上的難題
一般在企業內部要開始一個軟體開發的專案有很多時候是老闆忽然靈機一動地問說：「我們來開發一個某某系統，你覺得需要多久？」有經驗的人聽到這個問題時就知道這是考驗專業能力與政治敏感度的時刻，因為這是一個兩難的問題。在好傻好天真的時期會想：「天啊！系統要做到什麼程度、有多少人參與、要給多少資源都還沒確定，就要押完成日？」會有這樣的想法不意外，就像是要蓋一個房子，連要蓋幾層都不確定、設計圖都還沒畫，更別提建材和工人都還沒有著落的情況下就要問何時入住，回答得出來才有鬼！2016/3/25
驚！點鈔機進化到足以全面取代人工作業
日前 DeepHand 發表了一款新的點鈔機取名為 BetaCo，該點鈔機具備了可自我調整力道的滾輪、高精度的感應器，並且提昇了對於各種鈔票狀況的學習能力，能夠在收集一定數量的資料後適應並清點各種不同情況的紙鈔。雖然前一代的點幣機成功地擊敗了世界知名的點幣好手，但由於紙鈔具有柔軟的特性，而且有可能因為髒污、破損、折痕等各種情況導致機器在判讀上的失誤，難度相較於硬幣要高出好幾個等級，所以這一款點鈔機問世對於產業界來說有一定的指標意義。
DeepHand 的技術人員透過大量地餵入各種情況的鈔票，來讓機器收集資料、建立樣本庫，以便機器在面對不同情況的紙鈔時能更準確的調校內部機構的出力及感應器的門檻值，正確地算出鈔票的張數。為了更進一步驗證機器的能力，於是 DeepHand 向世界排行有數的點鈔快手發出比賽的邀請。
比賽由目前排名第四的選手出陣，一共進行五局，進行的方式是每局準備一落十九疊張數不等的舊鈔，共十九落，由雙方先後以計時的方式進行點鈔並各自記下結果。下一局對調雙方的點鈔順序，由前一局後數的一方先進行點鈔。結果於該局雙方點鈔完成後同時公開，如果雙方點出的張數都正確，則以進行的時間決勝負、時間較少者獲勝。
結果，戲劇性地 BetaCo 以壓倒的秒數就取得前三局的勝利，贏得與人類對戰的比賽。接下來的二局雖不影響賽果，BetaCo 仍以一勝一負優異的成績作終，在這次的比賽 BetaCo 以四比一的比數大勝對手。唯一落敗的一局，是因為對手先攻的情況之下，在數鈔時目視到二張完全貼合的鈔票但未將其分開，而後攻的點鈔機判斷失誤以致少算一張而出現數字不正確，將勝利拱手讓人，否則以時間來看機器還是技高一籌。
對於這樣的比賽結果，大多數的人認為是人類的最大失敗、該點鈔機將全面取代所有的人工。於是人人自危、擔心飯碗不保、生計無以為繼，更甚者有人喊出人類末日到了。針對這樣的後續發展，人們是否應該開始省思點鈔機所可能帶來的危害、是否該針對點鈔機的發展計劃做出限制？
以上內容皆為杜撰、如有雷同純屬模仿。應該不會有記者真的把上面的內容拿去做成一篇報導，最後引起軒然大波吧...
不過，這篇內容和軟體開發有什麼關係？BetaCo 應該是沒有，但 AlphaGo 就義意重大了！有寫過程式的人應該都會同意，程式是開發團隊對於特定領域經驗的一種延伸。軟體開發過程中的一項核心工作就是把要被程式取代的工作內容給規則化，以便開發人員可以編寫成程式碼。
開發團隊的成員就像是在戰場上擬定戰略的主帥，主帥憑著自己的經驗預想戰場上可能出現的情況，並且逐一設定好應對的標準程序。一旦開戰主帥只能置身事外，完全讓部隊照著程序執行，如果一切和預想的一樣，則戰勝的結果可期。然而，事先訂好的規則畢竟是死的，再怎麼周詳仍然會有盲點。所以，反之，出現料想之外的情況，前線部隊將無所適從，則會一路潰敗，以致兵敗如山倒。由此可知，如何把規則明確且周詳地定義出來，這是團隊的功力所在，也是程式品質優劣的關鍵。
以圍棋這個領或來說，寫能下棋的程式不是什麼問題，市面上隨便一本入門書都已經把所有的規則定義好了，只要按圖索驥即可。只是這樣的程式並沒有辦法下贏對手，甚至有可能輸了都不知道。倒底要如何才能贏？我想就連當今棋王也不見得能夠說出個所以然！AlphaGo 的開發團隊能夠把抽象的圍棋致勝規則給歸納出來，並且落實到程式中，還能夠真的在棋局中獲勝。對於現階段的軟體開發工作而言，是一項了不起的成就、一個重要的里程碑。也讓在軟體界打滾了一陣子，但才能平庸、學藝不精的我來說是一個難以望其項背的層次。
至於 AlphaGo 是否有可能統治人類？也許吧！但就現階段來說，應該還是跟一般程式一樣有其侷限性，大概就是止於模仿人類學習圍棋的程度，否則這次就不會只是挑戰圍棋了。所以要說 AlphaGo 有什麼更進一步的能力似乎還早了點，因為歷來這麼多棋手也沒看過有哪個職業被棋手取代，即使 AlphaGo 贏了棋，最應該擔心失業的是棋手才對吧！就像對點鈔機稍有概念的人看到這個文章的標題，應該都會一笑置之，畢竟點鈔機是專門設計用來點鈔，要用來清點書本頁數都不太可能！
DeepHand 的技術人員透過大量地餵入各種情況的鈔票，來讓機器收集資料、建立樣本庫，以便機器在面對不同情況的紙鈔時能更準確的調校內部機構的出力及感應器的門檻值，正確地算出鈔票的張數。為了更進一步驗證機器的能力，於是 DeepHand 向世界排行有數的點鈔快手發出比賽的邀請。
比賽由目前排名第四的選手出陣，一共進行五局，進行的方式是每局準備一落十九疊張數不等的舊鈔，共十九落，由雙方先後以計時的方式進行點鈔並各自記下結果。下一局對調雙方的點鈔順序，由前一局後數的一方先進行點鈔。結果於該局雙方點鈔完成後同時公開，如果雙方點出的張數都正確，則以進行的時間決勝負、時間較少者獲勝。
結果，戲劇性地 BetaCo 以壓倒的秒數就取得前三局的勝利，贏得與人類對戰的比賽。接下來的二局雖不影響賽果，BetaCo 仍以一勝一負優異的成績作終，在這次的比賽 BetaCo 以四比一的比數大勝對手。唯一落敗的一局，是因為對手先攻的情況之下，在數鈔時目視到二張完全貼合的鈔票但未將其分開，而後攻的點鈔機判斷失誤以致少算一張而出現數字不正確，將勝利拱手讓人，否則以時間來看機器還是技高一籌。
對於這樣的比賽結果，大多數的人認為是人類的最大失敗、該點鈔機將全面取代所有的人工。於是人人自危、擔心飯碗不保、生計無以為繼，更甚者有人喊出人類末日到了。針對這樣的後續發展，人們是否應該開始省思點鈔機所可能帶來的危害、是否該針對點鈔機的發展計劃做出限制？
以上內容皆為杜撰、如有雷同純屬模仿。應該不會有記者真的把上面的內容拿去做成一篇報導，最後引起軒然大波吧...
不過，這篇內容和軟體開發有什麼關係？BetaCo 應該是沒有，但 AlphaGo 就義意重大了！有寫過程式的人應該都會同意，程式是開發團隊對於特定領域經驗的一種延伸。軟體開發過程中的一項核心工作就是把要被程式取代的工作內容給規則化，以便開發人員可以編寫成程式碼。
開發團隊的成員就像是在戰場上擬定戰略的主帥，主帥憑著自己的經驗預想戰場上可能出現的情況，並且逐一設定好應對的標準程序。一旦開戰主帥只能置身事外，完全讓部隊照著程序執行，如果一切和預想的一樣，則戰勝的結果可期。然而，事先訂好的規則畢竟是死的，再怎麼周詳仍然會有盲點。所以，反之，出現料想之外的情況，前線部隊將無所適從，則會一路潰敗，以致兵敗如山倒。由此可知，如何把規則明確且周詳地定義出來，這是團隊的功力所在，也是程式品質優劣的關鍵。
以圍棋這個領或來說，寫能下棋的程式不是什麼問題，市面上隨便一本入門書都已經把所有的規則定義好了，只要按圖索驥即可。只是這樣的程式並沒有辦法下贏對手，甚至有可能輸了都不知道。倒底要如何才能贏？我想就連當今棋王也不見得能夠說出個所以然！AlphaGo 的開發團隊能夠把抽象的圍棋致勝規則給歸納出來，並且落實到程式中，還能夠真的在棋局中獲勝。對於現階段的軟體開發工作而言，是一項了不起的成就、一個重要的里程碑。也讓在軟體界打滾了一陣子，但才能平庸、學藝不精的我來說是一個難以望其項背的層次。
至於 AlphaGo 是否有可能統治人類？也許吧！但就現階段來說，應該還是跟一般程式一樣有其侷限性，大概就是止於模仿人類學習圍棋的程度，否則這次就不會只是挑戰圍棋了。所以要說 AlphaGo 有什麼更進一步的能力似乎還早了點，因為歷來這麼多棋手也沒看過有哪個職業被棋手取代，即使 AlphaGo 贏了棋，最應該擔心失業的是棋手才對吧！就像對點鈔機稍有概念的人看到這個文章的標題，應該都會一笑置之，畢竟點鈔機是專門設計用來點鈔，要用來清點書本頁數都不太可能！
2016/2/25
使用 iWork 的 Pages 來撰寫軟體開發文件
撰寫軟體開發文件在團隊裡往往都是一個讓人愛恨交織的課題，開發人員的身體裡大多都帶著討厭寫文件的基因。所以在時程不充裕的案子中，文件撰寫一定是背負著拖累時程的原罪、頭一個被捨棄的工作項目。但是在接手既有系統時，又期昐原本系統的開發相關人員能留下文件，哪怕是文字殘缺不全、沒有隨著最新的程式碼同步修正，就算只有隻字片語也多少能做為一窺系統設計全貌的契機。
文件本來的目的就是用來溝通(不過制度僵化的公司也許會拿文件來做神主牌)，而用什麼工具來撰寫文件會是個影響這項工作成效的關鍵因素。用 iWork 的 Pages 來撰寫軟體開發文件？用慣微軟產品組合的人第一個想法可能會是：為什麼這麼想不開？既然是要溝通，撰寫出來的文件內容就要具備可交換性。如果只是要文件內容可以被閱讀，那麼能輸出成類似 PDF 的通用格式的工具問題都不大。但如果牽涉到協同合作、共用編輯之類的情境，文件的格式轉換工作將會是一場災難。就算是微軟的 Word 在不同作業系統之下，呈現出來的效果也沒有辦法百分之百完全相同，更何況是使用二個設計概念不同的工具要進行轉換。
再者，以功能豐富度的角度來看，使用 Microsoft Word 上手之後，會覺得 Pages 像是 Windows 裡的 WordPad 加強版。Microsoft Word 在發展了這麼多年之後，考慮到許多內容呈現、版面排列、資訊彙整等除了文字以外附帶的功能，甚至也有為亞洲語系的特殊需求做設計，都大幅地增加文件製作者在使用上的彈性。反觀 Pages 在功能上則感覺不到有任何重大地進展或是想要向 Word 致敬的意圖，就是維持在大概夠用的程度。
的確，考慮到文件的可交換性，Pages 並不是個值得推薦的選項，除非整個團隊的工作環境都籠罩在蘋果光之下，不是使用 OSX 就是以 iOS 做為平台。如同大多數以 Windows 為平台的團隊會選擇使用 Microsoft Word 做為文件撰寫工具的第一首選，因為以 Word 普及的程度，就算開發團隊以外傳入的文件也有很大的機率是使用 Word 來撰寫。而 Pages 功能的豐富度上也遠不及 Microsoft Word，如果可以接受使用 Windows 裡的 WordPad 來撰寫開發文件、或是更原始地使用記事本來製作文件，在 OSX 上 Pages 才相對地是可以列入考慮的選項。
那為什麼要還要考慮使用 Pages 來撰寫文件？
隨著 iOS 成為行動裝置平台的顯學，改變了軟體開發的生態與銷售模式，為軟體開發從業人員帶來了不同的機會。想要靠開發 iOS App 來賺錢，受限於 Apple 的策略，所有開發的工作環境就必須要和 OSX 綁在一起。但日常事務性的作業卻不見得可以一併移轉，仍然要在 Windows 的平台中進行，而形成雙作業系統的狀態。如果要像過往在 Windows 平台一樣，以 Word 為撰寫文件的工具，就算公司有購置 Word 授權，也是 Windows 平台上的授權沒有辦法移轉到 OSX 上。所以勢必需要二份的授權費用，對許多團隊來說要再提撥額外的授權預算是沈重的選項。
所以，在 Apple 宣佈 iWork 免費下載之後，在不考慮其他開源的文書編輯軟體的情況下，Pages 是目前在 OSX 上可以直接取得、堪用、門檻最低的選擇。
只不過要拿 Pages 來撰寫文件在作法上還是要有一些調適，文件的可交換性降低了，就沒有特別期待能夠使用於共同編輯的情況，主要是著眼在做為「記錄設計軟體過程中思考路徑」的用途之上。設計通當都是反覆構思的循環，在設計的初始階段，為了釐清設計的重點，Mind Map 是一個值得推薦的工具。隨著工作的演進，我習慣用文字記錄設計上的一些想法，做為進一步文件的基礎。一般的純文字編輯器並沒有辦法滿足我的需求，畢竟思考是一個很容易被中斷的活動，像是生理時鐘、外在環境的干擾，甚至思考本身也會因為總總的想法造成設計上的分歧點，需要不斷的放下、回復。使用 Pages 可以做一些顏色、排版上的變化來幫助我記錄思考中斷的位置，讓我可以接續原本思考的狀態，做為後續調整設計方向的依據。
Pages 只是功能上和 Word 相比有一些不足之處，但仍是一個功能健全的文書編輯工具。如果是講究一點，還是可以套用 Pages 內建提供的範本，讓這些內容能夠直接輸出成一份俱專業感的正式文件。至於要和團隊中既有不同工具的文件體系銜接，就只能依靠 Pages 的格式轉換功能，和後續版面調整的功夫了。
文件本來的目的就是用來溝通(不過制度僵化的公司也許會拿文件來做神主牌)，而用什麼工具來撰寫文件會是個影響這項工作成效的關鍵因素。用 iWork 的 Pages 來撰寫軟體開發文件？用慣微軟產品組合的人第一個想法可能會是：為什麼這麼想不開？既然是要溝通，撰寫出來的文件內容就要具備可交換性。如果只是要文件內容可以被閱讀，那麼能輸出成類似 PDF 的通用格式的工具問題都不大。但如果牽涉到協同合作、共用編輯之類的情境，文件的格式轉換工作將會是一場災難。就算是微軟的 Word 在不同作業系統之下，呈現出來的效果也沒有辦法百分之百完全相同，更何況是使用二個設計概念不同的工具要進行轉換。
再者，以功能豐富度的角度來看，使用 Microsoft Word 上手之後，會覺得 Pages 像是 Windows 裡的 WordPad 加強版。Microsoft Word 在發展了這麼多年之後，考慮到許多內容呈現、版面排列、資訊彙整等除了文字以外附帶的功能，甚至也有為亞洲語系的特殊需求做設計，都大幅地增加文件製作者在使用上的彈性。反觀 Pages 在功能上則感覺不到有任何重大地進展或是想要向 Word 致敬的意圖，就是維持在大概夠用的程度。
的確，考慮到文件的可交換性，Pages 並不是個值得推薦的選項，除非整個團隊的工作環境都籠罩在蘋果光之下，不是使用 OSX 就是以 iOS 做為平台。如同大多數以 Windows 為平台的團隊會選擇使用 Microsoft Word 做為文件撰寫工具的第一首選，因為以 Word 普及的程度，就算開發團隊以外傳入的文件也有很大的機率是使用 Word 來撰寫。而 Pages 功能的豐富度上也遠不及 Microsoft Word，如果可以接受使用 Windows 裡的 WordPad 來撰寫開發文件、或是更原始地使用記事本來製作文件，在 OSX 上 Pages 才相對地是可以列入考慮的選項。
那為什麼要還要考慮使用 Pages 來撰寫文件？
隨著 iOS 成為行動裝置平台的顯學，改變了軟體開發的生態與銷售模式，為軟體開發從業人員帶來了不同的機會。想要靠開發 iOS App 來賺錢，受限於 Apple 的策略，所有開發的工作環境就必須要和 OSX 綁在一起。但日常事務性的作業卻不見得可以一併移轉，仍然要在 Windows 的平台中進行，而形成雙作業系統的狀態。如果要像過往在 Windows 平台一樣，以 Word 為撰寫文件的工具，就算公司有購置 Word 授權，也是 Windows 平台上的授權沒有辦法移轉到 OSX 上。所以勢必需要二份的授權費用，對許多團隊來說要再提撥額外的授權預算是沈重的選項。
所以，在 Apple 宣佈 iWork 免費下載之後，在不考慮其他開源的文書編輯軟體的情況下，Pages 是目前在 OSX 上可以直接取得、堪用、門檻最低的選擇。
只不過要拿 Pages 來撰寫文件在作法上還是要有一些調適，文件的可交換性降低了，就沒有特別期待能夠使用於共同編輯的情況，主要是著眼在做為「記錄設計軟體過程中思考路徑」的用途之上。設計通當都是反覆構思的循環，在設計的初始階段，為了釐清設計的重點，Mind Map 是一個值得推薦的工具。隨著工作的演進，我習慣用文字記錄設計上的一些想法，做為進一步文件的基礎。一般的純文字編輯器並沒有辦法滿足我的需求，畢竟思考是一個很容易被中斷的活動，像是生理時鐘、外在環境的干擾，甚至思考本身也會因為總總的想法造成設計上的分歧點，需要不斷的放下、回復。使用 Pages 可以做一些顏色、排版上的變化來幫助我記錄思考中斷的位置，讓我可以接續原本思考的狀態，做為後續調整設計方向的依據。
Pages 只是功能上和 Word 相比有一些不足之處，但仍是一個功能健全的文書編輯工具。如果是講究一點，還是可以套用 Pages 內建提供的範本，讓這些內容能夠直接輸出成一份俱專業感的正式文件。至於要和團隊中既有不同工具的文件體系銜接，就只能依靠 Pages 的格式轉換功能，和後續版面調整的功夫了。