#wedding-s は、 kei さんと yuca さんの結婚パーティのこと。2013年10月19日に六本木農園で開催された。コードネームは october19

今回、幹事チームのひとりとして、パーティの開催をお手伝いさせてもらいました。 パーティについては 他のメンバーのエントリ をみてもらうのがよさそう!

チームのはなし

まず kei さん、 yuca さん。何よりお二人がこれまで過ごしてきた日々のおかげでステキな場だったのだと思うし、それをすっと包む素晴らしい会場を手配してくれて、それから多分とても忙しい時期だったと思うけれどいつも質問とか確認に光の速さで対応してくれてありがとう!

そして幹事チーム。 @hmsk は言い出しっぺ係から会場とのやり取りに始まり wedding-s-messenger を開発して白手袋で iPod shuffle に焼きこんで渡すところまで、 @june29 はチームづくりからプロジェクトの進行と調整、そして司会業をまるっと、 @mamipeko さんは wedding-s-messenger のステキなガイド音声と、デザイン (紙を選びから印刷まで!) に受付をまるっと、 @tomoko_and さんも受付の段取りを中心に随所で細やかな気遣いをしてくださり。 他にもみんなで色々。

各自の役割と得意なところを押さえながら、全体としてもちゃんと進んでいくような、心強いチームでした。

自分は、というと「issue おじさん」などと呼ばれつつ、プロジェクトの GitHub issues を整理してました。当日に向けてサブスクリーンを用意したり、諸々の機材の手配して、あとは LT を。

LT のはなし

「LT のある結婚パーティ」とのことだったので、新郎新婦のお二人に「新婦の基調講演LT、新郎の結びのLT、公募LTと、新郎新婦それぞれひとりずつ招待LTでどうでしょう」みたいな提案をしていたところ、新郎に自分をそのひとりに選んでもらってしまって大変光栄ながら自演乙...という感じになりつつ、これはビシっとしないと〜と緊張感を高めておりました。

余白が狭すぎるはなし

結局、 JDK CHRONICLE のタイトルで、 @june29@darashi@kei_s の 3 人 (JDK) を中心に、仲間を巻き込みながらこれまでワーワーやってきた軌跡を、作品群を通して紹介する、という話をすることにしました。

「keiさんのいい話」とか「一緒につくった人とのエピソード」とか「なんでこの作品なの」とか「どういう想いでつくったの」とか「この作品があったからこの作品ができた」というような驚くべき話が沢山あったのだけれど、それを語るにはライトニングトークは短すぎる。ということで、出来上がった作品の話を中心に展開することにしました (裏側の "いい話" は発表資料を眺めて想像してもらったり、どこかでのんびりだらだらとお話できるといいなあ)。

驚き最大の方策

というわけで、JDK の歴史から始めて、今回幹事チームが用意した作品たちの話につなぎ、wedding-s-messenger で皆様からお預かりしたメッセージをサプライズでプレゼントする、という流れにすると綺麗なのでは、ということになりました。そこで、パーティの進行のほうも、自分のLTを新郎結びLTの直前にしてもらい、その場でプレゼントするという運びとなりました。

自分のLTでは新郎にドラを叩いてもらう段取りになっていたので、5分ぴったりでサプライズの直前(チラ見せ)まで来てドラ、そのあとプレゼントとなるようにしたいと思い、発表者メモに数ページ毎に予定通過時間をメモし、ひたすら練習して挑みました (でもちょっと時間が余っちゃった)。

楽しんでもらえてたらうれしいです。

御礼とご報告

ということで、寄せられたメッセージを iPod shuffle に焼きこみ、無事お二人にお届けできました。ご協力いただいたみなさん、ありがとうございました!

お芋おいしいです

自分は発表前はとても緊張するほうで、正直なところ緊張のあまりパーティのお料理を味わう心の余裕がなかったのですが、それでもお芋が美味かったのが特に記憶に残っているので、あのお芋は相当に美味しかったとおもいます。

おめでとう、ありがとう

おめでとうございます。お二人には夫婦ともども仲良くしてもらえて、とても、うれしいです。

そして、今回、心おきなく技術で遊びながら、ものづくりをしながら、みんなでお二人をお祝いできる機会をいただけたことに、心から感謝します。ありがとう!

どうかお幸せに!

関連エントリ

2013年の2月に一週間ほどシンガポールに行ってきたのでした。 写真は flickr に。 これから RedDotRubyConf などで訪れる方も多そうなので旅の tips 的なものを残しておきます。思い出話は直接きいてね。

無限インターネット関係

イモトのWiFI

イモトのWiFiでお馴染み(?)グローバルデータのMiFiを持って行った。色々使いづらい点もあったけれど、値段分の価値はあった。

WiFiスポット

電源

予約とか

あんまり良さげなパックを見つけられなかったので、宿と飛行機を別にとった。

お金とか

タクシーとか

ガイドブック

EZ-Link カード

食べ物とか

活動時に携行するとよいもの

はじめに

ソ〜シャルコ〜ディング全盛の現代において、地獄のミサワの女に惚れさす名言集 からシチュエーションに応じて適切な画像を素早く貼り付けることのできるエンジニアは常に一目置かれる存在です。

horesa.se は「貼りたい」と思った瞬間から貼り付けが完了するまでの時間を最小化することで、あなたの惚れさせソーシャルコーディングライフを強力にサポートします。

