Facebook 開發筆記 - 使用單一 Facebook app 仿 OAuth 架構提供單多平台多 app 登入使用

由於 Facebook app 在任何平台上，只能允許一個 app，例如 iOS platform 就只能綁定一個 iOS app，如果想要多個 iOS app 都用同一款 Facebook app 時，就出現了這奇妙的需求 :P

因此，再次包裝的方式，那就是用 UIWebview/WebView 來解吧！對於任何一款 Mobile app 都是採用 Browser 來完成登入的。而 Backend service 是維持採用同一款 Facebook app。

原理：主體是以 Facebook Javascript SDK 來使用，當完成 Facebook app 登入認證後，將 Javascript 端取得的 Facebook app token 丟給 backend service ，驗證後交換成自家 service token，未來用自己的 service token 來進行服務互動。

以上狀態僅需依照 Facebook SDK Javascript 文件已經可以完成大半了：

FB.getLoginStatus(function(response) {
  if (response.status === 'connected') {
    console.log('get facebook app token');
  }
  else {
    FB.login();
  }
});

在 response.status === 'connected' 就能取得 facebook token，再轉呼叫自家 service 來交換 token 即可收工。

然而？事情不是那麼簡單的 XD 在 mobile platform 環境上，用 chrome browser 或是 safari 都可以正常工作，唯獨 PhoneGap 等類似架構會出錯，主因是 Facebook SDK Javascript 登入時，會彈跳視窗，結束後可以再導回來，但在 PhoneGap 架構上，可能受限於沒有分頁機制而出錯？總之，解法：自行用 direct_url 跟 Facebook 互動吧！這招印象中是在寫 server side 的用法：

當使用者點擊 login 時，不要用 Facebook Javascript SDK，而是將網址導向到:

https://www.facebook.com/dialog/oauth?client_id=YourFacebookAppID&redirect_uri=http://localhostOrServiceWebURL/&response_type=token&scope=publish_stream,email

當使用者完成登入後，將導回你指定的位置，而這時在 FB.getLoginStatus 時，又可以正常取得 response.status === 'connected' 等資訊了。

不因善小而不為 –〉 快的打敗慢的

前陣子連續幾天下班後跟一位在 Y! 的學長聊天，聊著到底要選擇藍海還是紅海？讓我想起以前當兵擁抱藍色的經驗：

三年下來，幾乎都朝著藍海走，每年夏天都要提計畫、想創意，然後被顧問打槍... XD 後來，隨著神秘組織解散後，終於不用再想創意（當時為了想創意也開始看漫畫、讀小說，補齊兒時記憶）。那時的職業病：東西看越多，越想不出創意。任何組員提得出來的創意，都可以舉個國內外的例子出來。為了藍海目標、不與民爭利，於是乎...空轉。由於是藍海方向，高失敗率，於是乎...繼續空轉。

離開單位後，反而擁抱老二哲學。只要有想做的，馬上身體力行，因為自己想得到也深信別人也想得到 :P 大概是幾年空轉的職業傷害讓人更珍惜時間，一旦有想做的就是馬上衝，不二話，實在是點子就像錢存在銀行一樣，只會貶值。對於別人找我閒聊的方向，也一樣是建議對方盡快且堅定意志執行，別人有沒有做過沒什麼，就像大象(大公司)踩不死螞蟻(小公司、工作室)，差異化就像嘴炮一樣，永遠都可以找到，只是有沒有價值(客戶)是另一回事 XD 隨著工作經驗的增加，方向又稍微修正。做服務不會馬上衝下去弄個 prototype ，而是稍微想一下再進行，沒想好容易砍掉重練，為了不要讓思考過長，設定個 deadline 是很不錯的。

學長的經歷是支持藍海走向的，反而讓我回憶起不少事情：

