透過 BuyAndShip 購買 Amazon JP 的 Kindle Paperwhite 完整教學

大概十年前，在工作上也算半隻腳踏入電子書領域，那時已經拿著幾台 Kindle 把玩，但最後投入了 iPad 懷抱 XD 在 2010 買了 iPad，沒想到 2019 年終於買一台 Kindle 來用用。這是台 Amazon JP 牌的 Kindle ，預設的商城是 Amazon JP。

事隔 10 年，拿到 Kindle 時，真的覺得很小台。記得 10 年前還沒這麼小？可能是當時有實體 keyboard 吧。長大概是兩張名片長，寬是兩張名片寬再多一點。



這次是第一使用 BuyAndShip 服務，因為 Amazon JP Kindle 只能送貨到日本當地，就試試看在日本有倉庫的 BuyAndShip 國際網購代運。他是香港的公司，在世界幾處有倉庫，像我想買 Amazon JP Kindle 且Amazon JP把此商品限定寄送日本當地時，就把收信人填寫 BuyAndShip 在日本倉庫的地址，收信人則帶有自己在 BuyAndShip 的帳號資訊（姓名 + BuyAndShip 代號）。當 BuyAndShip 日本倉庫收件後，會立即再運到香港。BuyAndShip 用戶在填集運單發貨到台灣宅配收工。

整個 BuyAndShip 是秤重計費的。最近 BuyAndShip 台灣有活動，新建帳戶有 120 點數（若透過推薦人，首次交易完14天後又可以再多 200 點數），一點代表一塊台幣，而 120 點足以支付一磅的商品，而 Kindle 是 0.8 磅！若 Amazon JP 寄送到日本當地免運，那就沒有其他費用要支出，全程只有 Amazon JP 刷卡費(+銀行信用卡國際費用)，理論上境外商品進台灣還有關稅問題，但這段我不是很懂，BuyAndShip.com.tw 在官網上說台灣的關稅他都包了 XD



整個流程：

1. 註冊 BuyAndShip 帳號（ 若想再拿額外 200 點數，請點此 https://www.buyandship.com.tw/invite/2793172439/ 並且在推薦欄位上寫 2793172439 ）



2. 完成帳號註冊後，可在海外倉庫地址上，取得倉庫資訊，網頁上都有範例請你填寫收件人的方式，以及倉庫地址等等：



後續就是 Amazon JP 為例，在此就不多提 Amazon JP 帳號的註冊等（其實有些可以台灣收件的商品，就可以不用靠 BuyAndShip 了）。接著在 Amazon JP 購物時，就填寫寄送到 BuyAndShip 倉庫，主要是收件人和地址要有 BuyAndShip 個人代號。

接著 Amazon JP 發貨後，會顯示是靠哪家公司寄送以及貨品追蹤碼：



如此剩下的事就都在 BuyAndShip 網站了！首先填寫申報貨件







如此就完成第一階段的任務，接下來就是等待，等待貨品寄送到日本倉庫！這時我覺得 BuyAndShip 最方便的地方是每一步都會有狀態回報。當商品寄送到倉庫後，除了 Amazon JP 可以查看送貨情況外，當然 BuyAndShip 也會更新狀態，將貨件狀態更改為海外入庫，而後續也不用做什麼，會自動再轉成準備海外出庫，進入海外出庫後，下一步就是香港倉庫：





在香港倉庫時，就可以填寫轉運單，這時就會挑選要宅配回台灣哪裡了，在此步就會要付錢給 BuyAndShip 囉！由於創建帳號有 120 點，就在此用點數支付完畢：



填寫完就進入轉運單追蹤：



一開始還不會有宅配的資訊，大概過個1~2天就會出現（此例使用黑貓宅急便），雖然有單號了，還是查不到（因為黑貓只是把寄貨單發到各處，不代表已經被黑貓收件），如此，可以什麼都不管了，只等著黑貓寄貨到家囉。

收到商品後，看起來 BuyAndShip 也沒拆開，直接在包一層就寄出去了！



