まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

2014年04月

・・です。

IBM 開発コンテスト「IBM BlueMix Challenge」開催


詳細は5月21日~22日開催の「IBM Software XCITE Spring 2014」で発表されるらしいので、詳しい条件や規定、基準、そして気になる賞品(笑)については後日発表を待ちましょう。

まあ、でも、BlueMix のサーバーやサービスを使って面白いアプリを作りましょう、というものだとは思います。このブログでも紹介しているように、色んなプログラミング言語を選べるし、サーバー構築は簡単だし、敷居はそんなに高くないと思ってます。また以前に CloudFoundry 環境で作ったアプリがあれば、それを持ってきちゃえば動くかも(苦笑)しれないので、そういう手もあるのかな。

先日紹介した「Twilio を BlueMix で使う」の中で説明した実際に電話をかけるウェブアプリケーション、文章による説明文だけだと再現はちょっと難しいと思ったので、ダウンロード可能なサンプルを作ってみました:
Twilio サンプルアプリの Java プロジェクト

ダウンロードファイル名は twilio.zip です。


使うための前提として、事前に以下の準備が必要です:
(1) BlueMix のアカウント取得(参照)
(2) Twilio のアカウント取得(参照)
(3) Twilio の電話番号、SID、認証トークンの取得(参照)
(4) BlueMix 上に Twilio サービスを起動して、(3) で取得した SID と 認証トークンを設定しておく(参照)
(5) BlueMix 上で Liberty for JAVA アプリケーションサーバーを起動し、(4) で起動した Twilio サービスに紐付けておく(参照)

(6) cf が使える状態になっている(参照)


今から BlueMix を使いはじめる場合は準備項目が多くて大変かもしれませんが、ある程度 BlueMix を使いこなすためには cf ツールの環境設定は必須になると思うのでがんばってください。

ここまでできていれば、あとは上記のサンプルを少し改良するだけで試せるようになります。以下その説明です。

まずダウンロードした twilio.zip を cf が使えるシステム上で解凍・展開します。仮に展開先フォルダ名が c:\tmp だったとすると c:\tmp\twilio\ というサブフォルダ上にプロジェクトが展開されます。以下この前提で説明を続けます。

テキストエディタで c:\tmp\twilio\index.jsp を開いてください。なお、この中で (5) で紐付けられた Twilio サーバーから SID や認証トークンを取り出す作業もしているため、これらのプライバシー情報を Java のコーディング内に記述する必要はありません。

最後の方に以下のような3行がある箇所を見つけてください。この3行がカスタマイズ対象箇所です(余程のことがない限り、他は変更しないでください):
  :
params.put( "To", "+8180XXXXYYYY" ); //. 通話先電話番号
params.put( "From", "+8150AAAABBBB" ); //. 発信元電話番号
params.put( "Url", messageurl ); //. TwiMLのURL
  :

この中の一番上の通話先電話番号というコメントが書かれた箇所に電話をかける先の番号を指定します。注意点として日本の国際番号である +81 から始めて、局番の最初の0を取り除いて指定することです。例えば日本国内で使う時の電話番号が 080-1234-5678 だった場合、ここでは +818012345678 と指定します。自分が出ることのできる電話番号(携帯電話とか)に書き換えてください。

2番目は発信元電話番号を指定します。これは上記 (3) で取得した Twilio 電話番号のことで、おそらく 050 で始まる番号になっているはずです。これも同様のルールで、仮に 050-9876-5432 だったとしたら +815098765432 と書き換えてください。

3番目の TwiML の URL ですが、これは展開したプロジェクト内の同じフォルダにある message.xml というファイルを指すようにしています。ちなみに message.xml の内容はこんな感じにしています:
<?xml version="1.0" encoding="UTF-8"?>
<Response>
  <Say language="ja-JP" voice="alice">屋根より高いこいのぼり</Say>
  <Pause length="1"/>
  <Say language="ja-JP" voice="alice">大きいまごいはお父さん</Say>
  <Pause length="1"/>
  <Say language="ja-JP" voice="alice">小さいひごいは子供たち</Say>
  <Pause length="1"/>
  <Say language="ja-JP" voice="alice">面白そうに泳いでる</Say>
</Response>
これが Twilio に喋らせる内容になります。日本語の文章になっているのが、なんとなくわかりますかね。<Say>~</Say> 内がしゃべる内容です。経験上、簡単な漢字なら問題なさそうです。<Pause> 節は何もしない時間で1秒ずつ間をあけています。もちろんこのまま変更なしでも使えますし、異なる内容を喋らせたい場合は 必要に応じて message.xml の内容を書き換えてください。もし別の(外部の) TwiML を使いたい場合は messageurl の代わりにその URL をここで直接指定しても構いません。

