ubuntu 14.04 service nginx restart 出現 Fail 狀況

service nginx restart  執行 Fail 
今天在本來是一台 apache server 上的 Laravel，想要多架個 nginx，結果在 sudo service nginx restart 時一直出現 Fail：

(因為之前有耳聞如果 nginx 的設定檔沒有寫好，好像也會 fail，所以還有特地檢查我的 nginx 設定檔的寫法... Orz)

Laravel migration 建立 store procedure

在公司維護的某個網站，當初因為時程的關係，寫了一些方便撈資料的 SP，之前我都是 store procedure (以下簡稱 SP) 預設放在 DB，在 MySQL workbench 操作，再匯到自己的測試 DB，不過自從用了 Laravel 的 Migration 建立 Table 之後，覺得應該要連 SP 都統一靠 Migration 一起生成，會比較順一點，否則當專案交給別人時，他可以不會知道有這隻 SP，或者是我可能會漏掉給他 SP  這件事情。

宣告 SP 是靠 DB:unprepared()，你可以寫在 Up 的 function 裡面。

拔掉 SP 也是 DB:unprepared()，你可以寫在 down 的 function 裡面。

e.g :

public function up()

{

    Schema::create('tablename', function(xxx){

      //bla~bla~bla~bla~

   });

   
   // 建立 store procedure

   DB::unprepared('DROP PROCEDURE IF EXISTS ls_xx; .    BEGIN... END');

}

public function down()

{ 
   // 刪除 store procedure

   DB::unprepared('DROP PROCEDURE IF EXISTS  SP_NAME'); 
   Schema::drop('table_name');

}

至於在 controller 呼叫 store  procedure，可以用 DB::select :

$users = DB::select('CALL SP_GetUser(?)', array( $uid) );

參考文章:
Creating MYSQL Procedure in Laravel 4 Migrations

前端之路

＊如果你想學得快，就去看書，書有很多前人的經驗，看書可以知道別人解決問題的方法，一本書不過幾百塊錢，去圖書館借都有，這是省錢的方法。如果你不想看書，那就花錢上課，現在坊間的課很多，不用擔心沒得上。錢能解決的問題都是小事，如果你連最後一道防線，連錢都不願意付出，那就免談了，是你不想。你想要什麼你就會去追。 任何東西都是換來的。

Laravel table 建立多 primary key 主鍵

Laravel 的 Eloquent 預設是沒有支援多主鍵，但是如果真的想做的話就是把丟一個主鍵的 array 到 primary 的 medtho 去。

在 Migration 的地方，兩個主鍵設為 unsigned()
然後用 primary 的 method，傳入主鍵的欄位。

$table->integer('question_id')->unsigned();
$table->integer('choose_id')->unsigned();
$table->primary(array('question_id', 'choose_id'));

註:
1. 我是用 Laravel 4.2
2. 其實多主鍵如果不用 Migration 就很單純，問題是現在的專案所有 table 建立我都靠 Migration，只能這樣設定了，不知道有沒有更好的方法可以提供給我摟，謝謝 :)

參考:
Laravel - Multiple primary key 2014-10-13 16:47:00

私塾小調查

最近有一些想要週末出來聚聚的想法 。當然不一定會發生...，通常我週末也很忙 (拭淚...)，可是如果真的想辦，還是擠得出時間的，先讓我觀望先，謝謝!。  有些問題是我過去辦讀書會跟交朋友寫前端而衍生出來會遇過的狀況，希望大家可以幫忙作答。

不過要先說的事情是，這份問卷只針對有心想學的人，如果你只是想出來聽聽，或是工作用不到, 沒什麼機會用到，或是想說反正有人教，要不要來都無所謂的心態，還是只是來交朋友而已，那就比較不適合在我想了解的族群之類，謝謝啦

Initializr 初始化專案資料夾結構的快速工具

