AWS 筆記 - 使用 Amazon Cloudfront (CDN) 服務

切換到 AWS Cloudfront 頁面，可以看到支援 Web 跟 RTMP ，其中後者是 streaming media files。這次只使用 Web 方面。



整體設定上還滿簡單的，以 service.changyy.org 為例，後面是一台 server (node.changyy.org)：

• 先決定使用者最後會連結的服務的 domain name，此例是 service.changyy.org
• 設定 cloudfront 的資訊，例如 Origin Domain name 填寫實際服務的機器位置 node.changyy.org

如此，cloudfront 會建立一筆 xxxxxxxxx.cloudfront.net 是提供 CDN 服務了。


可以用 nslookup xxxxxxxxx.cloudfront.net 可以看到有一批機器在服務了。如果，想要用自己的 domain name 的話，需要再 cloudfront 多設定 Alternate Domain Names(CNAMEs) 的資訊，未設定則會出現：


這主因是使用 cloudfront 是要計費的，若別人亂設定個 CNAME 導到你的 Amazon Cloudfront 的話，就默默地一直被扣錢 XD 至於費用的部分：

• HTTP requests 費用: 在美國每 10000 則要價 0.0075 美金
• 資料傳輸費用：在美國每 1GB 要價 0.02 美金

若一天要服務 10000 個 reqeusts，每則 100kb，那 30 天的費用：

30 天 * [10000 * 0.0075/10000 (HTTP) + 10000 * 100kb * 0.02/GB (DATA) ] = 30 * (0.075 + 0.01907) 美金附近 = 2.82 美金

對於費用部分，建議連上官網觀看，例如各地費用皆不同等：http://aws.amazon.com/tw/cloudfront/pricing/

AWS 筆記 - 使用 Amazon Simple Email Service (Amazon SES) 服務

原先在開發電子報服務時就有要用，嘗試到一半就被其他事件 Orz 所以還是花點時間筆記一下這塊。首先，使用上需要 Amazon 帳號，打通後則是要用 AWS SES 服務的流程而已，其中 AWS 許多流程仍是依據 IAM 權限管理的，其實也是個挺漂亮的架構，粗略流程：

1. 透過 AWS 最高權限，在 Amazon SES -> SMTP Settings -> Create My SMTP Credentials，將得到一組 SMTP Username 和 Password 可使用。過程中會建立一個 AWS user，我印象中早期是要自己去處理的
2. 預設是 sandbox 環境，只能寄給已驗證的收信者，在 Amzaon SES Verified Sender 可以新增幾個試試。
3. 透過 SMTP protocol 寄信看看

此次使用 PHPMailer 來測試：

$ git clone https://github.com/Synchro/PHPMailer.git
$ vim PHPMailer/AWS-SES-test.php
<?php
require 'PHPMailerAutoload.php';

$mail = new PHPMailer;
$mail->SMTPDebug = 3;
$mail->isSMTP();
$mail->Host = 'email-smtp.us-west-2.amazonaws.com';
$mail->SMTPAuth = true;
$mail->Username = 'YourSMTPUsername';
$mail->Password = 'YourSMTPPassword';
$mail->SMTPSecure = 'tls';
$mail->Port = 587;

$mail->From = 'YourSenderEmail';
$mail->FromName = 'Mailer';

$mail->addAddress('YourTargetEmail');

$mail->isHTML(true);
$mail->Subject = 'Here is the subject';
$mail->Body    = 'This is the HTML message body <b>in bold!</b>';
$mail->AltBody = 'This is the body in plain text for non-HTML mail clients';

if(!$mail->send()) {
    echo 'Message could not be sent.';
    echo 'Mailer Error: ' . $mail->ErrorInfo;
} else {
    echo 'Message has been sent';
}

$ php PHPMailer/AWS-SES-test.php

在 sandbox 中，如果 $mail->addAddress 或是 $mail->From 使用的不是驗證過的，會出現 554 Message rejected: Email address is not verified.


最後，測試都差不多了，想要正式使用時，在申請一下  Requesting Production Access to Amazon SES 即可。理由可以很簡單，例如寄信給註冊的使用者們，不到20個英文字就搞定啦，但各個 region 必須分開申請。

Facebook 開發筆記 - Facebook app 無法取得真實的 account id

最近在開發 Facebook app 時，發現 Facebook API 已經有更新不少東西，其中有一項還滿不錯的，第三方 Facebook app 無法取得 Facebook user 的真實 ID 資訊，每個 app 會各別拿到一個，例如在 A app 跟 B app 詢問 graph api: /me 時，拿到的 id 會不一樣。然而，不一樣的 ID 卻仍可以一樣定位到同一個使用者。

這個最大的缺點是各個 Facebook app 沒有互通的資訊，但對於各個 facebook app 取得到的資訊卻還是一樣夠用。此外，可以用 www.facebook.com/id 去測試，可以發現仍可以定位到同一個 user，算是滿貼心的隱私設計。

https://developers.facebook.com/docs/graph-api/reference/v2.2/user

The id of this person's user account. This ID is unique to each app and cannot be used across different apps. Our upgrade guide provides more info about this.

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 台幣，如此而已。
• 所以對於外商的薪資，在台灣聘人真的是省到錢，至少省一半以上！

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

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