解開 APP 百萬下載次數的成就

最近某支 APP 達到一百萬人次下載了，個人第一個想法是如果下載次數可以換成錢就好了，目前大概除了每個月廣告的零用錢，和履歷上可以多寫這一項成就以外，大概就沒啥屁用了。避免本篇走向流於無意義的自我感覺良好閃光文，寫一些心得給想寫 APP 賺錢的人分享。

先說本人的背景，主力 Java，寫過韌體（CP / Merge 也算的話），早期用 Swing 寫桌面 APP，SQL 會用但不到 DBA 等級，網頁幼幼班（CSS/HTML/JS 看得懂可以改從無到有就有點強人所難），後台比較熟 Java EE 相關（Tomcat/JBoss 7/Wildfly），雲端服務看到會接看看（Amazon/Google/Openshift/Parse/Memcache...反正需要什麼就接什麼），SA 技術也是幼幼班（Linux 會 ps 會 ls 真的要用還是要查鳥杯杯）。技術講完講其他，有結婚有小孩有一份正職，所以只能用六點下班後的時間搞這些阿沙布魯的東西，以前很愛畫圖，所以美工自己來，勉勉強強可用，然後前台到後台都有碰過，所以基本上整個 APP 開發所需要的知識都算有涵蓋到。

因為技術點上 Java 點的比較多，所以理所當然就是開發 Android APP，需要的成本除了時間以外（個人是覺得時間最貴啦），開發者帳號終身約臺幣800元（如果你沒被停帳號的話，後面會提），其他的花費不一定，但基本上我花過的大致有雲端服務的費用（例如：Amazon S3 儲存檔案），買素材的費用（例如：圖示），下廣告的費用（例如：臉書廣告）。

做 APP 不考慮到人力成本，一定是做遊戲要不就是搞出一個社群然後這群人會生內容出來（例如：臉書）。個人覺得寫遊戲的物理一定要很好，另外企劃和對遊戲系統的平衡都要很有料，真的不是買一本書，弄個飛機射子彈還是青蛙過街就有人會買單了。再來是社群的東西，一來要經營社群，二來後台未來也不是隨便一台 PC 搞定，三來該有的社群也都有了，人家為什麼要用你的 APP。考慮以上，果然還是跟 Sam Lu 大講的差不多，只有工具類 APP 的規模和後續維護的心力比較符合我能投入的時間。

至於 APP 的主題，我自己是開發前問自己三個問題，如果都是正向的，才會花時間下去弄，寫出來給各位參考一下：

1. 使用者是誰？
2. 需要每天用嗎？
3. 一定得用手機嗎？ 

基本上就是強迫練習自己找問題來用技術解決，而不是看到新技術或是想練技術才找題目。成效如何？如果一萬人次下載就算成功，做了10+個 APP 有五個 APP 達標，所以這三個問題基本上應該還算可以刪掉一些無用的 APP 點子吧！

如果真的有幸，APP 做出來了，也上架了，我自己推廣的方式大概就是到 PTT / Mobile 01 寫推薦文，如果有相關的論壇也會上去推推文。付費的話有玩過 Google AdWords / Facebook。不管免費或者是付費，我自己的經驗效果都不會是很好，PTT / Mobile 01 頂多就是當天會有些人下載，隔天就沒了。付費廣告則是瀏覽量一直都有，但實際安裝人數並沒有上來，按點擊收費看起來也是只要點到 Google Play 就算你錢了，實際上從 Google Play 點安裝的轉換率並不會是100%。個人碰過比較有效的方式，一個是部落客名人/媒體推薦，（但這種可遇也不可求），第二個是 APP 搜尋結果/排行在很前面，新上架一個月有進“最新熱門項目”前三名，那以後就輕鬆得多，搜尋結果至少要排進第二名，不過現在 Google 會管你描述裡是不是有塞垃圾敘述，一不小心又會被下架，等等會提到。

再來提到違規了，說到違規我應該可以說是專家，個人違規有發生過以下項目：

1. 被人檢舉內容不符合普級（但明明三點不露，同類型 APP 也是普級）。
2. APP 描述頁面有重複詞彙（我不是亂塞，就是寫個“關鍵字：xxx，yyy，zzz”這種等級）。
3. 侵犯智慧財產權（當時一堆人都做進擊的巨人也都還活著）。
4. APP 內容裡頭有品牌名稱被說意圖假冒是別人做的 APP。

不說心得，直接說說要注意的事項，一個帳號只要犯三次，整個帳號會被終止，連同帳號底下其他的 APP 都會被下架，所以最好的方法是一個產品一個帳號，免得被拖累。再來基本上申訴也沒屁用，建議犯規一次就可以開新帳號準備了。

最後，回答大家可能最關心的問題，到底有沒有辦法賺錢，看我還在上班就知道沒有辦法賺到大錢，個人手上 APP 所有的使用者大概是45萬人左右，然後都是工具類，使用者大概點開來看個10分鐘就了不起了（抱歉我 APP 沒塞 GA 所以沒有詳細數據不是我不提供），這樣子的前提下，一個月的零用錢大概是5000~9000新台幣的水準，給各位參考一下。

當然啦我沒有辦法全心全意寫出並且經營一個很大很棒的點子，不過最前面有介紹我的個人背景，看官可以比對一下，也許你單身你技術強你有人脈你有錢請人，那我相信一定可以賺比我多很多啦！最後大家點一下小弟全家合力經營的 APP 作品集一和作品集二（Google Play 連結無毒），看看有沒有什麼剛好合用的 APP，下載或是推薦，小弟感恩不盡！

