ぱろっと・すたじお

技術メモなどをまったりと / my site : http://parrot-studio.com/

「女子大生とペアプロ問題」の言語別通過率を分析してみる

Ruby はてブ POH

先日私も参加した「女子大生とペアプロするだけのの簡単なお仕事」ですが、
最終的な結果がBlogで公開されました

【結果発表】女子大生プログラマの心を鷲掴みにした最強のコード8選 - paiza開発日誌

これの言語別通過率が興味深かったので、
もうちょっと突っ込んだ分析がしてみたくて、
通過率をグラフ化してみました(´･ω･)っ



ここからいろいろなことがわかると思いますが、
まずはTwitter上でいくつか挙げてみたのをメモっておきます


大前提として、「最速」はある一人のエンジニアにより達成されるものですが、
「通過率」は統計的な値であり、言語に関わるエンジニアの傾向を、
ある程度表していると推測されます

もちろん大前提として、以下の要因を満たす人の範囲で、ですが

  • 「エンジニア」である
    • プロかアマかは無関係ですが、おそらくはプロが多かったのではと
  • この手のチャレンジ的なものに興味がある
  • あの仕様を理解し、何らかのコードに落とし込めるスキルがある
    • 理解できないのであれば、コードが書けない or 通らないはず

それをふまえた上で、私が仕事で使ったことがある言語の範囲で
いろいろ推測してみますと・・・

Javaは言うまでもなく、業務系のシステムでよく使われる言語です
言い換えれば、フレームワークに乗せて終わり、といった
単純な開発は少ないと思われます

一方、Rubyを含めたWeb系言語は、
比較的フレームワーク上で完結してしまうケースが多く、
特にRubyはRailsの出来が良すぎる*1ため、そこに特化している人が少なくないのではと

今回の問題は、純粋にアルゴリズムとチューニングを要求される問題であり、
「独自の仕組み」を自分で考えないといけません

また、Web系システムにおけるチューニングがフロントエンド主眼だとすると、
業務系システムのチューニングは大規模データに対するものが多いでしょう

それこそ、TwitterはフロントエンドこそRubyですが、
バックエンドはScalaで書かれている*2わけですし、
言語にはやはり得意分野があります

あくまでこのキャンペーンに挑戦した人達の範囲で考えたとしても、
RubyのエンジニアよりもJavaエンジニアの方が、
大規模データに対する問題解決とチューニングに慣れている、ということかもしれません

ただし、今回の問題でJavaはC等と同じコンパイル系言語として扱われていますし、
スクリプト言語であるRuby等に比べると、
チューニングのやりやすさで優位、という側面もあるかとは思います

実際の開発においても、Ruby等で無理矢理チューニングするよりも、
バックエンドはJavaという事例が多くなり、
Rubyにおけるチューニングノウハウが浅い、という可能性はあるかもしれません

あと、個人的に気になるのはPHPです

どうもPHPが揶揄される傾向にありますが、
「エンジニアではない人をエンジニア視点で評価している」だけな気がしていて、
「PHPエンジニア」のレベルはある意味「他と変わらない分布」*3なのではと思っています

実際、今回の結果を見る限り、RubyよりもPHPの方がむしろ好成績なわけで、
PHPがWebフロントエンドだけでなく、バックエンドでも使われており、
バックエンドのエンジニアのレベル分布は他の言語とそう変わらない、ということかと*4

なお、今回一番勉強になったのは、
この手の問題を解くためのアルゴリズムが存在していたことですΣ(・ω・ノ)ノ

いもす法 - いもす研 (imos laboratory)