• 到處都有聰明的人
• 隨意逛 FB 還看到一位 28 歲的強者，除了在山景城工作外，兩年前還買了房 Orz 可真是高富帥的代言人
• 學長在 Y! 碰到純數學派的強者，因為金融界玩膩了跑來玩資料分析 Orz 做事時可是直接設計數學 Model 來分析的
• 資訊的匯流、個人或團隊成長跟環境有非常大的關係
• 剛進研究單位時，我曾經很佩服老闆怎會有那些創意構想，過了一兩年後，我開始覺得那只是該位置會收集到的資訊，就像組織請的那一排顧問吧？當了顧問常常打槍別人，開槍完再把對方的點子收起來用 XD
• 環境是非常重要的 :P 孟母三遷是非常經典的例子。有些環境雖然資源不錯，但沒有發揮環境時，除了自省有沒有哪些沒盡力之外，想進步還是要換換，不然只是另一個慢性毒藥
• 藍海、紅海，只不過是投資報酬率的問題
• 就像買樂透一樣，投資 50 元就有參加機會，但不參加，什麼機會都沒有
• 紅海，屬於民眾已教育過的為重，文化上已轉換成很直觀的項目，屬於穩定的低報酬投資
• 藍海，有機會還是去嘗試！畢竟有什麼比固定領薪水更差的情況呢？
• 外商薪情好
• 人太老實時，都會好奇為何外商肯用 2~3 倍台商的薪水請一個人？特別像是美商公司，然而，結論就只是生態，這就像台灣紡織業或其他高勞力傳統業，需要大量勞力的工作，在台灣有基本薪資19k，但去了大陸、越南、印尼等，基本薪資降到 3~9k 台幣，如此而已。
• 所以對於外商的薪資，在台灣聘人真的是省到錢，至少省一半以上！

今天跟朋友閒聊一些開發服務郁悶的事情，得到一個結論：快的，打敗慢的

沒有什麼永遠會贏的，與其躊躇著某些服務差異性不大，倒不如回歸底心，有愛就繼續，有時間就繼續，失敗了也沒什麼大不了。

[SQLite] 跨 database (db file) 進行 Table JOIN

使用 SQLITE - Attach 這個指令即可：

$ ls
a.sqlite3 b.sqlite3
$ sqlite3
sqlite> attach 'a.sqlite3' as adb
sqlite> attach 'b.sqlite3' as bdb
sqlite> .tables
adb.user  bdb.data
sqlite> SELECT adb.user.id, adb.user.name, bdb.data.info FROM adb.user, bdb.data WHERE adb.user.id = bdb.data.id

AWS 筆記 - DB Instance XXXX contains MyISAM tables that have not been migrated to InnoDB. These tables can impact your ability to perform point-in-time restores. Consider converting these tables to InnoDB

先查看有哪些 table:

mysql> SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES;
+----------------------+--------------------+
| TABLE_NAME           | ENGINE             |
+----------------------+--------------------+
...
| pma_bookmark         | MyISAM             |
| pma_column_info      | MyISAM             |
| pma_designer_coords  | MyISAM             |
| pma_history          | MyISAM             |
| pma_pdf_pages        | MyISAM             |
| pma_recent           | MyISAM             |
| pma_relation         | MyISAM             |
| pma_table_coords     | MyISAM             |
| pma_table_info       | MyISAM             |
| pma_table_uiprefs    | MyISAM             |
| pma_tracking         | MyISAM             |
| pma_userconfig       | MyISAM             |
...

結果發現是 PHPMyAdmin 的那些 tables，由於這些影響不大，就操刀吧！以 pma_bookmark 為例

mysql> ALTER TABLE  `phpmyadmin`.`pma_bookmark` ENGINE = INNODB;

收工。

Call Facebook API without token at Linode: error: message: Application request limit reached

昨晚開了一台 Linode Server，想說來研究一下 Facebook api，結果：

$ curl "https://graph.facebook.com/fql?q=SELECT%20total_count%20FROM%20link_stat%20WHERE%20url%20='www.google.com'"
{"error":{"message":"(#4) Application request limit reached","type":"OAuthException","code":4}}

不死心，發 ticket 抱怨一下，想說會不會前一個用戶太操，得到了免費換了 IP 。結果仍是一樣的。接著，想起有美國的機器，測了一下仍是如此。

幾番測試後，我猜 Linode IP Range 大概被關注很久，預設都不給用，看來人紅也是種困擾 XD

以上 command 在任何一台的機器，預期得到的正確結果為：

$ curl "https://graph.facebook.com/fql?q=SELECT%20total_count%20FROM%20link_stat%20WHERE%20url%20='www.google.com'"
{"data":[{"total_count":10366203}]}