yeoman webapp で複数ページでAMDする方法

最近仕事でもyeomanを使うことが多くなってきた。というか開発スタイルをできるだけ画一化したいので必要なことはyeoman上で片付けてしまおうという気持ちがまあ強い。

 べつにyeomanじゃなくてもいいんだけど、他にもっとよいツールが思いつかない状態なので。bracketsやDreamweaverなんかも試してみたんだけど個人的にはyeoman+vimがWebアプリもWebページも作りやすかったりしてます。bowerやnpmでモジュールの導入が楽なのとgrunt様が強力なおかげですね。

 yeomanはgeneratorというプロジェクト生成モジュールを使うことでいろいろな開発に適したプロジェクトを生成することができる。公式にもいっぱいあるのだけどGetting Startedで使われてるgenerator-webappが一番ポピュラーだろう。

 webappはいい感じのhtml、css、jsのセットを出してくれるんでよく使ってた。今まではWebサイトやシングルページの小さいアプリを作るときに使っていたんだけど、アプリの規模を大きくして複数のページで違うjsプログラムを使うようになってちょっとハマった。requirejsのビルド設定がうまくいかなかったのである。

 webappはgrunt-contrib-requirejsをつかってgrunt build時にrequire.config()が記述されているmain.jsを起点にdefineされたモジュールを結合、minifyしてくれる。なんとも便利なんだけど、これが2つ以上のページで異なるrequireをしたいときにはそのままじゃうまくいかない。

 例えば、index.htmlでmain.jsを使ってa.js, b.js, c.jsをrequireする。一方でabout.htmlではmain2.jsでb.js, c.js, d.jsをrequireするといったことをやろうと思ってもうまくいかない。about.htmlで 

<!-- build:js scripts/main2.js -->
<script data-main="scripts/main2" src="bower_components/requirejs/require.js">
<!-- endbuild -->

 みたいにしても、期待通りにビルドされない。これって簡単にできないと複数ページになるアプリが書けねえじゃんと思ってけっこう本気で調べたけどかなり時間がかかった。。まあ結果的にrequirejsやgrunt-contrib-requirejsのことがだいぶ判りましたよとほほ。

 で、結果としてできたのがこちらのgistにおいてあるコードです。

必要なのは主にGruntfileのビルド設定。 

ポイントは152行目のuglifyのブロックと156行目以降のrequirejsのブロック。

まずrequirejsでdist1、dist2という2つのbuild.jsオプションを記述。それぞれmain.jsとmain2.jsを割り当てる。ページが増えてrequireを記述するjsファイルが増えていけば同じようにdistを増やしていく。

この発想はなかった。ボクはoptionのほうでなんとかするもんだと思い込んでいてrequirejs-multipage-shim-tutorialなんかを参考に設定いじりまくってうまくいかなかった。のでこれ見たときコロンブスの卵すぎて鼻水出そうになった。どっかのstackoverflowでこれ見つけたんだけどリンク失ってしまった。ありがとうどっかのだれか！

dist1, dist2の設定により、これでmain.js、main2.jsはそれぞれよろしく結合されることになるんだけど、実際にビルドしてみるとmain2.jsのほうがminifyされない。調べてみるとmain2.jsの存在がuglifyに伝わってない感じだったのでwebappのGruntfileでは省略されているuglifyのブロックを追加してmain.js, main2.jsを明示した。するとmain2.jsもoptimizeされるようになった。ディ・モールト良し！

この方法だと、requireの制御が増えるごとにGruntfileを編集する必要があって、もう少しうまくタスクを組んで自動化できないかなあと思うのだけど、まあそんなにめんどいことじゃないからとりあえずこれでいいか、ということにした。

何よりこれで何日か悩んでた問題が解けたし、webappで開発できるアプリの幅が少し広がったので新たな欲が湧くまでは当面これでいいことにした次第です。

つーかもっとgenerator増えないかなあ。yeomanはもっとニッチなgeneratorが増えたほうが面白いことになると思う。generatorハッカソンとかやろうかなあ。誰も来ないかもなあｗ

<htmlday>に凸撃してきたお話

