2016/9/22

軟體的盈利模式

當辛辛苦苦開發好一個應用程式、一套系統,如果想要期望這個軟體能夠養家活口、甚至是榮華富貴,就必須要思考一個問題:如何向使用者收錢?

軟體可以收錢的模式,大致可分為幾種類型:
  • 依功能計價
  • 依資料容量計價
  • 依使用人數計價
  • 依使用時間計價
  • 依內容與服務計價

2016/8/4

如何使用程式更改 Activity 中 App Bar 的背景顏色

一般在設計 Activity 時,會設定 Activity 的佈景主題,也就是套用某一個特定的 Theme。如果今天在啟動 Activity 後想要動態調整 App Bar 的背景顏色,可以在另外指定 Activity 所套用的 Theme 後重新啟動 Activity。然而,這樣的程序只是為了換個顏色似乎有一點小題大作,所以在這篇文章中提供了另外一種不用重新啟動 Activity 的方法。

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

行動裝置的資料存取選項

今天如果是要開發一個在行動平台上的應用程式,應用程式的功能要夠豐富,就勢必得牽涉到資料存取的議題。否則使用者在操作程式時,就如同和海底總動員的 Dory 對話一般,每次開啟程式都只能反覆地進行基本的作業、無法累積操作狀態的資訊。

2016/5/30

使用 PMP 的 EVM 追蹤軟體開發進度

軟體開發在追蹤上的難題

一般在企業內部要開始一個軟體開發的專案有很多時候是老闆忽然靈機一動地問說:「我們來開發一個某某系統,你覺得需要多久?」有經驗的人聽到這個問題時就知道這是考驗專業能力與政治敏感度的時刻,因為這是一個兩難的問題。在好傻好天真的時期會想:「天啊!系統要做到什麼程度、有多少人參與、要給多少資源都還沒確定,就要押完成日?」會有這樣的想法不意外,就像是要蓋一個房子,連要蓋幾層都不確定、設計圖都還沒畫,更別提建材和工人都還沒有著落的情況下就要問何時入住,回答得出來才有鬼!

2016/3/25

驚!點鈔機進化到足以全面取代人工作業

日前 DeepHand 發表了一款新的點鈔機取名為 BetaCo,該點鈔機具備了可自我調整力道的滾輪、高精度的感應器,並且提昇了對於各種鈔票狀況的學習能力,能夠在收集一定數量的資料後適應並清點各種不同情況的紙鈔。雖然前一代的點幣機成功地擊敗了世界知名的點幣好手,但由於紙鈔具有柔軟的特性,而且有可能因為髒污、破損、折痕等各種情況導致機器在判讀上的失誤,難度相較於硬幣要高出好幾個等級,所以這一款點鈔機問世對於產業界來說有一定的指標意義。

DeepHand 的技術人員透過大量地餵入各種情況的鈔票,來讓機器收集資料、建立樣本庫,以便機器在面對不同情況的紙鈔時能更準確的調校內部機構的出力及感應器的門檻值,正確地算出鈔票的張數。為了更進一步驗證機器的能力,於是 DeepHand 向世界排行有數的點鈔快手發出比賽的邀請。

比賽由目前排名第四的選手出陣,一共進行五局,進行的方式是每局準備一落十九疊張數不等的舊鈔,共十九落,由雙方先後以計時的方式進行點鈔並各自記下結果。下一局對調雙方的點鈔順序,由前一局後數的一方先進行點鈔。結果於該局雙方點鈔完成後同時公開,如果雙方點出的張數都正確,則以進行的時間決勝負、時間較少者獲勝。

結果,戲劇性地 BetaCo 以壓倒的秒數就取得前三局的勝利,贏得與人類對戰的比賽。接下來的二局雖不影響賽果,BetaCo 仍以一勝一負優異的成績作終,在這次的比賽 BetaCo 以四比一的比數大勝對手。唯一落敗的一局,是因為對手先攻的情況之下,在數鈔時目視到二張完全貼合的鈔票但未將其分開,而後攻的點鈔機判斷失誤以致少算一張而出現數字不正確,將勝利拱手讓人,否則以時間來看機器還是技高一籌。

對於這樣的比賽結果,大多數的人認為是人類的最大失敗、該點鈔機將全面取代所有的人工。於是人人自危、擔心飯碗不保、生計無以為繼,更甚者有人喊出人類末日到了。針對這樣的後續發展,人們是否應該開始省思點鈔機所可能帶來的危害、是否該針對點鈔機的發展計劃做出限制?



以上內容皆為杜撰、如有雷同純屬模仿。應該不會有記者真的把上面的內容拿去做成一篇報導,最後引起軒然大波吧...

不過,這篇內容和軟體開發有什麼關係?BetaCo 應該是沒有,但 AlphaGo 就義意重大了!有寫過程式的人應該都會同意,程式是開發團隊對於特定領域經驗的一種延伸。軟體開發過程中的一項核心工作就是把要被程式取代的工作內容給規則化,以便開發人員可以編寫成程式碼。

開發團隊的成員就像是在戰場上擬定戰略的主帥,主帥憑著自己的經驗預想戰場上可能出現的情況,並且逐一設定好應對的標準程序。一旦開戰主帥只能置身事外,完全讓部隊照著程序執行,如果一切和預想的一樣,則戰勝的結果可期。然而,事先訂好的規則畢竟是死的,再怎麼周詳仍然會有盲點。所以,反之,出現料想之外的情況,前線部隊將無所適從,則會一路潰敗,以致兵敗如山倒。由此可知,如何把規則明確且周詳地定義出來,這是團隊的功力所在,也是程式品質優劣的關鍵。

以圍棋這個領或來說,寫能下棋的程式不是什麼問題,市面上隨便一本入門書都已經把所有的規則定義好了,只要按圖索驥即可。只是這樣的程式並沒有辦法下贏對手,甚至有可能輸了都不知道。倒底要如何才能贏?我想就連當今棋王也不見得能夠說出個所以然!AlphaGo 的開發團隊能夠把抽象的圍棋致勝規則給歸納出來,並且落實到程式中,還能夠真的在棋局中獲勝。對於現階段的軟體開發工作而言,是一項了不起的成就、一個重要的里程碑。也讓在軟體界打滾了一陣子,但才能平庸、學藝不精的我來說是一個難以望其項背的層次。

至於 AlphaGo 是否有可能統治人類?也許吧!但就現階段來說,應該還是跟一般程式一樣有其侷限性,大概就是止於模仿人類學習圍棋的程度,否則這次就不會只是挑戰圍棋了。所以要說 AlphaGo 有什麼更進一步的能力似乎還早了點,因為歷來這麼多棋手也沒看過有哪個職業被棋手取代,即使 AlphaGo 贏了棋,最應該擔心失業的是棋手才對吧!就像對點鈔機稍有概念的人看到這個文章的標題,應該都會一笑置之,畢竟點鈔機是專門設計用來點鈔,要用來清點書本頁數都不太可能!