Cross 2014メモ(2) 機械学習パネル、次世代Webセッション
もくじ
機械学習(後編)
参加者
- 福島さん @fukkyy
- 油井さん @myui
- 村上さん @junichi_m
- 小宮さん @komiya_atsushi
- 平手さん
- 田島さん
- 比戸さん
自己紹介・事例紹介続き
- 福島さん @ グノシー
- 比戸 @ PFI Preferred Infrastructure
パネルディスカッション
- 後半の流れ
- 導入と展望
- 精度で人間に勝てるのか
- 役立つケースとそうでないケース
- 支える技術やツールは何が有望か
- どのように導入を進めていけばいいか
機械学習導入の展望: どこから導入が進むのか
- 田島さん: 間違えてもおこられないところ。広告やリコメンデーションは多少間違えてもおこられない。広告の審査にも使っているが、薬事法に反した広告が出てはまずい。最終的には人間の判断になるが、その前段として使うと、問題の切り出しが難しい。間違ってもいいかどうかは導入のポイントのひとつ
- 平手さん: 人手で不可能とあきらめている大規模なデータでの発見などから始まっている印象がある
- 小宮さん: マーケティングでは機械学習は手段のひとつ。Webマーケティングにおいては利益追求のためのリコメンドなど。リアルマーケティングでは在庫管理などで使うことが多そう
- 村上さん: セキュリティーについては間違えてもいいという点で同意できる。機械学習の誤判定はセキュリティーにおいてはクリティカル。すぐ人間をリプレースできるという話ではない。人に対する説明が求められるので、専門家のヘルプや専門家の教育などに使える
- 油井さん: 別の軸もある。機械学習でどれだけ質のよい文例データが集められるかという面もある。CTR/CVRなど直接レベニューに効いてくるところから導入が進むだろう
- 福島さん: ようするにもうかるところ、精度が上がることが売上に直結するところで進むと思う。タスクの切りやすさ、男女予測やスパムフィルタは問題が明確であり、人手がかからないし意志決定者が問題を理解しやすい。そういう部分は進めやすい
- 福島さん: そうでない部分では、例えば広告システムでは意志決定者が理解できない部分では導入が進まない。なぜこうなるのかを広告主に説明できないと困る。人間の解釈可能なモデルが面白い
- 福島さん: やらないとわからないし、やってダメでしたも受け入れられる人が経営者にいるかどうかもポイント。仮説が感覚と合っていると使われやすいだろう
- 比戸さん: 自社サービスを社内で評価するときはやってダメでしたならいい。しかし、お金をもらって分析した結果、データに価値がありませんでしたをちゃんと報告できるかと言うと難しい。これで何%くらい出そうですかと聞かれてもやってみないで答えるのは無理
- 比戸さん: 投資対効果について
- 平手さん: ダメなものはダメだとして直さないといけない。変な画像を出してしまうとサービスの質の印象が下がってしまう。
- 田島さん: ROA的に見合いそうなところをさがしている。審査にしてもどうしても人間が見ないといけないところは難しい。機械でなんとかなるかどうかパートナーと相談するような感じ
機械学習は人間に精度で勝てるのか
- お題
- 専門家の経験とカン vs 過去データからの学習、あるいは両方を使う
- データ前処理の中に専門家の経験を生かすのはどこまで有効?
- 精度は高いが解釈できないもの vs 精度はそこそこだが解釈しやすいもの
- 田島さん: ブラックボックスでもいいから精度高くというのはなかなかない。なんでこんなの出ちゃったの、というのが現場で一番問題になる。対策打てないとどうしようもない。解釈可能なものが使いやすい
- 比戸さん: 人間が見るものを機械学習で絞り込んでおくのかな、と思いましたが、そうではないと
- 平手さん: 機械学習の結果と専門家によるマーケティングで一致する部分があるよね、という事例もあった。人間ではできなかったところを機械学習が切り拓く
- 小宮さん: 利益追求が大事。技術のほうはどうでもいい。精度は重要とはいえほどほどであって、その上で利益最大化できるのがうれしい。このリコメンドがなんでされたのか、適切なのか判断できることが精度よりも大切
- 比戸さん: CTRなど金額の大小によって誤判定のインパクトからリコメンドの活用度合を変えたりということはある? 小宮さん: ありますね
- 村上さん: 機械学習でうまくいかなかったときに、究極的にはそれを人間が正解かどうか判断できる、という前提に立っている。間違った結果を専門家が見たときに正解がどれか判断できる。セキュリティーは何に対するかで考える。人間がいなくてもうまくできますという世界になった場合、機械学習のことがわかる人がセキュリティーの専門家になるのだろう。うまくいかないときの説明可能性が大事
- 油井さん: 将棋・チェスでコンピュータが勝てるのは、いいデータがあるから。専門家の経験はデータ可が可能で、そこは対立軸ではないと思う
- 福島さん: 機械学習で勝つパターンは、トレーニングデータがいいとき。将棋やチェスは勝ちの条件が明確、かついいデータがたまっている。そういうとき人間は勝てないと思う。もうプロ棋士が負けたりしている。一方難しいのは価値判断が明確に決まらない部分
- 福島さん: モデルの解釈性で問題になるのは失敗時の説明もあるが、モデルのパラメータがチューニングにおいて、教科書的には特徴量の抽出のハイパーパラメータをやるが、実際には外れたデータが来たときにどうするかが困る
- 比戸さん: 論文レベルではデータ固定でアルゴリズムのチューニング勝負だったでしょうけど 福島さん: 企業してからはモデルを変えるよりも特徴量を変えた方がうまく効くということに気づいた。人がどういう記事が好きかどうかは曖昧なので
- 比戸さん: アカデミックな評価と実用の評価とは基準が違う。一方で新しい手法はアカデミアから来る。論文ではよさそうなのに使ってみたらダメダメということがある。これから機械学習をやってみようという人はどのように学んだらよいか
- 田島さん: 機械学習は1回でポンといいモノが入るわけではない。KPIを決めておく。売上なのかクリックなのか。それができないとプロジェクトが迷走してしまう。やりながらKPIが上がっていく、上げることを楽しむのが大事
- 油井さん: どういったアルゴリズムを適用したかなやんだとき、複数の手法で予測した結果を統合するアンサンブル学習という手法がある。データサイエンティストのコンペティションサイトで、上位の人の結果をマージしたらうまくいったという例がある。安定した結果を得られる
役立つケースとそうでないケースの違いとは
- 比戸さん: うまくいかなかった事例、他社事例でこれいい、これひどい、などあるか
- 田島さん: KPI設定の失敗は細かくいろいろある。失敗した例としては国によってマーケット規模を推定するようなこと。為替がががっと変わってモデルがダメになってしまったことがある。時間軸が短く、確実に構造が同じだよね、というところで生かせると思う
- 平手さん: よい学習データが得られるところがいいというのはある。これを抽出したい、に対してこういうのではない、ということがよくわかっているのがよい。不正検知は、こういうパターンはダメだったというのはよく上がってくるが、うまくいった例は上がってこないので難しい。正例・不例の用意が重要
- 小宮さん: 機械学習は手段という観点をくり返しますが、機械学習のアウトプットをそのまま顧客に渡すのではなく、ドメイン知識で解釈したものを出すべき
- 小宮さん: これはひどいの例: 冷蔵庫の商品ページで別の冷蔵庫を出すのはおかしい。一家に冷蔵庫は2台必要ない。冷蔵庫を買った人には同じメーカーの電子レンジをすすめるようなフィルタを入れるのがよいと思う
- 小宮さん: 購売ログではなく閲覧ログを元にリコメンドしてしまうとそういう変な例になってしまうと思われる
- 村上さん: 正常なソフトと不正なものを分離するという仕事をしているが、それは不可能なんではないかという考え方もある。ソフトウエア全体の中にマルウエアがあるとしても、その集団が全体から見ると小さい集合。それをうまく切るのはできないと考えることがたまにあります。データの性質や偏りによっては機械学習が適用できない場合もありそう
- 村上さん: ノイズのようなデータやリアルな未知のデータもある。うまくいくデータとのギャップを考える
- 油井さん: 学習データをもっとくれくれと言って集めてきても、特徴がいっぱいあってもノイズをうまく除去してくれるとは限らない。劇的な変化に対して過去のデータからの学習が予測に役立たないことがある。特徴選択というトピックで扱われる問題
- 福島さん: 問題の設定がうまくない場合もある。100個の中にスパムが1個あるときに「全部スパムではない」と答えると精度が高いと評価されてしまう。そういうミスは結構ハマりやすい
- 福島さん: リコメンドエンジンも「好きな物」がたくさんないとうまくいかない。不動産リコメンドエンジンも不動産は営業が集めてくるので、十分な数が集まらず失敗する
ツール、ソフトウエア
- 比戸さん: RとかSciPyを使っている人も、機械学習を使うといいかもしれない
次世代Webセッション プロトコル編
パネリスト
プロトコル編
- 何がおこっているのか、どこへ向かっていくのか
- Jxckさん: 去年からの1年間でプロトコルにどんなアップデートがあったのか
- Jxckさん: PRISMがプロトコルの見直しにどんな影響が
- 林さん: TLS前提になるのはあると思う。元々はOSがやるべき機能をアプリでやってると思う。layer violationについて保守的だった人達も先へ目が向いたと思う
- 吉野さん: QUICでも暗号化ができるように考えて設計している
- Jxckさん: SSLの必要性が高まっていると?
- Jxckさん: upgradeだとまだ通らないことがあるのかな?
- 吉野さん: chromiumチームが実験して、80番ポートが何をされるかわからないという話が残っている
- Jxckさん: 証明書もいろいろ攻撃されてますよね
- Jxckさん: SSL前提になるとCAと証明書の重要性がまた上がってくる?
- 林さん: CA局ビジネスがこれ以上進んで、CA局に責任が全部行ってしまうのはインターネットとしてはどうよと様子を見ている。だから日和見暗号が出てきている
- Jxckさん: 暗号化がWSSでできてdeflateが拡張でできるとして、あとはマルチプレクス?
- 吉野さん: HTTP/2.0にみんな取られちゃってWS over SPDYにする方向
- 辻川さん: SPDY上でWSをどう効率的にやるか。データフレーム内に全部隠蔽する方法がひとつ(jettyの人、ぼく)。フレームレイヤにヒントを入れる方法(グーグルの人)
- Jxckさん: deflateもできたし、HTTP/2.0を待ちつつWSをSPDYに乗せていく方向? 吉野さん: そう Jxckさん: そうするとまた同じ問題にぶつかってWS over QUICになると?
- Jxckさん: XHR2だとバイナリに行くんですかね
- 吉野さん: バイナリもひとつだけどstream使えるようにしたい。ダラダラと入力をたれ流したり
- Jxckさん: いま一番大きい問題は? 吉野さん: 技術的というよりみんなでコンセンサスを得るところ Jxckさん: 標準化作業ですか
- 辻川さん: HTTP/1.1にしても、ラストコールが起こるとみんな意見を言い始めて、そうするとみんな読んで意見言うので話が進まない
- 林さん: HTTP/1.1が早く終わって番号ついてくれないとHTTP/2からreferできなくて困るんだけど。あきらめてさっさと通せという圧力が最近やっと通ったので、同時に出たりしかねない
- 辻川さん: ヘッダ圧縮(HPACK)をどうするか細かい仕様がなかなか決まらない。ラストコールになると意見が出る
- Jxckさん: 最近はフレームの話よりセキュリティーやプロキシの話が多いんですか
- 辻川さん: フレームのpriorityが31bitくらいの整数だが、どう意味づけするかは完全に実装依存。server-clientが1対1なら問題ないが、プロキシが間に入るとpriority levelingが難しくなる。いまグーグルの人が重みつきなんとかという文書を書いているところ
- Jxckさん: 去年なんとなく話題になったのはWebRTC。IETFでも話が多かった?
- 林さん: 毎回2コマずつ、つまり1週間に4時間ずつWebRTCの話がある。1個だけ絶対に実装しないといけないコーデックを決めましょう戦争というのがあって、投票がようやく終わったはず。VP8になるかH264になるか、両方になるか
- 林さん: でも実装はみんなできてて相互接続できてるからいいじゃんという感じ。実装が先に出ていて、標準化が後という感じだと思う。少しずつインプリの調整をして、いつのまにかできてるって
- Jxckさん: それ以外のプロトコルには問題ない? 林さん: ほとんど見えている。もうスマートフォンでもちゃんとつながる状況。残る問題はカメラ使ってるときにindicationどうするとか周辺の問題
- Jxckさん: 個人で遊ぶにはNAT越えとか難しい仕様があったり 辻川さん: NAT越えはフォールバックがいくつもあって、とりあえずつながるのは面白い
- Jxckさん: NATがあるとみんななえるというか、WebRTCではNATが一番難しいんですかね
- 林さん: TURNサーバ用意したりとか、サービス提供者は考えること多いけど、ユーザー視点ではちゃんと考えられているプロトコルだと思う
- Jxckさん: WebRTCはP2Pという、今までと違うところから話が入ってきている。彼らがIETFで2時間話しているのはコーデックばっかり?
- Jxckさん: プロトコルについてはカーネルに手を入れないとできないことも出てきていると思うけど、round trip数とか輻輳制御とか
- 吉野さん: layeringは維持した方がいいって教科書的に言うけど、こわしたくなる。いろいろやってみるのがいいと思う
- 辻川さん: 流れとしてはいい
- Jxckさん: カーネルに全部入れるよりUDPに全部入れてオレオレでやったほうがいいよね、と言うとQUICはわかりやすい。オレ達のやりたいことを入れていくとQUICになるってことですかね
- Jxckさん: レイヤを見直さないといけない、そういう時期に来ている、QUICはそのひとつと考えられるわけですかね。QUICでぶっこわせそうですか
- Jxckさん: Google内ではQUIC通ってるんですか 吉野さん: まだだけど人は割いている
- Jxckさん: TCPが3way handshakeしてるからUDPで全部やってTLSやってWS通せばいいじゃんっていくと、カーネルに何か通してもらうとかしなくてもいいじゃん、って話かと思うんですが、それでみなさんいいんでしょうかね
- 辻川さん: Windowsとかモバイルとかどうなんでしょうか…
- Jxckさん: Google, Facebook, twitterとか、それがないとどうにもならない人達が使えばいいものであって、全員がHTTP2を使うべきとは作ってる方も考えていないんじゃないか
- 辻川さん: HTTP2はサーバーとクライアントが対応してくれればWebアプリはサーバーpushとか使わなければそのまま動く。QUICよりはHTTP2の方がみんなに使われるのではないかと思う
- Jxckさん: 本当に大きなトラフィックを流す人達でなくても、ちゃんと動けば使えると 辻川さん: 使うぞと思わなくても使えていると
- Jxckさん: DevOpsというチャンネルができたと思うけど読んでます? 林さん: 本当に流量がない
- 林さん: ログの記録とか何も決まっていないのに何をMLに流すのかという
- Jxckさん: 運用仕用はこなれてない中でゴリゴリやるのかな
- 林さん: 今年はやるんじゃないですかね
- Jxckさん: 来週IETFありますよね 林さん: 来週はHTTP2 Interimです。IETFは来月末。IETFではメインは暗号。多くのプロトコルでTLSを使うためのutlというWGができる。そこはもり上がっている
- 辻川さん: priorityの話はまだやらないと思う。プロキシのユースケースでうまくいかない
- 辻川さん: 今のHTTP2はSPDYを前提にしているが、はるかにうまく考えられている。SPDYは各種オプションをサーバ/クライアント間で送るが、同期の仕組がない。HTTP2では必ずACKを返すようになっていて、エラーハンドリングが厳密になる
- Jxckさん: 細かいところはともかく、動かすだけ考えるなら、そろうところはそろったなという感じ 辻川さん: そうですね。最初はfirefoxで動かなくて、ヘッダ圧縮のバグでメタメタになったりしていた。数をこなすうちよくなってきた
- Jxckさん: interopなんかで確認しながらじゃないと作れないですよね 辻川さん: ひとつのページを2度3度見てもダメで、違うページを次々見ていかないとバグが発現しなかったりして大変
- Jxckさん: 単体では日本はすごくそろっている → 林さん: クライアント/サーバー/ライブラリ全部自分で作っている辻川さんに日本語で質問できるのが、われわれ日本人にとってはうれしい
- Jxckさん: 2014どうなりますかね
- 吉野さん: WSマルチプレクスの上でAPIが使えるようになってほしい。WS APIにもっと日の目を見せてあげたい
- 辻川さん: 今年は去年に引き続きHTTP2をやっていこうと思う。HTTP1についてはわからない。WSも自前のドライバに入れていく。QUICは待ち
- 林さん: WSはブラウザ上にソケットが増えるということでブラウザの舞台が増えるということ。いいプラットフォームができて違ったプロトコル世界が見えるようになると楽しいなと思う
- Jxckさん: 実装担当と政治担当という感じで
- Jxckさん: まじめにネットワーク見始めたのは去年。QUICのねらいもわかるようになった。HTTP2も標準プロトコルとして最終的にはみんなが使えるようになるとしても、最初はHTTP1とあまりにも違うのでとまどう部分があると思う。ブログに書いたりします
次世代Webセッション アーキテクチャ編
アーキテクチャ編
- 何がおこっているのか、どこへ向かっていくのか
- Jxckさん: 前半をふまえると、TLS前提のWebを求めている人達がある程度はいるらしいとわかった。どうですか?
- Jxckさん: TLS前提のWebとなるとどう変わりますか 藤原さん: SSLは重いのでCPUがムダ、台数が増えるということはある。知らないうちに混在ページ作られちゃってギャーとか。画像だけHTTPだったり
- Jxckさん: クッキーの取り回しとかどうですか 竹馬さん: いろんなものができない前提でできているので、レイヤーができてしまうのはフロントからしても難しい。やるなら全部HTTPS化のほうがうれしい
- 田中さん: ブログやっているとSSLが増えることの影響はある。リファラに検索ワードが書き込まれなくなる。ブログへどんな導線で来たかわからなくなる。ブラウザによってリファラの飛び方の仕様も違う。ブログには外部リソースを貼る人も多くて、世の中TLS前提で進められると困る面もある
- Jxckさん: フルHTTPSはつらい? 田中さん: 何かヘッダを出すとHTTPコンテンツ入れられるんだったらいい Jxckさん: いっそ全世界がHTTPSになればいいと 田中さん: それならリファラも飛ぶし
- 藤原さん: telnetで通らなくなるとか、素人が手を出せる領域じゃなくなってくる、あたりがちょっとさびしいような
- Jxckさん: HTTPレイヤを誰もが書くわけではないので、辻川さんのような人が書いてくれるのならいいと 藤原さん: 難しいところはまかせて、その上で仕事ができるようになれば
- Jxckさん: 運用の話がまだ入ってないという点については? 藤原さん: SSLはセッションが重い。TCP張るよりSSLネゴシエーションも重いしセッションIDのマッピングとか大変
- 竹馬さん: リクエストを並行して投げたときにどれくらい失敗するのかとか。1秒が1.5秒になるのはいいが、0.1秒のものが0.5秒になるのはつらい。webゲームで顔しか表示されない、ようなネットが細くなったときの対応とか求められるのはつらい
- Jxckさん: 仕様を作ってる人達が最初に考えるのはモバイルでは1本のセッションを大事に使うという部分だろう。SSLはまた別の理由で入ってくるとは思うが、HTTP2は高速化をねらっているはずだが
- 藤原さん: WSあまり使ってないですね。数年前にサファリがプロキシ通すとクラッシュするとかあって採用できなかった
- 田中さん: はてなではWSを実際に使っている場所はない。モバイルになって必要性が増してきていて、実験したことはある。iOSアプリにSPDYのせて3G回線上でレイテンシの改善具合を見たことはある。結構使える。LINEがTLSなしでSPDYオレオレ実装していたり、ネイティブアプリでは高速なレスポンスができるようになってきた
- Jxckさん: 運用しているところはgoogleくらいしかなく、ノウハウが出てこない
- 田中さん: 今年後半では使えるようになるかな
- Jxckさん: LINEが辻川さんのライブラリ使っているというように、モバイルだと変わってくるのか
- 藤原さん: モバイルの方が環境決めうちできるのでやりやすい。先進的なことをやろうとするとネイティブでガッチリ組まないといけないのはつらい。リアルタイムが本質のものは使う必要があるだろうが、APIたたくだけのアプリならいらない
- 藤原さん: ゲームがコンソールのようなリアルタイム性を要求するようになってきたことも効いている
- 竹馬さん: ネイティブゲームだと変わってくるかというと、HTML5だといままでネイティブだったものがAPIとして出てきているので、emscriptenのようなガッツリのものが出てくる。ソーシャルゲームがリッチになってきた結果、ゲーム業界が参入してきた。Webもコンシューマゲームのようなリッチなものを作っていた人でないとリッチなものは戦えなくなるのではないか
- 竹馬さん: Webって初期化のレイヤが多い。永続化していって速くするというような、モバイルで回線が細いときの工夫がいろいろ必要になるだろう
- Jxckさん: シングルページとWebの対象ではブログがいい例だと思うが 田中さん: ツールはAngularJSで作ってみましたというのはある。スタティックなページとツールっぽいリッチなページと2分化していくのではないか
- Jxckさん: シングルページで遷移しなくなることによってJS初期化のレイヤがなくなってステート管理が大変などあると思う。運用からは結構変わるのか
- 藤原さん: 遷移しないとJSで通信するという部分が増える。ネイティブと同じでユーザーのアクションがなくても通信が発生する。リトライコードの書き方をしくじると、ブラウザ内でずっとバックグラウンドで動くことがある。堅牢に作らないとみんなが不幸に
- 藤原さん: ステータスが取れないので503を返してても無視してリトライされる場合もある
- Jxckさん: Webを作る上でここが変わったとか
- 竹馬さん: JS回りのエコシステムが充実した。去年と今年でJSでテスト回している人が増えた。ようやく開発がモダンになってきたと感じる
- 竹馬さん: IEとかAndroidブラウザとかJSのイケてないところに引っぱられていて、AltJSが流行る背景にもなっている。静的型付け言語でやっていた人にいきなりJSやれというのも無理。そのへんが変わっていくだろう
- 田中さん: JSに加えて、DevOps的な進化もある。上と下がすごく進化した。サーバーサイドアプリのレイヤーは相対的には進化しなかった Jxckさん: JSONだけ返せばいいから進化しなくてよかった
- 田中さん: シングルページだとパフォーマンス管理も難しい。サーバーで時間測ればよかったのが、クライアント側の処理が増えるとどのへんが遅いとか気づきにくくなる。Firefoxだけ遅いみたいになると方法を確立しないといけないな
- Jxckさん: ISUCONでシングルページを速くするとかなった場合にどうやって測るか 藤原さん: クライアントで何をしてから何をするまでの時間を測るような仕組を作らないとサーバー側で知り得ない
- 竹馬さん: JQueryを使っていることもあり、一度作ったDOMは使い回すとして、自分でやる分にはキャッシュ作ったりなどできるが、サーバー側のレンダリング処理の延長上でならない部分がある
- 藤原さん: 去年はWebの世界をあまり見ていなかったが、ゲームがリッチになってきて、Webやってた人が延長でやりたくなる部分、そうやると大変という部分がある Jxckさん: ゲーム部分はドキュメントベースの人が装飾でやっていると大変と
- Jxckさん: Angularなどはみんなゲームがやりたくてデータbinding入れたわけではないと思うけど 藤原さん: JSでリッチにしようと思うと職人芸。とは言えWebでやりたいという感じはある。いまは容易にできない。もう少しJSとかブラウザ型で性能が出るようになるといい
- 竹馬さん: 高速化というのは結局UXのためにどれだけ20msの中でやるかという部分であって、ユーザーに影響出ないようにインタラクティブにする以上、ゲームじゃなくても教育ソフトなどでも問題になる部分
- Jxckさん: ゲームでなくても職人芸的な部分を持っていたからできたという部分があると
- 田中さん: はてなにはそんなヘビーな部分はないが、すみずみまで知っている人がいて、安心感を持ってできている。まだしばらくは年単位で職人芸が残っていくのではないか。新しいのが出てくることを期待
- 竹馬さん: デザイナーとペアになってこれ重いですかとやっている。最低限速度を満たさないといけない部分は何msを取らないといけない。ユーザーに間を取らせるためのアニメーション遷移などはあきらめて職人芸でやるのもありかな、と
- 藤原さん: ロングpollしてるやつにリクエストが来るまでの時間を測ったり、リアルタイム通信でいかに速く返すかは少し入れたりした
- Jxckさん: いまのISUCONで勝つような人達はバックエンドのチューニングができる人達。フロントについては測定ができないのでISUCONで扱えないというような 竹馬さん: 職人芸というか定量的には測れないだろう
- 竹馬さん: 確実にボトルネックになるような部分があって、タイマーで更新されるべき部分をちゃんとできるか見るとか。モダンなブラウザは60FPSでやってると思うが1/60秒以上遅れるとユーザーは気づいてしまう
- Jxckさん: セキュリティー的にはJSで行くと抜かれちゃうという穴ができてしまうとか、そういう事例はありますか
- 田中さん: いまのところはそういうインシデントはありませんね
- Jxckさん: ダイアリーがブログになったときに問題が出ませんでしたか? 田中さん: ドメイン構造の変化によってクッキーのセキュリティーなど気を使った部分はあるが、HTML5だからどうということではない
- 藤原さん: フロントでいろいろやるようになった分、フロントで処理した数字をサーバーに送るようになって、その数字が正しいかチェックが必要になった。いわゆるゲームのチート対策
- 藤原さん: ゲームでランキングやるとチートが発生しやすい
- 竹馬さん: サーバーとクライアントで別々にバリデーションを持っているのがつらい。nodeを使って同じにできるとうれしいが今の枠組では難しい。walmatみたいにフロントサーバーを置くようなアーキテクチャが出てくるのではないか
- 藤原さん: nodeの運用については、メモリーリークがある。デーモン作るスキルのない人でもやるとできちゃうから問題。リクエスト単位で死んでもよければ多少リークしてもいいが、nodeはそういう用途では使わないので、逆に時々再起動とか残念な感じ
- Jxckさん: なんでもゲームの話になっちゃいますね。次世代Webでもゲームが求められているのかなw
- Jxckさん: シングルページのようなゲームのノウハウが必要なくらいクライアントリッチなものが書けるようになった。全部SSLとか言ってんじゃねーよ的な話が出ましたが、今年はどうなってほしいですか
- 藤原さん: HTTP2はなかなか実装が出てくれない一方、素人では作れないとなると、待つしかない。結局ビッグプレーヤーしか使えない。AWSさんがそういうレイヤを置いてくれれば使えるが、それだとつまんない#cross2014a
- 竹馬さん: MVC,MVVMとか2014年もライブラリがボンボン出ると思う。いままでのクライアントがflashでやってたような、デスクトップのフレームワークに近くなってリアルタイムJSに振られるのでは
- 田中さん: ゲームが一番のユーザーになるのかなと。PCの性能アップのときもそうだった。WSとか極めて高いリアルタイム性はゲームの方が需要が多いので、そこが牽引役になって進めてくれるとありがたい
- 田中さん: permalinkの扱いがどんどん雑になっている。その中でどうやってはてなブックマークなどでpermalink扱うにはどうするかは考えていかないと
- Jxckさん: 去年リアルタイムと言ってた部分が今日はまるまるゲームに置きかわったような気がして、Web上でもゲームの存在感強いな、と思いました。データバインドの話として去年はangularとbackboneの話がありましたがまだまだ結着はつかないですね
- Jxckさん: 「オレの考える次世代Web」についてみなさんブログに書いてください。そこまでがこのセッションです