2013年6月8日（土）。この日は日本のWeb業界において象徴的な日になったなぁと後で思った次第。なぜなら<htmlday>という日本全国でWeb系のイベントが同時多発的に開催されるという今までにないムーブメントが起こった日だからです。

このhtmldayを凸撃生放送したときのお話。詳しくは同じく取材スタッフをやってくれたIT Mediaのともちゃんが記事を書いてくれてます。

<htmlday> 凸撃生放送舞台裏 Photoレポート：世界のITエキスパートたちを捕獲！ 凸撃インタビュー - ＠IT

全国で32イベント、延べ1555名の賛同参加があったとのこと。すごい。
勉強会、セミナーから有志の飲み会まで。大阪でもHTML5など勉強会が賛同開催された。

実に様々なイベントが各地で開かれこの日全国でWebをテーマに1500名以上のクリエイターがWebについて考えた。まさに前代未聞の日だったと。うん、やっぱり後で考えてもすごい日だ。

同日東京では3つの大きなイベントが開催された。Build Insider Offline, Test the Web Forward, W3C Developers Meetup。どれもWebの未来という点で非常に重要なイベントである。TestTWF, W3C Dev Meetupについては世界中からW3Cメンバーの技術者たちが集まる場で、日本では希少な機会だ。

全国的にWebが盛り上がってるのもアツいが、東京もアツい。こんなすごい日はもう二度と無いかもしれないということで、html5jはメンバー総出で各イベントを全力サポートした。

できるかぎり配信したいということでhtml5jの放送職人がYoutube Liveで当日配信を行った。とりあえずW3C Dev Meetup のアーカイブはこちらでみることができる。

公式配信はOK。準備に抜かりはないなと思ったけどふと、先日ニコニコ超会議2に行った時の感覚がよみがえって「せっかくだから突撃取材やって会場の雰囲気流さねぇ？」って言ってみたらやろうやろうってなったからニコ生でhtmlday凸撃生放送というのをやることになった。こんな感じで。

まあほんと朝から晩まで生放送なんて初めての経験でした。しかもこの特製ヘルメットのおかげで取材役のクセに写メとられまくった。どっちが取材されたかわからん感じで。まず朝イチ羽田についてからヒルズへ直行。1Fのカフェでスタッフと準備。

いっしょにいるのがこの特製ヘルメット型配信装置を作成したwakasa氏。公式配信を手がけたhtml5jイチの配信職人でありこんなヘルメットを自作できるクレイジーエンジニアである。こだわりがいちいちすごい。

ヘルメットの装備。フロントカメラにGo Pro、配信装置にLiveShell、Wimaxルーター、バッテリーパックも装着。Go ProとLiveShellはHDMIで接続、マイク入力。これだけでPCレスの独立した配信装置として機能する。一応ノートPCを片手に持っていたがこれは画角とコメント確認用に使っていた。

まあこんな感じで各会場を巡って実況というかインタビューというか、なんかそんなことをしました。10:00〜22:00の間3回に分けての配信。断続的とはいえ長丁場でここ何年ぶりというくらい疲れました。楽しかったけどね。22:00くらいのボクはもうこんな感じだった。

最初の会場Build Insider Offline（品川のMS社）では会場の雰囲気が厳かな感じだったこともあって「ナレーションが堅えよ」などとコメントをいただいた。まあ若干緊張してたしなれない機材に気を遣いながらという感じだったのでアレでした。

まあ次の会場くらいには慣れてちょっとやわらかくなりました。外国のエンジニアもご陽気に接してくれたことも手伝ってだいぶ気分的にも楽になったかな。しかし配信がくだけてきた最も大きな要因は。。

この娘の暴走である。第2会場 TestTWFから本格的にエンジンがかかってきた。ボク的にはこの会場、W3CのSpec Editorらがわんさかいて「やべーいつもMLで見てるCSS Groupの◯◯だよ。。」と芸能人を見てる感じでビクビクしていると、誰かもわからず突入して「今持ってるボトル変わってますね。」などと配信的に微妙なことを聞いていく。

そんなともちゃん（写真）にツッコミを入れつつ、いらんことしようとするのを諌めつつの配信だった。思えばこれに体力を消耗した気がするんだけどまあそれはそれでネタてきにはおいしかったのかなと。ともちゃんのおかげで凸撃感のある配信になりました。感謝。