最速のコードはこれをふまえてチューニングされていたわけですが、
これを知らないまま独自にCase7を突破できたことは、
それなりに価値があったと信じたい・・・・・・(´･ω･`)

*1: しかも、追加で何か要求があったとしても、gemを追加すれば解決してしまうという、優秀なエコシステムもありますね

*2: 以前はそうだったはずですが、今はどうなんですかね・・・(´-ω-)

*3: スーパーエンジニアもいれば、普通の人もたくさんいるという、当たり前の構図

*4: 実際、私がPHPで仕事をしていた時は、バックエンドもPHPでしたし、一方でJavaを使ったりもしていました

「女子大生とペアプロするだけの簡単なお仕事」でSSSをとるまでに考えたこと

Ruby POH

今回で二回目になる「POH!」

女子大生とペアプロするだけの簡単なお仕事です！｜paizaオンラインハッカソンVol.2

前回*1は「合理的かつきれいに書けば通る」ってレベルだったのですが、
少なくとも私の（わりと雑な）プログラミングレベルだと、
今回は相当突き詰めないと難しかったのです

せっかく苦労して解いたので、自分の中でも一度整理しておきたいので、
思考の過程を思い出せる範囲でメモしてみます...φ(･ω･｀)

まずは仕様通りに書く

問題を大雑把に整理すると、「あるサイズのオブジェクトが、
既存のオブジェクトと衝突しない座標の数を求めよ」ということです

言い換えれば、「オブジェクトを各座標ごとに動かしながら、
オブジェクトの範囲に何か障害物があるか？」ということになります

これを馬鹿正直に実装したのがこちら(´･ω･)っ

あらかじめ各座標に「オブジェクトがあるか？」を入れておき、
座標を動かしながら、オブジェクトの範囲を探索する、という方法です
これでもcase4までをパスしています

全部埋まっている行は調べるだけ無駄だよね・・・？

サイトにある「入力例1」を見てもらえばわかるのですが、
4行目から7行目は「1」で埋まっている、つまり探索するだけ無駄です

それをふまえて実装したのがこちらですが・・・

・・・大差はありません(´-ω-)

データ構造に情報を畳み込もう

最初のやり方の問題は、各座標における探索回数が、
「縦×横」、つまりは「O(n^2)」になっていることです

これを「座標個×オブジェクト数」繰り返すとなると、
相当に無駄が含まれます

そこで、あらかじめ「横にいくつ空いているか？」を計算しておく、手を思いつきました

元データ
1000
1101
1001

計算後データ
0321
0010
0210

こうすると、ある座標を見ただけで、
そこに横幅いくつのオブジェクトが入るかすぐわかるので、
縦方向の探索だけで衝突判定できますヽ(`･ω･´)ノ

この構造を起点に、いろいろな計算回数の無駄を省いたのがこちら

これでcase5を突破しました

縦も考えてみる・・・？

元のデータが「横軸のデータを縦に向かって読む」という構造だったため、
どうしても横ばかり考えてしまいましたが、
状況によっては「縦軸の方が効率がよい」場合があります

縦に向かって探索する場合、「横2×縦100」のオブジェクトに対し、
最悪100回の衝突判定が必要ですが、
これを横に向かって探索すれば2回で終わります

なので、「縦にいくつ空いているか？」のデータも計算しておき、
「縦か横で計算回数が少なくなる方」で判定していけば、
計算量を減らせるのではと推測しました

まあ、あまり効果がなかったんですけどねΣ(・ω・ノ)ノ

盤面じゃなく、チェックするオブジェクトの問題じゃない・・・？

ここまでやっていまいちな成果しか得られなかったので、
別なところにボトルネックがあると推測しました

例えば、盤面のサイズが普通であったとしても、
チェックする対象が1万件あり、しかもそれが「2x2」の同じサイズなんて場合、
いちど計算すればあとの9999件は同じ値を出せばいいのです

つまり、「メモ化」しろと(`･ω･´)

ver2とver3に対し、それぞれ「結果を記録」するロジックを入れたところ、
たいして変わらなかったので、複雑化していたver3を破棄し、
ver2をメモ化したものをベースに進めることに

最終的にはメモ化というより「存在するパターンだけ調べる」に変わり、
ついでにコードも整理してみたのですが、やっぱりいまいちですね(´-ω-)

まだチェックするオブジェクトに無駄があるよね・・・？

盤面より大きなオブジェクトは排除するにしても、
もっと細かいレベルでオブジェクトを排除できないかと考えました

縦と横の空きデータを作る時点で、
「縦横それぞれこのサイズまでしか入らない」というのはわかるので、
それを元に弾いてしまえばいいのではと

ずっと壁になっていた、case6をついに突破しましたヽ(`･ω･´)ノ

さらに、「ある横幅を基準に考えて、縦幅を小さい順に探査したときに、
ある高さで答えが0ならば、それ以降の縦幅を計算するのは無駄」と気づきました

つまり、「横2×縦3」のオブジェクトが入らない状況で、
「横2×縦4」のオブジェクトは絶対に入りません
そこを削ればいいのではと

case6突破時点の11sから8sに縮まりました（ ﾟдﾟ）o彡ﾟ

そして深淵へ・・・

ここからはひたすら細かいチューニングを繰り返しました
オブジェクトの生成を抑えてみたり、
最終的には足し算の回数まで気にしてみたりΣ(ﾟДﾟ)ｶﾞｰﾝ

case6で4sまで縮まったものの、ここで完全に行き詰まりました・・・(´-ω-)

ちゃんと調べてみる

ここでいったん立ち止まり、わかっている問題を整理してみました

  • ループが多い
    • もっと単純な探査ができないか？
    • つまり、「計算する次元」を落とせないか？
  • データ構造が複雑
    • 構造が複雑だから、探査に時間がかかる

「衝突」という言葉を使っていますが、
ここまでくるとまさに、ゲームの当たり判定の話だと思いまして、
こちらの本の衝突判定をじっくり読んでみました

ゲームプログラマになる前に覚えておきたい技術

ゲームプログラマになる前に覚えておきたい技術