拆開後都是 Amazon JP 的包裝封套，拆開後是 Amazon JP 對商品的保護：





經過這次試用 BuyAndShip 後，覺得令人不安的地方都有被 BuyAndShip 不斷更新貨品狀態而解決了！加上在首次使用靠 120 點數而不用付費，更是降低戒心 XD 往後若有不能直寄台灣的商品，就還會再來用用看的。目前比較搞不懂的還是進台灣的關稅問題，目前 BuyAndShip 都說會自行吸收處理，未免太佛心了吧 :P 但 BuyAndShip 有限制商品大小，應當也是種自保機制。

Alexa Skill 開發筆記 - 使用 AWS Lambda 與 OAUTH2 帳號連結

公司的產品是 WiFi Display 設備，結合智慧音箱後，透過音控請裝置執行動作，如播放影片。在此就順便紀錄這些開發過程。此處不會提及 OATUH2 開發項目。

首先，Alexa Skill 是個滿好玩的點子，說穿了就像 Apple TV 可以安裝 Apps 的概念，他是個市集，可以讓開發者提供更多智慧音箱的技能擴充，大約是 2015 年開始的。上頭也可以有簡單的變現機制，可以參考：Alexa開發者也可以賺錢了！看亞馬遜怎麼開啟語音應用的全新獲利模式

首先，沒有 Alexa device 也可以開發，善用模擬器即可。開發流程：

1. 建立 Alexa Developer 帳號(過程就是建立 Amazon 帳號)
2. 建立 AWS 帳號(綁定信用卡，有免費額度可善用)
3. 使用模擬器服務 - https://echosim.io/

先在 Alexa Developer 先建立一個 Skill project，此例是 Video ，接著就要填寫 AWS Lambda 的位置，就切換到 AWS Lambda 創建流程，而 Alexa Skill 預設是提供 English (US) 的語系，參照 To create a Lambda function 第三步有強調 AWS Region 的部分：

Make sure you’ve selected the N.Virginia for English (US) skills or the EU (Ireland) region for English (UK) and German skills. The region is displayed in the upper right corner. Providing your Lambda function in the correct region prevents latency issues.

就要在 N.Virginia 創建 AWS Lambda function，不然亂建立根本無法互動。建立完 AWS Lambda function 後，替他增加 Alexa Skill Kit 和 Alexa Smart Home ，並且設定它的 Skill ID，並且把對應的程式碼上傳，且要記得發布出去！







如此一來，此 Skill 作者基本上已經可以測試了，而測試的條件包括要有一個 Alexa 音控裝置，這時就要靠模擬器，可以先到 https://echosim.io/ 登入 Amazon 帳號，即可獲得一台虛擬器。



接著，若你人在美國或是擁有美國的 iTunes / Google play 帳號可以下載得到 Amazon Alexa app ，那就直接用，不然只好跟我一樣用用網頁版： https://alexa.amazon.com/spa/index.html ，只要有先把 Amazon 帳號配對過 Alexa 音箱就可以正常切換到 Skill 頁面，點選右上角的 Your skill 即可切換到 Dev skill 來查看，並把自己開發的 skill 給 enable，過程就會觸發 OAUTH2 服務帳號的綁定並授權 Skill 服務使用等等，後續的過程先挑選哪個硬體裝置要被智慧音箱控制(AWS Lambda 要實作 device discovery 等機制)，接著再挑哪個智慧音箱來搭配，整個過程用瀏覽器開發工具查看到 api response：

• https://alexa.amazon.com/api/phoenix/discovery
• 得知哪些硬體裝置要被控制
• https://alexa.amazon.com/api/devices-v2/device
• 得知你的帳號有哪些智慧音箱裝置

最後，自己測試完後，可以再開啟 Beta Test 機制，邀請其他人來測試。而要開啟 Beta Test 只需要把資料填一填，並處於 ready for submission 即可（送審前一步），關鍵的地方就是補一補 icon、描述、甚至一些網址等等，若只要一直內測就可以先亂填





最後，有問題真的要好好看文件 XD 而 AWS Lambda 則可以善用 Cloud Watch 看 logs ，以此確保真的有連線

