2012年1月22日 (日)

Panda Streamを使ってWEBサイトに動画アップロード&エンコード&再生機能を作る

こんにちは、大橋です。
ひさしぶりの記事投稿になります。

今日はPanda Streamという動画アップロード、エンコード(変換)および再生機能を自分のサイトに組み込めるサービスを使ってみたので記事にしてみます。Panda Streamの公式サイトは以下です、あわせて見てみてください。

http://www.pandastream.com/


<Panda Stream概要&特徴>

Panda Streamを使うと、Youtubeみたいに動画ファイルをブラウザからアップロードして、アップロードしたファイルをブラウザ上で再生できる機能を簡単に既存Webサイトに組み込むことができます。特徴は以下です。

  1. すべての機能がREST API形式で提供されていて、Ruby, Python, PHPなどAPIを簡単にコールするライブラリも用意されている
  2. ブラウザからのアップロードはpandaのサーバ側に直接送信されるので、自前のサーバで動画アップ用にインフラ/ミドルなど構築をしなくてよい
  3. データのストア先はAmazon S3を使うので、ストレージを自前で用意する必要なし
  4. アップロード、再生するときのJavaScript, HTML,などサンプルが一通り用意されている。
  5. 多様なInputフォーマットからFLV, MP4(H.264), WebMなど主要な再生環境向けへの変化に対応。

名前はなんだかかわいいですが、できることはけっこうすごいですね。なにかと難しい、動画アップ、変換、が簡単にできちゃいます。HerokuのAdd-onにもなっているので、Herokuを使うときにも便利(←一部の人だけの恩恵かもですが・・・)。

<動画機能を利用するための流れ>

早速使っている前に、大まかな手順を確認しましょう。Panda Streamを使ってWebサイトに動画アップロード&再生機能を埋め込む手順は以下のようになります。

  1. Amazon Web Services(AWS)にサインアップしてAmazon S3を利用できるようにしておきます。
  2. PandaにSign Upします。
  3. CloudというS3のバケットに1対1で対応したエンコーディングした動画を管理するグループを作成。
  4. Panda StreamのAPI Access用のキーとCloud IDを取得。
  5. ここから本番。実際にWebサイトに組み込むためのプログラミングをします。


<実際にWebサイトに組み込むための前準備>

手順(1)〜(4)のCloud作成までは簡単なのでさらっと説明します。

まず、Amazon S3を用意しましょう。AWSのアカウントがなければ以下から申し込んで、Amazon S3を使えるようにしましょう。アップロードした動画やエンコード後の動画、および動画から抽出されたサムネイル画像はAmazon S3上に保存されます。

http://aws.amazon.com/jp/

次にPanda Streamのサイトへいってサインアップしましょう。

http://www.pandastream.com/

サインアップしたら、Home画面のメニューに「API Access」という項目があるので、そのリンクをたどると以下のような画面になります。

Pandaapikey

ここで、
 ・Access Key
 ・Secret Key
 ・API URL(api.pandastream.com)

があることを確認しましょう。これはPanda StreamのAPIを使うときに必要になります。

次にメニューの「Clouds」というメニューがありますのでここをたどり、「Create new cloud」をクリックし、Cloudを作成します。Cloudの名前とパーミッションおよびS3のバケット、Access Key、Secret Keyを設定します。すると、以下の画面のようにCloudが作成されるので、作成後に左上に表示されているIDがCloud IDというもので、この後、APIアクセスで使うので控えておきましょう。

Cloud_id

いろいろサインアップするものがあって大変ですが、これで準備完了です。


<WEBサイトに動画アップロード機能を埋め込む>

Panda Streamのサイトにサンプルコードがアップされているので、それを見たり、動かしたりするのが入門にはちょうどよいです。

http://www.pandastream.com/docs/sample_apps

ここでは、その中のエッセンスだけ抜き出して、アップロードから再生までどんなコードを書けばよいか解説していきます。

まず、アップロード画面のHTML/JavaScript側を準備します。
HTMLは以下のように記述します。actionの遷移先は適当に変えてください。
最初のhiddenはこのあと説明するJavaScriptによりアップロードに成功後に動画のIDが埋め込まれ、次の画面に遷移するときのパラメータになります。

 

   

   

 

JavaScriptはPandaが提供しているJavaScriptライブラリ、jquery.panda-uploaderを使います。jQuery本体を先に読み込んで、Pandaのアップローダーライブラリを読み込みます。

  
  

  


アップローダーの読み込み後、前準備で取得したPanda Stream用のaccess_key、cloud_idなどともにsignatureを書く必要があります。これはサーバサイドで値を作成します。サーバサイド用にはいろいろな言語用にクライアントライブラリがあるので、言語ごとのPandaライブラリを使うことで、signatureを取得できます。ライブラリは以下にあります。

http://www.pandastream.com/docs/client_libs

Ruby, PHP, Pythonなどのライブラリがあります。環境が整っていてよいですが、Java版やPerl版がなかったりもします。
たとえば、Pythonならば以下のような処理でJSON形式でsignatureなど取得できますので、JavaScriptに埋めてください。

panda = Panda(
    api_host='api.pandastream.com',
    cloud_id='Cloud ID',
    access_key='Panda API用のAccess Key',
    secret_key='Panda API用のSecret Key',
    )
python_access_details = panda.signed_params('POST', '/videos.json')
# 以下のようなJSONが取得できます。
#{'access_key': 'xxxxxxxxxxxxxxx', 'timestamp': '2012-01-19T15:01:43.268760+00:00', 'cloud_id': 'xxxxxxxxxxxxxxxxxxxx', 'signature': 'U8OOrnBlYekV3FjyyAIZj1H0kVZlAATn8O/uI07mEMI='}

ここまでのHTML, JavaScript, サーバサイドの処理を組み合わせて、アップロード処理が作れます。説明したパーツを組み合わせると以下のようにプログレスバーが出てくる動画アップロード機能が作れます。

Upload_progress

 アップロードが終わるとコンテンツはS3に登録され、Panda Streamのサーバ側でエンコーディング処理が始まります。同時に、HTMLにhiddenでpanda_video_idとしたところに、動画再生のためのIDがセットされ、フォームのアクション先にpanda_video_idがパラメータとなり画面遷移します。

アップロードされた動画はPanda Streamの画面でも以下のように作成したCloudのDashboardでエンコード中の動画が確認できます。

Dashboard


<WEBサイトで動画を再生する>

さて、アップロードされた動画はエンコードに多少時間がかかります。エンコードのフォーマットはPandaに作成したCloudごとにプロファイルを作成できます。デフォルトはmp4/h.264です。PandaのAPIを使ってエンコードの進捗が何パーセントかも取得できますが、それについては今日は省きます。