最後的最後，想當初讓一隻超爛手機（記得是台哥大的 A3）能超順瀏覽小海嚴選的美女圖，真的是超爽的。牛頭不對馬尾的舉例，其實我只是想說，下班以後寫程式這件事本身就是要有愛才做得到的，如果你夠幸運你會賺到大錢，如果不幸只有幾百人用，想想看有幾百人在用你寫的東西，不也是很爽的事情嗎！

Amazon S3 + Cloudflare 節省網路流量

手頭上一個寵物專案有用到 Amazon S3，就單純後台抓圖放到 S3，然後前台去下載圖片，最近使用者多了起來，雖然前台已經優化過了（前台會儲存已經看過的圖片），每個月會收到四美金的帳單，這時候才認真研究了 S3 的計費方式。

S3 的計費可以拆成三塊：

• 儲存：檔案佔的空間。
• 請求：HTTP Get / Post ...
• 資料傳輸：檔案傳輸的流量。

整個列下來發現，幾乎都是資料傳輸惹的禍，大概40張0.2MB的圖片，結果一個月來了30GB的流量，看來光是前台有優化不夠，每個使用者一個月只抓一次就可以把我打死了。

研究了一下常看到別人用的 Cloudflare，它提供 CDN（Content delivery network ）功能的雲端服務，如此若 Cloudflare 可以直接將圖片快取下來，使用者就不會跑到 S3 去下載圖片，藉此節省 S3 資料傳輸產生的費用。

廢話說多了開始進入正題，網路上看到的做法，要先有自己的網域，把網域對應至 Amazon S3 bucket 位置，最後將自己的網域上的 Name Server 指到 Cloudflare 上。



以上圖為例：

1. S3 設定：
1. 我有一張圖檔叫 bar.png。
2. 新增 bucket，取名為 files.foo.com（必須要跟 S3 上的 bucket 名稱一致）。
3. 圖檔放在此 bucket 內。
4. 此時可以透過 http://files.foo.com.s3.amazonaws.com/bar.png 下載圖片。
2. DNS 設定：
1. 我有一個自己的網域叫 foo.com，我建立了一個子網域 files.foo.com 要拿來指向 S3。
2. DNS 上新增 CName: files <-> files.foo.com.s3.amazonaws.com
3. 此時，就可以透過 http://files.foo.com/bar.png 下載圖片，接下來要接上 Cloudflare。
3. Cloudflare 設定：
1. 在 Cloudflare 上匯入 foo.com 網域，匯入後你原先那台 DNS 上的設定都會被匯入，你可以決定哪些設定要走 Cloudflare 哪些不要。
2. 看到 CName: file <-> files.foo.com.s3.amazonaws.com，設定這項設定要走 Cloudflare。
3. Cloudflare 會提示你因為 DNS 還沒將 Name Server 指過來，所以還沒連接上。
4. DNS 設定：
1. DNS 上將 NS 指到 Cloudflare 分配給你的 Name Server。
2. 此時，透過 http://files.foo.com/bar.png 下載圖片，多試幾次，用瀏覽器看 http header 會發現 server 從原本的 s3 變成 cloudflare，就代表設定已經生效了！

成果如下：

• Cloudflare 節省了我原本 85% 的流量。
• 原本每月要繳給 Amazon 4 美金，降至 0.6 美金。

Blogger 自動發文

需求很簡單，希望餵個標題跟內容，就自動產生文章貼到 Blogger 上，但弄的跌跌撞撞的，紀錄一下，留給麵包屑給未來的自己和有需要的人。

先來看一下官方作法 - 新增 Post 的做法，可以透過 Restful Web API 或是官方提供的 Java Library 來完成。理想上是這樣，看起來很間單，那為什麼我會跌的狗吃屎？

Restful Web API 的方式，參考指南這一篇，才發現 HTTP Header 還要填入 Authorization: /* OAuth 2.0 token here */，基本上就還是要透過 OAuth 2.0 的方式得到 token 才走的下去。那換成官方提供的 Java Library，反正連 Sample Code 都有了應該很簡單，貼上去才發現範例中的 OAuth2Native 根本沒有，需要自己實作。

做到這邊我心已死，成功之路沒有捷徑，只好去翻這兩份文件來看：

• Using OAuth 2.0 with the Google API Client Library for Java
• OAuth 2.0 and the Google OAuth Client Library for Java

大概的問題就是想辦法通過 OAuth 2.0 取得 Token，再來拿這個 Token，看是要用 Restful Web API 還是 Java Library 來新增 Post 都可。步驟如下：

1. 到 https://console.developers.google.com/ 下的 API 和驗證>API 把 Blogger API 啟用。
2. 到 https://console.developers.google.com/ 下的 API 和驗證>同意畫面 把該填的資訊填一填。
3. 到 https://console.developers.google.com/ 下的 API 和驗證>憑證>OAuth 建立用戶端 ID，類型選取已安裝的應用程式（我的 APP 是一個桌面執行程式）。
4. 此時會得到用戶端 ID，用戶端密碼。
5. 修改官方範例碼如下：

當執行這段範例碼時，在 Po 文之前，瀏覽器會自動打開，告知使用者有應用程式嘗試要存取你的 Blogger ，使用者同意之後就會自動 Po 文。