AWS 筆記 - 關於 Amazon EC2、Elastic Load Balancer (ELB)、Auto Scaling 與 CPU loading 過低問題 @ Ubuntu 14.04, Apache 2.4

使用 ELB + Auto Scaling 好一陣子了，最近因為服務量變大導致 Web Server 變多，然而，在部署程式方面就累了許多，因此朝 Scaling up 來進行一下，限縮機器數量並提升機器規格。

在這個過程中，從 m3.medium 改到 m3.large 或 m3.xlarge 等，卻發現越高級的機器，其 CPU Loading 衝不上去，並且限縮機器後導致服務極為不穩，連 Health check 也發現。但明明機器都不忙啊？！

接著因為非常忙，拖了兩個禮拜才正視這個問題。追了許多後，發現...只是 Apache Multi-Processing Module (MPM) 設定未同步拉高 XD 好蠢的一件事啊。此外，由於服務眾多，尚未有空最佳化，就先繼續用 prefork 架構了。

$ apache2 -v
Server version: Apache/2.4.7 (Ubuntu)
Server built:   Mar 10 2015 13:05:59
$ sudo vim /etc/apache2/mods-enabled/mpm_prefork.conf
<IfModule mpm_prefork_module>
        ServerLimit                7500 # 預設才 256
        StartServers               20
        MinSpareServers           15
        MaxSpareServers            50
        MaxRequestWorkers          7500 # 預設才 256
        MaxConnectionsPerChild     0
</IfModule>

總之，ServerLimit 跟 MaxRequestWorkers 就看當下的機器資訊，例如記憶體等等。

透過 Web server 執行的環境調整，機器的負載度自然可以提升，接著 Auto Scaling 的機制就可用啦！原先在 m3.medium 的機器是單核，而在 m3.large 開始就是多核心了！效能就能更往上衝囉。很妙地用系統預設的 prefork.conf 在 m3.medium 還混的不錯 :P 包含 CPU 會依照 requests 量變化，不像同樣的設定檔搬到多核心後就失效了，CPU 衝不起來，導致 Auto Scaling 也失效！

整體上，這次碰到 service 不穩的主因：

total requests 一直保持一個數量，而原先開 m3.medium x N ，想說機器提升成 m3.large 就把數量調整成一半，結果 web server 數量降低，再加上 prefork.conf 的設定，導致能服務的 requests 量也降低！而 Health check 無法正常被驗證，接著 AWS Scaling 會判斷機器出事要下線，甚至 requests 不導過去，頻頻出現：

503 Service Unavailable: Back-end server is at capacity

如今終於解掉了 :P Health check requests 也能被服務到，機器自然就不會被判斷成有問題，自然就解掉 503 Service Unavailable 現象。

最後，如果要追蹤網路流量，可以試試 nload 這個指令，看整體流量還滿方便的。

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 必須分開申請。

AWS 筆記 - Amazon Route 53 GeoDNS 用法 (Routing Policy: Latency)

想要讓不同 client 查詢統一個 Domain 時，回應離使用者近的 Data Center 的機器嗎？恰好 AWS 有提供這個功能，用法：

• 將各個 Data Center 的機器，透過 A Record 指定一個 Domain Name
• 將使用者真正查詢對象(DomainName)設定多筆 CName Record 對應，在新增時，選擇 Latency 並挑選區域即可，例如服務亞洲可以挑日本(ap-northeast-1), 其他地方挑美國(us-west-1)等，更多區域資訊請查詢：AWS Regions and Endpoints

接著，測試時，可以透過 nslookup 來指定要查詢的 DNS Server 來模擬不同區域的查詢結果，如 Google 8.8.8.8 和最近阿里雲對外公佈的新服務 ALiDNS 235.5.5.5，就可以看到因為地域的不同產生的變化。

連續動作：

1. 新增 A Record: www-geo-jp.changyy.org/1.1.1.1
2. 新增 A Record: www-geo-us.changyy.org/2.2.2.2
3. 新增 CName Record: www-geo.changyy.org/www-geo-jp.changyy.org/Latency/ap-northest-1
4. 新增 CName Record: www-geo.changyy.org/www-geo-us.changyy.org/Latency/us-west-1