まずは触ってみてください: horesa.se

チーム

今回は

の布陣でつくりました。 PS3 で大森、蒲田、札幌を結んで、相変わらずの楽しい開発でした。

恒例の記念撮影:

裏側の話

ソースコードが darashi/horesa.se にありますので、ご覧ください。

フロントエンド

Ember.js

Ember.js を使いました。

レイテンシを抑えるため、最初にデータをまとめて読み込んでクライアント側だけで検索する実装にしました。

horesa.seEmber.js で書かれた小さく、かつ実用的な(toy example ではない)サービスなので、動くサンプルとしてもお楽しみいただけるかもしれません (パッチお待ちしています)。

Ember.js それ自体はとてもおもしろいフレームワークで、わかってくると楽しく触れるのですが、外界との接続、たとえば Social widgets との相性がよくなかったり、jQuery の animation との相性がよくなかったり、ZeroClipboard との連携が...などなど、色々と苦労はありました。

GitHub Pages

サーバサイドに動的な処理が不要なように作ったので、データ及びコードはすべて GitHub Pages に置いています。

ZeroClipboard

クリップボードにコピーする部分に ZeroClipboard を使ったのですが、色々と制約が多く、かなり苦労しました。ただ、これは ZeroClipboard のせいというより、そもそも Adobe Flash movie を使ってクリップボードにコピーさせるということ自体が素直ではないということに依りそうです。技術的な制約の下 ZeroClipboard はよくできていると思います。

バックエンド

惚れさせ男子データベース

データには 惚れさせ男子データベース を使っています (じつは horesa.se のバックエンドとして使うために開始されたプロジェクト)。

ソ〜シャルの力で本文データも拡充されつつあり、2012-10-07 21:30 現在では、全体の 32.3% の本文が入力されています。

データの更新

Rake タスク で fetch してきて、前処理をして、 horesa.se のリポジトリに入れることでデータを更新します。

歴史

背後にこんな流れを感じました。

バタフライ・エフェクトっぽくてとてもいい。ソ〜シャル!

まとめ

惚れさせソ〜シャルコ〜ディングを強力に支援する horesa.se を作りました。 Ember.js を使い、 GitHub Pages に deploy しています。

超高速な惚れさせ貼り付け体験を提供します。

惚れさせ男子データベース を使っています。データの拡充にご協力ください。ソ〜シャル。

プロダクトの背後に歴史あり。

お楽しみください。

(カチャカチャカチャ…) (ッターン!)

札幌Ruby会議2012 の会期が終わりました。

Kaigi に関わるすべてのみなさんに深く感謝します。

ありがとう。ありがとう。

Kaigi は始まり、そして終わる

今回色々とつらいことが多すぎて、始まる直前まで正直 Kaigi はもう懲り懲りだと思っていました。

それでも、参加者がぞろぞろやってくると自然と Kaigi は始まるし、みんな楽しそうにしてるし、相変わらずよいものですねえ。

そして、終わる。ちゃんと、終わる。

膝に矢を受けてしまってな

そういう空気にやられて、またやっちゃうのかもしれません。でも少し冷静になったほうがいい。

「かー実行委員つれーわー、全然発表みられなくてつれーわー」というのも情けない話なのですが、穏やかな気持ちできちんと見られた発表が殆どなくて、よくなかった。 お話してみたいと思っていた人にも自分から声をかけられなくて。 当日スタッフのみなさんともあまりお話できなかった。 余裕が、なかったです。 折角の機会だったのに。 もっと RubyKaigi を楽しめたらよかった。

「こうなってほしい」と思っていることを、自分がきちんと実践できないのはよくない。

最後の最後にまた撤収も上手にできなくて、すっかりしょぼくれて打ち上げに向かいました。

あれから5年経った

でも。そこで、ちょっと、なんか、もう、そういうことがまるっとどうでも良くなるような出来事があったのでした。

当日スタッフとして参加していた @tanaka51 が、自分が 日本Ruby会議2007 で初めて当日スタッフとして参加したときに感じたようなことを、話してくれました。

当日スタッフとして参加できて、とても良かった。でもそれまでに実行委員が準備してきたから、自分がそういう体験をできたんだと思う、というような感じのこと。 勝手に自分の言葉として聞いてしまったので違っているかもしれないけれど・・・。と、いうのも・・・

僕が、日本Ruby会議2007の翌日、思い出深い秋葉原のアイカフェで書いたエントリ We are nice. - RubyKaigi2007 に当時の自分の言葉が残されています(なんと瑞々しい!)。

RubyKaigi2007 on Rails。実行委員の皆さんはもっとずっと前から着々と準備を進めてきていて、自分はそのレールの上で動かせてもらえたのだと思っています。この日に至るまでに自分には見えていなかった沢山の大変なことがあって、それを一つずつ解決してきていたのだろうなと。だからこそ美味しいところを味わわせてもらえたのだろうなと。本当に有り難いことです。そして、もし可能ならば何かそういう部分でも力になっていければと思いました。

5年かかりましたが、ちゃんと、一周できたみたいです。よかった。

改めて読むと、こんなことも書いてある。

東京はとっても刺激的。大好きな札幌でもこんな幸せな体験ができる日が来るといいなぁ。なんて思ったりもして。

