#wedding-sに向けてTwilioでお祝いのメッセージを集めた

 #wedding-sは、@kei-s と @yuca の結婚パーティ。夏に二人と食事をしたときに「二次会とかやんないんすかー、人生で人呼びつけられるのそんなにないっすよ」ってくだ巻いたら結婚式翌週のパーティの幹事のようなものになっていた。僕も葬式くらいは灰になるときに人を呼びつけたい。

 幹事をワンマン不安になってすぐに @june29 と @darashi に泣きついて何をやるかとか話して、そこからいっぱい助けられて先週末無事に会が終了した。

 コンテンツとしては

  • 新婦の思っていること*1を書いたテストコード(Expectedが見えないRSpec)に全部グリーンになるまで新郎が実装を書く新郎新婦初めてのTDDによるペアプログラミング

というのを一番やりたかったけれど、成功のイメージが一切思い描けなくてちゃんと没にした。

 ちょうどその頃WebPayのサポート周りの改善で、「電話での問い合わせ」を録音してスタッフ全員で共有していて、メールで投げつつ電話してきたり、電話したけど後でメールしますねみたいなユーザが結構居て、僕たちとユーザの間で無駄なやり取りが発生してユーザに余計な迷惑をかけるのを防ぐような対策をしていて、その電話の録音や通知の仕組みのところに @keikubo がTwilioを使っていたというのが着想で、Twilioを使って、結婚した二人へのお祝いのメッセージを電話で集めることにした。