じっとしてれば美人なんだけどねぇ。

こっちのがデフォルトみたい。

最後のほうにはともちゃんがヘルメットをかぶって配信してたんだけどまあ完全に酔っ払ってました。酔ってるのとヘルメットが重いのでともちゃんぐらんぐらんしてたみたいですね。「画面見てたら酔う」などとコメントをいただきボクは管理者コメで謝る役をやってました。

しかしさすが、「凸撃力は上がった」とのコメントもあり。こりゃあ酔ってない時にかぶせるべきだったかなと思った次第。来年もhtmldayをやるならともちゃんメインキャスターでやったほうがいいかなとも思いました。

おそらくWeb技術者としていままで経験したことのないインパクトの数々に出会った日。それを一日中実況した日。もうこんなのは二度とないかもな経験ができたのは日本と世界中から集まったWebを支える技術者たちとhtmldayを開催したhtml5jスタッフの尽力あってのことです。

ほんとみなさんおつかれさま＆ありがとうございました。

ほんと楽しかった。機会があればまたやりたい。

FirefoxOS keon 開封の儀

Firefox OSの開発者向け端末keonを購入した。
東京にいるので家に帰ってから開けようと思ってたんだけどいま少し時間ができたから開けてみようとおもった。ので今から開封の儀を行おうと思います。

箱のデザインはこんな感じ。なんかムダに縦に長い。

開封した。なんかリッチな感じでナナメに梱包されている。なるほど高さが出るはず。keonは低価格なほうの端末なのでせめてものリッチ感の演出か？

持ってみた。軽くて持ちやすい。やっぱ携帯電話はこれくらいのサイズが実用的だよな。

付属品はバッテリー、イヤホン、MicroUSBケーブル、コンセント。

裏面

電源を入れてみた。geeksphoneのロゴ。

FirefoxOSのロゴが次に出る。ピント合わなかったけど。

言語選択。日本語はない。

Wifi設定

SIM, Facebookから連絡先がインポートできるみたい

ニュースがほしかったらメアド入力してね

タイムゾーンの設定。ざっとみたところ+9:00が見当たらなかったので+9:30を設定。あとでよく探す。

Privacy Choice

初期設定は以上。以下クイックスタートが数画面続く

ロック画面きた。

ホーム画面。

右にスワイプ。Settingをクリックしてみる。

Settingの画面。設定内容はiOSやAndroidでよく見る感じの項目。

ホームから左にスワイプ。アプリケーションがカテゴリ別にまとめられている。

Google Mapを起動してみた。普通にヌルヌル動く。ハード的にはやや低スペックだけど特にストレスはない。

Firefoxブラウザを起動

hello と検索。検索エンジンはBing。

keonが欲しかった理由はFirefoxOSが低リソース環境でどこまで動くかということが知りたかったから。結果的にこれくらいのハードリソースなら余裕で動くということがわかった。これならキャリアは十分に実用的な100ドル端末をバラまくことができるんじゃないかな。面白くなってきた。

まじ神戸に帰ったらいろいろやってみようと思う。

あと、昨日中の人から「FirefoxOS アプリ開発者ガイド」すごいよと教えてもらった。うん、知ってる人たちが書いてるからいい本に違いないと思ってたんだけど正直Mozilla Wikiや公開されてるドキュメント読んでたらだいたいわかるでしょと思って購入をしぶってた。しかしちょっと読ませてもらって間違いだとわかった。

この本まじですごい。アプリの実践的な開発方法はもちろんのこと、FirefoxOS自体のビルドや公式にサポートされていないボードに対するカスタムビルドの解説、まだドキュメントが公開されていないAPIリストなど（これ、GeckoやGaiaのソースコード読まないと抽出できないはず）現時点で貴重な情報が収録されている。

keon引き取って帰りがけにAmazonでポチっておいた。帰宅する頃には届いているはず。本のレビューはまたゆっくりと。

さて、仕事行ってこよ。

Firefox OSアプリ開発ガイド

Firefoxでアプリケーションキャッシュをデバッグする

Firefox23（現在はAurora）になって、アプリケーションキャッシュがデバッグできるようになったみたいなことをどっかで見たので（どこで見たか忘れた）やってみることにした。