2次元を1次元ベクトルに落とし込む方法とか、
いろいろ書いてありまして、これをふまえて実装してみたのですが、
case4以降でエラーになってしまいました(´･ω･`)

1行の判定を1回の計算で済ませる

「効率の良い衝突判定」を調べていくうちに、ふと思い当たるものがありました
「bit演算でええやん」、とΣ(ﾟДﾟ)ｶﾞｰﾝ

b：盤面のある行
o：オブジェクトのある行

b:1001
o:0011
b & o = not 0 => 衝突

b:1001
o:0110
b & o = 0 => OK

b:1001
o:1100
b & o = not 0 => 衝突

このように、例えば「幅2」を表すbit列をずらしながら、
その列のbitパターンとand演算を行い、
「0」になるか否かという、実にシンプルな判定になります

データの構築もただのArrayになりますし、
判定ラインも横に対してのみ考えれば良くなります

さらに、横のパターンだけ「オブジェクト列に存在する値」にしつつ、
縦の探索方法を変えました

「何回連続して衝突しなかったか？」＝「そこに入る最大の縦サイズ」であり、
それより小さいものは全て入るはずです

コードの動きを具体的に書いてみますと・・・

盤面
1000
1001
1101
0001

探査するパターン
0110

1行目
1000 & 0110 => 0

counter += 1
h[1] = 1

2行目
1001 & 0110 => 0


counter += 1
h[1] = 2
h[2] = 1 

3行目
1101 & 0110 => not 0


counter = 0
h[1] = 2
h[2] = 1  


4行目
0001 & 0110 => 0 

counter += 1
h[1] = 3
h[2] = 1  

=> 横2×縦1は3個、横2×縦2は1個入る

普段bit演算は使わないというか、個人的に苦手なので避けていたので、
これに思い当たるまでにだいぶ遠回りしましたね・・・(´-ω-)

そんなわけで、無事に全てのTest caseを突破しました∠( ﾟдﾟ)／

一応まとめ

ご覧の通り、最終的なコードはver5までと比較にならないほどシンプルです
やはり、効率の良いコードはシンプルに落ち着くのだと思います *2


for "https://paiza.jp/poh/paizen"


普段、ここまでチューニングを要求されるシステムは担当してませんし、
どちらかといえば可読性を優先してコードを書いているつもりですが、
たまにはこういうコードも面白いですね

次回も期待しています(`･ω･´)ノ

追記