但實際上這段程式碼還是需要人為介入（在瀏覽器上同意），其實在 https://console.developers.google.com/ 下的 API 和驗證>憑證>OAuth 建立用戶端 ID，有一個類型叫做服務帳戶（Service Account）可以自動通過 OAuth 認證，但因為 Blogger 平台不支援用服務帳戶來發文，所以我們會得到 HTTP 403 授權失敗的錯誤。

PS: Google 關於通過 OAuth 的範例程式碼

建立自己的 Docker Registry

官方已經提供了很方便的 Docker Hub，讓我們能把做好的 Docker 映像檔分享，就像我們在 GitHub 分享程式碼專案一樣，但上面的映像檔都是公開的，所以我們需要建立自己的 Docker Registry。本文最下方直接提供了安裝和測試的相關步驟。



官方直接提供了 Docker Registry 的 Docker 映像檔，直接找台有安裝 Docker 的實體機器把這個映像檔跑起來就建立好一個自己的 Docker Registry。以上圖解釋，我在140.96.101.235這台電腦上裝了 Docker 也跑了一個 Docker Registry 的 Docker 容器（映像檔執行起來的實體就叫 Docker 容器），電腦1就能把映像檔上傳至 Docker Registry，電腦2就能從 Docker Registry 下載映像檔。



而實際上，畫得更詳細一些，140.96.101.235 是一台 Linux 主機，上面跑了個 Docker 容器（裏頭執行 Docker Registry），這個 Docker 容器的 port 5000 綁定實體機器的 port 5000，所以外部連到140.96.101.235:5000 的流量就會導到這個 Docker 容器的 port 5000。另外，這個 Docker 容器將儲存映像檔的路徑，與實體機器的 /home/vagrant/docker/registry 這個資料夾同步，如此不用進入 Docker 容器就能在實體機器上看到大家上傳的映像檔，也方便管理者可以用平常備份的方式替映像檔做備份。

本月關於 Docker 的三篇文章分別說明了為何要用 Docker、如何安裝 Docker、建立私有的 Docker Registry，看完的人可以開始試看看用 Docker 複製上線專案的正式/測試環境，或是試著用 Docker 建立新技術/新框架的開發環境。

為何要用 Docker

因為工作內容比較偏向程式開發這塊，當初接觸 Docker 也是很不能了解這跟一般的虛擬機器差在哪裡，就程式部署上去就好，幹嘛那麼麻煩？仔細回想過去一些覺得很麻煩的問題，答案就呼之欲出了！

• 想要玩個新技術，但要先裝環境和函式庫，都弄好半天又過去了，還沒玩到新技術心就涼了。
• 上述環境在公司弄好了，回家也想要玩，又要再弄一次。
• 上述環境不小心裝壞了，比如說 mac 上同時裝 python 2 和 python 3，搞到自己原本的環境都爛了。
• 整個專案要在自己的電腦，測試環境跑過，在上正式環境，部署之前把環境都弄成一模一樣就飽了。
• 安裝時都有乖乖寫安裝手冊，過了半年要裝新的環境，卻發現半年前的函式庫抓不到了。
• 設備移機...

以上問題只要使用 VM 就可以解決了，做好第一次安裝苦工，做成映像檔，以後就是利用映像檔複製出新的 VM。

那為什麼要用 Vagrant，因為第一次安裝用 VM 還是要走一次安裝流程（找 ubuntu.iso > 安裝 > 設定），更多的時候我只是要一個純命令列的 linux 環境再加個 SDK 和 Framework，透過 Vagrant 你可以在 http://www.vagrantbox.es/ 上找到別人做好的環境，不到三分鐘就可以做你真正想要做的事情，而不是一直在裝環境。

那為什麼要用 Docker，相較於 Vagrant 實際上是建立在 VMware / VirtualBox 上的虛擬化工具，Docker 是屬於作業系統層級的虛擬化，白話就是 Docker 更加輕量化的虛擬化工具，開啟速度快，吃的資源少（一台主機能開更多個 Docker 產生的虛擬機器），而且實際用起來跟 Vagrant 一樣好用。

個人不負責任白話解釋：

• VMware / VirtualBox：第一次安裝還是要花時間，但裝完至少匯出映像檔可以重複利用。
• Vagrant：用官方/別人分享的映像檔快速安裝環境，實際上還是會利用 VMware / VirtualBox 建立新的 VM。
• Docker：用官方/別人分享的映像檔快速安裝環境，而且更快，更小。不用安裝 VMware / VirtualBox。

以下圖來舉例，若我突然要用 Tomcat 來寫 Java Web 專案，直接先找別人做好的 Docker 映像檔（ubuntu + JAVA SDK + tomcat），利用映像檔產生 Docker 容器（想成是一個 VM 即可），你可以連進 Docker 容器就像用 SSH 一樣進去下指令，透過 tomcat 網頁部署 jar 檔，開發到最後還能把整個 Docker 容器再做成一個新的映像檔，其他人只要有安裝 Docker，就能馬上在自己的電腦上把環境包含你寫的 Java Web 專案跑起來！超級方便！



接下來會試著安裝自己的 Docker Registry（想成自己的 GitHub），模擬企業內部會採用的使用模式，RD 把應用程式跟環境包成映像檔上傳至 Registry，測試/部署人員直接在 Docker Registry 下載映像檔，複製出一樣的環境。