アプリケーションキャッシュというと強力な機能なんだけど実際に使いづらいという印象があってまだ積極的に使ってない。使い方としてはマニフェストファイルにキャッシュしたいデータを定義してmanifest属性でそれを指定するだけという超カンタンなんだけど簡単なだけに動きがブラックボックス的で挙動がわかりづらい。

あと開発者ツールでキャッシュ状況を閲覧したり操作したりできないから要望がなかったらまあいいやみたいな感じで敬遠してた感があった。ChromeではResourseパネルにApplication Cacheの項目があってたしかキャッシュ状況は閲覧できたはず。

Firefoxでは23から開発ツールバーでappcacheコマンドが打てるようになった。これを使ってアプリケーションキャッシュのデバッグがいろいろできそうな感じ。現在23はAuroraで提供されているので、Auroraで実際に試してみた。

まず、Auroraの[ツール] -> [Web開発] -> [開発ツールバー] をクリックする。

すると、ブラウザの最下部に、黒いテキストボックスが表示される。これが開発ツールバー。いわゆるFirefoxで開発するためのコマンドラインでaddonとか開発用ツールをコマンドでコントロールできる。

このコマンドラインで、「help appcache」と打つとこんな感じで表示される。

コマンドは4種類。
appcache clear：アプリケーションキャッシュを削除する
appcache list：キャッシュの一覧を表示する
appcache validate：マニフェストファイルをバリデートする
appcache viewentry：別タブで指定キャッシュの情報を表示する

だそうで。ためしにアプリケーションキャッシュのDemoサイトにアクセスしてみてappcache listを打つとこんな感じで表示された。

Chromeと比べてけっこう情報量が多い。要るか要らないかは別として。でもData sizeはうれしいかも。どうせならData sizeの合計もほしいかも。

あとclearやvalidateなんかは実際開発時に使えると思う。マニフェストファイルのバリデートはCache Manifest Validatorでオンラインできるんだけどここのコマンドでできるほうが便利。

うん、使える。アプリケーションキャッシュを使う開発ではこのappcacheコマンドを使うだろうなあと思いました。

企業内でIE6は使われ続けてもいい。ただアクセスを外に出さないでほしい。

双日システムズ、Windows XPから7/8への移行向けにIE6互換ブラウザを開発

こういうのは絶対出てくると思ってました。だってこれ儲かるもん。導入したい大企業はけっこう多いと思うので、一山なんぼのいい商売ができると思います。個人的にはシステム移行に怠慢な企業にバンバン営業をかけて儲けていただきたい。ただ売るときには以下の様な仕組みを合わせて導入して欲しいなと思います。それは、

IE6（互換ブラウザ）でWWWにアクセスできないような仕組み

です。双日システムさん開発するIE6互換ブラウザにこういう機能を実装するか別のアプライアンスとセットで売るか。なんかそんなことしていただきたい。

特定の企業の中でIE6が使われ続けて、中のWebサイトの表示の対応がややこしかったりセキュリティの問題が出たとしても、それが企業の中に閉じていて企業の責任範囲である以上問題はないと思います。それをサポートするサードパーティが儲かるなら良いと思うくらいです。

ただ、企業の中のIE6アクセスがWWWに出てしまい、企業の外のサイトにアクセスすることを止めてほしい。IE6を使いつづける者とは関係ないWebサイトにIE6のアクセスログが残ると、それらのサイトはIE6サポートが切れなくなる。クライアントはその僅かなアクセスログを根拠にウェブクリエイターにIE6対策を強いてくる。

結果ウェブクリエイターは今日も終電まで不毛なIE6対策に追われることになる。
これは、「IE6を使い続けるものが世の中に迷惑をかけている」状態と言っていいと思っています。

ボクは以前から「IE6対応? それ、別料金でできるよ。」キャンペーンでアンケートをとったり、IE6非対応サイトになるならば告知をしよう「ie6alert-js」をつくったり、Ie6をさっさとやめようなんて講演をあちこちでやったりしてきました。