どうも判定には「S」どころか「SS」や「SSS」もあるそうなのですが、
個人的には「S」だけ取れれば十分です(((((( ;ﾟДﾟ)))))

さらに追記

ちょっといじったら「SSS」に・・・(；　д )　ﾟ　ﾟ

カウントアップのところって、
カウンタがリセットされるときで十分だよな・・・と思っただけなのですが

つまり、カウンタが3まで行ってリセットされるとすると、
縦1は+3、縦2は+2、縦3は+1・・・となっているはずです

そのように数行書き換えただけなのですが、
それでカウントアップの計算回数が劇的に変わったと思われます

*1: 前回のコードと結果はこちら(´･ω･)っ https://gist.github.com/parrot-studio/7763295

*2: とはいえ、それは「結果」なのであって、最初から効率の良いコードが書ければいいのですが、普通はそこまで簡単ではありません。だからこそ、思考の過程を残しておくことで、「次回」に生かせるのではないかと。（Gitのような）「コード管理」についても、「履歴」という「思考の過程」を残せることが、重要なメリットだと思っています

Rails4.0のアプリをRails4.1に移行したときのメモ

Ruby Rails

先日、めでたくRails4.1がリリースされ、
新しい機能が追加されました(`･ω･´)

Ruby on Rails 4.1 Release Notes — Ruby on Rails Guides

いくつかの機能は自前で実装していたので、
公式に実装されたのは実にありがたいことです

そこで、早速私も手持ちの「Gagnrath」を4.1に対応させることに(`･ω･´)

メジャーバージョンアップではないので、
app/ 以下のアプリ本体には影響がないと思われる一方、
新機能向けにconfigが修正されていることは予測できました

そこで、Gemfileで4.1を指定してUpgradeするのではなく、
“rails new”して新しいプロジェクトを作り、
差分を見ながら移行してみることに...φ(･ω･｀)

実際にどう変わったかというのは、
以下のcommitを見てもらえばいいのですが、
大雑把に気づいた点だけメモしておきます

https://github.com/parrot-studio/gagnrath/commit/5b035a012cfa6c1092037b73c680cbcaa7e08de3

アプリケーションモジュール名の取り扱いが変更

config周りを呼び出す際、以前は「[アプリ名]::Application」を使っていました
これが「Rails.application」に統一されています

# 以前の形式
Gagnrath::Application.configure do
  # config.hoge = piyo
end

# 新しい形式
Rails.application.configure do
  # config.hoge = piyo
end

結果的に、アプリ名は「config/application.rb」だけになっています
（元々あったものです）

module Gagnrath
  class Application < Rails::Application
    # ...
  end
end

変更理由はわかりませんが、個人的には4.1の形式が好みです(`･ω･´)

secrets.yml の追加

元々、「config/initializers/secret_token.rb」にtokenの値が書かれていたのですが、
ソースを公開したり、開発環境と本番でtokenを分けたりするのに都合が悪かったので、
自前の設定ファイルに環境ごとのtokenを書けるようにしていました

それが公式に「secrets.yml」という形で追加されたため、そちらに移行しました

本番だとデフォルトでは環境変数から読み込む仕組みになっていますが、
おそらくheroku等を意識した記述だと思います
実際の運用では直に書いてしまっています(´-ω-)

database.yml の修正

共通設定をdefaultに切り出し、
各環境では差分だけ書く形式になっています
（書き方だけの変更で、YAMLに元々ある仕様を利用しています）

仕事のシステムでもこういう書き方をしていたのですが、
こっちの方が合理的ですよね(`･ω･´)

あと、PASSを環境変数から読み込むのがデフォルトになってますが、
おそらく(ry

migrationでschema.rbを更新しない設定が追加（動作未確認）

これは4.1からなのかわかりませんが、
今回の移行で初めて気づきました

# config/environments/production.rb
Rails.application.configure do

  # Do not dump schema after migrations.
  config.active_record.dump_schema_after_migration = false  

end

仕事のシステムでリリース時にmigrationすると、
schema.rbが書き換わって次のリリース時に引っかかる*1のが面倒だったのですが、
この設定があれば避けられそうですね(`･ω･´)

*1: schema.rbもgitの管理下にある場合、書き換わると次のmergeで引っかかるんですよね・・・(´-ω-)

下書きをひっそりと共有するサイト「紙片」を公開しました

サービス Ruby Rails

実は、結構前から知り合いに公開して運用していたのですが、
想定通り「使われている」ことが判明したので、
一般向けに公開いたします(´･ω･)っ


紙片 - 「みんなに見せるにはちょっと早い、でも見てほしい、そんなあなたへ。」
http://app.parrot-studio.com/shihen


基本は「編集用の合い言葉」を設定し、
ただひたすら「書く」だけです
編集をやめれば、そのうち文章は削除されます *1

保存は自動で行われますし、他のブラウザで編集を続けたいときは、
その「編集用URL」を開いて合い言葉で認証するだけです

誰かに見せたい場合は、「公開用の合い言葉」を設定し、
「公開用のURL」と一緒に伝えるだけです

コンセプト

「紙片」は「下書きを共有するための仕組み」です

Blogやサイトで何らかの文章を公開する場合、
たいていの方はどこかに「下書き」を書くと思います

私はこの文章の下書きをEvernoteに書いていますが、
「同期ができるテキストエディタ」として使っているので、
画像を貼り付けられるとか、そういう機能には一切期待していません

問題は、その下書きを「公開前に」「自分以外の誰かに」読んでもらいたい場合です

Evernoteにも共有機能はありますが、相手にも同じアプリを要求するのが面倒です

Blogで非公開に書く手もありますが、そのためにわざわざアカウントを取るのも面倒です

アップローダーは他の人にも読まれる可能性がありますし、
更新のたびにわざわざアップし直すのも面倒です

そもそも「下書き」なんて最終的には捨ててもいいわけですよ
どうせ公開するときにはさらに微調整を加えるわけですし、
下書きも残したいというのなら、それはもう「下書き」ではないわけで *2

どうせ「捨てる」文章なのだから、もっと簡単に共有できないか
面倒な管理がいらず、用が済んだら「忘れてもいい」、
そんなテキスト共有システムはないか

そう考えて「紙片」を作りました

実際、「想定ユーザ」として設定した友人は、
狙い通りに使ってくれているようなので、
こうして公開することにしたわけです

正直、あまり使われるとは思ってませんが、
「Gagnrath」同様、自分に都合がいい仕組みとして作ったので、
最悪自分とその周辺が使ってくれればいいかな・・・と


その他の使い方

元々のコンセプトは上記の通りですが、副次的な効果として、
「Webのどこかに書きたいが、不特定多数には見せたくない」
という文章を書くのにも使えます

愚痴をBlog等に書くと汚染されて都合が悪いですが、
かといって「Webのどこか」に書きたい、そんな欲求を満たすのにも使えます
どうしてもって場合は仲の良い誰かに見せることもできます *3

あとは、身内向けのイベント告知文を書いておいて、
公開用URLと合い言葉を伝えて見てもらうなんてのもできます
イベントが終わり、忘れた頃には消えています *4


「合い言葉」という表現

「紙片」では「パスワード」という言葉を一切使っていません
全て「合い言葉」で統一しています

「パスワード」という言葉から連想されるのは「英数字や記号」ですが、
「合い言葉」なら「日本語」を使うだろうと思ったからです

そもそも、何らかのパスワードをかける際に、
英数字や記号しか使えないというのは、古いシステムの都合や、
歴史的な経緯によるものでしかないのではと思ったのです

今の仕組みであれば、日本語で認証することも可能なはずで、
その実験的な意味合いを含んでいます

結果的に、他のシステムと「パスワードの共有」は起こりづらいと思います
もっとも、「アカウント」って概念も排除しているので、
「IDとパスワードの組」は一切存在しませんが


おまけの技術的な話

Ruby2.1＋Rails4＋MariaDBで動いています
ソースコードはそのうち公開予定です

Bootstrapは2.3を使っています
これを作っている昨年秋頃にはまだ3系の情報が少なく、
かといって今さら直す理由もなかったので・・・

Bootstrap3は次の何かで使うことにします

*1: 論理的に見えなくなるだけでなく、データレベルで削除しています

*2: それならgitあたりで履歴管理したりとか・・・

*3: いくら文章がサーバから消えるとはとはいえ、誰かが画像として保存し、別な形でUPされること（例：魚拓）は防げません。なので、「共有」にはそれ相応のリスクがあることは変わりません

*4: 実際、私のこの用途で利用しています

Developers Summit 2014 2日目 まとめ

devsumi2014

1日目の続きです

Developers Summit 2014 1日目 まとめ - ぱろっと・すたじお

Developers Summit 2014：開発者のためのITカンファレンス

デブサミ2014、講演関連資料まとめ：CodeZine

2日目は例の大雪でえらいことになり、
さすがに雅叙園前の急勾配は危ないだろうと、
Amazonさんの入っているビル経由で向かいました

エントランスももちろん綺麗なのですが、
度肝を抜かれたのは社食と思われるホールです
これが吹き抜けでびっくりするほど広いという(lllﾟДﾟ)

柱にはダンボーのイラストも描いてありましたが、
勝手に写真を撮るのもためらわれたので撮ってません
共用エリアから見えるので、一度見てみると面白いと思います

ただ、ビル内で相当迷いまして、
そもそもどこからどこまでが「入っていいエリア」なのかもわからず、
「THE・リア充」な雰囲気とあわせて混乱しましたΣ(ﾟДﾟ；≡；ﾟдﾟ)

2つ目のセッションから参加で、他に人が少なかったのもあります
人がたくさんいれば後ろをついていけたのですが・・・

14-B-2 グリーを支えるデータ分析基盤の過去と現在

「ビッグデータ」という言葉がバズワード化してしまってあれですが、
真の意味で「大規模なデータをどう分析するか」のお話でした

ただまあ、正直ここまでの規模のデータ分析（システム）は、
よほどの大企業・・・それこそGREEやDeNAクラスでないと、
とても考えられないレベルだと思います(lllﾟДﾟ)

ただ、他のセッションでも頻繁に出てきた、
「Fluentd」は気になりました

http://fluentd.org/

アーキテクチャの説明を見ていただければわかると思いますが、
ログデータを構造的に扱うため、入出力を仲介するもの・・・と考えればいいでしょう
Ruby系WebアプリにおけるRackの立ち位置だと思います

データをJSONとして扱っているのもポイントで、
これにより構造的なログ解析が可能になっているわけです

うちのような普通の会社であっても、Fluentdは使えそうな気がするので、
今度提案してみようと思います...φ(･ω･｀)

あと、Hadoop周りに関しては、あまりに規模が違いすぎて縁がないというか、
Hadoopの出始めの頃に買った本がまだ手つかずだったり・・・
技術的にどうって前に、そこまでのサーバリソースはなかなか用意できませんし

  • 既存の構造
    • Webサーバ->ストレージ->MySQL->分析
    • ストレージ->バッチ->分析
    • ストレージ/DB->SQLServer（生データっぽいもの）
  • 問題点
    • データ分析するユーザが増えた
    • エンジニアがデータを提供するのが難しく（人が限られる）
  • 改善へ
    • Accessability：誰でも自由に
    • Scalability：システムがスケールするように
    • 既存は維持
  • Treasure Data
    • Hadoop構築不要
    • ログの集積：fluentd
      • スキーマレス
      • データウェアハウスのコスト低減
      • BIツールと連携可能
    • 規模
      • ゲーム20タイトル
      • Webサーバ2000台
      • log aggregatorサーバ40台
      • 1TB/月
  • データ分析基盤
    • ログから分析して改善
      • Webサイトのアクセス改善を応用
    • ジョブ管理
      • 投げられた分析タスクを監視
  • ログ解析
    • ページ遷移（GoogleAnalyticsっぽいあれ）
    • 離脱（ユーザ属性・プレイ時間など）
    • クリック
      • Chromeの拡張で画面にクリック分析データをオーバーレイ
      • JSでクリックログを送信
  • 分析ジョブ管理
    • 社内一般ユーザにデータを解放 => 非効率なジョブが投げ込まれる
      • ジョブの可視化
      • 送信元の特定
      • スロークエリの可視化と判定
      • 強制kill
  • （以下、Hadoop周りの具体的な実装については割愛）


14-C-3 Web Platform 最前線 ～Web技術とアプリ開発のトレンド～

Slide : (not yet)

今年のデブサミで、自分にとって一番インパクトがあったというか、
パラダイムシフトを感じたのがこのセッションでした
資料が現時点で公開されていないのが残念です(´･ω･`)

いわゆる「WebOS」、さらにいえば「FirefoxOS」の話なのですが、
それが意味するところは「ブラウザOS」よりもはるかに大きくて、
「ソフトウェアとハードウェアの標準化」くらいのインパクトがあると思います

今までのOSにおいては、ハードウェアとのやり取りにデバイスドライバを使っており、
OSレベルで「API」としてハードウェアの機能を隠蔽していました
逆に言えば、OSレベルAPIの範囲でしか互換性を持たなかったのです*1

一方、現在W3Cが目指しているのは、
まさにその「ハードウェアレベルAPIの標準化」であり、
その現時点での実装が「FirefoxOS」なのです

ある意味、OSとアプリケーションが真の意味で分離されようとしており、
その技術としてHTML5とその周辺技術が存在しているわけです
OSやハードウェアを意識せずに、本当の意味でアプリが汎用化される可能性があります

かつてはJVMや.NETという形でバラバラに「マルチデバイス化」されていた概念を、
WebAPIという形で標準化しようとしているわけです
なので、おそらく「ブラウザOS」という表現は本質を捉えていません

もちろん、現時点ではまだパフォーマンスに問題があり、
機能もまだ揃っていません*2

ただ、WindowsやIEが今ではWeb標準に従っているように、
悪い意味で「昔のWindows化＝断片化/独自仕様化」しているAndroid等も、
何年先かはともかく、後々追随してくる可能性はあるでしょう

このセッションを聞くまで、FirefoxOSについて、
「真にOSSのAndroid」くらいの認識でいましたが、
全然見ているものが違いすぎました(ﾉ´･ω･)ﾉﾐ(m´_ _)m

個人的に思ったのは、CやJavaで実装されている「Ruby」が、
JavaScript上で実装されたとすると、相当面白くなると思うんですけどね・・・
その鍵を握るのが「asm.js」だとは思いますが(´-ω-) *3

ということで、FirefoxOSが動く端末を手に入れたいと思ってますが、
海外から輸入ってのも面倒なのでどうしたものか・・・

  • 背景
    • 従来：OSごと / Webはサブセット扱い
    • プラットフォーム依存
    • 不透明な継続性性・再利用性
    • 分断・実装依存
  • "APIが標準化されていない"
  • Web Platform
    • マルチデバイス（言語やAPIの共通化）
    • ベンダー非依存（持続性）
  • ブラウザ上で動くアプリ
    • ブラウザの開発にエンジニアリソースが割かれるように
  • Firefox Apps / Chrome Apps -> ローカルAppと区別できない
    • 例の「Flappy Bird」はFirefox Apps
  • WebOS
    • FirefoxOS / ChromeOS / TizenIVI / webOS -> Web主体
    • Win8 / Tizen Mobile -> ネイティブ主体
      • TizenはIVI と Mobileはカーネルが共通だけど別物
      • Tizen IVIはWebベースで完全にかける
  • WebOSが各種デバイスへ
    • モバイル/テレビ/デスクトップ/車載/健康/ライフサイエンス・政府/教育/ビッグデータ
    • ChromeOS -> アメリカのノートPCの20％（3万くらいの端末）
    • FirefoxOS -> 新興国系でそこそこ売れている
  • 課題：機能不足・パフォーマンス不足・エコシステム
  • デバイス系機能の標準化
    • 例：バッテリー残量取得のAPI化
      • FirefoxOSで実装 -> 他のOS
  • 大規模アプリでは遅い
    • asm.js
      • Cと比較して数十倍遅い から 数倍遅い程度まで＝Java/C#と同程度以上？
      • 現在はCの1.5倍程度（ただし苦手な処理もある）
        • （asm.jsを「ちょっと早いブラウザJS実行系」くらいに思っていた）
        • （実際はもっと上の概念のために実装されている）
  • Webテクノロジー
    • HTML5/CSS3を中心にかなり広域に
    • モバイルOSの標準化はほぼ完了
      • TVや車載OSはW3C以外との調整がいまいち
    • 実装されないと意味がない -> 今年色々出てくる？
  • UNREAL Engine
    • Webだけで3DゲームレベルもOK
      • （デモがめちゃくちゃ綺麗で軽くびびる(lllﾟДﾟ) ）
  • AOTでロードタイムも軽減
  • GCも軽減する手段がある
  • デスクトップのリモート実行
  • AmazonのGPUインスタンスで画面を描画
  • 「赤いきつね」：赤いネクサス5にFirefoxOS
    • （やりたいけど、お金が・・・(´-ω-) ）
  • OSが軽量なのでメモリを積まなくてもOK -> 安く売れる
  • OSカーネルとブラウザが分離されている
    • セキュリティパッチをブラウザレベルでできる
  • パナソニックがスマートTVをFirefoxOSで
  • 今後も端末やデバイスがいろいろ


14-C-4 DeNAにおけるゲーム以外の新規事業の立ち上げ方

Slide : https://speakerdeck.com/okitsutakatomo/debusami2014-14-c-4-denaniokerugemuyi-wai-falsexin-gui-shi-ye-falseli-tishang-gefang

DeNAは今でこそソーシャルゲーのイメージが強いですが、
元々はオークションや広告等、様々なカテゴリで事業を行っている会社です*4

とはいえ、今の主軸は間違いなくソーシャルゲーであり、
同時にソーシャルゲー自体がもはや微妙な立ち位置になっているため、
「次」を開拓するのは急務だと思います*5

そんな中でのこのセッションだったわけですが、
「事例」に寄っていて、非常に面白い内容でした(｀･ω･´) ｂ

ある意味では「今風」のやり方ではあるのですが、
そのバックボーンに「確立された技術」があるように見えましたし、
なによりとても「現実的」だと思います*6

  • エンターテイメント事業本部
    • 非ゲーム事業をやる
    • ゲームの次の領域を探す
  • マンガボックス
  • Showroom
    • アイドルのパフォーマンスを配信
    • （文字列ではなく）アバターが視覚的にコメント
    • UIでニコニコ等と差別化している
  • etc...
  • 一つの事業部で全部回している
    • "やることが多い"
    • 基本的な人員構成を揃えつつ、他の部署が全面的にバックアップしている
  • DeNAのスクラム
    • 守・破・離
    • 過去：スクラムフレームワークに忠実 -> コストがかかる
    • 現在
      • スクラムマスターを廃止
      • タスクの粒度を荒く、ストーリーポイント廃止
      • バーンダウンチャート廃止
      • タスク管理はチームでやりやすい方法
      • 少人数体制で適宜周囲がサポート
      • チーム単位で座席をまとめる
    • 各自が考えて行動している感が高まる
    • 少人数なのでコミット意識高い
    • 定量的な進捗管理をなくしたけど遅れはあまりない
    • 人が増えてくると意思疎通等のコストが -> 適宜最適化
  • プロダクト
    • みんなで必死に考える -> 作る -> 使われない
    • ユーザにインタビュー -> ⚪︎⚪︎機能に需要が -> 作る -> 使われない
    • "ニーズを検証する"
  • 例1：チラシル
    • 検証項目
      • 暮らしの中で使ってもらえるか？
      • 長期的に使ってもらえるか？
      • 紙と同じように使ってほしい
    • 練馬区限定でバイト募集 -> 社内に呼んで使ってもらう -> フィードバック
  • 例2：アプリゼミ
    • 検証項目
      • 長時間勉強して欲しい
      • 長時間勉強するのに何が楽しいか？
      • 親は子供が勉強しているかしりたいのか？
    • 最小限のモックを作って親子に評価してもらう
  • 例3：peko -> USの大学生向け
    • 検証項目
      • 初対面でもコミュニケーションは成立する？
      • 位置情報とか気にする？
      • FBログインは使う？
    • USの大学前でチラシを配ってテスター募集
      • 2週間試してもらう
      • ログを仕込んでおいて、何を使ったのかを調べる
      • ヘビーユーザにインタビューもする
        • アンケートだとFBログインを使いたいのは半分程度
        • 実際に使わせると8割は使っている
    • 定量化は重要
  • 企画の進め方
    • プロデューサーとエンジニアが意思疎通して意思決定
    • 9サービス中4サービスはエンジニアが立案
    • 全ての意思決定にエンジニアが参加
    • UserTesting,com
      • リモートでアプリを使ってもらう
      • 日本でも徐々に出てきている？
  • アーキテクチャ
    • リードエンジニアが好きに決めている
      • 結果的にPerlが多い
    • JSON-RPC or JSON on HTTP
  • 自社のデータセンター
    • ソーシャルゲーで鍛えられたインフラ部隊
      • たいがいのことは解決してくれる
    • 必要ならAWSも
  • スケーラビリティ
    • どんなにスモールスタートでも意識する
  • インフラ基本構成
  • コミュニケーション
    • GitHub Enterprise
    • 全リポジトリを全エンジニアが見られる
    • デザイナもpull-request
    • 画像のやりとりも
  • ネイティブアプリ
    • iOSかAndroidかどちらかを集中開発
    • いけそうならもう片方
    • 当たるかわからないものは最小のリソースで
    • ほとんどiOS6対応だが最近はiOS7専用が多い
      • カバー率よりスピード
    • Androidは2.3以降をサポート
  • 通知
    • OSが提供するpush通知だけではコミュニケーションスピードに対応しきれない
    • TCPでonlineサーバと常時接続（APIと別に）
      • （バッテリーとかどうなんだろう・・・？）
    • Node.jsでWebSocket
    • 通知以外でも常時接続を活用
  • 分析用のロギング
    • Server -> Fluentd -> HDFS
    • 分析者（非エンジニア）：HiveQLでHive
      • （GREEもそうだけど、DeNAでもプロデューサークラスがHive等を使えるのが前提になっている？）
    • バッチによる分析
  • ログの種類
  • 広告
    • リリースしても何も起こらない
      • ほっといても30-40程度
    • 広告を使ってユーザを流入させる
    • FacebookAdやTwitterAdはお安い
  • FBAd
    • キャラクター系 / 人物系 / アプリのUI系 -> どれが効果的か？
      • アプリのUIを見せるのが一番クリック率高かった
    • オフラインプロモーション in US
      • バーで「ビールをおごるからアプリを入れて」
  • 1年振り返って


14-A-6 Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所

Slide : http://www.slideshare.net/sifue/developers-summit-2014-play2scalaweb

えー・・・資料みてください、以上Σ(・ω・ノ)ノ

いや、あまりに高密度すぎて、Scalaの件あたりまではきっちり聞いていたのですが、
後半のスクラム周りは( ﾟдﾟ)ﾎﾟｶｰﾝと見ているしかなかったので・・・

この事例からもわかるのは、「フレームワークの作り直し」をする際に、
必要なのは「少人数のできる人"だけ"で構成されたチーム」ってことです

フレームワークができあがれば、多少の差を吸収できますが、
やはり基盤部分は「わかる人」が手を動かすのが最速である、ということです
今の「はてブ」だって、最初はnaoya氏が一人でベースを作ったわけで

ただ、後で個人的に思ったのは、ちょっとScalaにこだわりすぎかな・・・というところで

今の仕事をするまでは、私もそこまで考えてなかったと思いますが、
適切にサーバサイドAPIとViewが分離されていれば、
View側のアーキテクチャまでScalaである必要はないのではないかと

というのも、発表の中でScalaのテンプレートで引っかかっているという話があり、
わざわざGroovyまで使っているとのことですが、
それならいっそView部分だけPHPで実装する手もあったのでは

もちろん、PHPでは既存のアーキテクチャに引きずられるとか、
パフォーマンスの問題とかいろいろ背景はあったと思いますし、
そもそも、私ごときが何言ってるんだって話なんですが(´-ω-)

あと、DDD周りの話を見ていて思ったのが、
大規模なWebシステムは、もはやSIの領域と何ら変わりない、ということで

大規模化したシステムを滞りなく動かすノウハウという意味では、
どう考えてもエンタープライズ系が先行しているわけですが、
表面上のレイヤーが違うだけで、やってることは一緒になってます

その辺に気づいているWeb企業が、SIerの転職を歓迎していたりするわけで、
おそらくドワンゴもそういうフェーズに入ったってことでしょう*7

その他、細かいことは資料でみてください(´･ω･`)



ということで2日分をまとめてみました

やはり自分の中でインパクトがあったのは「FirefoxOS」です
別にフォクすけを愛しているからではないですよ(´･ω･)？ *8

エンジニアってやっぱり怠惰なもので、「面倒なこと」はしたくないわけですよ
例えば、環境ごとに言語レベルでコードを書き換えるとか

その現時点での解が「Xamarin」等の開発環境であり、
未来における解がFirefoxOSが目指す「APIの標準化」なのだと思いました

前回の冒頭でも書きましたが、
「未来の話」はそれはそれで面白いし大事なのですが、
「今、何ができるか？」はより重要です

とりあえず、「私が今できること」は、FirefoxOS周りの情報収集ですかね・・・(´-ω-)

*1: Windows同士とか、Mac同士とか・・・

*2: とはいえ、Rubyだって当初は「こんな遅い言語は使えない」と言われていたそうですが、今は時代が変わり、むしろメインストリームの一角です

*3: どちらにせよ、何年も先の話でしょう。でもRuby界隈の人なら考えそうな話で・・・

*4: GREEに比べると、圧倒的に「手堅い」イメージがあります。でなければ球団とか持てません

*5: とはいえ、GREEやソーシャルゲーに特化してしまったWebゲーム会社に比べればはるかにましかと

*6: 後に出てくるニコニコの事例は、たしかに「ハイレベル」ではあるのですが、まだ「教科書通り」のレベルから大きく離れていないというか・・・(´-ω-)

*7: C++の有名人を雇用（？）したりもしているようですが・・・Σ(ﾟДﾟ)ｶﾞｰﾝ

*8: Android版Firefoxのキャンペーンで当たったフォクすけぬいぐるみは、家宝として大事にしまってあります(*ﾟ∀ﾟ)=3