(此圖截自: http://www.initializr.com/)

Initializr 是一個可以快速把一個前端需要的資料夾跟檔案建立出來的工具，你可以選擇是否是純 HTML5 的 index.html 或者是有用 Bootstrap 的，甚至是一些經常用到的 plugin 他也可以幫你打包起來。

甚至你不用急著下載，可以先點擊 What's Inside 的按鈕，先知道會幫你組好哪些項目，再 Download 也不遲哦～

這個工具在我最近教朋友寫前端的時候是覺得挺方便的 (其實他好像很早就有了...，是我太晚知道)，以前都懶得先在自己的電腦建立這些資料夾 (或是用線上的 jsbin 直接在 browser 上操作)，建完還要慢慢建立 img, css, js 的檔案跟資料夾，真的是麻煩，太多人共同學習的時候又很容易遇到有朋友把資料夾層級建錯的時候，所以如果要要求統一的話，可以考慮看看用這個方便的工具。

其他我常用的教學跟 Demo 工具:
* jsbin.com
* jsfiddle.net
* http://plnkr.co/

Laravel 多國語系網站 (使用 Laravel 4.2)

我在家偶爾有空的時候有試了一下多國語系，不知道是我沒認真學還是怎樣，但是前前後後也花了兩週啊... QQ，總之，自己做多國語系要串 routes，但是其實不會很難，可是畢竟很多事情要控制，自己寫很容易漏掉，像是語系是否要預設語系 (舉例: 不論 user 身在何地都顯示英文) 還是以瀏覽器的預設語系為主 (舉例: 在台灣就幫你預設顯示繁體中文)，當下我是覺得我對多國語系需要的架構太不熟了...，所以我裝了 package 解決，文章後面會提到用哪些 package。

APP UI design presentations GIF

昨天在家一時興起就想說要來畫個圖，成果在這：http://www.behance.net/gallery/24497449/Taipei-Coffee-APP，雖然我不是什麼專業設計師，但是我很想了一下那種 App 情境的 gif 檔是怎麼做的。

就以手機 app 設計來說，如果你把所有的頁面都放在一個白色長條形的框內，那你確實在做設計，可是看不出情境跟轉頁的效果, 串場等等。

然後昨天光是忙完 illustrator 就忙了一整晚，所以今天晚上才有空研究怎麼把它轉成可以 Demo 情境的 gif 檔，因為看很多 App 設計師都會這樣做。

所以我找到了這篇還不錯的文章： (你可以一路從 part1  看到 part3)
How to create animated GIFs for UI design presentations: Part 1 MAY 9, 2014 / CALVIN PEDZAI

先決條件是你會需要 Adobe  After Effect，至於設計本身，你是用 photoshop 或是 illustrator 都無所謂。

after effect 呢本身的難度就是你要摸熟他... (還好我大學修過...)

另外手機的 mock up，也是上網就能找到，你甚至抓得到免費的情境圖，例如:
50 Free iPhone 6 and iPhone 6 Plus Mockups (PSD, AI & Sketch)

恩... 好吧其實今天我很詞窮 (淚奔)，這是 Blue Monday 的威力嗎QQ

[讀書心得] 第三方支付的真相

完整書名: 第三方支付的真相：如何從網路收到錢？線上開店和個人賣家都要懂的行動金流攻略 - 作者： 陳柏江

這本書還蠻適合給正在研究要不要做電商的人，而且書不厚，在咖啡廳待個兩小時就可以看完了。

Grunt FTP Deploy，一行 command line 就上 code!

我還記得以前在還在接案公司的時候，那時候程式沒有很好，(當然現在也沒有到多好...)，以前要更新程式碼到 server，都還是用 FIleZIlla，當然我不是瞧不起 FIleZilla...，而是檔案散佈很多不同資料夾，或只需要更新特定檔案時，找來找去實在很麻煩。

幾年後出現了 Grunt 這樣子的前端自動化工具之後，減少了不需要安裝 FileZilla 的麻煩，當然 Gulp 也有類似的工具。(我個人比較習慣 Grunt，所以 Gulp 就不多做介紹了..)

好處是因為 Grunt 已經幫我處理掉很多前端的事情了，像是 CSS, JavaScript 檔案壓縮，語法檢查等等，那麼如果連 FTP 都可以透過 Grunt 做掉，也是蠻方便的，現在我用的套件是這個:  zonak/grunt-ftp-deploy。

npm 套件的安裝清一色幾乎都是一樣的流程。必要條件是你必須要安裝:
＊Node.js
＊npm
而因為我們用的是 Grunt 的工具，因此也要裝 Grunt:
＊Grunt

必要的項目的裝完了之後，在自己的資料夾下安裝  Grunt ftp deploy
npm install grunt-ftp-deploy --save-dev

同樣的，你也必須有一個 Gruntfile.js，官網有非常詳細的 example，你可以從那裡 copy，接著看 github 上的說明或範例，直接拷貝。

目錄底下的 package.json 起碼會有這些東西: (如果你不知道什麼是 package.json，那請你在你網站的根目錄底下下 npm i 指令，一直按 enter，就會建立一個預設的 package.json)
＊"grunt": "^0.4.5",
＊"grunt-ftp-deploy": "^0.1.10"


接著這是我的 Gruntfile.js，這只是個 sample，給你參考用，其實跟官網的差不多...：
因為 FTP 連線需要帳號密碼，你要在目錄下也建立一個 .ftpconfig (Auth 的 .ftpconfig) 填入你的帳號密碼，然後在 Gruntfile.js 說明是用哪一組 Key 去登入 (Auth 的 authKey)。

然後我在 registerTask 指定當 Grunt 接收到 push 指令的時候，就幫我執行 ftp-deploy 的行為，把 src 目錄下的東西拷貝到 dest 目錄下的地方。

其實有些時候 FTP 也蠻管用的，只是我現在很少用到就是了...
非不得已的情況下，比方說 server 不允許 ssh 之類的，那就可以考慮看看用 Grunt 嘍!

Hack inline-block Element Spacing

今天在教我朋友寫前端的時後發現我們在 <ul> 底下所有的 <li> 做 inline-block 的時候會有奇怪的間距 (因為也不知道問題是 margin 還是 padding 還是 font-size 之類的...，但清掉還是一樣)。

問題是都已經 inline-block 而且寬度也除到剛好的百分比了，怎麼會有這種怪事...。

demo Source:
http://jsbin.com/juloyekinu/1/watch?html,css,output
http://jsbin.com/juloyekinu/1/

但我又不想用 float 解決，這樣還要用 clearfix 也不是方便哪裡去。後來找到了這篇
Fighting the Space Between Inline Block Elements Published April 21, 2012 by Chris Coyier ，當作解法，解法有幾種，我都不很喜歡... 最後還是挑了 Negative margin，當做最後的方法。

不知道大家有沒有什麼好建議，歡迎留言給我~ 謝謝!

更新:
後來找到一篇討論:
How to get rid of space between divs when display inline-block and stacked horizontally?
除了子層加 margin-left: -4px; 之外，可以用把父層的 font-size 設為 0 也可以。
哦.. 好不科學哦... css你... ><

[讀書心得] 巨型網站成長從無到無限大，技術架構大揭祕

在去年年底，我從天瓏書局扛了一堆書回家，其中一本就是 從車庫的舊PC到百萬台伺服器：巨型網站成長從無到無限大，技術架構大揭祕，作者是 李智慧。

後來因為忙碌，一直沒有去看，直到我做網站遇到了一些瓶頸，從上個月看到今天，大約六週的時間，總算看完了。

這本書寫的是經驗跟方法，並不適用於所有的網站，而是依照業務上的需求，而有不同的規劃。有業務，才有技術上的考量。

Facebook Graph API (v2.x) 之檢查權限授權篇 - {user-id}/permission

我們假設你今天的 Facebook App，在某個按下按鈕的動作，或是某個 po 文的瞬間，因為當初 user 在 Facebook Login 時沒有給予你網站業務需求上應該需要的權限，而導致各種 error 或是 bla~bla~bla~  等奇怪的頁面，你就需要額外去想辦法知道該 user 是否有給你應有的權限去做某件事情，進而做出適當的處理。

(圖: 使用者透過 facebook 第一次登入時，可以修改是否要給予 APP 何種權限)


Example: 比方說你的某個功能需要幫 user 發文到塗鴉牆，照理說 user 應該要給你的 app 有 publish_action 的權限，但他沒有給，然而在 po 文的那刻才出錯，燈惹!~，因為你沒有去判斷他到底有沒有給你這個權限。

由於工程師在時程壓力下，大部份都會按照著心中認為順利的流程下去走，所以難免會遺漏掉這些不在正軌上的流程，往往會再發生問題那一刻才會想起來，對耶~ 忘記檔這個功能等等的內心 OS，其實我也是這樣，這是常態 XDD。

接下來就直接看 API 的部分:

/{user-id}/permission

/{user-id}/permission (/me/permissions) 這隻 Graph API 屬於 User 分類下面的 API， 我現在用的版本是 v2.x 的，過去 v1.0 也有這個 api，只是要到的資料格式不太一樣。

permission 僅供你兩個可用的 Method，Get 跟 Delete:

(一) GET
你用 GET (Reading) 的方式取拿取某個 user 針對你提出授權的項目的狀態，包含 granted 跟  declined (同意或是不同意)。

要到的資料為 permission 表示權限的名稱，以及 status 表示狀態，會用 enum 的方式列舉，不是 granted 就是 declined。

這是我用 Graph API Explorer 針對某隻 App 測試的結果:

{
  "data": [
    {
      "permission": "public_profile",
      "status": "granted"
    },
    {
      "permission": "email",
      "status": "granted"
    },
    {
      "permission": "publish_actions",
      "status": "granted"
    },
    {
      "permission": "user_friends",
      "status": "granted"
    }
  ]
}

如果要測試 declined，就要自己去 facebook app setting 找出該 app，把某個權限拿掉，ex: 拿掉該 app 的 publish_action:

然後再要一次 permission 的結果，就會拿到 declined:

通常如果取得 declined，在自己的 app 因為達不到某種功能，所以通常會有個訊息告訴 user 沒有給予適當的權限，可以先做 permission 確認再決定要不要繼續執行後面需要的 API。


(二) Delete 
用來刪除某個權限。(我現在想不起來到底哪時候會用到這個...，我沒有經驗，所以無法多做說明。XD)


結論
permission 確認其實蠻方便的，我太晚知道這個功能了，問題是什麼時機點要 call 這個 API 以及這種資料該用何種方式存下來我倒是覺得比較傷腦筋，值得思考...。很可惜我沒這方面的經驗，無法分享 :P


參考
＊https://developers.facebook.com/docs/graph-api/reference/v2.2/user/permissions


相關文章
＊Facebook Graph API 升級到 v2.x
＊Facebook Graph API (v2.x) 之審核篇 - 標記朋友 Taggable Friends

Facebook Graph API (v2.x) 之審核篇 - 標記朋友 Taggable Friends

這一篇其實是想要延續昨天寫的 Facebook Graph API 升級到 v2.x 繼續聊。

現在的活動網站的方向，大部份都會跟社群媒體做結合，以 Facebook 的整合為最大宗，其次是 google 跟 twitter, instagram 等等。Facebook 的話，Graph API 多到數不清，想怎麼整就怎麼整，而且效果不差 (尤其是曝光度)，問題是: 要~審~核~。

今天要提到的是如何申請取得好友名單的權限，在過去 v1.0 的版本時，可以輕鬆要到好友名單，在 v2.0 時，需要額外申請權限 Taggable Friends，跟 user 取得 Taggable Friends 你可以要到他的好友名單，當然，這個權限可以做的事情很多，確實你可以用它來標記朋友在 custom story 或是上傳圖片時可以 tag 朋友等等。

以下是合理的使用範圍: 
  * Let people tag their friends in stories published by your app
     讓 user 透過你的 app 在發佈 story 時可以 tag 他的朋友。
  * Let people mention their friends in stories published by your app

你不能做的事情: 
  * Use a person's friends for any purpose other than tagging or mentioning
  其實這樣寫有點籠統，總之主要你只能用來讓 user 標記他的朋友，其他事你不太能做，反正最後也是要通過審核那一關，到時候如果沒有通過，FB 會告訴你原因。

PS:  如果你把每個登入你 app 而且給你 Taggable Friends user 的資料都存起來，你拿到的 facebook id 也只某種 scoped id 而已，看你想怎麼運用那些 data 吧...，我個人是覺得連這種資料都要存起來是挺變態的 XD。

說到這裡，下面可以進入正題了，我分三個部分來講，

(1) 設定篇

(2) Graph API 解說篇 (不包含程式實作)

(3) 送審篇


(1) 設定篇

基本順序就是這樣

a. 去 developer 頁面，『My Apps』(1) 下拉選單選擇你的 APP (前提是你有權限可以設定...)，然後左側選單點選 『Status & Review』(2)，切換到 『items in review』(3) 的 Tab，點選 『Add Items to this Submission』(4) 的按鈕，再勾選 FEATURES 底下的  Taggable Friends (5) 的權限，按下『Add Items』(6)。

(因為我這是為了截圖而開的測試 app，很多紅紅的地方是因為沒有填資料而已)

完成了 add 1 item 之後，畫面會 reload，你會看到這樣，看到紅色驚嘆號請不要緊張，我會解釋。

首先，Status & Reviews 的按鈕之所有驚嘆號，表示你有未通過的審核，或是尚未審核的項目。在網站還在開發階段時，這裡還是驚嘆號都無所謂，只要你測試的時候用的 Facebook 帳號有被加到這個 app 的 developers 之中，你都可以使用 Taggable Friends 的 API，或是你可以建立 Test User 帳號來測試 Taggable Friends 也可以用。

換句話說就是，不要天真的想說自己可以用，好像功能都正常，那是不是就不需要審核了呢，不是這樣的哦...。開發者可以用是很正常的，但是不要太開心請親朋好友測試，因為他們沒有被加到開發者名單，而且又還未通過審核的狀態時，他在使用這個 Facebook  登入  app 時會這樣... 顯示這樣的訊息 : 『Some of the permission below have not been approved for use by Facebook』，會露餡 :P

恩，總之這個部分我只是提醒，一定要審核。

完成設定上的步驟，接下來應該先實作你的程式，讓網站可以成功的跟 taggable friends 的 api 完美的 work，要完美哦! 因為審核是真的有人來用你的網站，玩到一半不能用就糗了。

第二件事情，App Details 在送審時不能沒有資料，你一定要寫，而且你的網站一定要有一個 privacy policy 的頁面網址。詳情可以看 https://developers.facebook.com/docs/apps/review。總之這頁該填的要填。

(2) Graph API 解說篇 (不包含程式實作)

API 實作其實沒有什麼好講的，我也說不清楚啊，看你用什麼語言開發 (看你是 php, 還是 javascript, android, ios...)，方便用什麼方式去接資料吧。文章在此請服用。

文件寫得非常的直白了，我想我無法說得比文章更詳細。

只有以下事情要提醒跟說明:

(1) 用 taggable_friends 要搭配 user_friends 才可以用。user_friends 不用特地審核，可是你開始在取得 access token 時要自己加入這一項，以我自己的 php 的程式來說就像這樣：

   'default_scope' => ['email', 'user_friends', 'publish_actions'],

(2) 回傳的資料有該 user 可以被 tag 的朋友名單，其各個朋友的資料包含 id, name 跟 picture。id 就是要 tag 朋友時用的 id，這個等你需要做什麼發佈圖片或是 share with  誰誰誰的那種功能你就會用到了, picture 就是縮圖這樣而已。 三種資料你也不一定要全拿啦，但通常都是全拿  :P。

(3) 送審篇

如果你測試了 taggable_friends 沒問題之後，你必須在審核時合理的解釋為什麼需要用它，以及如何讓審核人員知道如何用 facebook 登入你的 app (必須截圖)，並且說明。

送審你必須回到 developers  設定頁面。找到前面說的那個申請的地方，點開 taggable friends 的 Add Note 按鈕，然後詳述他問你的問題。

通常是一次送一堆出去審，比較方便 XD

下面的問題也要填，required 的地方一定要填，Screenshot 的地方，你要截下網頁的圖並且說明 (至少四張)，審核人員是會真的造訪你的網站，親自去試的。

你如果不會寫，請先看 guideline，很實用，還有要注意，要用英文寫。
https://developers.facebook.com/docs/apps/review
最好是 step 說明，像他的提示那樣。

如果你都填好之後，同一下最下方，勾選你確定你測過這個功能了，然後按下 submit for Review，就可以了。

submit 一旦送出：
你不能再修改 review 寫的那些內容，screenshot, App Detail, website url 什麼的，都不能再改，除非你中途取消送審。

送審要多久?
最長七天，根據我的過去的經驗，最快 1 天半就過了，有時候是兩到三天，最久我沒等過七天的耶。

送審之後，你會收到一封信，只是通知你而已。
接著就是只能靜待審核結果，也是會寄信通知，或是會顯示在 alert 的頁面上。

審核結果會顯示在 Statue & Review 頁面上
恩... 我實在是沒有未通過的照片，反正紅通通的就是沒過，綠通通的就是過摟。
沒過你也不用擔心，他會告訴你為什麼，反正你修改過後，送審的步驟就是再送一次，已經通過的不用重新送，沒通過的才要。

結尾
＊ 這篇只是個簡單介紹流程的文章，實際上標記朋友不會單獨申請，會搭配 publish_action 等等。
＊ test user 的功能很方便，別遺忘這個功能。
＊要考慮到網站上線的時間，請務必要拿捏好審核的時間點，以及如果未通過之後，程式修改後又再次送審的時間。
＊我之前研究這一塊真的是花蠻多時間的，當然送審沒過的機率也是有，通常會跟你有沒有正確使用這項權限有比較大的關係。


我們從頭到尾來複習一下要個權限有多少事情要做
1. 網站要有網址，不要用 ip (印象中 ip 應該也不行)
2. 申請要的權限項目 (Status & Review)
3. App Details 該填的填
4. 要準備 privacy policy 頁面，提供網址填到 app details 頁面的 privacy policy URL 項目
5. 程式要實作 api
6. 測試 fb 登入跟申請的 api 可以 work，以及流程順暢
7. 送審，做 screenshot，寫說明，然後就 submit! 靜待結果

Facebook Graph API 升級到 v2.x

因為公司的案子有一個 app 還是 v1.0 的狀況，所以最近我只要進入 developers 的頁面都一直被提醒，真的很煩，總之就是告訴你務必在 50 幾天之內趕快把你的 (Graph) API 版本換成 v2.0 的，否則有些權限在 v2.0 之後要全面用審核的方式通過，一些變更像是：


取得好友名單
在 v2.0 就要審核(需要分別跟每個使用者要求 user_friends 權限)，而 /me/friends 只會拿到也有使用該 app 共同好友 (In v2.0 of the Graph API, calling /me/friends returns the person's friends who also use the app.)。

詳情你可以看這篇 stackoverflow，沒錯，如果換成 v2.0，/me/friends 可能回傳的資料會是空的，並不是 api 壞了，而是剛好真的沒有共同好友也有使用該 app。你必須搭配 user_friends 加上 /me/friends 才會取到該 user 的好友名單。


Basic info 改為 Public Profile
以前的預設權限叫做 basic_info 會被 public_profile 取代，public_profile 不包含使用者的朋友名單。參考。


權限申請審核
public_profile, email, user_friends 之外的 permission，都需要申請審核。


App-scoped User IDs
這大概是我覺得最恐怖的一件升級狀況。
v1.0 app 拿到的 user id 是他在 facebook 上真實的 id，但 v2.0 之後，會針對不同的 app 給不同的 scoped-id，也就是說，user 用 fb 登入你們的 app，你拿的到是他在你 app 之下的 scoped-id，不是他本人在 fb 上的 id。

很多人都在擔心,在詢問: 那以前登入我 app 的 user id 怎麼辦，應該是不會有事，不用擔心 id 不一樣的問題，請參考：How do I get old UserID as of Graph API v2.0?

However, for users that have previously logged into your app, the user ID will not change. 
(這句話我還在想是不是指說，之前登入過 app 的 user，則 id 應該不會被換掉.... 猜的拉，希望是，不然自家的會員系統會大亂...。)



除了要 /{id}/picture 之外，其他所有的 API 都需要 access token。


-------------------這-是-華-麗-的-分-隔-線---------------------


因為日子有點接近，所以特地要注意一下，如果你的 facebook app 使用的 api 是舊版的，要在今年 2015/4/30 之前完成更新到 v2.X 的版本。( We also announced that all apps requesting these additional permissions must undergo review by April 30, 2015, when we will deprecate Graph API v1.0. )，若我有說錯麻煩留言跟我說一下，謝謝。

就我的認知，其實你不自己升級應該也不會有事，fb 應該會幫你升級，只是有些權限你會拿到空的，或是拿不到資料而已...，像是 user_birthday,  friend，要注意自己的程式有沒有判斷到這一塊 QQ，不過，長久之計，還是升級吧..。

以下的文章可以幫助你更加了解升級的事情:

＊Facebook 之不升級v2.0+ 你怎麼死都不知道指南 BY 羊小咩
＊Facebook Platform Upgrade Guide
＊Login Review and API v2.0 Migration Reminder by Andreea Manole - February 27 at 4:00am，這篇文章有提到如何避免你的 app 在 4/30 號之後會壞掉。
＊Easily upgrade to Graph API v2.x with no code changes by Dan Xu - February 6 at 5:00am