ちゃんとできてたみたい。しかも札幌で。

救われたなあと思いました。

今回自分に至らない点が多くて、色々迷惑をかけてしまいました。

たくさん助けてもらいました。

ありがとう。ありがとう。

膝に矢を受けた感はあるので、もし次があるのなら、そして許されるなら、「矢面」から一歩後ろに下がって、またやりなおすのがいいかもなあと思いました。たとえば Things を Done にする人として。

宿題のはなし

今回、発表をしました。これは実は 日本Ruby会議2011 の打ち上げでもらった宿題でした。

中華を食べながら(美味しかった!) @takai さんと @adzuki34 さんにもらった宿題。 「@darashi が発表してるのをみたい」って言ってくれたのでした。

「自分に心から話したいことができたらその時にやります、それができるように日々を過ごしたい」というようなことを答えた気がします。だいぶ酔っ払ってたけど。

その後 LT とか短めの発表をする機会は何度かあったけど、30分の枠で話したのはそれ以来はじめてのこと。 だから、今回は自分にとって特別な機会でした。

「よかった」って言ってもらえて、うれしかったです。 僕の中のヒーロ達にも声をかけてもらえてうれしかったし、心強く感じました。 やってよかった。

今回のテーマについては、まだ先があるなあと感じていて、これからも折にふれて考えていきたいです。

あ、でも「カンファレンスの運営と発表を同時にやらない」という自分ルールを破ってしまったのはやっぱりよくなかったかも。 札幌Ruby会議02 のあとから気をつけていて、でもまたやってしまって、その想いを強くしました。

「気をまわすリソース」は自分が想像する以上に少なくて、あっという間に枯渇してしまうのでした。そうなるとろくな事がない。

We coded. We shipped.

@shyouhei さんが1日目のセッション開始前に Kaigi Subscreen に Github 絵文字が出ないか試していて、 :smile: が画面に表示されてしまったのでついカッとなってパッチを書きました。 パッチはできたのだけれど、2日目のセッション開始までにはレビューしてもらってデプロイまでする時間は取れなかったので、そのままリモートブランチで寝かせていました。

そうこうしているうちに @takai さんの LT でまた絵文字が出てきたみたいでいよいよ悔しくなって懇親会に向かうタクシーのなかで @june29 とペアデプロイしました。

ちょっとだけど、会期中にちゃんと We Code. できてよかった。

クックパッド社主催「第3回開発コンテスト24」にて「おやすみシャワー」をチームで開発し、2度目の特別賞を受賞しました

応募した作品については、以下のビデオをご覧ください:

あなたは一日の終わりを誰と過ごしますか。
ときには見知らぬ誰かと「おやすみ」の言葉を交わすのはどうでしょう。
「おやすみ」はあなたに降り注ぐ、流星のシャワーのように。
素晴らしい一日の終わりを分かちあう、最高のおやすみ体験をお届けします。

そして次は、あなたから。

@darashi から見たその軌跡を記録し、共有します。 もう少し掘り下げた "想い" のようなものは、少し時間を置いてうまく整理ができたらアウトプットしていきたいです。

他のメンバーの記録

他メンバーからの目線で書かれたエントリもあわせてごらんください!

去年のこと、今年のこと

去年のことは、特別賞の受賞が決まった直後に書いたエントリ 「できればいいのに」が現実になる場所: 1/2 Real-time Tab Sync の開発に混ぜてもらいました に(かなりテンションが高い感じで)まとめてあります。

去年のコンテストは「@kei_s がプロダクトの骨格をつくり上げたところに、途中から参加させてもらって、楽しくワイワイ開発した」というのが僕からの景色でした。

今回はそれとはちょっと違っていて、開始時には既に @kei_s@june29 の間で「今年も参加しよう」という合意がされている状態でした。

私たちについて

私たちのチーム Team OyasumiSupport#end_of_day は

の総勢4名でした。

@darashi@kei_s@june29 は 2007年に Ruby札幌 の勉強会で会ってからの仲です。一緒に同じチームでお仕事したり、悪ノリしたり、いくつかのカンファレンスを一緒に運営したり、いくつかの作品を一緒に作ったりする間柄です。当初開発は3人で進めていたのですが、途中から @ZoAmichi が画を作るのに協力してくれるということになり、急遽 join してくれました。素敵アートワークをありがとう!

@darashiは札幌に住んでいて、@kei_sは大森、@june29@ZoAmichiは蒲田に住んでいます。最終的には札幌、大森、蒲田の3拠点4名をPS3のビデオチャットで結んでの開発となりました。

Team OyasumiSupport#end_of_day

左から大森、札幌、蒲田。下の iPad に映っているのは UTC と JST を表示するように 設定された World Clock Pro

何が起こったか

開発がどういう風に進んだのかを共有します。

何をどういう順序で行って、どのくらい時間を使ったかを書いてみます。 もちろん、実際には重なりながら進行しているので、大体の目安だと考えてください。

前夜

@darashi@kei_s がいる facebook グループに @june29 が種になるキーワードを投稿してくれました。抜粋すると・・・

...

このときポストされていた「伏線」のうちいくつかは回収され、最終的なプロダクトの中に息づいています。

08:00-09:00 起床〜テーマ発表直前

朝起きてから、@kei_s がセットアップしてくれた さくらのVPS(V3)1GB が使えるように準備しました。 テーマに依らず必要になるであろう共同作業用のインフラは準備しておこう、というところです。