三分鐘用 Vagrant 裝好一個 Docker

單純裝 Docker 應該不用一分鐘，因為指令下完就裝好了，我因為不想弄髒我的環境，所以這邊在做的是，在我的筆電上用 Vagrant 建立一台安裝好 Docker 的 CentOS 7 虛擬機器。

Vagrant 是一個建立在 Virtual Box 之上的工具，可以很快從無到有用指令的方式安裝好一台乾淨的 Linux，而不需要從建立虛擬機器開始，然後還要下載 Linux 映像檔來安裝。

Docker 可以想成是一個更輕量級虛擬技術（啟動速度快，耗費資源少，存放空間小），也可以是想成是虛擬化技術的 GitHub。Docker 映像檔中除了專案外，還能包含專案所需要的環境，開發人員/測試人員/維運人員透過公開或自己架設的 Docker 映像檔倉庫，同步一模一樣的專案環境，如此可以減少環境設定造成的問題，也節省分別架設開發環境/測試環境/正式環境的時間。

廢話說很多，安裝方式請直接拉到最下方。關於 Docker 應用，等到自己玩幾個 Hello World 再來獻醜。

Facebook 買廣告

推廣 APP 是件麻煩事，目前看到大家的做法（我們自己也是）貼 PTT 貼 Mobile 01 貼論壇，有關係就請部落客推薦一下，有錢就買 Google 廣告，這次我買的是 Facebook 廣告，不專業筆記一下，分享給看到的獨立開發者。



怕爆預算的話，基本上你可以設定每天費用上限，或是替整個廣告播放期間設一個費用上限。

費用的計算分成，別人有點擊廣告才算錢，或是按曝光次數來算錢，不過我建立廣告時行銷活動目標是選“增加應用程式安裝次數”，就只能選擇前者。

它後台報表可以直接看到 APP 安裝的次數，不過我的一直顯示為零，仔細去看文件，這部分應該是要後台去註冊我是這 APP 的擁有者，加上 APP 裡頭要包 Facebook 的 SDK，才能偵測到 APP 安裝的次數。

再來就看看成效了，講一下自己的心得了。

廣告我買了五天

• 花費了我30.38刀（約942新台幣）
• 曝光了14,278次
• 臉書後台顯示點擊了369次（有點去 Google Play 看）
• Google Play 後台顯示安裝了111次（真的有下載來安裝的）

所以大概就等於

• 每天大約有22人下載（姑且先假設都是看到臉書廣告點的）
• 一個人下載我需要花8.5新台幣

APP 有上到該分類最新熱門免費項目的第八名，也有上該分類的上升速度最快的榜單。就申請難易度較低，費用門檻也不高。

廣告播放能限定使用者組群/使用設備/使用網路，目前我是指定28歲~43歲，住在台灣，使用 Android 手機，使用 Wi-Fi，以上條件的情況下才播放廣告，這些篩選條件至少可以排除用 iOS 手機然後點擊（我要被收錢）然後發現是 Android APP 很囧。

比照之前洗版請親友推薦，或是上網自我推薦，雖然要出錢，但的確下載數據是有往上跑，而且費用跟下載是正相關，不至於是肉包子打狗。在初期階段想要衝榜，在沒人氣，又沒想用網路上所謂衝榜的服務（開發者應該常常收到類似的廣告信），這次的經驗是還蠻不錯的，如果有人有更便宜又更有效的廣告途徑，歡迎或來信留言討論。

Spark - Java 輕量級的 Web 框架

這跟處理巨量資料的 apache spark 無關！

如果有時候只是要寫個沒幾個人用的 Restful API，或只是想要有個 HTTP 接口（透過 get/post）來呼叫我們寫好的 Java SE 程式，如果對架設 tomcat / Java EE Server 又不熟悉，那可以考慮用 Spark！

Hello World

Spark 2 以後需要用到 lambda 語法，需要安裝 Java 8。如果只有 Java 7，請找 Spark 1 或是去玩 play。

以 Eclipse 為例，安裝 Spark 方法有兩種：

第一種比較簡單，直接建立 Maven 專案，在 pom.xml 加入對 spark 的 dependency 就好了。

第二種就到 github clone 下來，不過實際建立時，我還是得把這專案轉成 maven 專案，才能利用 pom.xml 把其他要用的 jar 檔抓回來...也可能我太笨沒抓到官方給的提示...

寫一個 HelloWorld.java 包含一個 main 如下：

import static spark.Spark.*;

public class HelloWorld {
    public static void main(String[] args) {
        get("/hello", (req, res) -> "Hello World");
    }
}

直接執行 HelloWorld.java，無需安裝另外的 Web Container，無需任何設定，在瀏覽器打開 http://localhost:4567/hello 就可以看到結果。

Spark 提供的功能

大部份 Restful API 需要的功能都有：

• 指定 URL 路徑。
• 存取 request 標頭/參數/...。
• 回寫 response。
• 處理 session。
• 處理每個 request 前後插入 filter 做前置/後置處理。

除了單純回傳資料，也可以介接 Freemarker 這類的 HTML Template Engine，將要顯示的值以類似 JSP EL 的方式，填到預先寫好的 HTML Template 上。

也可以介接 AngularJS 做出類似 Gmail 這種只有一頁的 Web 網站。

部署