wedding-s-messenger

 Twilioは電話がかかってくると指定したURLにXMLを見にきてくれて、Twimlで定義されているフォーマットでレスポンスすると言う事を聞いてくれる。

 シーケンス制御を組み立てる感じで分岐を作って

  • (1) 電話を受け付けてウェルカムなメッセージを流す
  • (2) メッセージ入力方法の説明を流す(終わったら#押してねみたいな)
  • (3) 発信音を鳴らして録音を実施する(#で終了する)
  • (4) 録音したメッセージを流すよと宣言して流す
  • (5) このメッセージで良かったら"1"を押せ、もう一度録るなら"3"を押せと促しつつ入力を待つ
  • (6) 入力された数字が、"1"なら(7)へ、"3"なら(2)へ、それ以外なら(5)へリダイレクト
  • (7) お礼を流して電話を切る

 Twilioがtwimlを見に来てくれるときは、GET/POSTでよしなにパラメータ付きでやってくるので、やってくる先をSinatraによるウェブアプリにしておいて、やってくるメッセージの情報をよしなにデータベースに保存するようにした。この仕組みを会の名称に合わせてwedding-s-messengerと名付けた。

上のシーケンスまわりのソースは概ねこんな感じ

そして、アプリ側では管理画面を作っておいて、メッセージの削除とかダウンロードとかを行えるようにしておいた。

 ちなみに、これの電話番号は結婚式やインターネットで新郎新婦に分からないように撒いておいて、新郎新婦の電話番号から万が一かかってきたら別ルートに分岐するという対策もとっていた。

 一番大事だったのは受話器に流すメッセージで、テスト用には僕が自分で喋った声を入れて流していたのだけれど、ちゃんと喋る力を持った @mamipeko の声に差し替えた途端に栄えたし、これは本当に価値があるのかと不安なプロダクトに対して自信を持てて、コードよりも価値があった。Retinaディスプレイかと思った。
 特に自分の声だと、なんだろ、ホテルのユニットバス系のトイレで用を足してて自分の股間が鏡越しに見えるような虚しさに近かった。

 僕のブログでその声を聞けるというのはどうしようものかと思っていたらご本人が公開してくれたので良かった。MacbookPro 13 inch Retinaも薄く軽くなったことだし。


 新郎新婦の日頃の行いもあって(メッセージを入れることを快く引き受けてくださった皆さんありがとうございました)、200件近い録音が行われたけどこれで負担額は$5そこそこ(もちろんかける側も電話代を負担しているが)
当日集まったメッセージの「けいさん」「ゆかさん」「おめでとう」を切り抜きまくって重ねまくった音声を流しつつ、刻印を入れたiPod Shuffle(シルバーだと結婚感ある)に全ての音声を入れてお渡しできた。

 @darashi が「これはもう祝電2.0ですよ〜」と事前準備で会った時か僕の夢かで言っていたのがとても印象的だった。

 この仕組みで、少なくとも幸せになれるユーザが世に居るのが分かるので、いい感じにASPとかにしたりするのはどうだろう。今回はサプライズなやつだったけど、電報感覚でまー会場に届いてますっていうのに声が追加されるのは素敵なことだと思う。もうあるのか結婚したことがないからよくわからない。

あまり関係ないけどgit-subtreeが便利

にもあるように本会の準備の進行に主婦と一緒にGithubを使っていたのだけど、このwedding-s-messengerがリポジトリの中に/messenger というディレクトリをルートとするアプリとしてpushしていて、これではHerokuにデプロイするのが不便なのではという時にgit-subtreeが最適だった。

git subtree push --prefix messenger heroku master
で、messengerディレクトリがルートなアプリをHerokuにデプロイできる。

 あと、HerokuだとRack appがお休みなさるので、ずっと監視用のリクエストを叩き続けていた。

*1:ありそうなのは子どもが何人だとか

ユーザから代価を得ることをお手伝いしています。

 昨秋よりWebPayに関わっている。
 クラウド系かなーとfluxflexに行った初日に「決済に本腰入れ始める」と聞いた時に呆然としたところから、予想したよりも続いているし予想したよりも面白いものを見つけたと思えるようになっている。

 最近の悩みはクレジットカードの更新時に再審査してもらったものの限度額が10万円だったこと。
 WebPayの検証用にもDiners Clubのカードが欲しいのだけれど、誰一人持てないのではないか。Dinersホルダーのエンジニアの入社が待たれる。

WEB+DB PRESS Vol.76 特集2 Web決済入門

 春先に「決済やってるんですよ」と@inaoさんに挨拶をしたところから、@keikubo, @sowawaと3人で寄稿させて頂くこととなった。

WEB+DB PRESS Vol.76

WEB+DB PRESS Vol.76

  • 作者: 五十嵐啓人,伊野亘輝,近藤宇智朗,渡邊恵太,須藤耕平,中島聡,A-Listers,はまちや2,川添貴生,片山育美,池田拓司,濱崎健吾,佐藤太一,曾川景介,久保渓,門脇恒平,登尾徳誠,伊藤直也,mala,後藤秀宣,若原祥正,奥野幹也,大林源,WEB+DB PRESS編集部
  • 出版社/メーカー: 技術評論社
  • 発売日: 2013/08/24
  • メディア: 大型本
  • この商品を含むブログを見る

■特集2
Web決済入門
PayPal、WebPay、iOS/Androidアプリ内決済の導入方法
本特集では、Webサービスやスマートフォンアプリで行う課金についての最新動向を解説します。初めて課金を導入しようと思ったとき、どのような課金手段があり、どれくらいの手数料がかかるのか、どのような事前審査があるのか、どのように実装すればよいのか、セキュリティはどうなっているのかなど、わからないことだらけです。本特集ではこれらの全体像を整理し、クレジットカード、iOS/Androidアプリ内課金、PayPalなどの主な課金方法についての実装ノウハウも解説します。

Amazon.co.jp: WEB+DB PRESS Vol.76: 五十嵐 啓人, 伊野 亘輝, 近藤 宇智朗, 渡邊 恵太, 須藤 耕平, 中島 聡, A-Listers, はまちや2, 川添 貴生, 片山 育美, 池田 拓司, 濱崎 健吾, 佐藤 太一, 曾川 景介, 久保 渓, 門脇 恒平, 登尾 徳誠, 伊藤 直也, mala, 後藤 秀宣, 若原 祥正, 奥野 幹也, 大林 源, WEB+DB PRESS編集部: 本

 日本で決済代行サービスをやっていると、カード会社や資金決済業など外からではよくわからなかった世界が少しずつ見えてきていて、今回の構成はサービス提供者として決済に関わる人には知っておいて欲しいというトピックを集めたものだ。WEBでもDBでもないだろみたいな話も多く含まれているのは正しかったのかどうか不安な限りだ。

 前号のペパボの特集の際のスケジュールを@hsbtさんが書かれていた(しかも、とても素晴らしい進行だった)のを見て脱稿までずっとヒヤヒヤしたり、あまりに見積もりが甘い上、伝えたいことを書き出したら止まらなくて、10ページ以上オーバーした文字数を削り切ったと旅先の札幌で@inaoさんに連絡したら、改ページ等諸々で「ほとんど減っていません」と返ってきて青ざめたりもしたものの何とか形となってひとまずは安心している。

 執筆に係っている約2ヶ月間で、WebPayの中もなかなか変化していて、特にWebPayのサブスクリプションに関する節を書いた直後あたりで、当該機能を削る時は気が動転して鼻水が止まらなくなったこともあった。

 以前クックパッドの特集(vol.66)の時(偶然にも今号の特集1もクックパッドだ)に、数ページ書かせてもらったのとは全く違い、執筆者側の取りまとめを僕がやって@inaoさんとやり取りしながら進めたけれど、@inaoさんの進行管理の巧さに感嘆するばかりだった。これを隔月で何件も同時に回している中でやってくださるのだから接待及び贈答品も送りたくなる。

 他の著者さんほど執筆環境を追求出来ていないが、Githubとmarkdownだけを僕たちは気にすれば良い状況にしてもらえたのが何よりも有り難かった。

よろしくお願いします

 有償のWebサービスをつくるときに、提供者は「自分たちのWebサービスの代価をユーザに求めるということがどういうことか」を考え続けることに集中できるよう、周辺のルールや技術的なこと、何となく中身が不安な仕組み(今回はクレジットカードだけだけれど)を知っておくために本特集へ目を通してもらえたらとても嬉しい。

 「だである」調で書くとやたら偉そうになるのが辛い。(本特集は「ですます」調です)

プロジェクタ用のパソコンを準備したくない

Kaigi Signage1

 RubyKaigi2013のアクシデンタルスタッフ*1をした。2010,2011と当日スタッフをやらせてもらっていたけど今年は色々逸していて、前日までは普通の参加者のつもりだった。スクリーンのコンテンツ表示や自動起動などをするAndroidアプリを今回のスクリーン群の管理システムに合わせてつくって、前日に設営に会場に行ったが為にスタッフの仲間に入れてもらえて、気づけばスクリーン達の面倒をみながら見たい発表や、RubyKaigiならではの再会を楽しむことになった。

 ホワイエの3台とホールAの前、会議室1の左側のスクリーンの計5つは全てAndroidで動かしていたことに来場者たちは気づいただろうか。

RubyKaigiのスクリーン達

 だんだん当たり前の風景のようになってしまっているが、RubyKaigiの会場各所でTwitterIRC、運営からのお知らせ、良い弁当などの情報が来場者達に向けて輝いている。そのスクリーン群もRubyKaigiとKaigi Freaksと一緒に成長を遂げていて、今年も進歩をしながら実用に耐えた様子だった。

Androidをプロジェクタ用端末として使う

 今回、スクリーンの一部に、スティック型の、テレビに直接HDMIで繋げて使うようなAndroid端末を使用した。

 @darashiのスティックと僕のスティックそれぞれで買っていたものを持ち寄っていたので金額は様々だが平均すると1台5000円そこそこでリースの端末よりも取り回しがよく、電力を食べず、予期せぬ外乱が少ないので、ブラウザで得られる情報のみを表示するのならば、こういったイベントのサブスクリーンに使うには最適だった。誰々のスティックと呼ぶと何だか卑猥に聞こえるので慣用していたが、いまづ先輩には全部スルーされた。

 「起動したらすぐに動いて欲しい」など、ただブラウザをフルスクリーンで表示するだけでは足りないニーズをAndroidアプリケーションで補うのが僕の今回のお手伝いとなった。お得意のWebViewベースハイブリットアプリだ。

 結果としてリースで会場用に借りていたWindows端末の使用は7台に押え込めて、設営や撤収などの諸々のコストを下げられたのはとても良い成果だった。

 加えて、リコーさんの超単焦点モデルのプロジェクタが無ければホワイエの格好良いスクリーン群が叶わなかったことを付記しておきたい。

 Androidアプリの細かいことだったりは、@darashiと@june29が綴るデジタルサイネージの管理システムの話と一緒でまたどこかで書いたり喋ったり出来るのだと思っているので会期終了後の高揚感のメモとして。RubyKaigiに限らず、二人がたのしく何かを開発しているのを割と近いところで知っていて、その中に少しでも入り込めてものをつくれたのはとてもとても良かった。

 @makimotoさんが今回のLTで紹介していたGlitch Rubyistokeiを表示していたのだが、スクリーンが壊れているよと来場者に知らされ、僭越ながらGlitchの説明をさせて頂きますということが何度かあったがGlitchのことをあまり僕はよくわかっていない。
Kaigi Signage2

サンコー Android Stick 4 SmartTV ANDHDM40

サンコー Android Stick 4 SmartTV ANDHDM40

 これとは別にRubyistokeiを電源接続時などのDayDreamで楽しめるAndroidアプリをスピンアウト的につくったが、Rubyistokeiのアイコンが決まり次第(!)公開したい。

*1:© @kakutani

お参りに行った。

Metal Android at Googleplex

 Googleの本社を訪問した。気持ちの良い日光の元で食事や散歩をした。室内に入ったのは食事をお盆に載せるのと、On site storeで買い物をする時だけだった。訪れるのはこれも4年ぶりで色々様子は変わっていたようだが、ストアの位置が変わったことくらいしか感知出来なかった。

 Androidの次期バージョンに合わせてオブジェが追加されたとよく報じられるGoogle Building 44の前に訪れるのは念願といえば大袈裟だけれど、行っておきたい場所だった。というのも、ここ2年近くはAndroidのおかげでご飯を食べたり、人と関われていたりする部分が僕には少なからずあって、頭の隅にいる背徳心みたいなモヤっとしたものを扱いきれずに居た。44棟の前まで行って、同行者達に対して恥ずかしくて声には出せなかったけど感謝の気持ちを念じた。

 こういう感覚には一貫性がなくて、もしAndroidにこういう気持ちを持つのなら、僕は山ほどのOSSにもっと感情やコミットを持ち合わせないといけないと思って気が滅入って来た。ただ、それとはどう違うかは少しわかっていて、好きなアーティストが地元で公演するから行くのに近い。帰りにTシャツ買っちゃう感じ。

 写真のオブジェについては帰ってからウェブで報じられていてびっくりした。ほやほやらしい。

芝生が好きです。


Stanford Oval by Kengo Hamasaki on 500px.com

 前の記事でちらりと書いたけれど、11月の末からカリフォルニア州ベルモントという都市*1で暮らしている。日本で個人的に受託した仕事に手に取り組みつつ、時間が許す限りはこちらで過ごすつもりでいる。所謂シリコンバレーと呼ばれるようなところにあたる場所に来るのは、22歳のシリコンバレー訪問記 - 目次---22歳のシリコンバレー訪問記:ITproから4年近くが過ぎていて思うことは大幅に変わってしまったけれど、スタンフォードの芝生でまたごろごろ出来て良かった。

 何故シリコンバレーに行きたいの?という言葉に対して、正当化するのを第一に理由を作ったり、尋ねられた時に納得してもらうのを念頭に自信を持って答えられる情報を準備する必要はなくて、あそこのお店のチャーハンが美味しいしジャンプもマガジンもあるからあそこによく入り浸っているんだというのに似た選択だったんじゃないかなあと1ヶ月と少しを過ごして思うようになった。

 その答えも簡単に曲がったりしそうなので、逐次感じ取ったことを書くようにしている

*1:都市というには閑静すぎる田舎町だけれど