あげくのはてに去年のIE6をやめようと思ってももう手遅れに至っては6万Viewを超え2ちゃんねるのネタ速報に載ったとか。これはさすがに笑ったけど。まあ一部からはすっかりIE6を目の敵にしてるキャラだと思われてるのかもしれないですねｗ

けど、実際はそんなことはなくて優秀なブラウザだと思っています。優秀であるがゆえに今も使われ続けている。そんな側面もあると思うので。あえて言うなら優秀じゃないのは今までIE6対策に手を出さなかった人間のほうですよね。

まあそんなグチっぽいことは置いといて、IE6対策についていろいろ考えてきた中で、ある時期から「IE6サポートが終了してもたいしてIE6の数は減らないんじゃないか？」と思うようになりました。なぜならWin7, 8に移行してもIE6を使い続ける手段があるから。そのひとつが上記プレスリリースのような仕組みですね。

簡単に解決できる。業務システム刷新のコストより導入コストのほうが安い（たぶん）。責任者がなんもしなくていい。こういう仕組みは売れます。こういう製品が出て売れるのであればIE6の利用数は下げ止まるだろうと。たぶん2014年以降そうなるんじゃないかと思います。0.5%くらいを維持し続けるんじゃないかな。

それは悪いことか？と考えてみると、実はそうでもない。企業の立場になってみると、下手をすると億かかるかもしれないシステム刷新より低コストでスムーズに解決できるというのは筋がいい。さらに上記のように企業内に閉じてIE6を使うことは我々にとって迷惑じゃない。それをふまえて改めてボクが求めているのは何か？と考えてみると、

企業内でIE6は使われ続けてもいい。ただアクセスを外に出さないでほしい。

だったことがわかりました。

それでその考えを形で示そうと思ってつくったのが、ie6-proxy。
こういうファイアーウォールを置いてとにかくIE6（互換ブラウザ）のアクセスが外に出るのを禁じるようにしたらいいと。業務システムを使っていて、うっかりそのまま昼休憩にYahoo!を見に行くとかできないようにしたらいいと思うんです。

今後IE6がWWWをウロウロするというのは、我々Webクリエイターにとって迷惑なだけじゃなく、セキュリティ的な観点からも悪いのは明白です。ほんとITコンサルの方々もそういったことを指導していったほうがいいと思うのですよね。それはそれでうまくやればいい小遣い稼ぎになると思いますよ。

ニコニコ超会議2に行ってきた

実はニコニコ動画より比較的Youtube派だったり、配信はUSTREAMばかりでニコニコ生放送はやったことがなかったりするボクですが、電王戦が超アツだったり最近コンビニとかでよく初音ミクを見かけたりとニコニコのコンテンツをよく出くわすようになったのでちょっと面白そうだなと思って行ってみた。

けっこう真面目な話市場調査というか最新動向の調査という名目に仕立てあげて最近台頭しているニコニコ動画が日本のコンテンツ市場にどういう影響をあたえるか考察するというテーマにしといて行ってきた。結果的にはまあ勉強になったというか楽しかった。いやこれはニコ厨じゃなくても普通に楽しいですよ総合エンタメでしたね。

来年も開催されるみたいじゃないですか。来年も時間が許せば行きたいなと思いました。つーか帰ってから「なんかいろいろやってニコニコ動画にあげてみようかな？」という気分になった。開催の目論見どおりだと思うけど、それだけインパクトが大きかったですよ実際。HTML5飲み会UST in 大阪とかいっぺんニコニコ生放送でやってみようかしら？

さて、当日の様子は以下。
まずは電車で会場にたどり着いた。

進んでいくとやばそうな行列が。。

めちゃくちゃ並ぶ。結局受付に辿りついたのは約1時間後だった。
午前中がこんなに混んだらしい。午後からはスカスカだったとのこと。

やっと会場にたどり着いた。もちろん中もすごい人である。

入り口前のドミノ・ピザは初音ミク仕様になっていた。

 なんかラクガキだらけのエヴァ初号機。

個人的に一番見たかった自民党の街宣車。こんなん持ってくるってなんかわかってるなあ自民党という感じがした。

自民党のブース広い。なんか気合が入っていてスタッフの方が盛んにグッズの宣伝してた。