官網上沒有特別寫部屬的方式，試了一下。就直接在 Eclipse 上匯出一個可執行的 jar，執行的目標就指向有 main 的那支 java。

執行匯出的 jar 就會在本機上開啟 Web Server 了（參考下圖）！開發到使用完全就像執行一般 jar 一樣！

參考

• 官網
• Developing Single Page Web Applications using Java 8, Spark, MongoDB, and AngularJS
• Create a REST services layer with Spark

Asus Zenfone 2 (ZE551ML) 入手

原本是使用紅米 note 3G 增強版，用了也快十個月吧，因為最近加入中華電信 4G 的企客方案，又要保留台哥大讓家人網內熱線，所以就開始找新的替代機，需求就是雙卡雙待支援 4G 然後不要超過八千。HTC 820、HTC E9 都很不錯，不過價錢都太貴了，紅米2 雖然便宜但 2G RAM 版本遲遲不在台灣開賣，擺明倒庫存給台灣所以不爽買。

此時 Zenfone 2 出了四個版本，用訂價記憶最快：

• 4990：螢幕 5" HD，但只有單卡，所以打槍！
• 5990：螢幕 5.5" HD(1280 * 720)，雙卡雙待通，已經想買！
• 6990：螢幕 5.5" FHD(1920*1080)，雙卡雙待通，又附快充充電器，ROM 變成 32G，多一千多很多我想要的！理智線已斷！
• 8990：主要就 RAM 2G 變成 4G，業界第一台 4G，但喊爽的，第一時間也沒賣。

3/9 當天就在全家預訂一台 6990 元的版本，後來的故事大家都知道，除了少數第一波的準時出貨，其他通路不是少量加減出貨，大部份都延到四月初"陸續"出貨。小米饑餓行銷好歹是有錢買不到，華碩是你錢都先繳了還要等一個月才有機會拿到。更誇張是預購得都沒拿到，反而很多通信行有現貨，而且還訂價加一兩千賣(新竹詢價)，搞得第一批鐵粉天怒人怨，激怒行銷堪稱一絕！

罵歸罵，最後我還是在 01 二手市集上撿到了一台二手 6990 元的版本，下面就跟原本的紅米 note 比較一下。


左邊是 Zenfone 2 右邊是紅米 note

兩台都是 5.5"，差不多重量，外表質感的話是 Zenfone 2 勝出，軟體跟介面還是紅米 note 比較強，Zenfone 2 的 UI 大概跟原生的差不多(當然是有加了華碩的 APP 和雲端服務)，主題跟圖示替換跟小米不能比，桌面空間那麼大但還是沒有辦法設成 4 * 5 排列，反正玩起來跟 nexus 差不多。


左邊是 Zenfone 2 右邊是紅米 note


左邊是 Zenfone 2 右邊是紅米 note

Zenfone 2 解析度是 1920 * 1080 比紅米 note 1280 * 720 規格上來的強，不過真正使用上，我自己是非常用力看才能明顯看出差距(兩眼要貼在手機上了)。反而是螢幕的顏色跟對比有比較大的差距。

紅米 note 的顏色比較暖，最大亮度比較亮，對比也比較好(黑比較黑)。相反地，Zenfone 2 顏色比較偏冷一些，黑色還是沒有紅米 note 的黑來的黑。不過以上都是兩個放在一起比較才看得出來。



Zenfone 2 全新一開機起來，可用記憶體大概 700 MB，玩了一陣子把我該裝都裝了後(非遊戲玩家，只裝裝社群/社交 APP)可用記憶體大概是 300 MB 左右。

快充的部份試了一下，40 分鐘電量 14% > 67%，光這點我覺得就蠻值得多花一千升到 6990 元這個版本。

WiFi 連線的部份，連家裡/公司/其他手機熱點都沒遇到問題。

Android 5.0 支援雙擊螢幕就開機/關機的功能，這功能在大螢幕手機上(特別電源鍵還給你做到頭頂)相當實用！


紅米 note 戶外 GPS Test


Zenfone 2 戶外 GPS Test

GPS 戶外開起來兩秒就抓到了，同時間紅米 note 看到 9 顆，Zenfone 2 看到 19 顆，但紅米的信噪比(SNR)比較好，準確性反而就紅米 note 比較準。

不免俗，這兩天也把兩個手機去拍照比較一下，只挑了幾個自己比較常會碰到的情境，除了 HDR 其他全部都是預設值也沒開閃光，Zenfone 2 軟體已經更新到最新版，滑鼠滑到照片上會顯示是用哪台拍的，不太早破梗是讓大家自行感受一下。

對焦部份明顯 Zenfone 2 快很多，雖然跟 iphone 5 不能比，但總比紅米 note 拍好，小朋友臉都僵了來的強！

室內只有一般光源：





半開放空間：





物品近拍：





前鏡頭自拍：





戶外晚上：




上圖的原圖裁剪




上圖的原圖裁剪




上圖的原圖裁剪




上圖的原圖裁剪

戶外開 HDR：




上圖的原圖裁剪




上圖的原圖裁剪

目前用下來，除了能夠 4G 上網、快速充電、拍照對焦比較快，基本上我比較喜歡紅米 note，以當初紅米 note 五千不到的價格，還真的是打遍天下無敵手。我想我會等到紅米 note 4G 雙卡版出了，或是小米 note 比較便宜的版本出了，我應該就會跳回去了...