上記例で書き換えた後の index.jsp はこんな感じになります:
  :
params.put( "To", "+818012345678" ); //. 通話先電話番号
params.put( "From", "+815098765432" ); //. 発信元電話番号
params.put( "Url", messageurl ); //. TwiML(message.xml)のURL
  :

この状態にカスタマイズできたら cf ツールを使って BlueMix のアプリケーションサーバーにデプロイします。コマンドラインプロンプトで c:\tmp\twilio(index.jsp があるフォルダ)に移り、以下のコマンドを実行します(Liberty for JAVA のアプリケーション名が APP1 である場合の例です。各自の環境に合わせてください):
> cf push APP1

これでカスタマイズした Twilio サンプルアプリがデプロイされました。デプロイ後はブラウザでこの Liberty for JAVA のアプリケーションサーバーにアクセスすると index.jsp が実行され、指定された番号に電話がかかってきて、着信すると message.xml に指定された内容を女性の声で話してくれます(Twilio アカウントがトライアルの場合は、最初にその旨のメッセージも流れます)。

一応、message.xml を書き換えるだけで話す内容をカスタマイズできるし、電話番号を変更するだけで各自の環境用のサーバーを作れるようにしたつもりです。 これが BlueMix と Twilio の連携サービス構築の参考になれば。


※このサンプルを用意する過程で知った余談ですが、童謡「こいのぼり」の著作権はちょっと複雑な背景があるんですね・・・
Wikipedia - こいのぼり


 

突然始まった身に覚えのない Google Wallet への不正請求事件への対処を開始してから約半年、やっと、やっとこのエントリを書く時がやってきました。
過去の経緯はこちらを参照ください:     


先日、某クレジットサービス会社から1通の手紙が届きました:
gw99

「勝訴!」 d(ToT)

とまでは言わないけど、見に覚えないんだからそりゃそうだ。
当時よりは円安なんだから利子だけでなく為替差分も付けて返してほしい所だが・・・
2014041901
 ↑為替差分も利子もついてないし・・・



ではハッキリした以上言わせてもらおう。

まずこの件の直接の原因について、グーグルからは「原因はいろいろ考えられる」という返答しかもらっていないけど、他の多くの事例報告からもグーグルアカウントが流出したことしか考えられない。自分自身もグーグルアカウントの取り扱いを見直すきっかけになったし、お金の絡むサービスなんだからしっかり管理してほしい。 ただグーグルウォレットチームとのやりとりやこの件での素早くて真摯なサポートは本当に助かりました。敢えてお願いすることがあるとしたら、同様のサポートを日本でも(というか日本語でも)提供してほしいです。僕のブログのアクセスログを見る限りでも、同様の事件で困っている人は多そうなのです。今回の対応も僕が英語で直談判しなかったら何も解決しなかったと思ってます。

次に名前をぶちまけてやりたいくらいの某クレジットサービス社。何度も「子供のイタズラ」を疑ったり(独身子無しだと何度言えば・・)、「GMailアカウントを変えろ」とかムチャなことを言ってきたり、今回の対応も「やりたくない」感アリアリで、いちいち遅かった。こういうもんなの?

最後に某大手カード会社。上記サービス会社によると「ここが『カードを新規に作り直さない限りは対応しない』と言ってきた」そうだ。詳しくは過去のエントリに書いたけど、今回の件はグーグル側に原因がある(と思う)ので、カードを作り直しても、グーグルに登録し直したらすぐに再発する可能性が高い問題だ。当然番号も変わるのであちこち登録し直さないといけない。セキュアでも何でもなく単に不便なだけなんだけど、それでもカードを新規登録させる意味が分からない。

今回の件は極端な話、生活に支障がでるような請求額ではなかった。でも対応しているうちに額の問題ではなくなって、「何がなんでも自分の主張を通さないと気が済まない」本気モードになった。熱くさせてくれた上で最後にはこちらの主張を認めてくれた、という点で後者2社には感謝してます。 :P






 

とある人からBlueMix で開発すると何かいいことあるの?」と聞かれたので、その答をこのブログエントリに書いておきます。 まあ答は BlueMix というよりも、CloudFoundry 全般に言える内容なんでしょうけど。