なんか自民党本部にしか売ってないグッズとか販売してたので、調子に乗って「一揃えください」と言って全部買ったら、スタッフの人えらい喜んでくれていっしょに写真撮った。左の方は神奈川県選出の衆議院議員さん。すごい気さくな方だった。

日本共産党のブース。なんかふつーのブースだなあと思ったら脇にひっそりと古い本が飾ってある。みると「蟹工船の初版です」。ある意味わかっていらっしゃるつかみのあるブースでした。

ユーザーが熱唱しているブースも有り、

巨大なシメジがあり、

DJが延々アニソンを流している。脈絡はないが会場の盛り上がりがすごい。

個人的に興味があった自衛隊コーナー。かっこええ。
海自。

陸自。

陸自の偵察用バイク

空自。

一番見たかった10式。カッコイイ！

もう圧巻である。

技術部方面。MMD+Kinectだと思う。この人ずっとこんな調子で手ふってたからかなり疲れたに違いない。

技術部〜してみたコーナー。

ネギ振りキーホルダーみたいのを自作できるコーナーだった。これは面白そう。事前に予約しときゃよかった。。

なんかすごいもんが飛んでた。。

ホリエモン監獄コーナー。知らないにーちゃんが「オレ入りますよ。撮ってください！」と。絵ズラ的には助かる感じありがとう。

政治討論会的なことをやってる

裏で皇室評論家の武田さんがなんかN●Kダメ的なことをぶっちゃけてた。

巨大スクリーンに映し出される生放送の様子。

踊ってみた ブース。開始前だったけど既にすごい人だかり。

電王戦。ここも必ず見ておきたかった。

対局できるようになっていて、囲碁、将棋、どうぶつしょうぎが楽しめるようになってた。

演奏してみた。すごい人だかり。となりには電子楽器体験コーナーも。

なんか神社があって、みんな行列に並んでお願いごとしてた。

鉄道模型。詳しい友達に聞いたら「あえてこの感じがいい。」つくりのようだ。

ライブドローイング ブース。プロの人がライブでなんか描いてた。

グッズ売り場。Tシャツがけっこう売り切れてた。技術部のやつとか欲しかったな。とりあえずカチューシャ買った。

歌ってみた。こういうユーザー主導型の人気とテンションがすごかったのはさすがという他ない。

アニソンのライブもあり、

ボーカロイドのブースも。これってポリッドスクリーンってやつだと思う。前から興味あって動画見てたけど、実際にみてみるとすごい。やってみたくなる。

うまく撮れなかったけどピラミッド型のスクリーンで擬似ホログラフィー。上部のiPadで映写してるんだけどこれも面白かった。

ボカロPの制作部屋紹介やら

制作体験やら

ボーカロイドの歴史

等身大フィギュアまで。さすがにコンテンツが厚かった。

ボカロ曲のDJブース。印象的だったのはテンションすごくてグルーブ感すごいにも関わらず誰も踊ってなくてみんな延々手を振っていたこと。

これはこういうものなんだろうな。なんかクラブとかと較べて異質な感じはしたけど、感じた印象は「これはこれでアリ。」

フードコート。食べてみたかった「しげるカレー」は速攻で売り切れてた。他のもすごい行列だったので食うのを諦める。空いた時間帯でピザでも食うか。

セグウェイ試乗会。乗りたかったけど行列にダウン。

超ZUNビール。ひろゆきがめっちゃ飲んでたらしいね。

鉄道ブース。解体オークションの時は入れないくらいの人だった。さすがの盛況ぶり。

任天堂。わかってらっしゃるブース。マリオのコスプレのユーザーふつうにいたもんね。

初号機の脚組み立て中。なんかレゴマインドストームで作ってたからあとでたぶん動く。

整備してみた。延々おねえさんが整備してた。

工場っぽいものがレゴで再現されてた。ほんとどうやってつくるんだこれ。。

ニコ動の歴史

インフラの説明。仕事柄けっこう読み込んだ。

会場ブロックの間のスペースにはコスプレの人がわんさかいたんだけど、その人達が面白かった。自宅警備隊の皆さん

誰か捕まってた。

hello WORK の人。警戒任務についておられる。この人達は本職の警備員の人に紛れるとよくわからなかった。