公開鍵やドットファイル類を送り、手に馴染んだ道具ということで、 Ruby と node.js を予めビルドしておきました。

09:00-11:00 テーマ発表から手を動かし始めるまで

今回、@june29 は土曜日に仕事があったので、午前9時過ぎに家をでなければいけない状況でした。 そこで、テーマが発表されてすぐ、 Skype の音声チャットをつないで打ち合わせを始めることにしました。

「前回の実績からすると最初の2時間くらいはアイディア出しに使っても大丈夫」という @kei_s の心強いアドバイスがあったので、それなりにだらだらと話し始めました。

札幌、大森、蒲田、雑踏

あっという間に @june29 が出発する時間になったので、iPhone の Skype に切り替えてもらい、そのまま打ち合わせを続けました。 彼の移動する道すがらの音がリアルタイムで流れて、なかなか味わい深い体験でした。 電車に乗っている間も、イヤホンで聞いてもらってチャットに発言する、という感じで進みました。

これが想像以上に新鮮で刺激的でした。雑踏、そして時には隣の人の立ち話まで聞こえて来て、まるで自分が東京で電車に乗っているかのような感覚でした。特に、馴染みのある電車を利用していたときは、懐かしさすら感じるレベルでした。それから、イヤホンをしたままトイレに行った@kei_sが、駅の真ん中で用を足しているかのような背徳感があったと発言していたことをここに記録しておきます。面白いことを言って電車に乗っている @june29 をニヤニヤさせる遊びも楽しかったです。

そんなこんなで、チームの間に「音は楽しい」という共通認識が育ちました。

ネタ帳を少し

で、その中でどういう話をしていたかというと、記録に残っている分をなんとなく箇条書きにすると、

という感じです。アイディア出しをしながら facebook のグループのウォールに適宜スレッドを分けてポストしていきました。

やっぱり「音」は楽しい

そして次第に「音」に興味が移っていく... このへんで 10:00 くらい。

ここで 10:40 くらい。

期限内に形にできそうなものは何か

そろそろ11時なので、「24時間以内に何らかのプロダクトとしてまとめられそう」という観点で見直すことにしました。

このへんが残りました。この中でテンションが上がるのはやはり「音」だったので、プロダクトの詳細な形は置いておいても、まずどうやれば音を録音したり、再生したりできるかを考えることにしました。

プラットフォームの選定

プロダクトとチームのスキルセットを考え、どういう技術を採用するかを検討しました。

スマートフォンかPCか

寝る前に何らかの音を録音するとすると、スマートフォンをターゲットにするのが順当に思えました。タブレットやPCをベッドで使う人はそこまで多くは無さそうです。

PC 用のアプリケーションとしてつくると、機種によってマイクやスピーカーが無いかもしれません。また、メンバーが得意な技術のなかで、PCで手軽に録音/再生できる、というようなものはありませんでした。Flash なら実現できそうでしたが、誰もほとんど経験がありませんでした(たぶん。実際には知らない)。

開発経験と見積もり

経験という意味では、自分はスマートフォンアプリの開発はほとんど経験はありませんでした。

それでも、自分には iPhone ネイティブアプリや、Android ネイティブアプリ、Titanium MobilePhoneGap をつかって Hello World に毛の生えたものくらいは作った経験があったので、なんとなくどれを使うべきかという感覚はあって、

という印象でした。

お互いをよく知っているということ

ちなみに、他のメンバーも、お互いにスマートフォン開発の経験が豊富ではないことを知っていました。それだけではなくて、 @kei_s が JavaScript を得意としていること、 Titanium Mobile の経験があることも知っていました。フロントエンドの得意な @june29 がスマートフォン向けWebサイトの開発経験がある、ということも知っていました。

皆 Web アプリケーションはそれなりに経験がある、ということも知っていました。 一番得意な分野をバックエンド寄りなほうからフロントエンド寄りのほうに並べると、@darashi@kei_s@june29 になると思います。今回のプロジェクトでも、結果的にちょうどそのくらいの部分を中心に担当しました。

このこと——誰が何をどのくらいできて、何ができないかをお互いが包み隠さずよく知っていること——はチームで開発する上でとても大事なことです。この共通認識があって、共通認識があるということを認識しているだけで、話し合うまでもなくタスクが適切な人に届けられることになります。気がついたらその時点で最も適切な人がやっているのです。

相手の腹を探っている暇はないのです。

iPhone w/PhoneGap を選択

僕らは全員が iPhone ユーザであるということも知っていました。 なので、対象プラットフォームは自然に iPhone に決まりました。 (@kei_s@darashi は Android も持っていることも知っていました。ただ、この状況で敢えて Android を選ぶメリットは大きくないだろうとすぐに判断できました)。

フロントエンドを得意とする @june29 が戻ってくるまでの間に、必要な要素技術を JavaScript からすぐに呼び出せるように揃えてさえおければ、その後はなんとかなるだろうという気がしました。PhoneGap はスマートフォン Web 開発の知識の多くがそのまま使えるフレームワークだからです。

そういうわけで、チームとして考えても iPhone アプリケーションを PhoneGap でつくるのが最善手であるように思われました。 逆に、PhoneGap で録音再生がうまく出来ないと、他のフレームワークを選択せざるを得ず、スマートフォンをターゲットにするのは難しくなると思われました。