この質問者の意図は「オンプレミス環境や IaaS 環境でアプリ開発した場合と比較して、BlueMix だとどれだけ楽に作れるの?」ということだったようです。Java アプリ開発に特化した内容はないのですが、BlueMix に興味を持っている層の人は Java が比較的多いのかな、と思ったので、一応 Java 開発者向けの前提で書いてみます。


で、僕の答はシンプルで「特別変わらない。そしてそれが素晴らしい」です。

「変わらないことが素晴らしい」とは、少し分かりにくいかもしれません。多少くどい話になってしまいますが、これは BlueMix ではない他の PaaS と IaaS 間の移植を考えたケースと比較すると分かりやすいかもしれません。

例えば Google App Engine  というグーグルの PaaS 環境があります。言語としては Java / Python / Go が使えて、データストアも KVS 型と SQL 型が選べて、メッセージング機能が含まれていたりする上に、負荷に合わせて勝手にスケールアウトしてくれます。しかもある制約の範囲内で利用する限りは無料! というなかなか魅力的な環境です(個人的にも使ってます)。

ただ大きな悩みが1つ。他の環境とのポータビリティがほとんどないのでした。App Engine というパブリックな PaaS 環境内で使う前提であればこれは問題にならないのですが、(一部でも)自社サーバー環境で構築し直したいとか、サーバーはどこぞのクラウドのを使いたいとか、そういった要件にそのまま対応ができないのでした。言語として Java が使えると書きましたが、一般的な意味での Java アプリケーションとは少々違うもの(というか、App Engine 専用の Java アプリケーション)なのです。

で、「とはいえ同じ Java で作ったウェブアプリケーションなんだから、移植すればいいのでは?」という発想にたどり着きますが、これがまたややこしい話というか・・・ 確かに同じ言語を使ってはいますが、アプリケーションとして全然違うもの(Eclipse レベルの話をすると、最初に新規作成するプロジェクトからして別モノ)です。AppEngine 環境では専用の Base64 エンコーダー/デコーダーなど色々便利なライブラリが付属してはいるのは事実なんですが、それらを使ってしまうと移植時には全く別の手段を探すことになってしまうのでした。なお同じことが一般的な Java アプリケーションを App Engine 向けに(逆向きに)移植する場合でも同じことが言えます。

僕自身は過去に2度、App Engine プロジェクトを一般的な Java アプリケーションプロジェクトに移植した経験があります。(制約面では厳しい環境から緩い環境になるので)たしかに出来ないことではないし、同じ言語なので一部コピペが使えるのも事実ではあるのですが、やはりどうしても移植しきれなくて、一部機能だけは App Engine に残して併用する、という運用を今も続けていたりします。

これは App Engine が悪いというわけではなく、それだけ便利な環境を提供してくれていることの裏返しでもあるのですが、その便利さに頼ってしまうと後戻りができなくなってしまう、ということだと思っています。いわゆる「ベンダーロックイン」です。ないとは思っていますが、もしも Google が App Engine というサービスを止めてしまった場合、もうこのサービスは諦めるか、腹をくくって同じ機能をゼロから作り直す必要があると思っています。

同じことはセールスフォースの force.com プラットフォームにも言えます。一応 Java ライクな言語でアプリ開発ができる、ということになっていますが、これはセールスフォース独自の APEX という、ちょっと違う言語を使うことになります。実際に移植経験があるわけではないのですが、移植性とかの話になるとかなり厳しいのではないかな、と思っています。

そしてこれは App Engine や force.com に限ったことではなく、PaaS という OS やミドルウェアの概念を意識させないような便利なプラットフォームサービスを利用する以上は避けて通るのが難しいものだと思っていました。現に IaaS や SaaS などと比べて、その中間に位置する PaaS についてはどのベンダーも苦戦気味ですが、それはこういった「資産を移植しにくい」という背景も関係しているのだと思っています。


・・・なんか長くなってしまいました。話を冒頭に戻します。

私自身が BlueMix を使って感じた特徴の1つ、それは「オンプレミス環境や IaaS 環境とのポータビリティ」だと感じてます。オンプレミス用に作成したり、現にいま Amazon EC2 環境で動いている Java アプリケーションが、ほぼ変更なしにそのまま BlueMix で動かすことができる、ということです。もちろん例外的なケースもあるとは思いますが、一般的なウェブアプリケーションであれば、バイナリの WAR ファイルをほぼそのまま(ケース次第では1バイトも変更せずに) BlueMix / 各種 IaaS / オンプレミス環境全てにデプロイ出来る、ということも可能になります。