さっきの初号機。いつのまにかだいぶ出来てた。けど時間の関係で動くトコまではみれなかった残念。

さっきの神社では結婚式がおこなわれており、

討論ブースではホリエモンが登場してた。

ダイオウイカとダイオウグソクムシから献花が。こういうネタは好き。

そろそろ時間なので帰ろうと思い会場入口まで戻ってきたら痛車が陳列されてた。午前中はまだなかったよな？もったいないシトロエン

ここまで来るとこれはこういうもんだと納得できるクオリティ。

もうなんかガチのモーターショーにもこういう一角があっていい。

痛バイク。もう清々しいですよ。

痛ブルドーザー

痛Zだがこれをみたころにはもうこれはこれでステキという感覚が芽生えてきてた。

いやほんと、わかったものもわからなかったものも量が多すぎてまとめきれない感じだった。しかしアツい。

会場回ってた途中で、「この参加者って一人ひとりが一アクセスなんだよな」と感じた。普段アクセスしているニコ動の画面の中でこれだけのユーザーが回遊しているわけである。

なるほどニコ動をリアルで再現というコンセプトを実感できた。そして今後ももっと膨らんでいくだろうという期待感も十分に得られた。

まじなんかやってみよう。
なにかこのノリに参加してみよう。

そう思える一日だった。
写真は全部Skydriveに入れてあります。

帰ってから土産物を見てみると、非常に政治色が強い内容だった。
まあある意味興味あったのはそっちだしいいか。

YeomanでフロントエンドとREST APIサーバーを同時に開発する方法

先月のHTML5など勉強会で、Yeoman超入門を発表したときに、Yeomanはフロントエンド開発専用にlocalhostサーバー立ち上げるからサーバーサイドとの同時開発はちょっと工夫がいるよね〜みたいな話題があって、参加されてたnode.jsに詳しい方からhttp-proxyつかってapiの部分リダイレクトかけたらいいよみたいな方法を教えてもらった。

なるほどそれは便利だなと思って実際書いてみたら手軽に使える感じにできたので書いておきます。ちなみに今週水曜日にGoogle Developers Liveに出演してYeomanのことを喋らせていただく機会に恵まれたので、その時の参照にも使えるかと思って。（ライブのスライドはこちら）

Yeomanは $ grunt server で開発用のWebサーバーを起動することができる。デフォルトで http://localhost:9000/ 以降ファイルをセーブするたびに自動的に画面をリロードしてくれたりしてデバッグやDesigning in the Browserな点ですごく便利。

フロントエンドのみを開発する場合はこれで十分なんだけど、JSONベースのREST APIサーバーも同時に開発している際はちょっと問題がある。フロントエンド開発用サーバーがlocalhost:9000を専有しているからREST APIサーバーを同じオリジンで立てることができない。

つまり別のオリジン例えば localhost:3000 とかで立てないといけないんだけど、そうすると同一生成元ポリシーの関係でフロントエンド側からJSONを取得したりすることができなくなる。フロントエンドとAPIサーバーを同時進行で開発というのはよくあるし、End-to-Endテストしたい場合どうすんの？とか、ちょっと問題になってくるわけです。

こういうケースの場合、上記2つのサーバーとは別にプロキシサーバーを立てて、フロントエンドからAPIサーバーへのリクエストのみを別オリジンのAPIサーバーに渡してしまおうというのが今回のお話です。まあ上記の理屈がよくわからなくても実際やってみるとなんとなく感覚がわかると思います。

以下はYeomanが使える環境が整っている前提。

まず準備から。APIサーバーをいちいち書くのがめんどくさいので今回はnode.jsのeasymockモジュールを使います。REST APIサーバーのモックアップが超簡単に立てられるやつ。これをグローバルインストールします。

$ npm install -g easymock

次にyomanでフロントエンドのスケルトンを作成します。
仮に名前を test としましょう。

$ mkdir /YOUR PROJECT DIR/test
$ cd /YOUR PROJECT DIR/test
$ yo webapp
Out of the box I include HTML5 Boilerplate, jQuery and Modernizr.
Would you like to include Twitter Bootstrap for Sass? (Y/n) y
Would you like to include RequireJS (for AMD support)? (Y/n) y