技術的リスクにそなえて

PhoneGap でうまく音声を録音/再生出来なかった場合に備えて、他の方法で代替できないかというアイディア出しも簡単にしておきました。

@june29 から、ビデオをメールに添付して送ってもらえばスマートフォンでの録音したものを取得できる、というアイディアが出ました。これならば、再生も http で送ればよいので、現時点で自分たちが持っている技術で全て賄えそうです。

もちろんクールではないのだけれど、何もアイディアが無いよりはマシです。

次に進む方向

このへんで @june29 がお仕事へ旅立って行きました。ちょうど 11:00 くらいでしょうか。

この時点で、僕の中で MVP として考えていたのは、誰かの「おやすみ」を聞いたり、自分の「おやすみ」を録音したりできる、というプロダクトです。これだけでも実現出来れば、まずは出せるものにはなるだろう、という感触がありました。

ざっくり調査

調べてみると、 リファレンス にも それらしいAPI が載っていて、 PhoneGap で音声の録音再生をしている記事 なども見つかったので、なんとかなりそうだなあという気持ちになってきました。

ということで、まずは PhoneGap で必要なことが "本当に" "全て" できるのか、向こう3時間くらいをタイムボックスにして技術調査を行うことにしました。

作業しつつ、進む方向を固定してしまう前に、すこしアイディアを揺さぶってみたりもしました。「おやすみ」以外に何があるだろう。「おつかれ」でも楽しいかもしれない。単にリレーするだけでなく、新着n件を重ねて同時に再生するとかでも面白いかも。

11:00-15:00 技術調査, スパイクコード

まずは世界に挨拶を

@kei_s が少しの間離れることになったので、"Hello World" を PhoneGap で動かすところを目的にしてスタートしました。

PhoneGap はかなり前に試していたのですが、すっかり忘れていて、ドキュメントをみながらセットアップしました。エミュレータで "Hello World" 的なものが動き、実機でも動いたところで @kei_s が戻ってきました。

同期

ここから PS3 を使ったビデオチャットができるようになったので、つなぎながら作業の続きにとりかかりました。

まず @kei_s に現状までの進捗を報告し、環境構築やプロジェクトの新規作成でハマったポイント、リファレンスを読んでいてわかったことを共有しました。ほどなくして @kei_s の手元でも同じところまで動くようになりました。

次の目標を iPhone で「録音できること」に置きました。

分岐

最初は二人で調査していたのですが、二人の目が必要な作業ではないと判断して、途中から調査と実装を @kei_s に引き継ぎ、@darashi はバックエンドの作成に移りました。

というのも、iPhone で録音ができたとして、それが本当に録音できているのかを確認するためには、iPhone で実際に再生するか、データを外部に転送する必要があるからです。 iPhone 上で再生して確認する方法だと、もしうまく再生出来なかった場合に、再生が失敗しているのか、録音を失敗しているのかを切り分けるのが困難になりそうだと考えました。

そこで、先に仮実装でもよいからサーバを用意しておき、ネットワークで転送してもらうことにしました(サーバの実装が間に合わなかったら、ローカルファイルの再生に進んでもらおうと考えつつ)。

そのほうが「音が鳴る/ならない」の二択ではなく、「データのここがおかしい」という判断ができる可能性があります。さらに言うと、iPhone からサーバに転送する部分は、いずれ必ず必要になる部分なのです (iPhone 上で音声データを再生する部分も一見必要になりそうですが、このとき想定していたプロダクトであれば、ネットワークから音声データを受信して再生出来れば十分で、iPhone のローカルファイルを再生する必要はないかもしれません)。

バックエンドの仮実装

というわけでバックエンドをつくります。Sinatra でサクっと作りました。ここは慣れているので、時間をかけずにすぐに・・・と言いたいところでしたが、ちょっとハマりつつ、@kei_s がサーバに送る部分を書き上げるくらいのタイミングでちょうどバックエンドの準備もできました。

録音→サーバに送るところまで

早速テスト。まず、クライアントからデータをサーバに送ります。次に、scp でローカルマシンに転送します。きちんと音声が録音されていたことが確認できました。 サーバからデータを取り出す部分はまだ書いていなかったので、とりあえずの確認方法です。

これで勝つる。最悪再生は Web でもできるはずなので、なんとかいけるなーと思いました。ここまででだいたい 15:00 です。

サーバ→再生も

@darashi がサーバ側から音声データを送り出す部分を書いている間に、 @kei_s がサーバからのデータを受信するところを書いてくれました。録音してサーバに送った音声データを、クライアントで再生することができるようになりました。ここまでで 15:30 くらい。

次は、実機で触って遊んでみたいということで、リリースの準備作業をすることにしました。前回はリリース前にバタバタしたので、まず先にいつでもリリース出来る状態をつくろうという意識がありました。

15:30-18:30 コードの整理, デプロイメント, 配布の用意

「最初のリリース」を次の目標にしました。そこに向けて進むために、まずは足場を固めることにしました。

コードの置き場

この時点では、バックエンドは VPS に ssh でログインしたターミナルで vi で編集したり、rackup で起動したりしていました。フロントエンドのコードは Dropbox を使ってやり取りしていました。このままでは後々きつくなってくることが明らかでした。 そこで、 github にリポジトリを二つ作成し、それぞれフロントエンドとバックエンドを置くようにしました。