特に Java アプリケーションの(オンプレミスや IaaS 用の)資産が手元にある場合、BlueMix では WebSphere Application Server をベースとした(と思われる)"Liberty for JAVA" という Java アプリケーションサーバー環境を標準提供しています。この辺りは IBM の得意分野でもあるのでしょうが、我々開発者や開発ベンダーが持っている Java アプリケーション資産を動かすための準備は既に提供されていることになります。

冒頭で「(BlueMix は他の環境と比べて)特別変わらない、それが素晴らしい」と書いたのはまさにこのことです。オンプレミス/IaaS を選ぶお客様もいれば PaaS 環境を選択するお客様もいます。開発者はその2つの環境用に異なるアプリケーションモジュールを準備しておく必要があります。でもその PaaS が BlueMix や CloudFoundry であれば、その適応のための変更という作業はほぼ不要になります。もしかしたらそのまま動いてしまうかもしれません。これがメリットでなくて何?ということを言いたかったのでした。


そしてもう1つの特徴、それは「オープン」であることです。BlueMix はオープンソースの CloudFoundry V2 をベースに作られています。そのため万が一 IBM が BlueMix サービスを打ち切ることがあっても、PaaS 環境としての CloudFoundry に移して運用を続けることもできますし、自社に CloudFoundry 環境を構築してオンプレミスな PaaS 環境(?)の上で運用を続けるという選択肢もあります。更に CloudFoundry の活発なコミュニティの中で開発・提供されている便利なツールや資料など、コミュニティのパワーを借りることができることもオープン環境の強みだと思っています。

アプリケーションを開発する立場では複数環境用の移植メンテナンスがほぼ不要で、シングルソースのまま各種環境向けの提供できるようになります。 また運用する側も CloudFoundry コミュニティから提供される各種情報を便りに、場合によってはコスト比較をしながら運用環境や体制を変えていくこともできるようになります。少し前の PaaS では考えにくかったこんなことが今はできるようになっているのでした。

もちろんこれだけではないのですが、こういったオープン性を背景にしたことによる BlueMix のアドバンテージは計り知れないと感じています。繰り返しになりますが、オンプレ/IaaS 用に開発された Java アプリケーションの WAR ファイルがもしかしたらそのまま、そうでなくても最小限の変更で PaaS 上で動くかもしれない、というのはやはり魅力的です。今は本家 CloudFoundry も有償版しかないので、無料で CloudFoundry が試せる環境という意味でも BlueMix はなかなかおいしくて気にいってます。CloudFoundry や PaaS に興味を持っているアプリ開発者の方は、BlueMix という名の CloudFoundry を試してみて、手元のアプリがどれだけ動くのか、動作確認だけでも早めにやっておくといいかもしれません。今なら無料なので(笑)。





 

こんなニュースがありました:
グーグルが「Gmail」の利用規約を更新 - メール内容の解析を明示

グーグルは Gmail に書かれた内容を読んでいる、ということ。
その是非が色々言われているようですが、その件についてコメントは控えます。

僕は知ってました。というか、そういうものだと思ってました。
普段から自分でいくつかのウェブサービスを遊びで開発して公開したりしてます。
ある時、まだ誰にも話してないし、リンクも作っていない作りたてのウェブサイトのURLを Gmail で知り合いに送った所、その数日後から Google のクローラーボットがやってくるようになりました(苦笑)。本当にこのメールがきっかけだったのかどうかは分からないのですが、原因がメール内容しか思い当たらなかったので、以来そういうものだと思っていました。

で、それを逆手にとったというわけではないですが、裏ワザを1つ紹介します。

これから公開しようとしているウェブサービスを開発したら、公開前にわざと GMail にその URL を書いて誰かに(例えば自分の別のアドレスに)送ります。それでグーグルはその新サービスの URL を知ることになるので、数日中にクローラーボットが送り込まれて、グーグルの検索エンジンにインデックスしてくれます。

これで、サービスがスタートする際には既にサービス内の大半のページがグーグル検索結果に表示される状態を作っておくことができます。厳密には、サービススタート前に(キーワード次第では)検索結果に表示されるのはともかく、実際に訪問されては困る、ということもあると思います。そういう場合は UserAgent を見て、グーグルボットの場合だけは訪問を許し、それ以外の場合はエラーにする、という処理を加えておいて、サービス開始直前に無効にする、といった対策で訪問を回避することもできます。


と、まあグーグルが勝手にメールを解析してくれるのであれば、それを勝手に有効活用させてもらいましょう、という方法でした。


 

このページのトップヘ