Raspberry Pi B+ 入手順便讓他唱小蘋果

以下會簡單介紹 Raspberry Pi 的用途，安裝 Raspbain 作業系統，最後寫一個 Python 程式讓 Raspberry Pi 透過蜂鳴器唱出世界名曲-小蘋果。廢話不多說直接先 po 成果：

流水帳

Raspberry Pi 出一陣子了，突然想買是因為最近出二代了，價錢不變但 CPU 變四核心，也就還蠻心動的，在 RS 上買含運也不到1200元， 但下完單才發現三月中才能拿到（靠！我是想買來過年玩的誒），就在機器人王國又花了一千七百多買了Raspberry Pi B+ 套餐（多外殼，5V2A 電源 + 金士頓 16G micro SD 卡），現在算算反正我一時用不到很多輸出，應該就直接花五百單買出清中的 Raspberry Pi B 就夠了。總共我買了以下設備：

• Raspberry Pi 2 B（還在海上...）
• Raspberry Pi B+
• b+ 透明外殼（可用在 2 上）
• 5V2A 電源
• 金士頓 class 10 16G micro SD 卡
• 羅技無線鍵盤 k400r（含觸碰板）
• 麵包板
• 杜邦線公+母
• LED
• 電阻
• 蜂鳴器

Raspberry Pi 能做啥？

反正出發點跟百元筆電一樣，是希望大家能以比較低的價格擁有一個能寫程式的硬體，基本上可以想成一台像信用卡大小的電腦，上面跑 Linux 的作業系統，插上滑鼠鍵盤再用 HDMI 輸出到螢幕上就是一台電腦。

因為價格實在太便宜了，除了拿來當電腦用以外，有人會拿來安裝軟體/作業系統，把 Raspberry Pi 搖身一變當成 Web Server，家庭娛樂中心，NAS，電動模擬器來使用。



另外 Raspberry Pi 版子上有一組 GPIO 輸入輸出界面，裝上感應器/攝影機當輸入，裝上馬達/蜂鳴器/LED Matrix 當輸出，輸出輸入都可以透過程式（Python，Java...）的方式來控制，對軟體工程師來說，瞬間突破了只能用鍵盤當輸入，螢幕顯示當輸出的限制，感覺又可以幹很多壞事了...

安裝 OS

我選的是最多人用的 Raspbain，參考官方說明絕對不會錯，大概步驟如下：

1. 格式化 SD 卡
2. 下載 Raspbain
3. 透過特殊軟體將 Raspbain 寫到 SD 卡上
4. SD 卡裝到 Raspberry 後開機
5. 第一次開機會進入設定畫面（鍵盤，語系，開啟 SSH...etc）

裝完後，基本上你就有一台圖形化的 Linux 電腦可用了。

第一支 Script

因為之後這台 Raspberry Pi 可能會拿來拿去，不想每一次都要接上螢幕鍵盤進去看 IP，所以想要一開機就自己把自己取得的 IP 寄到我的 Gmail 信箱，詳細步驟如下：

1. 寫一個 Python Script - send_ip.py （程式碼參考下面）取得 IP 透過 Gmail 寄到你指定的信箱。
2. 寫一個 Script - laucher.sh 內容為執行 send_ip.py。
3. 將 laucher.sh 設定成開機時會自動執行。
1. 將 launcher.sh 拷貝到 /etc/initd
2. sudo update-rc.d launcher.sh defaults # 新增開機執行
3. sudo chmod +x /etc/init.d/launcher.sh # 增加執行的權限

這樣每次開機就會收到 Raspberry 取得的 IP，我就可以用這 IP 來連 SSH。如果屌一點應該要改成用外接 LED 跑馬燈的方式來顯示取得的 IP。

小蘋果

書看再多還不如動手做比較印象深刻，我買 Raspberry Pi 主要是想玩一些硬體的東西，未來搭配程式可以做一些小玩具，第一支程式的目標是讓 Raspberry Pi 唱出小蘋果，當然一開始是完全沒頭緒，只知道用 Python 可以控制 GPIO，GPIO 的訊號可以控制蜂鳴器發出聲音。

一開始是直接 SSH 連進去用 vim 寫 Python，好處是直接在上面跑結果，但 vim 對我來說還是有些難用。後來想改用在 macbook pro 上用 IDE 寫，然後透過 git 兩邊作同步的方式，但實際應用每次修改都要上 commit / push，Raspberry Pi 又要 pull 下來才能執行，感覺更麻煩了。

最終改用 FTP + git 的方式來開發，Raspberry Pi 上裝 vftpd 當作 FTP Server，在 macbook pro 上開發透過 FTP 上傳到 Raspberry Pi（部署至硬體），Raspberry Pi 執行成功在 commit 到 git 上（版本控管）。FTP 上傳這段，應該有 IDE 支援，不過過年時間有限 + 還不確定未來都是用 Python 來開發，就先這樣。

上網找到這影片如下，最後我的接法跟他差不多。

• 硬體部分：透過 GPIO 接上蜂鳴器當輸出。
• 軟體部分：透過 Python （程式碼如下）控制 GPIO 接上蜂鳴器的針腳，改變其發生頻率和播放時間。

最終就可以聽到小蘋果了！

參考：

• using beeper via GPIO and python
• Using PWM in RPi.GPIO
• Arduino 筆記 – Lab6 控制蜂鳴器發聲
• 小苹果-筷子兄弟(完整版带和弦简谱)