バックエンドの自動デプロイ

また、@kei_s がフロントエンドのコードを整理している間に、バックエンドを自動デプロイ可能にすることにしました。Passenger をセットアップし、 capistrano でデプロイできるように準備しました ("一昨日やった問題"だったので15分くらいでできました。素振り重要)。

TestFlight での配布の練習

バックエンドは慣れているので良かったのですが、問題はフロントエンドのプロダクションの準備でした。何しろ TestFlight はテスターとして使ったことがあるだけ、というレベルなので、Xcode でのビルドの仕方も含めて調べる必要がありました。

それでも、この作業をこなしておかないとリリース可能な状態にはならないので、必ず今やるべきだという確信がありました。

試行錯誤の末、TestFlight をつかってテスト版を配布できる状態になりました。以降、@darashi はビルド職人(オフショアのビルド担当者!)として、その時間の多くを過ごすことになります。チームの変更を受け取ってビルドし、テスト版を TestFlight にリリースする。このサイクルを何度も回しながら開発を進めていきました(本当はもっと自動化できるとよかった)。

18:30-22:00 プロダクトデザイン, ユーザストーリー

技術的に不安だった部分が全て片付いて一段落したところで、今手元に揃った材料をどうパッケージしていくかを改めて考え始めることにしました。課題「一日の終わりを楽しくするもの」との整合性も改めて確認することにしました。

何ができるとよいのか

ユーザにとって、どういう風に見えるプロダクトであるべきか。またしてもちょっと悪ノリした感じのアイディア出し:

この大きく二つのアイディアがありました。僕は、おやすみリレーのほうがシンプルで、パッケージとしてうまくまとめやすそうだと感じていました。今手元にあるプロダクトからの差分も小さそうだという印象もありました。

このとき手元にあったもの

この時点で僕らの手元にあったのは、「録音する」「送信する」「音声を再生する」のボタンが並んでいるだけのアプリケーションでした。これを順番に操作することで、録音したり、それを聞いたりできます。

逆に言うと、適切な順番に操作しないと、期待されるような体験は得られません。作りかけのボイスレコーダーです。

プロダクトの形として、何通りもの可能性を考えることはできました。しかし、まだこの時点では、どういう順序に何がおこるのか、というストーリーを一本に絞ることができませんでした。一度「おやすみ」を投稿すると、それ以降に来た「おやすみ」が聞けるようにする、というアイディアもありました(ただし「これではいつ寝ればいいのかわからない」「(ユーザ数が十分でないと)実際にはそんなにタイミングよく来ない」という理由で採用されませんでした)。

決断を先送りしたい

この判断はコンテストの中で一番大事な判断になるところだと感じていたので、だいぶ悩みました。 なによりストーリーが大事です。でも、まだ「これでいこう」という決断までは出来ない状態でした。

そうこうしているうちに、 @june29 が仕事を終えて戻ってくる時間が近づいてきました。@june29 はこういうストーリーを組み立てるのがとても上手なので、彼もいるところで一緒に話をしたいという気持ちが強くありました。 それから、手元にあるものを誰かに見せてフィードバックを得たい、という気持ちもかなり強くなってきました。

送信前の確認機能はほしい

煮詰ってしまったので、ひとまず手を動かす作業に戻ることにしました。どう転んでも必要になるであろう、無駄にならないと思われるものを選んで実装することにしました。

プロダクトから録音機能が無くなることはないだろうから、録音をする上での不便を潰すのは無駄にならない作業だろうと考えました。

まず、 @kei_s が録音した音声を送信する前に確認できるようにしてくれました。

同時に再生するとほどよい悪戯っぽさが生まれる

それから、複数のデータを保存できるようにしたほうが良いだろうということで @darashi がバックエンドを変更し、@kei_s がフロントエンドを変更しました。

最初のバージョンは複数の音声が同時に再生されるものでした。順番にではなく同時に再生するようにしたのは、第一には実装の手数が少なかったからです。ただ、実際やってみると、複数の「おやすみー」が同時に再生されるのはかなり面白い体験で、これは何とかなりそう、という気持ちになってきました。

「おやすみを共有するサービス」という括りでみると、レッドオーシャン感があって怖いなあと思ったのでした。なのですが、「複数の人の声が同時に再生される」という、ちょっと悪戯っぽいところが気に入りました。この「ほどよい悪戯っぽさ」は武器になるだろうと感じたので、大事にしたいと思いました。

ここまでで 20:30 くらいです。

無駄にならない改良をもう一つ

いじっていて、録音開始のタイミングと、終了のタイミングがわかりづらいというのが気になりました。これも @kei_s がカウントダウンするようにしてくれて、対応しました。

この間、@darashi はプロダクションビルド、署名と TestFlight への送信の練習などをしていました。

ここまで 21:50 くらいです。

22:00-23:00 状況の同期, チーム拡大

このへんで @june29@ZoAmichi がガローア(蒲田サテライト; @june29邸)に到着しました。 PS3 で3拠点接続を開始します。

状況の同期

まず最初に、何をしてきて、何が今僕らの手元にあるのかを共有しました。

@june29 がフロントエンドをいじる体制ですすめるのが最適だと考えていたので、 とるべき次のアクションは大きく以下の3つだと認識していました:

これらを並行して進めながら、チームが再編成されていきました。

現状のプロダクトで遊んでみたところ、ガローア会場も好感触でした。安心感が増しました。

ガローア会場からの初コミットは 23:11 でした。

コードの引き継ぎ, 教えて kei さん

このへんでフロントエンドのコードが @kei_s から @june29 に引き継がれることになりました。

手が空いた @kei_s は、皆の色々な調べ物を一手に引き受けてくれました。 とても心強く、安心して作業を進められました。 今思うと、他のメンバーと三組のペアプロを同時にこなすナビゲーターのようでした。

加速するため、あるいはペア間の情報共有を有効に行うため、複数のドライバーでナビゲータ共有するようなペアプロのやり方も、状況に依っては有効かもしれません。

23:00-00:30 プロダクト名決定ミーティング

作業を続けるうち、そろそろプロダクト名を確定していたほうがよいという場面が増えてきました。 プロダクト名決定会議が始まります。 ここまでの開発コードネームは Koe でした。

出てきた命名(部品)の一部を紹介すると:

・・・と実際にはこれの数倍はあったのですが、

"おやすみのシャワーを浴びて寝る" というフレーズが出てきました。 交差点よりシャワーのほうがアイコンもやりやすいという @ZoAmichi の声もあり、おやすみシャワーに決定しました。

00:17 ごろの出来事です。

決定したプロジェクト名でリポジトリを作りなおす

命名類を直すのが面倒だったので (Xcode のどこをいじれば十分なのかよくわからなかったし)、 フロントエンドはリポジトリから作りなおしました (00:22)。

00:30-01:00 プロダクト再設計, 応募の準備

応募用のメモを Google Docs で作成開始

プロダクト名も決まったので、応募フォームに書く内容の検討を始めました。01:20 頃です。 Google Docs をメンバーで共有して、書けるところから書いて行きました。

プロダクトの設計 reloaded

「おもしろくて眠れなくなる」のでは本末転倒なので、何度も聞けないようになりました。 録音したあと、一度聞いたらそれで終わりで、そのアプリはもう何もできなくなる。 あとはちゃんと寝てください!という設計です。

それから、いきなり「おやすみを言ってください」と言ってもどうしていいかわからないので、先に例示としての再生が必要、という @kei_s のアイディアもありました。

起動直後に、いきなりおやすみが再生されるとまずい (多くの人はサイレントにしている) ので、 再生ボタンは必要だよね、というのもありました。

結局、最初に直近5人ぶんの「おやすみ」再生され、録音、確認、送信すると、自分を含む「おやすみ」が再生される、という仕様に落ち着きました。

@june29 が画面設計の初案を Keynote で作ってくれました。 画面設計について資料を見ながら話し合い、気になっていることを共有し、実装に着手することになりました。

01:00-03:00 アクションフローの実現, パーツの改善

サーバサイドで音声をミキシングするように

@ZoAmichi が画像をつくり、 @june29 がフローの実装をしている間、@kei_s@darashi で取れそうなフィーチャーを片付けることにしました。

複数の音声を同時に再生する際、iPhone からサーバ上の5つの音声ファイルに対してリクエストが発行されるような作りになっていました。しかし、これがややもたつくので、サーバサイドでストリームを一個にミキシングして渡すことにしました。

クライアントサイドは @kei_s が、サーバサイドは @darashi が担当しました。02:40 頃に完了しました。

エミュレータから送られてくる wav ファイルの形式が実機のそれと違っており (ステレオになっていた)、ややハマりました。

フローができる

03:12 に @june29 から push されてきた変更で、音声の再生、録音、確認、送信、自分の声を含む音声を再生する、という一連の流れがページを順に進んで行くインターフェイスで実現されました。

一箇所、動作に不具合があったので(録音したデータを送信するところが動いてなかった)、@kei_s@june29 でそれを直しつつ、という感じだったと思います。 記憶の残存具合から、この頃から自分の意識がだんだん薄くなってきているのがわかります。

03:00-05:30 ビジュアルデザイン, 全体のブラッシュアップ, 応募関連作業

紹介文

自分の担当範囲は大体落ち着いたので、紹介文の原案を作成することにしました。 だらだらーっと書いて、だいぶ良い感じのポエムができました。

アプリアイコン, スプラッシュ画面

そうこうしているうちに、 @ZoAmichi によるアプリアイコンがリポジトリに push されました。 キラキラっと星がシャワーになっていて、とっても素敵な感じになりました。03:30 頃の出来事です。 続いてスプラッシュ画面の画像が 04:45 頃に push され、フロントエンド側の大枠が固まりました。

(@ZoAmichi が居なかったらアイコンとかどうしていたんだろうと思うとおそろしい... 完全に考えから漏れていました)

TestFlight の invitation をコンテストのアカウントへ送信

そろそろ提出に向けての準備が必要だという状況だったので、TestFlight からコンテストのアカウントに向けて invitation を送信しておきました。 5:14 に Accept してもらいました。ご担当者様、おつかれさまです><

紹介文 2nd

紹介文を皆でみてもらって、最終稿ができました。これで作品を投稿できる状態になりました。

iPhone 3GS で検証