プロキシーサーバー用のnode.jsモジュール http-proxy をインストールします。

$ npm install http-proxy

次にこのディレクトリにサーバー用のディレクトリを作成します。

$ mkdir -p server/api-server/api/items

easymock用のコンフィグファイルを各ディレクトリに配置します。
まず、以下のコードを server/api-server/api/config.json という名前で配置します。
server/api-server/api/config.json

次に以下のコードを server/api-server/api/items/_get.json という名前で配置します。

ここまでできたら、server/api-serverディレクトリに移動してAPIサーバーを起動してみましょう。

$ cd server/api-server
$ easymock
Server running on http://localhost:3000
Server running on http://localhost:3000/_documentation/

サーバーが起動するのでWebブラウザで http://localhost:3000/api/items/ にアクセスしてみます。

[
  {
    "id": 1,
    "user": "john",
    "message": "hello"
  },
  {
    "id": 2,
    "user": "bob",
    "message": "Hi!"
  },
  {
    "id": 3,
    "user": "mike",
    "message": "good bye."
  }
]    

というJSONが返ってくれば正常に起動しています。違う場合はディレクトリの配置、ファイル名などが違っている場合があるので確認しましょう。

このAPIサーバーはそのまま起動しておいて、別のターミナルウィンドウを開き、プロジェクトのディレクトリに移動します。

$ cd /YOUR PROJECT DIR/test

app/index.htmlのdiv.containerブロックを以下のように変更します。

次に app/scripts/app.coffee をapp.coffeeという名前で配置します。

フロントエンド開発用のサーバーを起ち上げます。

$ grunt server

Webブラウザが自動的に開いて以下の様な画面が表示されます。

Webブラウザとwebappのサーバーをそのままにして、また別のターミナルウィンドウを開いてプロジェクト中のserverディレクトリに移動します。

 $ cd /YOUR PROJECT DIR/test/server

このserverディレクトリに proxyServer.coffee という名前で以下のコードを配置します。
proxyServer.coffee

proxyServer.coffeeを起動します。

$coffee proxyServer.coffee
Starting Server at http://localhost:8000/

localhost:8000 でプロキシサーバーが起動しました。
この状態で、Webブラウザで開いているwebapp画面のURLを http://localhost:8000/ に変更してみましょう。以下のような表示になるはずです。

最初にwebappを起動した時とちがって、リストが表示されました。これは http://localhost:8000/api/items から取得したデータです。データの取得は app.coffeeの jQuery.getJSON で行なっています。

proxyServer.coffeeで、/api のリクエストのみを http://localhost:3000 へ再リクエストしています。これによってsame originリクエストとなりajaxリクエストに対して正常にJSONが返ってくることになりました。

ちなみに、app.coffee で $.getJSON('http://localhost:3000/api/items/', ... とやってポート3000のAPIサーバーに直接リクエストを送ってみると、、、

というふうにcross originは許可されてないよと言われてデータが正常に取得できません。この場合はChrome先生がおっしゃってるようにAPIサーバでAccess-Control-Allow-OriginをHTTPヘッダに追加してレスポンスしてやる必要がありますが、開発するアプリケーションのフロントエンドとAPIサーバーが同一オリジンならばそもそもこの設定は不要です。

下手にやると脆弱性につながる危険性もあるので、上記のようにプロキシをかませる方法で開発を進めたほうがより良いんじゃないかなと思います。これだと設定も何も変えなくてもフロントエンドとAPIサーバーを本番環境にアップできるのでいいですね。

そうそう、このセットアップ以降はYeomanでのフロントエンド開発は localhost:8000 で行う。grunt で起動したポートが違うけどファイルのセーブとか監視してくれんの？と思うけど大丈夫。しっかり監視してリロードしてくれます。

ただし一度落として $ grunt server で再起動した場合は localhost:9000 で上がってくるのでもう一度手動で localhost:8000 に変更してやる必要があります。お忘れなく。

追記 2013.4.23
http://bit.ly/13r1xj5
このプロキシ使う方法を教えていただいた @kamiyam さんがもっと便利な方法を公開してくださいました。途中までやり方はいっしょだけど要のproxyの管理がgrunt taskになっていてよりスマートになってます。こちらのほうがオススメです！