查詢：

$ nslookup www-geo.changyy.org 223.5.5.5
Server:         223.5.5.5
Address:        223.5.5.5#53

Non-authoritative answer:
www-geo.changyy.org       canonical name = www-geo-jp.changyy.org.
Name:   www-geo-jp.changyy.org
Address: 1.1.1.1

$ nslookup www-geo.changyy.org 8.8.8.8
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
www-geo.changyy.org       canonical name = www-geo-us.changyy.org.
Name:   www-geo-us.changyy.org
Address: 2.2.2.2

別忘了，這種功能是需要額外收費的。

Amazon Route 53 Pricing：

• Standard Queries
• $0.500 per million queries – first 1 Billion queries / month
• $0.250 per million queries – over 1 Billion queries / month
• Latency Based Routing Queries
• $0.750 per million queries – first 1 Billion queries / month
• $0.375 per million queries – over 1 Billion queries / month

AWSome Day 2014 Taipei

記得上一回使用 Amazon EC2 已經是 2009 年年底了，當時有 firefox plugin 可以管 EC2 就很威了！經過幾年少用 EC2 後，今年想說該複習一下，就報名參加了 :P

聽完一輪的想法：

• AWS 提供很完整的方案，甚至企業型用法的 Amazon Virtual Private Cloud (VPC)
• 比起 2009 年的概念，現在有很完整的 Access control 稱作 AWS Identity and Access Management (IAM)
• 現在有 Amazon Relational Database Service (RDS)，我猜應該本就有 HA 功能，而 RDS 所謂的 HA 方案是指跨 region 程度的。此外自家也有推 Amazon DynamoDB 的 NOSQL 方案
• 檔案儲存的 Amazon S3 也有便利的 access control ！以 bucket (類似folder) 為單位
• Amazon ElastiCache 還可以建 Cluster ，有常見 Redis 跟 Memcached 方案 
• AWS Elastic Load Balancing (ELB) ，如其名 load balancing
• Amazon CloudWatch，可以監控機器狀況，若太操時可以選擇自動加開機器等
• 有點內建 CDN 功能：世界各地有 Region 跟 Edge，其中 Region 是可以開機器，而 Edge 則是 cache 

聽到這裡，我認為 AWS 真的很猛，大概把一般公司對 MIS 的需求都做完了 XD 難怪一直主打 startup 廣告，如 airbnb 如何在 2012 年靠 AWS 服務，處理六個月內倍增的訂單數等，其他家則是說用了 AWS 省了多少錢。

對於錢的角度，我認為 AWS 就像買保險一樣，初期看起來花費比其他家 VPS 貴，但它提供的方案很全面性，如彈性計算的 EC2、資料庫 RDS、檔案儲存備份 S3、服務分流 ELB 跟服務監控與自動彈性調整 CloudWatch 等，一整個讓 startup 不必分心於管機器這件事，更可以專心做服務。流量大就砸錢，錢花完就增資 XD

管機器啊，只有真的管過才知道機器難管之處 XDDD 所以，要怎樣說服老闆花錢又是另一門學問囉！例如顧一個 MIS 年花 60 萬好了，但這個價碼初期用 AWS (WebOps) 好像很噴錢（大多都是 RD 兼職），但一旦服務流量變大時，馬上加人不見得可以處理好，用 AWS 卻像買個保險可以快速解決，甚至某些服務性質來說，有可能省到錢（節省人力）。

最後一提...不是用了 AWS 就可以自動 scale up！當然是自家服務本身就要設計，所以在 AWS 的傳道上，會鼓吹一開始就設計可以 scale up 的架構，而非像其他 startup 先不作重在 scale up ，等做大再煩惱 :P

相關連結：

• AWS Global Infrastructure
• AWS SIMPLE MONTHLY CALCULATOR
• Amazon RDS: Does Amazon RDS solve the MySQL scaling issue?