TestFlight でみると、コンテストの検証機に iPhone 3GS も含まれているようだったので、手元の iPhone 3GS を引っ張りだしてきて(充電して)検証しておきました。動作には特に問題がなさそうだったので安心しました。

05:30-06:00 「おかわり」の実装, 小さな改良

この時点でいつでもリリース可能な状態になったのですが、締切りまでに時間がまだあったので、小さめのフィーチャを一つだけ選んで実装することにしました。

おかわり

ここで選ばれたのは「おかわり」と呼ばれるフィーチャです。 自分のおやすみを送信したあとに流れる音声を、もう一度だけ聞くことができるものです。

自分が「おやすみ」を送信すると、直後に皆の「おやすみ」が返ってくるので、何が起きたかわからないユーザがいるかも知れない。あるいは、自分の声が本当に入っていたのかわからなかったユーザがいるかもしれない。それを解決するために「おかわり」が作られました。

@june29 が何度でも聞けるようしないほうがよい、と主張しました。「一回だけだよ」と言われて大事に聞いてほしい、という意図からです。それで、泣きの一回「おかわり」をすると、もうアプリケーションは何も出来なくなるように作られました。

(課金でもう一度聞けるようにしよう、などというジョークもありましたが...)

厳密な実装ではなくてもよいという判断

これは実は厳密な実装にはなっていません。自分が録音した後に5人以上の人が録音すると、おかわりしても自分の声が入らない音声が返ってくるのです。しかし、今回のコンテストを主眼に置くとそれでも十分 work するだろうと判断しました。まずはその状態を体験したい、という気持ちもありました。

この作業のためにリポジトリに用意されたブランチが「おかわりブランチ (okawari branch)」です。@kei_s が(朝食もまだだというのに)おかわりのブランチを作りました。

次のおやすみに備える

この時点では、アプリケーションは「おかわり」を終えて最終状態まで来ると本当に何もできなくなってしまう仕様でした。 最後の画面でアプリがバックグラウンドに回されると、次の日に備えて最初の状態に戻るように @kei_s が改良しました。画面の遷移を作成した @june29 とコミュニケーションをとりながら作業が進められました。

06:00-07:30 リリース

最終のビルド

コンテスト検証機を対象に入れて最終のビルドをしました。また、アップデートを通知しました。

ビデオ撮影

時間がまだあるので、ビデオを作ろうということになりました。 ガローア会場で @june29 が出演し、@ZoAmichi が iPhone で撮影しました。 監督は大森会場の @kei_s です。

この頃には「おやすみ」どころかすっかり空が明るくなってしまっていたので、ガローアの2人は仲良く布団を被りながら夜を演出しつつ撮影しました。札幌から遠く離れた地で、男性2名が仲良く布団を被って iPhone を弄るビデオを撮影している様を、生中継で見ていました。人生に一度あるかどうかわからないレベルの経験です。声が出ないように我慢しました (ミュートすればよかった)。

ビデオ編集

ガローア会場で撮られた動画は大森会場に転送され、 @kei_s がそれを編集しました。 @darashi はその様子を観ながら半分ねてました...

ビデオ完成

いい感じにできあがったところで、たまたま vimeo の Pro アカウントを持っていた @darashi がアップロードすることになりました。結果、蒲田→大森→札幌と動画が移動して世界に公開されることになりました。

投稿

vimeo の動画が投稿され、フォームを埋めるのに必要なものが全て揃ったので、投稿しました。7:35 提出完了です。 お疲れ様でした。その時の写真がこちらです。

Team OyasumiSupport#end_of_day

特別賞

昼過ぎまで泥のように眠り、私用から帰ってきて仕事をしていたら、審査結果が発表されました。

また特別賞をいただくことができました。

うれしい!!!やりましたね!!!!!!!!!!!!!

使っていた主なツール、インフラ

だいたい、こんなものを使っていました。色々なジャンルが混ざっていますが、参考まで。

まとめ

クックパッド社主催の「第3回開発コンテスト24」にチームで参戦し、二回目の特別賞を受賞しました。

チームが過ごした24時間を @darashi の目線からまとめました。

今回は、早い段階からリリース可能な状態を保ち、それを改善していくというやり方で比較的うまく回せたように思います。プロセスが自分たちの手でコントロールできている、という感覚がありました。今回に関していうと、与えられた制約や時間のなかで、だいぶ上手に進めていけたのではないかと思います。

「おやすみシャワー」を使ってくれる方を募集します

おやすみシャワーを使ってくださる方を若干名募集してみたいと思います!

iPhone をお持ちで「一緒におやすみしてみたい」という方は、 TestFlight にご登録の上、 @darashi までご連絡ください! 希望者が多いとご希望に添えない可能性もあるのですが、ひとまずご連絡いただければと思います。

あわせて読みたい

御礼

このような機会を与えてくださった、クックパッドさまに感謝いたします。素敵な審査員からのコメントをつけていただいたり、作品の説明を素敵な英語に訳していただいたりと、色々なところからコンテストをよりよいものにしようという気持ちを強く感じました。

感謝の気持ちとともに、月曜日の夜はお祝いということで大好物のしめ鯖とアボカドを さっぱりアボカドしめ鯖 でいただき、つくれぽも送ってみました!!

チームの皆に、心からの「ありがとう」を。おかげさまで楽しい時間を過ごすことができました。

コンテストに関わる全ての皆様に、深く感謝いたします。