結語

整篇文章看完，我們可以得到以下結論：

• Raspberry Pi 不會很貴！
• Raspberry Pi 可以拿來當 Linux Server 用！
• 透過 Raspberry Pi 的 GPIO，程式設計師可以有更多種輸入/輸出的選擇！

Sketch 3 - MAC 上的向量繪圖軟體

原本做圖都是用 inkscape，優點是開源軟體(沒有盜版問題)/免費/跨平台(Linux,MAC,windows都吃)，但自從轉用 macbook 以後，MAC 版的 inkscape 要跑在 X11上，動不動要更新，要不就是開很久根本不知道是不是開不起來，還有我比較笨，一些功能都要找一下，久沒用又要花時間想上次是去哪裡打開的(比如圖層,物件的對齊...)。

有時候只是要做簡單的海報或是示意圖，大概都是用 Google Doc 裏的簡報，優點是雲端存取/簡單好用/物件對齊很直覺，不過就沒辦法做些漸層/陰影/光線...等可以增加質感的設計。

某天在推特上看到推友這一篇 - My Must-Have Mac Apps, 2014 Edition（漫步版），裡面提到

Sketch，这应该是今年对我来说最重要的、让我收获最多的软件了。这是一个矢量设计软件，应该很多人都已经听过或用过，它见长于 Web Design、Mobile Design，它让我一个不懂 PS 的人也可以尝试去画一些东西，比如网站的界面，手机 app 界面和图标等，我现在也用它来画原型（线框图、高保真、低保真图等）。

想到我每次用 inkscpae 都用到很卡很度爛，Google Doc 功能又不夠強大，就怒買一套裝在 macbook 裡了，一套台幣三千多，沒錢買的或是要找破解的可以離開了...

用了幾天下來，心得如下：

• 想要的功能都有，對齊/光影/遮罩...
• 功能放的位置蠻直覺的，不會找不到。
• 網路上有許多別人提供的專案範本，打開來複製頁面就可以用了。
• inkscape 可以 uninstall 了...

順手寫了投影片，讓大家快速了解 Sketch 3 的功能/介面/相關資源，沒啥內容但足夠讓你判斷要不要去買一套來裝了。

Build Android apk 流程

最快產生 apk 的方式當然是用 IDE 匯出就好，但因為我要用客製化的 android.jar 來編譯，還要讓 jenkins Server 能自己 build apk，所以必須要了解 build apk 的流程。

在 Andoid 專案下看到 build.xml 那就八九不離十是用 ants 來做這件事，點進去看大概的思考邏輯就是：

• 會 import Android SDK 的 build.xml，檔案位置會在 ${android_sdk}/tools/ant/build.xml
• 可以利用 ant 命令列帶參數覆寫 property
• 可以建立 ${你的專案}/ant.properties 來覆寫 property
• 覆寫 Android SDK 的 build.xml 裏的 target
• 新增 Android SDK 的 build.xml 裏的 target

到 ${android_sdk}/tools/ant/build.xml 最下面可以看到定義好的所有 target，很明顯要包 apk 需要執行 release 這個 target，執行成功可以看到以下 target 被執行的過程為：

1. -set-mode-check:
2. -set-release-mode:
3. -release-obfuscation-check:
4. -pre-build:
5. -check-env:
6. -setup:
7. -build-setup:
8. -code-gen:
9. -pre-compile:
10. -compile:
11. -post-compile:
12. -obfuscate:
13. -dex:
14. -crunch:
15. -package-resources:
16. -package:
17. -post-package:
18. -release-prompt-for-password:
19. -release-nosign:
20. -release-sign:
21. -post-build:
22. release

這些都搞定之後，就可以根據自己的需求來 修改 property 或是 覆寫 target，這裏才是地獄的開始，Good Luck！

PS：利用指令自動產生專案跟 ants 相關的檔案 > android update project -p ${你的專案}

參考：

• Building an Android app and test project

Jenkins 兩個月心得

寫一下這一兩個月使用 Jenkins Server 的心得，我目前使用的狀況如下：

• Android APP 專案 * 1
• 自動定期查詢 SVN Server，若有更新就開始建構流程。
• 在 Jenkins Server 上安裝 Android SDK，搭配 Android 產生出來的 build.xml 建構 APK。
• 搭配 ANTS 用廠商提供的 jar 簽署 APK。
• 封存最終的 APK（只保留最新10筆），可直接從 Jenkins Server 上下載。
• ASP.Net 專案 * 1
• 手動去 SVN Server 抓 Code，開始建構流程。
• 搭配 Linux Script 針對測試環境 / 正式環境去改關鍵設定檔內容。
• 將 Project 排除掉不需要的資料夾（.git, .svn ...etc）打包成 zip 檔。
• 將 Project / zip 檔上傳至測試環境 / 正式環境。
• Java SE 專案 * 1
• 自動定期查詢 git Server，若有更新就開始建構流程。
• 在 Jenkins Server 上專裝 Java SDK，搭配 ANTS 產生 jar 檔。
• 封存最終的 jar 檔（只保留最新10筆），可直接從 Jenkins Server 上下載。

流水線的建置

基本上所有行為都還是要 Jenkins Server 要先安裝好工具，再找 Jenkins 上有無別人開發好的 Plug-in 去介接這些工具，簡化設定流程。真的都沒有才會考慮用 linux / windows command 的方式去接。

