【js】milkcocoaを使って「見てるYoutubeの動画が勝手に同期されるページ」を作ったよ
先日、milkcocoaがパワーアップしたと聞いたので、またちょっと遊んでみました。
ただし、パワーアップした部分の機能は全く使っていませんww
milkcocoaとは
BaaS(Backend as a Service)に分類されるサービス。
Javascriptを1行書くだけで、データアクセス周りのバックエンドを肩代わりしてくれるというものです。
アクセスの方法もシンプルで分かりやすい（APIのドキュメントも結構充実してる）のと、
複数端末からの同時アクセスでもリアルタイムに同期されるのが素晴らしいです。
ほんとにビックリするくらい簡単なので、趣味プログラミングやプロトタイプ作成にはもってこいかと思います。
つくったもの
milkcocoaとYoutubeのiframe埋め込みAPIを使って、
「誰かが見ている動画を変更したら同時にアクセスしている他の人が見ている動画まで変わってしまうページ」を作りました。（プロトタイプですが）
上記からアクセスできるので、せっかくなので動画を差し替えるなりチャット欄にコメント残すなりしていただけると幸いです。
なお、正直何の役に立つのか分かりませんが、思いつくものとしては以下のような使い方が出来るかなぁと。
・何らかの作業用BGMが常に流れてるページ
動画はリピートされるようになっているので、作業用BGMとして何かの動画を流しておいて、誰かがBGMを差し替えたいなと思ったら他の人のも変わる、という使い方。
作業用BGMって、「正直何でも良い」って人も結構いると思うんですが、そういう人にとっては毎回探すのも面倒なので、誰かがセレクトした楽曲が常に流れているページ（しかも時々勝手に変わる）というのはちょっと便利かもなと。
職場とかで、「作業用BGMは欲しいけど、探すのはめんどくさい」という人が何人かいたら、これを使うといいかもしれません。
また、休憩時間を各自で勝手に決めて取っているような場合は、チャット欄でコミュニケーションが生まれるかもしれません。
・同じ動画を見ながらチャットしてコミュニケーションを楽しむページ
面白いと思った動画などをコミットして、それを見ながらチャットするという使い方。
お気に入りのお笑い動画とかを見て欲しい時の、
「あれ面白いから！URL（または検索ワード）送るから見て！」→「見たよ！面白かった」
というやりとりが1ページで完結するから、ちょっと便利かも。
上記と違って、見ながらチャットもできるし。
ただ、動画IDが連携されるだけでシークバーとかは同期されないので、全く同時に見ながらリアルタイム実況みたいなことはやりづらい。
別々の場所にいる人が映画とかアニメ見ながらリアルタイムにチャットできたら結構いいかなと思うんですが、そういう使い方にはやや不便です。
huluとかを完全に同期して見れるととても良いと思うんですけどねー。
プロトタイプには実装しなかったけどあったらいいなと思うもの
プロトタイプには付けていませんが、チャンネル機能があるといいなと思います。
ユーザー管理を付けてユーザーごとにチャンネルを持てるようにするとか、
ジャンル毎にチャンネルを作っておいて、同じ作業用BGMでもジャンルや傾向で分けておくと、
「BGMなんでもいいけど、うるさいのは集中できないから嫌」みたいなのにも対応できるので。
あとはYoutubeの動画を検索できるようにもなっていると便利、というかそれが無いと実質Youtubeと2タブ開いてないと何も出来ないのですが、
動画検索の方のAPIは埋め込みのAPIよりもややこしそうだったので実装できていません。
感想
正直何の役にも立たないものを作ったなぁと思っているのですが、何の役にも立たないものを作るのって楽しいです。
もちろんプロのえんじにゃーとしては役に立つもの、価値があるもの、メリットがあるものを作るのが当然なのですが、
趣味プログラミングで何の役にも立たないものを作るのはそれはそれですげー楽しい。
誰か一緒に趣味プログラミングしてくれる人いないかなぁ。
Youtubeのiframeの埋め込みの部分とか細かいソースの話は時間があれば今度書きます。
終わり。
【読書感想文】How Google Works を読んだ その3
How Google Worksの読書メモその3です。
その1はこちら⇒【読書感想文】How Google Works を読んだ その1 - 16bit!
※引用と個人的な感想が混合しています。ご注意ください。
五年後の自分をイメージする
まず、現在ではなく五年後の自分に取って理想の仕事を考えてみよう。どこで、何をしていたいか。（中略）たとえばその仕事を転職サイトに載せるとしたら、どんな説明になるだろう。
僕が新卒で就職活動をした約5年前には、「死ぬまでに何をしたいか」をゴールとして決めたり、「10年後にどんな人間になっていたか」を考えて逆算したりしていましたが、実際に社会人になってみると、これはちょっと無駄に長過ぎる視点だったなぁと思います。
実際数年間で自分の理想とするゴールなんてころころ変わったし、内的要因だけじゃなくて外的要因もどんどん変わる。
そんな中で10年以上先のことを決め打ちするなんて無駄だし、むしろそれに引っ張られる方がリスクがある。
そういう意味でも5年後くらいのイメージというのはギリギリ見通せる長さとしてちょうど良いと思うので、常に5年後くらいのマイルストーンを意識しながら、都度都度方向修正するのが良いような気がします。
あと、自分の仕事内容をちゃんとシンプルに言語化することっていうのも、キャリアの上では結構大事なことだなと個人的には思います。
「どこで、何を、どのくらいやっていた」という説明で、他人に「自分に何ができるのか」をイメージしてもらうことが、市場価値を見いだしてもらうためには必要なんだろうなと。
データに基づいて決定する
事例の複数形はデータである。
さまざまな選択肢や見解について議論する会議では、まずデータを見るところから始める。他の人を説得するのに「私が思うに…」という言い方はしない。「ちょっとこれを見てください」と言うのだ。
誤解を恐れずに言えば、意思決定のための情報は多ければ多いほど良いはずです。
母数が大きくなればなるほど異常値がもたらず影響が小さくなり、正しい事実に近くなるので。
確かにこれまではあまりにも多くのデータはむしろ判断を遅くする原因でもありましたが、これは技術の発達によって解消されつつあるので、「全てのデータ」を分析して意思決定に利用することが現実に可能になってきました。
これはとてもありがたいことで、少数の事例（しかも属人的な）による判断だと、どうしても主観による意思決定になりがちで、その場合、どうしても組織内でヒエラルキーの高い人間の意見が重要視されることになるのを、事例をデータとして分析することで、主観やヒエラルキーの影響を抑えられるようになる。
その結果、例えばヒエラルキーの高い人物が持っていた事例が異常値であった場合などの誤った意思決定を防ぐことができます。
ドリー
そこで「ドリー」という名前のシステムが誕生した。
これは単純に面白い仕組みだとと思ったのでメモ。
Googleの社内で利用している経営陣への質問ツールで、誰でも匿名で質問をドリーに投稿でき、社員が良い質問か悪い質問かを投票し、毎週開催される全社向けのミーティングにて、投票で上位になった質問から経営陣は答えていく、というもの。
経営陣への意見や質問を吸い上げる仕組みは色々な会社で工夫されていると思いますが、投票によって質問が決まるというこの仕組みはなかなか良いなと思います。
目安箱を透明化したみたいなシステムですが、多くの質疑応答の時間が限られている多くの場合において、この仕組みは活用できるのではないかと。
イノベーションを起こすなら、競合がひしめく市場で
イノベーションにふさわしい環境とは、たいてい急速に拡大しており、たくさんの競合企業がひしめく市場だ。（中略）からっぽな市場にはたいていそれなりの理由がある。企業の成長を維持するだけの規模がないのだ。
起業する場合のある種の定石として、大企業が手を伸ばしていないニッチな市場を狙うというのがありますが、それとは反対の考え方。
確かに、パイが小さい割に市場の変化が速かったりして割に合わないため、大企業が手を出していないニッチな市場にスピーディに参入して、臨機応変にニーズの変化にも対応することで利益を上げることはできるが、これだとどうしても企業の成長はある一定のところで止まってしまう。
逆に大きな市場だと競合も多いが、技術的イノベーションによって他社との明確な競争優位を確率できれば得られるものも大きいし、企業もかなり大きなところまで成長できる。
「目を付ける速さ」で勝負するにはよくない市場ですが、前のパートで述べたみたいに、技術的アイデアに基づくイノベーションで勝負するなら、既存のパイが大きな市場ほどチャンスが大きいということになる。
また、ちょっと話は変わりますが、最近のWEBサービスやスマートフォンアプリとかを見ていても、「これはちょっと便利になるな」とは思うのですが、「これはものすごく便利だな！」というものはあんまり無いよなぁと感じています。
ニッチなところを狙っていたり、かゆいところに手が届いていたりはするのですが、やはりそれだけだと既存の競合を駆逐してしまえるようなインパクトは無くて、「ちょっと便利」ばっかりが起こっているのが個人的にはもにゃっとします。
アイデアの自然淘汰（ダーウィンの進化論）
とても生き残れないほど多くの「アイデア」が生まれる。その結果、生存のための闘いが繰り返される、複雑で、ときには変化する状況においては、たとえわずかでも自己保存に適した変化を遂げた「アイデア」ほど生き残る可能性が高まり、自然選択される。
上記はダーウィンの『種の起源』の一説を、「アイデアの自然淘汰」に書き換えたもので、「たくさん生まれたアイデアの内、環境に適した進化を遂げたものがイノベーションへと辿り着く」ということを表している。
アイデアは生まれた時点ではちょっとした単発の改善でしかないので、それが進化していって大きなイノベーションにつながるという考え方は割としっくりきます。
つまりアイデアはなるべく多く、それこそ淘汰されること（＝失敗すること）を前提として出てくる必要があり、そういう意味では全ての社員に、アイデアを発信し、他者を巻き込んでも良いだけの自由と権限、そして失敗を許される権利を与えることが必要になります。
さらに言えば、アイデアの優劣を決めるのは純粋な自然淘汰によってなされるべきで、誰のアイデアかといった政治的な要因に影響されてはいけない。
これらは全て企業文化によってもたらされるもので、したがってイノベーションというものは一朝一夕では成せないということになりますね。
//
その3はここまで。
長さとメモしたいことの数的にはあと1つで終わる予定です。
書き留めておきたいことがたくさんあって長くなっていますが、基本的には自分宛の読書メモが主目的なので、まぁいいかな。
いったんおわり。
【読書感想文】How Google Works を読んだ その2
How Google Worksの読書メモその2です。
バタバタしててその1からだいぶ間が空いてしまいました。
その1⇒【読書感想文】How Google Works を読んだ その1 - 16bit!
その3⇒まだです。
※引用と個人的な感想が混合しています。ご注意ください。
プロダクトはユーザーのために
なぜ（テレビのリモコンの）「ミュート」ボタンはあんなに小さいのに、「オンデマンド」ボタンは大きくて、しかも目立つ色になっているのか？それはオンデマンド事業部には達成すべきノルマがある一方、ユーザーがCMをミュートにしても誰の給料も増えないからだ。
2012年に開始した「ナレッジグラフ」は、検索した人物、場所、物事に関する情報をアルゴリズムによって簡潔にまとめ、検索結果ページの右上に表示する機能だ。（中略）ほとんどの検索語の場合、これまで広告が表示されていた場所に、代わりにナレッジグラフが入ることになった。これはグーグルの収益に多少マイナスの影響を与えた。
1つ目の引用が利益を中心に考えた一般的（？）なプロダクトデザイン、2つ目の引用がGoogleのプロダクトデザインについての具体例です。
「ユーザー（お客様）のことを第一に考える」と言葉でいうのは簡単ですが、その機能をリリースすれば収益が下がることがほぼ確実であってもユーザーにとって便利な機能をリリースするという、こんなことを実際にやれる企業はほとんどないんじゃないかと思います。
しかもこれは別にボランティアであっているわけではなくて、たとえ一時的に利益が下がっても、ユーザー第一でプロダクトを作り続けていれば、必ず後からペイすると確信していることがすごい。
「すごいサービスでしょ！しかも無料だよ！1円も儲けないよ！」ではないんですよね。
「必要不可欠な人間」を作らない
誰かが自分は会社の成功に書かせない存在なので、1〜2週間も休暇を取ったらとんでもないことになる、と思っているなら、かなり深刻な問題があるサインだ。必要不可欠な人間などいるべきではないし、またそんなことはあり得ない。
これって本当にそうで、仕事でものすごく重要なポジションをやっている人が1週間休んだところで意外とまわるし、そのために企業という組織はある。
逆に本当にある人が抜けるだけでチームがまわらなくなるとしたら、それはすごく不健全な組織だと思う。
レアルマドリードはロナウドが抜けてもレアルの試合ができるし、バルセロナからメッシが抜けてもバルサの試合ができる（もちろん多少レベルは下がるが）。
これが健全な組織だと思う。
逆にスアレスが抜けて全然点が取れなくなったリバプールはきっと健全な組織ではなかったんだと思う。
「必要不可欠な人間」になることが雇用の安定につながるといった謝った認識のために、わざとそういう状況を作り出そうとする人もいる。
これも個人的には本当に逆だと思っていて、変な話、「自分にしかできないこと」を増やせば増やすほど、自分は新しいことができなくなって、いつまでもその仕事しかできないしやらせてもらえないので、いつか誰かがその仕事をやれるようになったり、その仕事自体が不要になったりしたら、自分にしかできないことはなくなり、さらに自分には他には何もできないので、むしろ要らない人間になってしまう。
自分の価値を高めたければ、自分ができるようになったことはさっさと他の人にもできるようにしてしまって引き継ぎ、自分は次のことをやった方が良いと思う。
その方が組織も個人もハッピーになる。
技術的アイデアに賭ける
たいていの企業ではプロダクト計画を立てるのはプロダクト・リーダーだが、彼らの立てる計画には最も重要な要素が欠けていることが多い。それは、新たな機能、プロダクト、あるいはプラットフォームの出発点となる技術的アイデアは何か、である。
正直、この発想でプロダクト計画を立てている企業はほとんどないんじゃないかと思います。
たいていの企業の発想は、「問題があって、それを解決するために技術がある」なので、技術を始点に戦略を立てることはあまりない。
ただ、これも（Googleの成功の影響なのか）最近は変わってきていて、
「自社には○○の領域における優れた技術があるが、これを活かしたプロダクト計画とは何だろう？」という考え方をする企業も増えてきているとのこと。
確かに技術を起点にしたプロダクトは、他社が容易に真似できないものになるので、成功すればしばらくブルーオーシャンでいられるという大きな利点がありますからね。
ロナルド・コースの考え
ベンダーを探し、条件交渉をし、きちんと業務が遂行されるように監視するコストは高いため、企業にとって業務を外部に任せるより、内製化したほうが合理的な場合が多い。（中略）「企業は、社内で新たな取引を組織するコストが、同じ取引を自由市場での交換のかたちで実行する場合のコスト、あるいは別の会社との間で組織するコストと一致するまで拡大する」
インターネットによって取引コストが劇的に低下したため、コースの法則は逆から読んだ方が良くなった。（中略）企業は社内で取引をするコストが、社外と取引するコストを超えないようになるまで規模を縮小すべきだ。
単純な費用対効果の話なのですが、この考えはわかりやすくてとても良いなと思います。
ただ、これは不採算部門を廃止して、より安いところにアウトソーシングしてコストを抑えよう、というのが本来の目的ではなく、「自社でこんなことをしたい、そのためには○○をするための組織が必要だ」が出発点なので、そこを間違えるとただのコストカット、規模の縮小だけになってしまう。
本当の利点は、インターネットによって「餅は餅屋」が安価に実現できるようになったことなので、本来は規模の縮小によるコストカットという守りの戦略ではなく、専門企業とのコラボレーションという攻めの戦略であるべきです。
ライバル企業に追随しない
「ぼくの重要な仕事は、社員にライバル企業のことを考えさせないようにすることだ。一般的に、人は既にあるモノのことを考えがちだ。ぼくらの仕事は、まだ考えてみたことも無いけれど、本当に必要なものを思いつくことだ。ライバルがそれを知っていたとしても、当然ぼくらには教えてくれないからね」
ライバル企業の方を見ていても良いものはできないというのはその通りで、結局はただ表面的にコピーしたものを（しかも後追いで）出すことになってしまう。
如何にライバルのことを模倣せず、自分たちでものを考えられるかが、プロダクトを開発する上では重要です。
ちょっと話がずれますが、古川日出男という作家さんの「聖家族」という小説があるのですが、その作品がライバル視したのは「サグラダ・ファミリア」だそうです。
ちょっとよく意味がわかりませんが、すぐ隣にいる競合企業をライバル視するのではなく、全く関係なさそうなものをライバル視するというのはありかもしれません。
これがマイケル・ポーターの5つの力*1とは異なる発想なのか、それとも「代替品」のところにサグラダ・ファミリアが入るのかは分かりませんが、少なくとも表面的なコピーはできないので、本質を考えるしかないという意味では、1つ面白い思考法だなと思います。
人材の採用が最も重要な仕事
大企業の幹部に、「あなたの仕事のうち、一番重要なものは？」と尋ねると、ほとんどの人が反射的に「会議に出ること」と答えるはずだ。（中略）同じ質問を一流のスポーツチームのコーチやゼネラルマネージャーにしたらどうだろう？（中略）「最高のプレイヤーをドラフトで獲得するか、スカウトするか、あるいはトレードで持ってくること」と答えるだろう。
「採用が最も重要な仕事」だとか「人材が最も重要な資産」という言葉はいろんな企業で言われていますが、それが本当に文化や仕組みとして実現できている企業はほとんど無いように思われます。
僕も今働いている会社で、プロダクト開発の合間を縫って一度だけ採用プロセスに関わったことがあったのですが、その採用活動の部分って、業務の成果としてはほとんど認められない。
僕の場合は別に採用活動の成果を評価してもらいたいとは思っていなかったのでモチベーションとしても特に問題はなかったのですが、
本当に採用が最も重要な仕事なら、採用に関わる活動をちゃんと評価する仕組みが必要なのではないかと感じました。
ラーニング・アニマル
大切なのは優秀な人が「何を知っているか」ではなく、「これから何を学ぶか」だ。
書いてあることはすごくシンプルで、要するに学び続けることのできる人間は変化に対応できるし、むしろ変化を楽しもうとするので、変化が激しい時代においては貴重な人材である、ということなんですが、単純に「ラーニング・アニマル」っていう言葉がキャッチーで良いなと思ったのでメモしておきます。
これは「Aという仕事があるので、Aの経験がある人をアサインしよう」という組織のマネジメントが間違いであることを表しているし、「自分はBの経験があるから、Bをやるところで働こう」という個人の選択が間違いであることも表している。
自分が自分の経験と既存の知識で生きて行こうという判断をしそうになったら、この単語を思い出そうと思います。
その2はここまで。
だいたい全体の半分くらいなので、その4くらいまで書くことありそうです・・・。
一旦終わり。
【読書感想文】How Google Works を読んだ その1
今年は小説もちゃんと読む年にしようということで、ここ最近はずっと友達に借りた戯言シリーズ*1を読んでいたんですが、
息抜きにビジネス書も読みたくなったのでタイトルだけみて買って読みました。
「働き方の本かな？」と思って買ったけど、中身は割とマネジメント寄りの本でした。
が、Googleのエピソードとかもちょこちょこ載ってて、ニヤッとできるし面白かったです。
以下感想と読書メモ。
※引用と要約と個人的な意見が混在しているのでご注意ください。
「計画なんて何のためにあるんだい？」
「担当チームが計画を前倒しで達成したなんて例を聞いたことがあるかい？」
「君の部下たちが、計画を超えるプロダクトを仕上げたことがあるかい？」
「じゃあ、計画なんて何のためにあるんだい？」
ジョナサン・ローゼンバーグ*2が入社間もない頃、綿密なプロダクト計画書を作成してラリー・ペイジに提出した際に言われたこと。
目的は計画通りに進めることではなく、優れたプロダクトを作ることなので、計画そのものが目的であってはならない。
ガチガチに管理しても計画当初に計画を作った人が考えたレベルのものしかできない。しかも期限ギリギリまでかかって。
計画を立てる人間が圧倒的に優れていて、未来に渡って全てを見通せるくらいの能力を持っているならメンバーを管理することに意味はあるが、凡人（Googleのプロダクトマネージャですらそうらしい）ならメンバーには自由と権限を与えた方がより良いものができる、とのこと。
また、「計画」という単語ではもう1つエピソードが。
「そうだな、計画ではリリースはあと数週間先ということになっているから、もう少しテストをして、完璧を期してはどうだろう」
「なるほど。でも計画以外に、いますぐリリースできない理由はあるの？」
計画通りであることは目的ではないよという話。
マーケティング < プロダクト
いまや企業の成功に最も重要な要素はプロダクトの優位性になった。
古い世界では持てる時間の30％を優れたプロダクトの開発に、70％をそれがどれほどすばらしいプロダクトか吹聴してまわるのに充てていた。それが新たな世界では逆転した。
いろんなところで言われていることですが、インターネットのおかげで消費者は多くの情報に簡単にアクセスできるようになり、またその発言力もあがったため、
大事なのはプロダクトがすばらしいものであることを宣伝することではなく、すばらしいものであると消費者自身に宣伝してもらうことになっていると思います。
奴隷労働なしで
インターネットの世紀は、未建設のピラミッドであふれている。さあ、とりかかろうじゃないか。
しかも今回は、奴隷労働なしで。
この「奴隷労働なしで」というフレーズがとても好きです。
本書とは全然関係ない話だけど、人間の代わりにコンピュータに働いてもらうのがITのひとつの可能性なわけで、さらに言えば、働く上で大事なことは、「自分よりも優秀な人間にいかに動いてもらうか」であるわけで、そういう意味では、優れた人工知能に働いてもらうのが理想なんだよなぁ、ということを、最近ちょっと考えたりしています。
戯言読み終わったら次に読みたい本。
企業理念・企業文化
（企業文化を）表現する文言を変えたら何が起こるか、想像してみることだ。
たとえば「敬意、誠実さ、コミュニケーション、卓越性」を「強欲、強欲、カネへの渇望、強欲」に変えたとしたら・・・
個人的には、企業理念って大事だなと思います。
何を一番大事にしているのか、どこを向いているのか。
具体的で、全ての従業員にちゃんと浸透していること。
グーグルの場合は「ユーザー」を一番大事にしていて、これを「広告主」に変えたら暴動が起こるだろうと本書には書かれていますが、ただの美辞麗句で、「理念は立派だけど、実際には全然そうなってないよねーw」と従業員が言っているようなら、そんな理念に意味はないなぁと。
独立採算にしない
組織を事業部、あるいはプロダクトライン別にすると、それぞれの事業部が自分のことだけを考えるようになり、情報や人の自由な流れが阻害される。
独立採算制は、各事業部の実績を測るのに都合が良さそうだが、人々の行動を歪めるという好ましくない副作用が生じるリスクがある。
グーグルが新事業を立ち上げる際、それがどのくらい利益を上げるかについてはとりあえず何も考えない、というのは有名な話ですが、
広告収入であげている利益を、利益が出るかどうかなんて考えてもいない新規事業に回せるのは、ひとえに独立採算にしていないからだよなぁと思います*3。
ただこれは、お金を稼ぐことや報酬を上げることが重視されていない企業文化があって初めて実現できることだという気もするので、ある意味では潤沢な資金があることが前提になっている。
一方、世の中の困っている会社の多くはお金がないから困っているのであって、お金がない時の解決策として、「組織改編して独立採算をやめます！」というのは難しそう。
なお、独立採算制と多少関係のある話ですが、本書では、「マネージャは異動させるメンバーを選ぶ時、優秀な人間を残そうとし、凡庸なメンバーを放出しようとする」という話を上げ、それはそのチームにとっては好都合かもしれないが、会社全体から見ればマイナスだと書いている。
これも独立採算の弊害のひとつですね。
ひとまずここまで。
その1だけ書いてみた感じだと、ボリューム的にはたぶんその3くらいまでかかりそうです。
おわり。
【js】milkcocoaを使って作ったゲームをGithhub Pagesで公開したよ
先日、milkcocoaというサービスを見つけまして、それが非常に簡単で面白そうだったので遊んでみました。
milkcocoaとは
BaaS(Backend as a Service)に分類されるサービス。
Javascriptを1行書くだけで、データアクセス周りのバックエンドを肩代わりしてくれるというものです。
アクセスの方法もシンプルで分かりやすい（APIのドキュメントも結構充実してる）のと、
複数端末からの同時アクセスでもリアルタイムに同期されるのが素晴らしいです。
つくったもの
『ミリオンまおう』というゲーム（？）を作り、Github Pagesで公開しました。*1
HPが100万ある『ミリオンまおう』を、みんなで協力してやっつけるゲームです。
Androidアプリ『100万のタマゴ』のパクリにインスパイアされています。
因みにGithub Pagesで何かを公開したのも初めてだったのですが、これも非常に簡単でとても良いですね。
基本的には静的ページしか作れませんが、milkcocoa等を使えばそれなりに動的にできるし。
なお、他の人が攻撃した内容も自分の画面に表示される（ここがリアルタイム通信）のですが、
HPが0になった時に表示される「ミリオンまおうをやっつけた！」という文章は、その時に通信していた人にしか表示されないのでなかなかレアです。
倒した後になってアクセスしても、「ミリオンまおうはすでに滅びた」みたいなメッセージしか出ないので。
アルゴリズム弱者のソース晒し
データアクセス周りはものすごく簡単に実装できるのですが、僕の頭がおかしかったせいで、『ミリオンまおう』は実は既に2回も修正されてます。
当初
//画面起動時の読込部分 query.limit(1000000); query.done(function(data) { var count = 0; for (var i=0; i<data.length; i++) { count++; } remain = 1000000 - count; txtCount.innerHTML=String(remain); });
最初は、ダメージを与える度にデータをpushして、そのcountでこれまでに与えたダメージを測るというアルゴリズムでした。
が、データが10万件を超えたあたりから最初の読み込みに時間がかかりすぎるようになってきたので、
データにその時の残HPを持たせ、最新の1件だけ読み込めば良いようにしたのが1回目の修正。
1回目修正後
//画面起動時の読込部分 query.sort(desc).limit(1); query.done(function(data) { data.forEach(function(value) { remain = Number(value.hp); }); txtCount.innerHTML=String(remain); }); //データのpush部分 dataStore.push({name : pName, hp : String(remain-1)}, function(data){ console.log("送信OK!"); );
データに値を複数持たせたい時も、カンマ区切りで書けば良いだけなので簡単です。
しかしこの修正の後、「そもそも100万件分もデータを保存したら、フリープランの容量をオーバーする」ということが判明。
よって、pushでどんどんデータを積むのではなく、setを使ってデータを使い回すように修正しました。
2回目修正後
//画面起動時の読込部分 query.sort(desc).limit(1); query.done(function(data) { data.forEach(function(value) { maoId = value.id; remain = Number(value.hp); }); txtCount.innerHTML=String(remain); }); //こうげき function attack(){ if (remain > 0) { if (maoId.length == 0) { dataStore.push({name : pName, hp : String(remain-1)}, function(data){ console.log("送信OK!"); maoId = data.id; }); } else { dataStore.set(maoId, {name : pName, hp : String(remain-1)}); } } else { … } }
既にダメージを与えている場合はデータを使い回すようにしたので、データが1件で済むようになりました。
当初は「データを積んでおけば後々ダメージ数ランキングとかも実装できるな」とかも考えたんですが、
動かないことにはどうしようも無いので。
ランキング実装したくなったらユーザー毎にデータ作って、「これまでにそのユーザーが与えたダメージ」を持つようにしよう。
また、ランキングの他には「コンソール部分を使って普通にチャットもできるように」とかも考えてました。
が、とりあえずリアルタイム通信が簡単にできることを試したかっただけなので、ひとまずカット。
ミニマルデザインです。
感想
これだけ簡単にリアルタイム通信のアプリケーションが作れるというのはすごいなぁと。
ただ、
http://www.appiaries.com/jp/baas/
http://e-words.jp/w/BaaS.html
サービス終了のお知らせ - NAVER まとめ
この辺にも書かれてますが、Baasが一番必要なのはモバイルかなという気がするので、
milkcocoaも早くandroidに対応して欲しいなと思いました。
android対応したらユーザー管理とランキング機能とチャット機能付けてアプリ作ろ。
終わり。
*1:画像は星乃だーつ グーテンベルグの娘より拝借いたしました。ありがとうございます。