動画のエンコードが終わったら、PandaStreamのDashboard上でも再生できますが、アップロード時に取得できたpanda_video_idをパラメータにencodings APIを呼び出し、エンコードされたS3上のファイルパスを取得します。エンコーディングのプロファイルごとにファイルパスや拡張子、スクリーンショットのパスが取得できます。Pythonだと以下のようなコードで取得できます。

    # panda_video_idはアップロード時に取得したID。pandaはPandaクラスのインスタンス
    panda_encodings = json.loads(panda.get("/videos/%s/encodings.json" % panda_video_id))

    encoding = None
 
 # エンコーディングのプロファイルごとに取得できる
    for panda_encoding in panda_encodings:
        if panda_encoding['extname'] == '.mp4' and panda_encoding['status'] == 'success':
            encoding = {
                'id'     : panda_encoding['id'],
                'width'  : panda_encoding['width'],
                'height' : panda_encoding['height'],
                # 以下のようにすると動画のURLやスクリーンショットのjpegのURLが取得できる
                'url'    : "http://%s.s3.amazonaws.com/%s%s" % (’S3のバケット名', panda_encoding['id'], panda_encoding['extname']),
                'screenshot_url' : "http://%s.s3.amazonaws.com/%s_4.jpg" % ('S3のバケット名', panda_encoding['id']),
            }

取得したurlやscreenshot_urlをHTML上で以下のように埋め込みます。ここではHTML5で再生する例を示します。

サーバ側で取得したスクリーンショットのURLや動画ファイルのURLをそれぞれ埋め込めば再生できると思います。もちろん、エンコードが終わってからですが。

かんたんな使い方は以上になります。Panda StreamのDocumentにいろいろな情報があるので、ここから先はそちらを見るようお願いします。


<気になる価格体系>

そういえば、価格について触れないといけないですね。以下のページに記載がありますが、同時に処理できるエンコーダの数により価格が決まります。

http://www.pandastream.com/pricing_and_signup

フリー版はエンコーダは他の人とシェア、ファイルサイズの上限が10MBです。有料版は1つの専用のエンコーダ(dedicated encoder)あたり月間99ドルです。たとえば、3つのエンコーダならば397ドルです。エンコーダの数は同時にエンコードできる動画の数と考えてください。実際には占有できるCPU coreのようです。あと有料版はファイルサイズの上限が5GBのファイルの動画までエンコードできます。


<PaaS上でのプログラミング>

今回はPanda Streamという動画アップロード、エンコード、再生を実現するためのサービスの紹介をしましたが、こういった特定の機能を提供するサービスは動画のエンコードだけでもZencoder(http://zencoder.com/ )など他のサービスがあります。他にも画像変換、メール、PDF生成など、スクラッチで作ると手がかかる機能の実現が最近は外部サービスを使うことで可能になってきているようですね。

Heroku、DotCloudなどのPaaSにより、簡単にアプリケーションをクラウド上にデプロイできるようになりましたが、動画処理やサムネイル生成など特別な機能の実現をしようというときにこれまでと同じやり方ではできないものもあり、少し頭を悩ます部分です。

そういった問題への解決策がPanda Streamのようにアプリケーションの特定の機能を提供するサービス群なのかな、と思います。

クラウド環境でのプログラミングは主にWEB、アプリケーションサーバ用のCPU/DBを提供するHerokuなどのPaaSとその周辺を補強するサービス群を使いこなすことがポイントになるんだろうと思い始めています。

PaaSを使ったアプリケーション構築スタイルをこれから追求しないといけない分野ですね。


<まとめ>

Panda Streamという動画アップロード、エンコード、再生機能を簡単にWebサイトに組み込めます。

こういったサービスは他にもたくさんあるので、今後もたくさん試してみてこのブログ上で共有していきたいと思います。

Panda Streamを使ってWEBサイトに動画アップロード&エンコード&再生機能を作る

こんにちは、大橋です。
ひさしぶりの記事投稿になります。

今日はPanda Streamという動画アップロード、エンコード(変換)および再生機能を自分のサイトに組み込めるサービスを使ってみたので記事にしてみます。Panda Streamの公式サイトは以下です、あわせて見てみてください。

http://www.pandastream.com/


<Panda Stream概要&特徴>

Panda Streamを使うと、Youtubeみたいに動画ファイルをブラウザからアップロードして、アップロードしたファイルをブラウザ上で再生できる機能を簡単に既存Webサイトに組み込むことができます。特徴は以下です。

  1. すべての機能がREST API形式で提供されていて、Ruby, Python, PHPなどAPIを簡単にコールするライブラリも用意されている
  2. ブラウザからのアップロードはpandaのサーバ側に直接送信されるので、自前のサーバで動画アップ用にインフラ/ミドルなど構築をしなくてよい
  3. データのストア先はAmazon S3を使うので、ストレージを自前で用意する必要なし
  4. アップロード、再生するときのJavaScript, HTML,などサンプルが一通り用意されている。
  5. 多様なInputフォーマットからFLV, MP4(H.264), WebMなど主要な再生環境向けへの変化に対応。

名前はなんだかかわいいですが、できることはけっこうすごいですね。なにかと難しい、動画アップ、変換、が簡単にできちゃいます。HerokuのAdd-onにもなっているので、Herokuを使うときにも便利(←一部の人だけの恩恵かもですが・・・)。

<動画機能を利用するための流れ>

早速使っている前に、大まかな手順を確認しましょう。Panda Streamを使ってWebサイトに動画アップロード&再生機能を埋め込む手順は以下のようになります。

  1. Amazon Web Services(AWS)にサインアップしてAmazon S3を利用できるようにしておきます。
  2. PandaにSign Upします。
  3. CloudというS3のバケットに1対1で対応したエンコーディングした動画を管理するグループを作成。
  4. Panda StreamのAPI Access用のキーとCloud IDを取得。
  5. ここから本番。実際にWebサイトに組み込むためのプログラミングをします。


<実際にWebサイトに組み込むための前準備>

手順(1)〜(4)のCloud作成までは簡単なのでさらっと説明します。

まず、Amazon S3を用意しましょう。AWSのアカウントがなければ以下から申し込んで、Amazon S3を使えるようにしましょう。アップロードした動画やエンコード後の動画、および動画から抽出されたサムネイル画像はAmazon S3上に保存されます。

http://aws.amazon.com/jp/

次にPanda Streamのサイトへいってサインアップしましょう。

http://www.pandastream.com/

サインアップしたら、Home画面のメニューに「API Access」という項目があるので、そのリンクをたどると以下のような画面になります。

Pandaapikey

ここで、
 ・Access Key
 ・Secret Key
 ・API URL(api.pandastream.com)

があることを確認しましょう。これはPanda StreamのAPIを使うときに必要になります。

次にメニューの「Clouds」というメニューがありますのでここをたどり、「Create new cloud」をクリックし、Cloudを作成します。Cloudの名前とパーミッションおよびS3のバケット、Access Key、Secret Keyを設定します。すると、以下の画面のようにCloudが作成されるので、作成後に左上に表示されているIDがCloud IDというもので、この後、APIアクセスで使うので控えておきましょう。

Cloud_id

いろいろサインアップするものがあって大変ですが、これで準備完了です。


<WEBサイトに動画アップロード機能を埋め込む>

Panda Streamのサイトにサンプルコードがアップされているので、それを見たり、動かしたりするのが入門にはちょうどよいです。

http://www.pandastream.com/docs/sample_apps

ここでは、その中のエッセンスだけ抜き出して、アップロードから再生までどんなコードを書けばよいか解説していきます。

まず、アップロード画面のHTML/JavaScript側を準備します。
HTMLは以下のように記述します。actionの遷移先は適当に変えてください。
最初のhiddenはこのあと説明するJavaScriptによりアップロードに成功後に動画のIDが埋め込まれ、次の画面に遷移するときのパラメータになります。

 

   

   

 

JavaScriptはPandaが提供しているJavaScriptライブラリ、jquery.panda-uploaderを使います。jQuery本体を先に読み込んで、Pandaのアップローダーライブラリを読み込みます。

  
  

  


アップローダーの読み込み後、前準備で取得したPanda Stream用のaccess_key、cloud_idなどともにsignatureを書く必要があります。これはサーバサイドで値を作成します。サーバサイド用にはいろいろな言語用にクライアントライブラリがあるので、言語ごとのPandaライブラリを使うことで、signatureを取得できます。ライブラリは以下にあります。

http://www.pandastream.com/docs/client_libs

Ruby, PHP, Pythonなどのライブラリがあります。環境が整っていてよいですが、Java版やPerl版がなかったりもします。
たとえば、Pythonならば以下のような処理でJSON形式でsignatureなど取得できますので、JavaScriptに埋めてください。

panda = Panda(
    api_host='api.pandastream.com',
    cloud_id='Cloud ID',
    access_key='Panda API用のAccess Key',
    secret_key='Panda API用のSecret Key',
    )
python_access_details = panda.signed_params('POST', '/videos.json')
# 以下のようなJSONが取得できます。
#{'access_key': 'xxxxxxxxxxxxxxx', 'timestamp': '2012-01-19T15:01:43.268760+00:00', 'cloud_id': 'xxxxxxxxxxxxxxxxxxxx', 'signature': 'U8OOrnBlYekV3FjyyAIZj1H0kVZlAATn8O/uI07mEMI='}

ここまでのHTML, JavaScript, サーバサイドの処理を組み合わせて、アップロード処理が作れます。説明したパーツを組み合わせると以下のようにプログレスバーが出てくる動画アップロード機能が作れます。

Upload_progress

 アップロードが終わるとコンテンツはS3に登録され、Panda Streamのサーバ側でエンコーディング処理が始まります。同時に、HTMLにhiddenでpanda_video_idとしたところに、動画再生のためのIDがセットされ、フォームのアクション先にpanda_video_idがパラメータとなり画面遷移します。

アップロードされた動画はPanda Streamの画面でも以下のように作成したCloudのDashboardでエンコード中の動画が確認できます。

Dashboard


<WEBサイトで動画を再生する>

さて、アップロードされた動画はエンコードに多少時間がかかります。エンコードのフォーマットはPandaに作成したCloudごとにプロファイルを作成できます。デフォルトはmp4/h.264です。PandaのAPIを使ってエンコードの進捗が何パーセントかも取得できますが、それについては今日は省きます。

動画のエンコードが終わったら、PandaStreamのDashboard上でも再生できますが、アップロード時に取得できたpanda_video_idをパラメータにencodings APIを呼び出し、エンコードされたS3上のファイルパスを取得します。エンコーディングのプロファイルごとにファイルパスや拡張子、スクリーンショットのパスが取得できます。Pythonだと以下のようなコードで取得できます。

    # panda_video_idはアップロード時に取得したID。pandaはPandaクラスのインスタンス
    panda_encodings = json.loads(panda.get("/videos/%s/encodings.json" % panda_video_id))

    encoding = None
 
 # エンコーディングのプロファイルごとに取得できる
    for panda_encoding in panda_encodings:
        if panda_encoding['extname'] == '.mp4' and panda_encoding['status'] == 'success':
            encoding = {
                'id'     : panda_encoding['id'],
                'width'  : panda_encoding['width'],
                'height' : panda_encoding['height'],
                # 以下のようにすると動画のURLやスクリーンショットのjpegのURLが取得できる
                'url'    : "http://%s.s3.amazonaws.com/%s%s" % (’S3のバケット名', panda_encoding['id'], panda_encoding['extname']),
                'screenshot_url' : "http://%s.s3.amazonaws.com/%s_4.jpg" % ('S3のバケット名', panda_encoding['id']),
            }

取得したurlやscreenshot_urlをHTML上で以下のように埋め込みます。ここではHTML5で再生する例を示します。

サーバ側で取得したスクリーンショットのURLや動画ファイルのURLをそれぞれ埋め込めば再生できると思います。もちろん、エンコードが終わってからですが。

かんたんな使い方は以上になります。Panda StreamのDocumentにいろいろな情報があるので、ここから先はそちらを見るようお願いします。


<気になる価格体系>

そういえば、価格について触れないといけないですね。以下のページに記載がありますが、同時に処理できるエンコーダの数により価格が決まります。

http://www.pandastream.com/pricing_and_signup

フリー版はエンコーダは他の人とシェア、ファイルサイズの上限が10MBです。有料版は1つの専用のエンコーダ(dedicated encoder)あたり月間99ドルです。たとえば、3つのエンコーダならば397ドルです。エンコーダの数は同時にエンコードできる動画の数と考えてください。実際には占有できるCPU coreのようです。あと有料版はファイルサイズの上限が5GBのファイルの動画までエンコードできます。


<PaaS上でのプログラミング>

今回はPanda Streamという動画アップロード、エンコード、再生を実現するためのサービスの紹介をしましたが、こういった特定の機能を提供するサービスは動画のエンコードだけでもZencoder(http://zencoder.com/ )など他のサービスがあります。他にも画像変換、メール、PDF生成など、スクラッチで作ると手がかかる機能の実現が最近は外部サービスを使うことで可能になってきているようですね。

Heroku、DotCloudなどのPaaSにより、簡単にアプリケーションをクラウド上にデプロイできるようになりましたが、動画処理やサムネイル生成など特別な機能の実現をしようというときにこれまでと同じやり方ではできないものもあり、少し頭を悩ます部分です。

そういった問題への解決策がPanda Streamのようにアプリケーションの特定の機能を提供するサービス群なのかな、と思います。

クラウド環境でのプログラミングは主にWEB、アプリケーションサーバ用のCPU/DBを提供するHerokuなどのPaaSとその周辺を補強するサービス群を使いこなすことがポイントになるんだろうと思い始めています。

PaaSを使ったアプリケーション構築スタイルをこれから追求しないといけない分野ですね。


<まとめ>

Panda Streamという動画アップロード、エンコード、再生機能を簡単にWebサイトに組み込めます。

こういったサービスは他にもたくさんあるので、今後もたくさん試してみてこのブログ上で共有していきたいと思います。

2011年9月 1日 (木)

Dreamforce'11 参加レポートと感想(2) ~第1のデバイスとしてのモバイル~

前回に引き続き、参加レポートその2。

モバイルデバイスの増加と、それに対してのDreamforce'11内で自分が拾った情報と感想を簡単にまとめてみます。Salesforceな部分が少ない記事になっていますが、ご容赦を。


■ モバイルデバイスの利用増

モバイルデバイスについて基調講演にてその成長についてグラフが示されていました。

Mobile_as_first_device

Employees_have_tablets


コンシューマや企業の従業員がモバイルデバイスでWEBアクセスをするだけでなく、企業においては従業員がタブレットデバイスを使うようになっていて、その勢いがすごく大きいということです。

たしかに、自分のお取引させていただいているお客様でもiPadを持っている方が増えています。スマートフォンを含めたスマートモバイルデバイスの利用というのは加速度的に増えていて、その結果、PCからのアクセスというのが主流ではなくなる(なくなった)ということのようです。

自分は大学時代からずっとPCなので、今でもPCメインですが、もう1まわり下の世代以下になるとスマートモバイルデバイスでのWEBアクセスが普段から主流になっていたりするのかな、と思います。

■ 第1のデバイスとしてのスマートモバイルデバイス

そういったスマートモバイルデバイスの増加を考えると、これからは第1のデバイスとして考えなくてはいけないのだと認識しました。

基調講演でモバイルすごいな、と思ってその後のSocial Enterprice Applicationのアーキテクチャについてのセッションに参加したら、これからアプリケーションを作るときにはモバイルデバイスをfirst deviceとして扱おうといった話を聞きました。

そのセッションでは90年代はクラサバ、2000年代はRIAやサーバサイドが中心だったが、これからはハイスペックなモバイル端末のパワーを活かしたアプリケーションアーキテクチャになるという話がありました。Database.comの話をしたうえで、従来はアプリケーションサーバを介してモバイルデバイスはWEBなどにアクセスしたけど、次のアーキテクチャとしてDatabase.comに直接、つなげるようにするという例の紹介がありました。

われわれはWEB開発では今まではPCを第1のデバイスとして考えることが多かったですが、今後は徐々にスマートモバイルデバイスを第1のデバイスとして考えるようにシフトしていかないとまずいなぁ、と認識。そのときにはアプリケーションアーキテクチャ設計、実装、サービス開発のロードマップなども、順序や発想が違うので、今からそういった順序で開発するときの考え方を築いていかないとならないときと実感しました。

■ HTML5で対応するtouch.salesforce.com

Salesforceの毎回の新機能、製品の発表を見ると、基本的には企業向けであるSalesforceの製品であってもコンシューマ向けのサービスで必要とされるレベルのユーザエクスペリエンスをちゃんと提供していきたい、という意志のようなものを感じます。

スマートモバイルデバイスの増加に対してもtouch.salesforce.comとして基調講演で解がひとつ発表されていました。

Touch


touch.salesforce.comはHTML5でできていて、タブレット型、スマートフォン型など問わず、タッチUIを持つスマートモバイルデバイスでSalesforceの機能が使えるようになるということです。Visual Forceでガリガリに書き換えた画面等はできないかもですが、カスタムオブジェクトなどユーザがカスタマイズした部分についても対応しているとのことで、Salesforceのプロダクト群もスマートモバイルデバイスからより使いやすくなるのかと思います。

ソーシャルの波に引き続き、モバイルについてもきっちり対応していっていることが分かる発表でした。

■ まとめ

モバイルが大事だ、は最近ずっと言われていることで、当たり前といえば当たり前なのかもですが、より強く実感をしましたし、帰国したら社内でのモバイル対応の既存の動きについてもっと加速度をつけたい、と思います。

次回はHerokuやSiteforceについてセッションやブースで見聞きしたことを書いてみたいと思います。

Dreamforce'11 参加レポートと感想(2) ~第1のデバイスとしてのモバイル~

前回に引き続き、参加レポートその2。

モバイルデバイスの増加と、それに対してのDreamforce'11内で自分が拾った情報と感想を簡単にまとめてみます。Salesforceな部分が少ない記事になっていますが、ご容赦を。


■ モバイルデバイスの利用増

モバイルデバイスについて基調講演にてその成長についてグラフが示されていました。

Mobile_as_first_device

Employees_have_tablets


コンシューマや企業の従業員がモバイルデバイスでWEBアクセスをするだけでなく、企業においては従業員がタブレットデバイスを使うようになっていて、その勢いがすごく大きいということです。

たしかに、自分のお取引させていただいているお客様でもiPadを持っている方が増えています。スマートフォンを含めたスマートモバイルデバイスの利用というのは加速度的に増えていて、その結果、PCからのアクセスというのが主流ではなくなる(なくなった)ということのようです。

自分は大学時代からずっとPCなので、今でもPCメインですが、もう1まわり下の世代以下になるとスマートモバイルデバイスでのWEBアクセスが普段から主流になっていたりするのかな、と思います。

■ 第1のデバイスとしてのスマートモバイルデバイス

そういったスマートモバイルデバイスの増加を考えると、これからは第1のデバイスとして考えなくてはいけないのだと認識しました。

基調講演でモバイルすごいな、と思ってその後のSocial Enterprice Applicationのアーキテクチャについてのセッションに参加したら、これからアプリケーションを作るときにはモバイルデバイスをfirst deviceとして扱おうといった話を聞きました。

そのセッションでは90年代はクラサバ、2000年代はRIAやサーバサイドが中心だったが、これからはハイスペックなモバイル端末のパワーを活かしたアプリケーションアーキテクチャになるという話がありました。Database.comの話をしたうえで、従来はアプリケーションサーバを介してモバイルデバイスはWEBなどにアクセスしたけど、次のアーキテクチャとしてDatabase.comに直接、つなげるようにするという例の紹介がありました。

われわれはWEB開発では今まではPCを第1のデバイスとして考えることが多かったですが、今後は徐々にスマートモバイルデバイスを第1のデバイスとして考えるようにシフトしていかないとまずいなぁ、と認識。そのときにはアプリケーションアーキテクチャ設計、実装、サービス開発のロードマップなども、順序や発想が違うので、今からそういった順序で開発するときの考え方を築いていかないとならないときと実感しました。

■ HTML5で対応するtouch.salesforce.com

Salesforceの毎回の新機能、製品の発表を見ると、基本的には企業向けであるSalesforceの製品であってもコンシューマ向けのサービスで必要とされるレベルのユーザエクスペリエンスをちゃんと提供していきたい、という意志のようなものを感じます。

スマートモバイルデバイスの増加に対してもtouch.salesforce.comとして基調講演で解がひとつ発表されていました。

Touch


touch.salesforce.comはHTML5でできていて、タブレット型、スマートフォン型など問わず、タッチUIを持つスマートモバイルデバイスでSalesforceの機能が使えるようになるということです。Visual Forceでガリガリに書き換えた画面等はできないかもですが、カスタムオブジェクトなどユーザがカスタマイズした部分についても対応しているとのことで、Salesforceのプロダクト群もスマートモバイルデバイスからより使いやすくなるのかと思います。

ソーシャルの波に引き続き、モバイルについてもきっちり対応していっていることが分かる発表でした。

■ まとめ

モバイルが大事だ、は最近ずっと言われていることで、当たり前といえば当たり前なのかもですが、より強く実感をしましたし、帰国したら社内でのモバイル対応の既存の動きについてもっと加速度をつけたい、と思います。

次回はHerokuやSiteforceについてセッションやブースで見聞きしたことを書いてみたいと思います。

Dreamforce'11 参加レポートと感想(1) ~企業のソーシャル化について~

8/30からDreamforce参加にしています。社長の黒川と私とで2人で参加しています。

Salesforce_plus_you_2


8/31まで終わったのでその分について忘れないうちにまとめておきたいと思います。
われわれはSalesforce関連のインテグレーション開発を主力している会社なので、そういった視点になります。

レポートは何回かに分かれます。Salesforce.comはビジネスユーザー向けのアプリケーションサービスの会社であるとともに開発者向けプラットフォームの会社でもあり、視点はいろいろあります。まずは前者のサービス観点から気になったこととして、「企業のソーシャル化」についてのレポート、感想です。

■ 従来のWEBと企業のソーシャル化

従来のWEBと企業のソーシャル化について基調講演での発表内容についてはPublickeyさんの以下の記事に正確な情報があるのでそちらを参照してもらえるとよいかと思います。

http://www.publickey1.jp/blog/11/chatterhtml5ui.html

ここではフレクトの担当者としての追加の感想を書きます。

基調講演では最初の方にデータとしてインターネットの利用が従来の検索から始まるWEBではなく、Facebookなどのソーシャルメディアを中心としたものに変遷してきていることが示されていました。日本ではどうかは正確にはわからないのですが、そんなに使われているんだぁ、と思いました。

Fb_eat_web


その上で、ネットサービス、コンシューマ向けサービスがソーシャル化する中、「企業のソーシャル化ができているか?」と問いかけ、それに対するSalesforce.comのアプローチがChatterをベースにした各種機能の発表がありました。

ChatterでIMができる、顧客とプライベートグループを作ってコミュニケーションができる、Contact(取引先責任者)にSocial Media上でのコミュニケーション情報が記録されるなどソーシャル化を示す機能が次々と発表されました。次々と発表されるのでメモが追いつかないくらいでした。

Chatter_now


ポイントは、(1)フィードやチャットなどChatterを基本としてFacebookのようにエンタープライズシステムが使える、(2)従来のWebではなく、ソーシャルなインターネットを前提とした顧客とのリレーションづくりができる、という2点だと思います。

(1)についてはChatterが出てきたときからそういった発想がありましたし、新しくはないかもですが、大事なことと考えています。Salesforceはコンシューマサービスの中でも特にユーザへのサービス、UIが進んでいるところと同じようにエンタープライズシステムを使えるようにしたい、というのが強い会社なので今はFacebookと同じようにユーザエクスペリエンスを提供していくということなのかと。(昔はAmazonのように、将来はわかりません)。

(2)は特に今回強調されたことで、ソーシャルメディアの情報をSalesforceに統合することで、新しい顧客との関係づくり、をイメージさせるようなデモが多く見られました。(2)については以下の感想でもう少し詳細を。

■ ソーシャルメディアの情報を使っている現場から感想

一緒に参加した社長とともに、企業のソーシャル化、Chatterを中心としたソーシャルメディアとの連携には強い興味を持ちました。(ほかの参加者さんも同じと思いますが)

私どもも社内では営業管理にSalesforceを使っています。顧客や顧客の担当者情報についてFacebookやTwitterのURLが分かっていれば、取引先責任者(Contact)のフィールド(カスタムで追加)に入れるよう"手動運用"していて「顧客がどんなことに関心を持っているのか」についてわれわれも強く関心を持って営業活動をしています。

運用してみると、実際に初めてお会いする方でも、ソーシャルメディア上で関心事などがあらかじめ分かっていると、より強く相手に関心を持った状態で人とお会いしてよりよいコミュニケーションがとれるようになったと思います。また、お客様との双方向の関係においてもソーシャルメディア上でのつながりが何かしらある方が、より深いリレーションが築けています。

そういった現場にいる担当として、顧客管理をするシステムとしてのSalesforceが次にChatterを基点に外部のソーシャルメディアと連動して情報も含めて顧客とよいリレーションを築けるようにしよう、という方向のは単純に私どもの手動運用を減らしてくれるだけでなく、顧客とのよりより関係づくりの新しい手段を提供してくれる可能性を持っているのではと思いました。

ただ、システムの機能としては充実したとしても、機能だけではなく、まだ成熟していないソーシャルメディアを使った業務、運用に耐えられる同時にベターなやり方、自分たちなりのプラクティスを同時に蓄積していく必要があると思いました。ぼくらも顧客のソーシャルメディア情報を登録していますが、活用については人によってまだばらつきがある感じです。

Social Divideという言葉が基調講演でありましたが、ITリテラシーという言葉があるように、ソーシャルメディアと使った顧客とのリレーション構築には、何かしらのリテラシーが必要で、企業としてはそれができる集団になっていかないと、効果を上げられないだろうなぁ、と思いました。

■ まとめと次回

ソーシャルメディアをつかった企業活動については今回の発表にある機能によい運用がかけ合わさればより新しいレベルでのリレーションづくりができると思いました。

まだ運用プラクティスが少ない分野ですが、自分たちでも機能のあるなしにかかわらず、引き続き実践して、機能の理解だけでなく、より使いこなせるようになるよう、がんばってみます。

次のレポートはモバイル関連を書いて、その次はHerokuとかSiteforceのことを書こうかと思います。

Dreamforce'11 参加レポートと感想(1) ~企業のソーシャル化について~

8/30からDreamforce参加にしています。社長の黒川と私とで2人で参加しています。

Salesforce_plus_you_2


8/31まで終わったのでその分について忘れないうちにまとめておきたいと思います。
われわれはSalesforce関連のインテグレーション開発を主力している会社なので、そういった視点になります。

レポートは何回かに分かれます。Salesforce.comはビジネスユーザー向けのアプリケーションサービスの会社であるとともに開発者向けプラットフォームの会社でもあり、視点はいろいろあります。まずは前者のサービス観点から気になったこととして、「企業のソーシャル化」についてのレポート、感想です。

■ 従来のWEBと企業のソーシャル化

従来のWEBと企業のソーシャル化について基調講演での発表内容についてはPublickeyさんの以下の記事に正確な情報があるのでそちらを参照してもらえるとよいかと思います。

http://www.publickey1.jp/blog/11/chatterhtml5ui.html

ここではフレクトの担当者としての追加の感想を書きます。

基調講演では最初の方にデータとしてインターネットの利用が従来の検索から始まるWEBではなく、Facebookなどのソーシャルメディアを中心としたものに変遷してきていることが示されていました。日本ではどうかは正確にはわからないのですが、そんなに使われているんだぁ、と思いました。

Fb_eat_web


その上で、ネットサービス、コンシューマ向けサービスがソーシャル化する中、「企業のソーシャル化ができているか?」と問いかけ、それに対するSalesforce.comのアプローチがChatterをベースにした各種機能の発表がありました。

ChatterでIMができる、顧客とプライベートグループを作ってコミュニケーションができる、Contact(取引先責任者)にSocial Media上でのコミュニケーション情報が記録されるなどソーシャル化を示す機能が次々と発表されました。次々と発表されるのでメモが追いつかないくらいでした。

Chatter_now


ポイントは、(1)フィードやチャットなどChatterを基本としてFacebookのようにエンタープライズシステムが使える、(2)従来のWebではなく、ソーシャルなインターネットを前提とした顧客とのリレーションづくりができる、という2点だと思います。

(1)についてはChatterが出てきたときからそういった発想がありましたし、新しくはないかもですが、大事なことと考えています。Salesforceはコンシューマサービスの中でも特にユーザへのサービス、UIが進んでいるところと同じようにエンタープライズシステムを使えるようにしたい、というのが強い会社なので今はFacebookと同じようにユーザエクスペリエンスを提供していくということなのかと。(昔はAmazonのように、将来はわかりません)。

(2)は特に今回強調されたことで、ソーシャルメディアの情報をSalesforceに統合することで、新しい顧客との関係づくり、をイメージさせるようなデモが多く見られました。(2)については以下の感想でもう少し詳細を。

■ ソーシャルメディアの情報を使っている現場から感想

一緒に参加した社長とともに、企業のソーシャル化、Chatterを中心としたソーシャルメディアとの連携には強い興味を持ちました。(ほかの参加者さんも同じと思いますが)

私どもも社内では営業管理にSalesforceを使っています。顧客や顧客の担当者情報についてFacebookやTwitterのURLが分かっていれば、取引先責任者(Contact)のフィールド(カスタムで追加)に入れるよう"手動運用"していて「顧客がどんなことに関心を持っているのか」についてわれわれも強く関心を持って営業活動をしています。

運用してみると、実際に初めてお会いする方でも、ソーシャルメディア上で関心事などがあらかじめ分かっていると、より強く相手に関心を持った状態で人とお会いしてよりよいコミュニケーションがとれるようになったと思います。また、お客様との双方向の関係においてもソーシャルメディア上でのつながりが何かしらある方が、より深いリレーションが築けています。

そういった現場にいる担当として、顧客管理をするシステムとしてのSalesforceが次にChatterを基点に外部のソーシャルメディアと連動して情報も含めて顧客とよいリレーションを築けるようにしよう、という方向のは単純に私どもの手動運用を減らしてくれるだけでなく、顧客とのよりより関係づくりの新しい手段を提供してくれる可能性を持っているのではと思いました。

ただ、システムの機能としては充実したとしても、機能だけではなく、まだ成熟していないソーシャルメディアを使った業務、運用に耐えられる同時にベターなやり方、自分たちなりのプラクティスを同時に蓄積していく必要があると思いました。ぼくらも顧客のソーシャルメディア情報を登録していますが、活用については人によってまだばらつきがある感じです。

Social Divideという言葉が基調講演でありましたが、ITリテラシーという言葉があるように、ソーシャルメディアと使った顧客とのリレーション構築には、何かしらのリテラシーが必要で、企業としてはそれができる集団になっていかないと、効果を上げられないだろうなぁ、と思いました。

■ まとめと次回

ソーシャルメディアをつかった企業活動については今回の発表にある機能によい運用がかけ合わさればより新しいレベルでのリレーションづくりができると思いました。

まだ運用プラクティスが少ない分野ですが、自分たちでも機能のあるなしにかかわらず、引き続き実践して、機能の理解だけでなく、より使いこなせるようになるよう、がんばってみます。

次のレポートはモバイル関連を書いて、その次はHerokuとかSiteforceのことを書こうかと思います。

2011年8月26日 (金)

Heroku for Javaとセールスフォース

HerokuがJavaをサポートするとのことです。

http://blog.heroku.com/archives/2011/8/25/java/

昨年、2010年のDreamforceでセールスフォース・ドットコム(以下、セールスフォース)がHerokuを買収したというニュースが出たあと、Node.jsなどがサポートされ、RubyまつもとゆきひろさんがHerokuに参加され、といろいろな注目すべきニュースがありましたが、Javaのサポートもすごく大きなニュースです。

また、フレクトはJavaによるWEB開発を得意領域のひとつにしているので、当社としては待ち望んでいたニュースでもありました。

以下、さーっと、Herokuのブログ記事やDev Centerのドキュメントを読んだかぎりでのHeroku for Javaについての自分なりの理解をまとめておこうと思います。(さーっと読んだ結果なので、間違いあるかもです)

■ HerokuっぽくJavaを使う

Herokuは小さいチームがスピード感を持ってインフラ/ミドル管理などのストレスなく高い生産性でアプリケーションをシンプルに構築できるプラットフォームを作るという思想でサービスの拡張等を進めているとぼくは理解しています。ビジネスマンというよりはDeveloperの立ち位置にすごく近い感じ。Rubyが最初の言語として選択されているのは、そういう思想のもとにサービスを展開しているからと理解していました。

したがって、個人的(フレクト的にも)Javaをサポートしてほしいな、と思いながら、ちょっと文化が違うかも、とも思っていました。Herokuっぽい部分とJavaっぽい部分が合わない部分があるのではと(あいまいな表現ですみません)。

これについて、Herokuはブログ記事によると、Javaにはやはりいくつか問題があると認識していたようです。特にJ2EE(JEE)とJ2EEアプリケーションコンテナを使った開発、デプロイが問題であることを認識していたようです。

これに対して、Heroku for JavaではJ2EE的なアプリケーションコンテナを使わないでJettyをアプリケーション内に埋め込むというアプローチをとっています。そのうえで、J2EE的なアプリケーションコンテナが提供しているデプロイ、ロギング、クラスタリング等の機能をHerokuのプラットフォームが提供するということのようです。

こういったアプローチをとることにより、JavaにおいてもRubyでHerokuを使うのと同じようにソースを書いて、gitにコミットして、pushするというRubyの場合と同じステップで簡単にアプリケーション構築・デプロイができるようになっています。実際にブログ記事中の「Heroku for Java in 2 minutes」を見ても、Rubyでのソース書く→Deployのステップとまったく同じように見えます。すごくシンプルですね。

Javaのサポートってどうなるのかな、Herokuと合うのかな、とちょっとだけ心配していましたが、杞憂のようでした。Herokuが大事にしている生産性、シンプルにストレスのないことをJavaでもとなってますね。Java的な文化にあわせるのではなく、JavaをHerokuっぽく使えるようにされています。すごくよいと思いました。社内でもいいねと話しています。早急に社内のエンジニア達でキャッチアップしようと思います。

■ セールスフォース風味な部分やVMforceな部分が少し入っている

あと、今回のJavaサポート関連のドキュメントを読んでいると、セールスフォースとの関連がちらほら見え隠れします。

たとえば、Force.com、Database.comとHerokuとのインテグレーションはどうするの?といったFAQが入っています。

http://devcenter.heroku.com/articles/java-faq#how_do_i_build_forcecom_and_databasecom_java_applications_on_heroku

買収後、あまりセールスフォース的な要素が見られなかったHerokuですが、少しずつ相乗効果が出せる部分が見えてきそうです。セールスフォースを使ってインテグレーション事業に取り組んでいる我々としてはこういったことは大歓迎です。

VMForce風なところは、tutorialにSpringをつかったものがあったり、ブログ記事中の「Why Java?」に対して「600万人のDeveloperがいるから」みたいな記述がある部分です。VMForceはSpringという業界でよく使われているのフレームワークで、なおかつ世界中の600万人のJava Developerにクラウドを提供できる、という触れ込みだったので、その辺の文言やら雰囲気がちょっとだけHeroku for Javaに混ざっていると感じました。VMForceは今後、Heroku for Javaとどう違いを出すのでしょうか。いろいろ気になることはありますが、Dreamforce等、今後のニュースを確かめたいです。

■ まとめ

Heroku for Javaについて今ある情報だけからの感想を簡単にまとめました。Herokuのよさを最大限に活かしてJavaが使えるというのがすごくうれしいですね。

セールスフォースのプロダクト群とも、Database.comなど相乗効果が高そうなものはどんどん連携しやすくなるのだと思います。その辺も要ウォッチですね。

今後は実際に使ってみた記事など技術的なことも書いていきたいと思います。

■ ちょっとだけ当社のことと中途採用のこと

フレクトはWEBサイトとSalesforceとの連携開発を1つの強みとしており、WEB開発についはJavaがメインです。そういった我々にとってHeroku for Javaの発表は待ちに待った発表でした。今後、Heroku for Javaと他のSalesforceプロダクト群連携ソリューションをもっと充実させていきたいと思います。

また、それを担ってくれるエンジニアも引き続き募集しています。Herokuなどクラウドプラットフォームでの開発を行いたい方、ぜひ以下からご連絡をいただければと思います。

http://www.flect.co.jp/recruit/index.html

Heroku for Javaとセールスフォース

HerokuがJavaをサポートするとのことです。

http://blog.heroku.com/archives/2011/8/25/java/

昨年、2010年のDreamforceでセールスフォース・ドットコム(以下、セールスフォース)がHerokuを買収したというニュースが出たあと、Node.jsなどがサポートされ、RubyまつもとゆきひろさんがHerokuに参加され、といろいろな注目すべきニュースがありましたが、Javaのサポートもすごく大きなニュースです。

また、フレクトはJavaによるWEB開発を得意領域のひとつにしているので、当社としては待ち望んでいたニュースでもありました。

以下、さーっと、Herokuのブログ記事やDev Centerのドキュメントを読んだかぎりでのHeroku for Javaについての自分なりの理解をまとめておこうと思います。(さーっと読んだ結果なので、間違いあるかもです)

■ HerokuっぽくJavaを使う

Herokuは小さいチームがスピード感を持ってインフラ/ミドル管理などのストレスなく高い生産性でアプリケーションをシンプルに構築できるプラットフォームを作るという思想でサービスの拡張等を進めているとぼくは理解しています。ビジネスマンというよりはDeveloperの立ち位置にすごく近い感じ。Rubyが最初の言語として選択されているのは、そういう思想のもとにサービスを展開しているからと理解していました。

したがって、個人的(フレクト的にも)Javaをサポートしてほしいな、と思いながら、ちょっと文化が違うかも、とも思っていました。Herokuっぽい部分とJavaっぽい部分が合わない部分があるのではと(あいまいな表現ですみません)。

これについて、Herokuはブログ記事によると、Javaにはやはりいくつか問題があると認識していたようです。特にJ2EE(JEE)とJ2EEアプリケーションコンテナを使った開発、デプロイが問題であることを認識していたようです。

これに対して、Heroku for JavaではJ2EE的なアプリケーションコンテナを使わないでJettyをアプリケーション内に埋め込むというアプローチをとっています。そのうえで、J2EE的なアプリケーションコンテナが提供しているデプロイ、ロギング、クラスタリング等の機能をHerokuのプラットフォームが提供するということのようです。

こういったアプローチをとることにより、JavaにおいてもRubyでHerokuを使うのと同じようにソースを書いて、gitにコミットして、pushするというRubyの場合と同じステップで簡単にアプリケーション構築・デプロイができるようになっています。実際にブログ記事中の「Heroku for Java in 2 minutes」を見ても、Rubyでのソース書く→Deployのステップとまったく同じように見えます。すごくシンプルですね。

Javaのサポートってどうなるのかな、Herokuと合うのかな、とちょっとだけ心配していましたが、杞憂のようでした。Herokuが大事にしている生産性、シンプルにストレスのないことをJavaでもとなってますね。Java的な文化にあわせるのではなく、JavaをHerokuっぽく使えるようにされています。すごくよいと思いました。社内でもいいねと話しています。早急に社内のエンジニア達でキャッチアップしようと思います。

■ セールスフォース風味な部分やVMforceな部分が少し入っている

あと、今回のJavaサポート関連のドキュメントを読んでいると、セールスフォースとの関連がちらほら見え隠れします。

たとえば、Force.com、Database.comとHerokuとのインテグレーションはどうするの?といったFAQが入っています。

http://devcenter.heroku.com/articles/java-faq#how_do_i_build_forcecom_and_databasecom_java_applications_on_heroku

買収後、あまりセールスフォース的な要素が見られなかったHerokuですが、少しずつ相乗効果が出せる部分が見えてきそうです。セールスフォースを使ってインテグレーション事業に取り組んでいる我々としてはこういったことは大歓迎です。

VMForce風なところは、tutorialにSpringをつかったものがあったり、ブログ記事中の「Why Java?」に対して「600万人のDeveloperがいるから」みたいな記述がある部分です。VMForceはSpringという業界でよく使われているのフレームワークで、なおかつ世界中の600万人のJava Developerにクラウドを提供できる、という触れ込みだったので、その辺の文言やら雰囲気がちょっとだけHeroku for Javaに混ざっていると感じました。VMForceは今後、Heroku for Javaとどう違いを出すのでしょうか。いろいろ気になることはありますが、Dreamforce等、今後のニュースを確かめたいです。

■ まとめ

Heroku for Javaについて今ある情報だけからの感想を簡単にまとめました。Herokuのよさを最大限に活かしてJavaが使えるというのがすごくうれしいですね。

セールスフォースのプロダクト群とも、Database.comなど相乗効果が高そうなものはどんどん連携しやすくなるのだと思います。その辺も要ウォッチですね。

今後は実際に使ってみた記事など技術的なことも書いていきたいと思います。

■ ちょっとだけ当社のことと中途採用のこと

フレクトはWEBサイトとSalesforceとの連携開発を1つの強みとしており、WEB開発についはJavaがメインです。そういった我々にとってHeroku for Javaの発表は待ちに待った発表でした。今後、Heroku for Javaと他のSalesforceプロダクト群連携ソリューションをもっと充実させていきたいと思います。

また、それを担ってくれるエンジニアも引き続き募集しています。Herokuなどクラウドプラットフォームでの開発を行いたい方、ぜひ以下からご連絡をいただければと思います。

http://www.flect.co.jp/recruit/index.html

2011年8月18日 (木)

Amazon SESをbotoを使ってPythonで操作する

前回の記事に引き続き、Amazon SESについてです。

今回はPythonでbotoを使って実際にAmazon SESを使ってメールを送信したり、メール送信結果の統計情報を取得してみようと思います。


■ botoを利用する

botoはAmazon SESなどAmazon Web Servicesのプロダクト群のAPIを操作できるPython用のライブラリです。

インストール方法については以前、Amazon S3を操作する方法の記事で書いたので、以下を参照してください。

http://blog.flect.co.jp/cto/2011/08/pythonamazon-s3-d36b.html


■ Amazon SESを使えるようにする

botoを使う前にAmazon SESのページへ行き、サービス利用を申し込んでおいてください。

申し込んだ直後に利用できる環境はサンドボックス環境と呼ばれる環境です。1日に200通までの送信、および認証されたメールアドレスにしか送受信できない、という制限があります。サンドボックス環境で十分に検証をしたら、以下からプロダクション環境利用の申請をします。

https://aws-portal.amazon.com/gp/aws/html-forms-controller/contactus/SESAccessRequest


■ SESへの接続

では、これから実際に使ってみます。
環境変数としてAWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEYをあらかじめセットしておけばプログラム中にアクセスキー、秘密キーを記述する必要はありません。以下のような感じで接続できます。

from boto.ses.connection import SESConnection
conn = SESConnection()

ホストの指定も以下のように一応できますが、現状では東海岸しかホストされていないので、あまり指定する意味はないです。

# SESへの接続用オブジェクト作成。現在は東海岸しかホストされていない。
conn = SESConnection(host='email.us-east-1.amazonaws.com')

■ メールアドレスの認証

先ほども記載した通り、Amazon SESでは認証されたメールアドレスしか、送受信できません。
Amazon SESにはVerifyEmailAddressというAPIが用意されていて、これを使うことでメールアドレスの認証ができます。以下のようにして呼び出します。

conn = SESConnection()
conn.verify_email_address('o-masaoki@flect.co.jp')

このAPIを呼び出すと、対象のメールアドレスに認証確認のメールが届き、メール本文内のURLをクリックすると認証成功となります。ListVefiriedEmailAddressesというAPIを呼び出すことで認証済みのメールアドレスのリストを取得できます。たとえば、以下のようにすると呼び出せます。

# 認証済みアドレスの取得(細かいチェック省いています)
response = conn.list_verified_email_addresses()
result = response['ListVerifiedEmailAddressesResponse']['ListVerifiedEmailAddressesResult']
addresses = result['VerifiedEmailAddresses']

for address in addresses:
   print address


■ メールの送信

メールの送信はSendEmail APIを使います。使い方は以下のような感じです。

#!/usr/bin/env python
# -*- coding:utf-8 -*-

from boto.ses.connection import SESConnection

# SESへの接続用オブジェクト作成。
conn = SESConnection()

# 送信先のtoのアドレスリスト
to_addresses = [
   'o-masaoki+sestest01@flect.co.jp',
   'o-masaoki+sestest02@flect.co.jp',
   'o-masaoki+sestest03@flect.co.jp',
   ]

# reply to headerにセットするアドレス
reply_addresses = ['o-masaoki@flect.co.jp']

# SendMail APIを呼び出す
conn.send_email('o-masaoki@flect.co.jp' # from
               ,u'テスト'               # subject
               ,u'本文のテスト'          # body
               ,to_addresses           # toのアドレスリスト
               ,cc_addresses=[]        # ccのアドレスリスト
               ,bcc_addresses=[]       # bccのアドレスリスト
               ,reply_addresses=reply_addresses        # Reply-toヘッダの設定
               ,return_path='masaoki.ohashi@gmail.com' # bounceメールを返す場所
               )

上記のサンプルは日本語が書かれていますが、送信元のプログラムがMac OS
X、受信側のメーラーがGMailという環境では日本語がUTF-8で表示されました。他の環境ではダメかもしれません。SendEmail APIのリファレンスは以下ですが、主要なパラメータについて上記サンプル中のコメントに説明を記載しておきました。

http://docs.amazonwebservices.com/ses/latest/APIReferene/index.html?API_SendEmail.html

SendEmail APIはパラメータにReply-toやbounceメールを指定すると、自動的にメールのヘッダに付与してくれます。文字コードのエンコードの指定やヘッダの細かい制御等を行うにはSendRawEmailというAPIがあります。これについてはまたの機会に書きたいと思います。


■ 統計情報の取得

前回の記事で、ユーザはバウンスメール数などの統計情報のフィードバックを見られる旨を記載しましたが、それが次に説明するGetSendStatistics APIです。この機能と次に説明するQuotaの機能が、Amazon SESのすごく特徴的なところで、Amazon SESの配信性能の仕組みを支えている部分のひとつになります。

まず、GetSendStatistics APIです。このAPIでは15分インターバルで集計される送信メールの統計情報(15分ごとの統計情報のグループをDataPointと言うようです)を取得できます。サンプルは以下の通りです。

#!/usr/bin/env python
# -*- coding:utf-8 -*-

from boto.ses.connection import SESConnection

# SESへの接続用オブジェクト作成。現在は東海岸しかホストされていない。
conn = SESConnection(host='email.us-east-1.amazonaws.com')

# 15分間隔ポイントで統計情報を作成している
response = conn.get_send_statistics()

result = response['GetSendStatisticsResponse']['GetSendStatisticsResult']
points = result['SendDataPoints']

for p in points:
   print '----------------------'
   print 'time of data point : %s' % p['Timestamp']

   # 配信を試みたメール数(配信数)
   print 'delivery attempts : %s' % p['DeliveryAttempts']

   # 何かしらの原因で不達になったバウンスメール数
   print 'bounces : %s' % p['Bounces']

   # 苦情として連絡されたメール数(受信者から拒否されたメール数)
   print 'complaints : %s' % p['Complaints']

   # Amazon SESサービスにより拒否されたメール数。SESのフィルタリングにひっかかったものと思われる。
   print 'rejects : %s' % p['Rejects']

print '----------------------'

取得できるのは配信試行数(DeliveryAttempts)、バウンスメール数(Bounces)、受信側から拒否された数(Complaints)、Amazon SESのフィルタリングにより送信拒否となった数(Rejects)の4つの数値とDataPointのタイムスタンプが取得できます。上記のサンプルプログラムだと以下のように出力されます。

----------------------
time of data point : 2011-08-15T02:38:00Z
delivery attempts : 17
bounces : 0
complaints : 0
rejects : 0
----------------------
time of data point : 2011-08-11T15:23:00Z
delivery attempts : 1
bounces : 0
complaints : 0
rejects : 0
----------------------
time of data point : 2011-08-17T15:38:00Z
delivery attempts : 3
bounces : 0
complaints : 0
rejects : 0
----------------------

ユーザはこれを見て、bounces、complaints, rejectsを減らすことによって配信メールの品質を向上させていく必要があります。Amazon SESにはじかれたメールはAPI経由で、バウンスメールはReturn-Pathのメールから判断できるので、それらの内容をよく確認し、配信リストの修正、品質向上に取り組むといいと思います。


■ 配信割当量(Quota)情報の取得

サンドボックス環境だと固定の数値、プロダクション環境だと、送信したメール数、品質によって徐々にアップしていきます。取得できるAPIはGetSendQuotaで、以下のように使います。

# SESへの接続まではGetSendStatisticsのサンプルと同じです。
response = conn.get_send_quota()
result = response['GetSendQuotaResponse']['GetSendQuotaResult']

# 24時間以内に送信できるメール数
print 'max 24 hour send : %s' % result['Max24HourSend']

# 24時間以内に送信したメール数
print 'sent last hour send : %s' % result['SentLast24Hours']

# 1秒間に送信できるメール数
print 'max send rate : %s' % result['MaxSendRate']

上記のサンプルの通り、24時間以内に送信できるメール数、実際に24時間以内に送信したメール数、それと1秒間に何通送信できるか、という割当情報が取得できます。GetSendStatistics APIで品質チェックをして、品質向上と配信数の向上に努めたら、徐々にこの割当がアップしていくようです。なんだか、レベル上げみたいですね。

 

■ まとめ

前回の記事に引き続き、今回はAmazon SESのAPIをbotoライブラリを使ってPythonでプログラミングする場合の使い方をまとめました。ただ送信するだけではなく、SESからフィードバックをもらい、より高品質なメール配信ができるようにしてもらいたい、というAWS側からの意思みたいなものを感じるAPIですね。

AWSはまだまだ使っていないプロダクトも多いので、今後もいろいろいじってみて実運用につなげていきたいと思います。

■ おまけ ~中途採用のお知らせ~

フレクトではAWSやSalesforceを使ったソリューション事業の拡大をしております。クラウド環境を使った開発に興味がある人はぜひご連絡いただければと思います。以下、採用ページです。

http://www.flect.co.jp/recruit/index.html

Amazon SESをbotoを使ってPythonで操作する

前回の記事に引き続き、Amazon SESについてです。

今回はPythonでbotoを使って実際にAmazon SESを使ってメールを送信したり、メール送信結果の統計情報を取得してみようと思います。


■ botoを利用する

botoはAmazon SESなどAmazon Web Servicesのプロダクト群のAPIを操作できるPython用のライブラリです。

インストール方法については以前、Amazon S3を操作する方法の記事で書いたので、以下を参照してください。

http://blog.flect.co.jp/cto/2011/08/pythonamazon-s3-d36b.html


■ Amazon SESを使えるようにする

botoを使う前にAmazon SESのページへ行き、サービス利用を申し込んでおいてください。

申し込んだ直後に利用できる環境はサンドボックス環境と呼ばれる環境です。1日に200通までの送信、および認証されたメールアドレスにしか送受信できない、という制限があります。サンドボックス環境で十分に検証をしたら、以下からプロダクション環境利用の申請をします。

https://aws-portal.amazon.com/gp/aws/html-forms-controller/contactus/SESAccessRequest


■ SESへの接続

では、これから実際に使ってみます。
環境変数としてAWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEYをあらかじめセットしておけばプログラム中にアクセスキー、秘密キーを記述する必要はありません。以下のような感じで接続できます。

from boto.ses.connection import SESConnection
conn = SESConnection()

ホストの指定も以下のように一応できますが、現状では東海岸しかホストされていないので、あまり指定する意味はないです。

# SESへの接続用オブジェクト作成。現在は東海岸しかホストされていない。
conn = SESConnection(host='email.us-east-1.amazonaws.com')

■ メールアドレスの認証

先ほども記載した通り、Amazon SESでは認証されたメールアドレスしか、送受信できません。
Amazon SESにはVerifyEmailAddressというAPIが用意されていて、これを使うことでメールアドレスの認証ができます。以下のようにして呼び出します。

conn = SESConnection()
conn.verify_email_address('o-masaoki@flect.co.jp')

このAPIを呼び出すと、対象のメールアドレスに認証確認のメールが届き、メール本文内のURLをクリックすると認証成功となります。ListVefiriedEmailAddressesというAPIを呼び出すことで認証済みのメールアドレスのリストを取得できます。たとえば、以下のようにすると呼び出せます。

# 認証済みアドレスの取得(細かいチェック省いています)
response = conn.list_verified_email_addresses()
result = response['ListVerifiedEmailAddressesResponse']['ListVerifiedEmailAddressesResult']
addresses = result['VerifiedEmailAddresses']

for address in addresses:
   print address


■ メールの送信

メールの送信はSendEmail APIを使います。使い方は以下のような感じです。

#!/usr/bin/env python
# -*- coding:utf-8 -*-

from boto.ses.connection import SESConnection

# SESへの接続用オブジェクト作成。
conn = SESConnection()

# 送信先のtoのアドレスリスト
to_addresses = [
   'o-masaoki+sestest01@flect.co.jp',
   'o-masaoki+sestest02@flect.co.jp',
   'o-masaoki+sestest03@flect.co.jp',
   ]

# reply to headerにセットするアドレス
reply_addresses = ['o-masaoki@flect.co.jp']

# SendMail APIを呼び出す
conn.send_email('o-masaoki@flect.co.jp' # from
               ,u'テスト'               # subject
               ,u'本文のテスト'          # body
               ,to_addresses           # toのアドレスリスト
               ,cc_addresses=[]        # ccのアドレスリスト
               ,bcc_addresses=[]       # bccのアドレスリスト
               ,reply_addresses=reply_addresses        # Reply-toヘッダの設定
               ,return_path='masaoki.ohashi@gmail.com' # bounceメールを返す場所
               )

上記のサンプルは日本語が書かれていますが、送信元のプログラムがMac OS
X、受信側のメーラーがGMailという環境では日本語がUTF-8で表示されました。他の環境ではダメかもしれません。SendEmail APIのリファレンスは以下ですが、主要なパラメータについて上記サンプル中のコメントに説明を記載しておきました。

http://docs.amazonwebservices.com/ses/latest/APIReferene/index.html?API_SendEmail.html

SendEmail APIはパラメータにReply-toやbounceメールを指定すると、自動的にメールのヘッダに付与してくれます。文字コードのエンコードの指定やヘッダの細かい制御等を行うにはSendRawEmailというAPIがあります。これについてはまたの機会に書きたいと思います。


■ 統計情報の取得

前回の記事で、ユーザはバウンスメール数などの統計情報のフィードバックを見られる旨を記載しましたが、それが次に説明するGetSendStatistics APIです。この機能と次に説明するQuotaの機能が、Amazon SESのすごく特徴的なところで、Amazon SESの配信性能の仕組みを支えている部分のひとつになります。

まず、GetSendStatistics APIです。このAPIでは15分インターバルで集計される送信メールの統計情報(15分ごとの統計情報のグループをDataPointと言うようです)を取得できます。サンプルは以下の通りです。

#!/usr/bin/env python
# -*- coding:utf-8 -*-

from boto.ses.connection import SESConnection

# SESへの接続用オブジェクト作成。現在は東海岸しかホストされていない。
conn = SESConnection(host='email.us-east-1.amazonaws.com')

# 15分間隔ポイントで統計情報を作成している
response = conn.get_send_statistics()

result = response['GetSendStatisticsResponse']['GetSendStatisticsResult']
points = result['SendDataPoints']

for p in points:
   print '----------------------'
   print 'time of data point : %s' % p['Timestamp']

   # 配信を試みたメール数(配信数)
   print 'delivery attempts : %s' % p['DeliveryAttempts']

   # 何かしらの原因で不達になったバウンスメール数
   print 'bounces : %s' % p['Bounces']

   # 苦情として連絡されたメール数(受信者から拒否されたメール数)
   print 'complaints : %s' % p['Complaints']

   # Amazon SESサービスにより拒否されたメール数。SESのフィルタリングにひっかかったものと思われる。
   print 'rejects : %s' % p['Rejects']

print '----------------------'

取得できるのは配信試行数(DeliveryAttempts)、バウンスメール数(Bounces)、受信側から拒否された数(Complaints)、Amazon SESのフィルタリングにより送信拒否となった数(Rejects)の4つの数値とDataPointのタイムスタンプが取得できます。上記のサンプルプログラムだと以下のように出力されます。

----------------------
time of data point : 2011-08-15T02:38:00Z
delivery attempts : 17
bounces : 0
complaints : 0
rejects : 0
----------------------
time of data point : 2011-08-11T15:23:00Z
delivery attempts : 1
bounces : 0
complaints : 0
rejects : 0
----------------------
time of data point : 2011-08-17T15:38:00Z
delivery attempts : 3
bounces : 0
complaints : 0
rejects : 0
----------------------

ユーザはこれを見て、bounces、complaints, rejectsを減らすことによって配信メールの品質を向上させていく必要があります。Amazon SESにはじかれたメールはAPI経由で、バウンスメールはReturn-Pathのメールから判断できるので、それらの内容をよく確認し、配信リストの修正、品質向上に取り組むといいと思います。


■ 配信割当量(Quota)情報の取得

サンドボックス環境だと固定の数値、プロダクション環境だと、送信したメール数、品質によって徐々にアップしていきます。取得できるAPIはGetSendQuotaで、以下のように使います。

# SESへの接続まではGetSendStatisticsのサンプルと同じです。
response = conn.get_send_quota()
result = response['GetSendQuotaResponse']['GetSendQuotaResult']

# 24時間以内に送信できるメール数
print 'max 24 hour send : %s' % result['Max24HourSend']

# 24時間以内に送信したメール数
print 'sent last hour send : %s' % result['SentLast24Hours']

# 1秒間に送信できるメール数
print 'max send rate : %s' % result['MaxSendRate']

上記のサンプルの通り、24時間以内に送信できるメール数、実際に24時間以内に送信したメール数、それと1秒間に何通送信できるか、という割当情報が取得できます。GetSendStatistics APIで品質チェックをして、品質向上と配信数の向上に努めたら、徐々にこの割当がアップしていくようです。なんだか、レベル上げみたいですね。

 

■ まとめ

前回の記事に引き続き、今回はAmazon SESのAPIをbotoライブラリを使ってPythonでプログラミングする場合の使い方をまとめました。ただ送信するだけではなく、SESからフィードバックをもらい、より高品質なメール配信ができるようにしてもらいたい、というAWS側からの意思みたいなものを感じるAPIですね。

AWSはまだまだ使っていないプロダクトも多いので、今後もいろいろいじってみて実運用につなげていきたいと思います。

■ おまけ ~中途採用のお知らせ~

フレクトではAWSやSalesforceを使ったソリューション事業の拡大をしております。クラウド環境を使った開発に興味がある人はぜひご連絡いただければと思います。以下、採用ページです。

http://www.flect.co.jp/recruit/index.html

採用情報

株式会社フレクトでは、事業拡大のため、
・Salesforce/Force.comのアプリケーション開発
・HerokuやAWSなどのクラウドプラットフォーム上での
Webアプリケーション開発
をする、エンジニアを募集中です。

未経験でも、これからクラウドをやってみたい方、
是非ご応募下さい。

フレクト採用ページへ

プロフィール

執筆者:大橋 正興
株式会社フレクト 取締役

【得意分野/業務分野】

B2Cのサイト開発を主な業務領域とするシステムエンジニアです。あと、Salesforce.com認定デベロッパーです。AW、Salesforce、システム基盤構築・運用、サーバ/インフラ構築・運用が今の注力分野です。

【簡単な経歴】

埼玉県所沢市出身。1979年生まれ。大学からSFC。修士(政策・メディア)。ソニーエリクソンで携帯電話のアプリ・ミドル の先行開発に従事したあと、フレクトに参加。2009年6月より取締役。ベターホームレシピの開発ディレクション等、B2Cサイト構築においてアプリ開発やインフラ構築などに従事中。

会社紹介

株式会社フレクトは、
認定コンサルタント
認定上級デベロッパー
認定デベロッパー
が在籍している、セールスフォースパートナーです。
セールスフォースパートナー
また、heroku partnersにも登録されています。
herokuパートナー
株式会社フレクトのSalesforce/Force.com
導入支援サービス
弊社の認定プロフェッショナルが支援致します。
・Visualforce/Apexによるアプリ開発
・Salesforceと連携するWebアプリ開発
も承っております。
セールスフォースご検討の際は、
お気軽にお問合せください。

Twitter

頻繁ではないですが、ときどきツイートしています。 お気軽にフォローしてください。

2021年1月

          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
ブログ powered by TypePad