比如要導入 Selenium 進行瀏覽器做自動化測試，那 CI Server 就要先安裝 Selenium 和 Firefox 等，像我目前的 CI Server 只是一台沒有 GUI Shell 的 Linux ，想要用 Selenium 就 GG 了！

方便

一鍵產出檔案，然後網頁上就可以直接下載。我就不用自己包好然後才 mail 寄給大家，之後還要考慮到其他人到底是用哪個版本的問題，直接就丟 URL 請對方下載就好！

一鍵就發佈網站。明明只是改幾行，但部署到主機上有很多眉眉角角（主機位址帳號密碼，哪些檔案不能覆蓋...etc），一定要翻文件才能一步步做，現在一鍵就完成了，若發佈有問題，馬上拉上一版的 Code 一鍵 rollback。

目前這台 Jenkins Server 也只是台 VM，VM 備份出來在其他實體機器上還原就又可以 build code 了，接手的人只要會改 Code 會上版本控管就夠了，這可比寫文件來得實用多了。

陣痛期

痛的點大概就是：

先搞懂什麼是 CI > 搞懂 Jenkins 怎麼使用 > 搞懂 Jenkins 可以做哪些事情 > 搞懂各種專案怎麼建置

考量到現在 IDE 太強大了，很多人（包括我）都只會利用 IDE 產出檔案。但導 Jenkins 就必須要自己跳下來弄懂 Build Code Command，流程和背後的原理，這的確是有心要精進自己軟體開發能力的人不得不去碰的，要不然就會被 IDE 綁定，明明都是 Java Web 專案卻只能用 NetBean 某一版開發？

此外，你做出來的成果是可以被重用的，因為 Jenkins 也不過就是台會做事的主機，而且提供 Web 介面，其他人只要上去按的鈕就開始跑了。這樣的改變，比你拿一個 build.xml 讓其他人去用來的讓人接受...

目前結論

如果你已經有了自己的建構流程（ANTS，Grandle，Script...etc），可以重新把這些東西整合進 Jenkins，其他人也就在不知不覺中用到這些成果。如果你連自動化建構還不了解，那還是先從寫寫 ANTS 開始。

以 Java 來說，寫桌面程式就包一個 jar，寫網頁程式不就包一個 war 然後 FTP 上傳，寫 Android APP 就包一個 apk，初期沒有要導 unit test，code style 檢查這些東西，其實要弄懂的東西也就是如何擺脫 IDE 自己包檔案出來罷了，對很多以前 筆記本 + 命令列 的前輩應該都是一片蛋糕。

對於團隊來說，至少我覺得導入 CI Tool 會減少人員請假或是離職交接所帶來的衝擊。再來考慮到補上單元測試，整合測試，程式碼風格檢查這些東西，能夠大大增加專案發佈的信心和品質。


參考：CI Server 30 - Jenkins總回顧

[讀書心得] 告別瀑布擁抱 Scrum

原本想自己畫一張圖來說明，不過網路上已經看到很棒又很宅的說明圖，就直接引用了。

先說明一下角色：

• Product Owner：就是 PM，客戶需求與開發團隊的橋樑，確認做出來的東西是不是客戶想要的。
• Scrum Master：熟悉 scrum 的人，了解 scrume 流程要做些什麼，有哪些 scrume 工具（ex：看板，燃盡圖...etc）可以用。
• Team：就是實際在開發的開發成員啦。

接下來就直接看圖說故事了。

圖片來源：http://www.scrumprimer.org/en/anime

整個流程可以分成三大塊：

• Sprint 計畫會議（上圖左）
• 類似 kick-off 會議，Product Owner 將客戶需求說明給大家聽，由開發成員把需求轉化成工作清單。
• 決定第一個 Spirit 的工作清單。
• 會議時間不超過一天。
• 每個 Sprint（上圖中）
• 一個 Sprint 為一週 ~ 一個月。
• 每個 Sprint 的目標就是完成該 Sprint 的工作清單。
• 每日立會
• 昨日完成哪些工作。
• 今日預計要完成哪些工作。
• 讓別人知道遇到那些困難，會後就可以討論。
• 每日立會時間不超過15分鐘。
• Product Owner 要保證不變動目前在開發的需求，所有變動都等到這個 Sprint 完再說。
• 每個 Sprint 結束後（上圖右）
• 檢視會議
• 檢視目前的專案狀況。
• 完成的工作。
• 沒完成的工作。
• 新增加的需求。
• 決定下個 Sprint 的工作清單。
• 決定是否要繼續執行專案。
• 回顧會議
• 針對開發流程做討論。
• 預估 SKD 是否準確，為什麼？
• 哪些流程工具需要改進。
• 兩個會議時間加起來不超過一天。

最直白來說，不斷執行 Sprint，執行完一個 Sprint 就做調整。

個人感覺最大優點有幾個：

• 理論上每個 Sprint 完，都應該有個可以動的東西（雖然功能可能不足）讓客戶看到並反饋，再根據客戶反饋來修正或修改需求，而不用等到第一次正式交付才發現我做的不是你要的。
• 開發成員眼前的目標就是這個 Sprint 的工作，而 PM 要保證這個 Sprint 內都不會有變動也沒人會去打擾開發成員。有變動沒關係，下個 Sprint 再說，如此開發人員有個節奏，而不是永遠做不完的死亡行軍。