「女子大生とペアプロするだけの簡単なお仕事」でSSSをとるまでに考えたこと
今回で二回目になる「POH!」
女子大生とペアプロするだけの簡単なお仕事です！｜paizaオンラインハッカソンVol.2
前回*1は「合理的かつきれいに書けば通る」ってレベルだったのですが、
少なくとも私の（わりと雑な）プログラミングレベルだと、
今回は相当突き詰めないと難しかったのです
- コード：https://gist.github.com/parrot-studio/10815136
- 修正履歴：https://gist.github.com/parrot-studio/10815136/revisions
せっかく苦労して解いたので、自分の中でも一度整理しておきたいので、
思考の過程を思い出せる範囲でメモしてみます...φ(･ω･｀)
まずは仕様通りに書く
問題を大雑把に整理すると、「あるサイズのオブジェクトが、
既存のオブジェクトと衝突しない座標の数を求めよ」ということです
言い換えれば、「オブジェクトを各座標ごとに動かしながら、
オブジェクトの範囲に何か障害物があるか？」ということになります
これを馬鹿正直に実装したのがこちら(´･ω･)っ
- https://gist.github.com/parrot-studio/10815136/7bd496e09c6b758977e53104e82d0a4a8045e7a5
- http://paiza.jp/poh/paizen/result/abc3618a53b7b7da07400343b7a02dae
あらかじめ各座標に「オブジェクトがあるか？」を入れておき、
座標を動かしながら、オブジェクトの範囲を探索する、という方法です
これでもcase4までをパスしています
全部埋まっている行は調べるだけ無駄だよね・・・？
サイトにある「入力例1」を見てもらえばわかるのですが、
4行目から7行目は「1」で埋まっている、つまり探索するだけ無駄です
それをふまえて実装したのがこちらですが・・・
- https://gist.github.com/parrot-studio/10815136/130e41388289d6bf82cd61d7b8745af885c77c0a
- http://paiza.jp/poh/paizen/result/4f222df289dfbc2d4e60b75e6dc7f06d
・・・大差はありません(´-ω-)
データ構造に情報を畳み込もう
最初のやり方の問題は、各座標における探索回数が、
「縦×横」、つまりは「O(n^2)」になっていることです
これを「座標個×オブジェクト数」繰り返すとなると、
相当に無駄が含まれます
そこで、あらかじめ「横にいくつ空いているか？」を計算しておく、手を思いつきました
元データ 1000 1101 1001 計算後データ 0321 0010 0210
こうすると、ある座標を見ただけで、
そこに横幅いくつのオブジェクトが入るかすぐわかるので、
縦方向の探索だけで衝突判定できますヽ(`･ω･´)ノ
この構造を起点に、いろいろな計算回数の無駄を省いたのがこちら
- https://gist.github.com/parrot-studio/10815136/a7aa0a0c5b5cc72b5d324729c63585ea64a435eb
- paizen2.rb
- http://paiza.jp/poh/paizen/result/6d279a6289bb5c20a3cdd040e17b53a0
これでcase5を突破しました
縦も考えてみる・・・？
元のデータが「横軸のデータを縦に向かって読む」という構造だったため、
どうしても横ばかり考えてしまいましたが、
状況によっては「縦軸の方が効率がよい」場合があります
縦に向かって探索する場合、「横2×縦100」のオブジェクトに対し、
最悪100回の衝突判定が必要ですが、
これを横に向かって探索すれば2回で終わります
なので、「縦にいくつ空いているか？」のデータも計算しておき、
「縦か横で計算回数が少なくなる方」で判定していけば、
計算量を減らせるのではと推測しました
- https://gist.github.com/parrot-studio/10815136/a1162fd4eee10faa7f83d4bf09b9a410459566c0
- paizen3.rb
- http://paiza.jp/poh/paizen/result/dca478c337ea383a0e9bbcb02259a3a5
まあ、あまり効果がなかったんですけどねΣ(・ω・ノ)ノ
盤面じゃなく、チェックするオブジェクトの問題じゃない・・・？
ここまでやっていまいちな成果しか得られなかったので、
別なところにボトルネックがあると推測しました
例えば、盤面のサイズが普通であったとしても、
チェックする対象が1万件あり、しかもそれが「2x2」の同じサイズなんて場合、
いちど計算すればあとの9999件は同じ値を出せばいいのです
つまり、「メモ化」しろと(`･ω･´)
ver2とver3に対し、それぞれ「結果を記録」するロジックを入れたところ、
たいして変わらなかったので、複雑化していたver3を破棄し、
ver2をメモ化したものをベースに進めることに
- https://gist.github.com/parrot-studio/10815136/c909a2f9a2a0153846efe41df004b6d4dc18f726
- わかりづらいですが、「paizen2.rb」が対象です
- http://paiza.jp/poh/paizen/result/3dbb079041abc8a3f68cd8d9b740f051
最終的にはメモ化というより「存在するパターンだけ調べる」に変わり、
ついでにコードも整理してみたのですが、やっぱりいまいちですね(´-ω-)
まだチェックするオブジェクトに無駄があるよね・・・？
盤面より大きなオブジェクトは排除するにしても、
もっと細かいレベルでオブジェクトを排除できないかと考えました
縦と横の空きデータを作る時点で、
「縦横それぞれこのサイズまでしか入らない」というのはわかるので、
それを元に弾いてしまえばいいのではと
- https://gist.github.com/parrot-studio/10815136/0d23637c8aa3042f906e23b38a85947380546556
- paizen4.rb
- http://paiza.jp/poh/paizen/result/4fd6144322ba720a5503a5c718c46e75
ずっと壁になっていた、case6をついに突破しましたヽ(`･ω･´)ノ
さらに、「ある横幅を基準に考えて、縦幅を小さい順に探査したときに、
ある高さで答えが0ならば、それ以降の縦幅を計算するのは無駄」と気づきました
つまり、「横2×縦3」のオブジェクトが入らない状況で、
「横2×縦4」のオブジェクトは絶対に入りません
そこを削ればいいのではと
- https://gist.github.com/parrot-studio/10815136/21af47337f2bbce839a56ebffc61b287ba7cfa96
- paizen4.rb
- http://paiza.jp/poh/paizen/result/19295f1c27e78ba08a8a98326d898616
case6突破時点の11sから8sに縮まりました（ ﾟдﾟ）o彡ﾟ
そして深淵へ・・・
ここからはひたすら細かいチューニングを繰り返しました
オブジェクトの生成を抑えてみたり、
最終的には足し算の回数まで気にしてみたりΣ(ﾟДﾟ)ｶﾞｰﾝ
- https://gist.github.com/parrot-studio/10815136/47c8e2a4cce5624d1c8c1d37a4c154e5a1288efe
- paizen5.rb
- http://paiza.jp/poh/paizen/result/da003df380f521e46f8d1ae449edb06d
case6で4sまで縮まったものの、ここで完全に行き詰まりました・・・(´-ω-)
ちゃんと調べてみる
ここでいったん立ち止まり、わかっている問題を整理してみました
- ループが多い
- もっと単純な探査ができないか？
- つまり、「計算する次元」を落とせないか？
- データ構造が複雑
- 構造が複雑だから、探査に時間がかかる
「衝突」という言葉を使っていますが、
ここまでくるとまさに、ゲームの当たり判定の話だと思いまして、
こちらの本の衝突判定をじっくり読んでみました
- 作者: 平山尚(株式会社セガ)
- 出版社/メーカー: 秀和システム
- 発売日: 2008/11/15
- メディア: 単行本
- 購入: 112人 クリック: 3,473回
- この商品を含むブログ (193件) を見る
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演算は使わないというか、個人的に苦手なので避けていたので、
これに思い当たるまでにだいぶ遠回りしましたね・・・(´-ω-)
- https://gist.github.com/parrot-studio/10815136/3650f82ab6fe261f32d4483061dc1ec9d222d52a
- http://paiza.jp/poh/paizen/result/82967b508c0f18216f02892f36adb69d
そんなわけで、無事に全てのTest caseを突破しました∠( ﾟдﾟ)／
一応まとめ
ご覧の通り、最終的なコードはver5までと比較にならないほどシンプルです
やはり、効率の良いコードはシンプルに落ち着くのだと思います *2
for "https://paiza.jp/poh/paizen"
普段、ここまでチューニングを要求されるシステムは担当してませんし、
どちらかといえば可読性を優先してコードを書いているつもりですが、
たまにはこういうコードも面白いですね
次回も期待しています(`･ω･´)ノ
追記
どうも判定には「S」どころか「SS」や「SSS」もあるそうなのですが、
個人的には「S」だけ取れれば十分です(((((( ;ﾟДﾟ)))))
さらに追記
ちょっといじったら「SSS」に・・・(； д ) ﾟ ﾟ
- https://gist.github.com/parrot-studio/10815136/9b15a29f4f21b6ca5441f0d7d0f470eb6bd792c9
- http://paiza.jp/poh/paizen/result/0ba0a0c1b970fb72525886d3abc42e15
カウントアップのところって、
カウンタがリセットされるときで十分だよな・・・と思っただけなのですが
つまり、カウンタが3まで行ってリセットされるとすると、
縦1は+3、縦2は+2、縦3は+1・・・となっているはずです
そのように数行書き換えただけなのですが、
それでカウントアップの計算回数が劇的に変わったと思われます
*1: 前回のコードと結果はこちら(´･ω･)っ https://gist.github.com/parrot-studio/7763295
*2: とはいえ、それは「結果」なのであって、最初から効率の良いコードが書ければいいのですが、普通はそこまで簡単ではありません。だからこそ、思考の過程を残しておくことで、「次回」に生かせるのではないかと。（Gitのような）「コード管理」についても、「履歴」という「思考の過程」を残せることが、重要なメリットだと思っています
Rails4.0のアプリをRails4.1に移行したときのメモ
先日、めでたくRails4.1がリリースされ、
新しい機能が追加されました(`･ω･´)
Ruby on Rails 4.1 Release Notes — Ruby on Rails Guides
いくつかの機能は自前で実装していたので、
公式に実装されたのは実にありがたいことです
そこで、早速私も手持ちの「Gagnrath」を4.1に対応させることに(`･ω･´)
- Gagnrath - ROGv : Forts Watching System
- source : https://github.com/parrot-studio/gagnrath
- sample site : http://ro.parrot-studio.com/rogvs
- Gagnrath(Viewer)
メジャーバージョンアップではないので、
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で引っかかるんですよね・・・(´-ω-)
下書きをひっそりと共有するサイト「紙片」を公開しました
実は、結構前から知り合いに公開して運用していたのですが、
想定通り「使われている」ことが判明したので、
一般向けに公開いたします(´･ω･)っ
紙片 - 「みんなに見せるにはちょっと早い、でも見てほしい、そんなあなたへ。」
http://app.parrot-studio.com/shihen
基本は「編集用の合い言葉」を設定し、
ただひたすら「書く」だけです
編集をやめれば、そのうち文章は削除されます *1
保存は自動で行われますし、他のブラウザで編集を続けたいときは、
その「編集用URL」を開いて合い言葉で認証するだけです
誰かに見せたい場合は、「公開用の合い言葉」を設定し、
「公開用のURL」と一緒に伝えるだけです
コンセプト
「紙片」は「下書きを共有するための仕組み」です
Blogやサイトで何らかの文章を公開する場合、
たいていの方はどこかに「下書き」を書くと思います
私はこの文章の下書きをEvernoteに書いていますが、
「同期ができるテキストエディタ」として使っているので、
画像を貼り付けられるとか、そういう機能には一切期待していません
問題は、その下書きを「公開前に」「自分以外の誰かに」読んでもらいたい場合です
Evernoteにも共有機能はありますが、相手にも同じアプリを要求するのが面倒です
Blogで非公開に書く手もありますが、そのためにわざわざアカウントを取るのも面倒です
アップローダーは他の人にも読まれる可能性がありますし、
更新のたびにわざわざアップし直すのも面倒です
そもそも「下書き」なんて最終的には捨ててもいいわけですよ
どうせ公開するときにはさらに微調整を加えるわけですし、
下書きも残したいというのなら、それはもう「下書き」ではないわけで *2
どうせ「捨てる」文章なのだから、もっと簡単に共有できないか
面倒な管理がいらず、用が済んだら「忘れてもいい」、
そんなテキスト共有システムはないか
そう考えて「紙片」を作りました
実際、「想定ユーザ」として設定した友人は、
狙い通りに使ってくれているようなので、
こうして公開することにしたわけです
正直、あまり使われるとは思ってませんが、
「Gagnrath」同様、自分に都合がいい仕組みとして作ったので、
最悪自分とその周辺が使ってくれればいいかな・・・と
その他の使い方
元々のコンセプトは上記の通りですが、副次的な効果として、
「Webのどこかに書きたいが、不特定多数には見せたくない」
という文章を書くのにも使えます
愚痴をBlog等に書くと汚染されて都合が悪いですが、
かといって「Webのどこか」に書きたい、そんな欲求を満たすのにも使えます
どうしてもって場合は仲の良い誰かに見せることもできます *3
あとは、身内向けのイベント告知文を書いておいて、
公開用URLと合い言葉を伝えて見てもらうなんてのもできます
イベントが終わり、忘れた頃には消えています *4
「合い言葉」という表現
「紙片」では「パスワード」という言葉を一切使っていません
全て「合い言葉」で統一しています
「パスワード」という言葉から連想されるのは「英数字や記号」ですが、
「合い言葉」なら「日本語」を使うだろうと思ったからです
そもそも、何らかのパスワードをかける際に、
英数字や記号しか使えないというのは、古いシステムの都合や、
歴史的な経緯によるものでしかないのではと思ったのです
今の仕組みであれば、日本語で認証することも可能なはずで、
その実験的な意味合いを含んでいます
結果的に、他のシステムと「パスワードの共有」は起こりづらいと思います
もっとも、「アカウント」って概念も排除しているので、
「IDとパスワードの組」は一切存在しませんが
Developers Summit 2014 2日目 まとめ
1日目の続きです
Developers Summit 2014 1日目 まとめ - ぱろっと・すたじお
Developers Summit 2014：開発者のためのITカンファレンス
2日目は例の大雪でえらいことになり、
さすがに雅叙園前の急勾配は危ないだろうと、
Amazonさんの入っているビル経由で向かいました
エントランスももちろん綺麗なのですが、
度肝を抜かれたのは社食と思われるホールです
これが吹き抜けでびっくりするほど広いという(lllﾟДﾟ)
柱にはダンボーのイラストも描いてありましたが、
勝手に写真を撮るのもためらわれたので撮ってません
共用エリアから見えるので、一度見てみると面白いと思います
ただ、ビル内で相当迷いまして、
そもそもどこからどこまでが「入っていいエリア」なのかもわからず、
「THE・リア充」な雰囲気とあわせて混乱しましたΣ(ﾟДﾟ；≡；ﾟдﾟ)
2つ目のセッションから参加で、他に人が少なかったのもあります
人がたくさんいれば後ろをついていけたのですが・・・
14-B-2 グリーを支えるデータ分析基盤の過去と現在
「ビッグデータ」という言葉がバズワード化してしまってあれですが、
真の意味で「大規模なデータをどう分析するか」のお話でした
ただまあ、正直ここまでの規模のデータ分析（システム）は、
よほどの大企業・・・それこそGREEやDeNAクラスでないと、
とても考えられないレベルだと思います(lllﾟДﾟ)
ただ、他のセッションでも頻繁に出てきた、
「Fluentd」は気になりました
アーキテクチャの説明を見ていただければわかると思いますが、
ログデータを構造的に扱うため、入出力を仲介するもの・・・と考えればいいでしょう
Ruby系WebアプリにおけるRackの立ち位置だと思います
データをJSONとして扱っているのもポイントで、
これにより構造的なログ解析が可能になっているわけです
うちのような普通の会社であっても、Fluentdは使えそうな気がするので、
今度提案してみようと思います...φ(･ω･｀)
あと、Hadoop周りに関しては、あまりに規模が違いすぎて縁がないというか、
Hadoopの出始めの頃に買った本がまだ手つかずだったり・・・
技術的にどうって前に、そこまでのサーバリソースはなかなか用意できませんし
- 既存の構造
- 問題点
- データ分析するユーザが増えた
- エンジニアがデータを提供するのが難しく（人が限られる）
- 改善へ
- Treasure Data
- データ分析基盤
- ログから分析して改善
- 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
- WebOSが各種デバイスへ
- 課題：機能不足・パフォーマンス不足・エコシステム
- デバイス系機能の標準化
- 例：バッテリー残量取得のAPI化
- FirefoxOSで実装 -> 他のOS
- 例：バッテリー残量取得のAPI化
- 大規模アプリでは遅い
- Webテクノロジー
- UNREAL Engine
- Webだけで3DゲームレベルもOK
- （デモがめちゃくちゃ綺麗で軽くびびる(lllﾟДﾟ) ）
- Webだけで3DゲームレベルもOK
- AOTでロードタイムも軽減
- GCも軽減する手段がある
- デスクトップのリモート実行
- AmazonのGPUインスタンスで画面を描画
- 「赤いきつね」：赤いネクサス5にFirefoxOS
- （やりたいけど、お金が・・・(´-ω-) ）
- OSが軽量なのでメモリを積まなくてもOK -> 安く売れる
- OSカーネルとブラウザが分離されている
- セキュリティパッチをブラウザレベルでできる
- パナソニックがスマートTVをFirefoxOSで
- 今後も端末やデバイスがいろいろ
14-C-4 DeNAにおけるゲーム以外の新規事業の立ち上げ方
DeNAは今でこそソーシャルゲーのイメージが強いですが、
元々はオークションや広告等、様々なカテゴリで事業を行っている会社です*4
とはいえ、今の主軸は間違いなくソーシャルゲーであり、
同時にソーシャルゲー自体がもはや微妙な立ち位置になっているため、
「次」を開拓するのは急務だと思います*5
そんな中でのこのセッションだったわけですが、
「事例」に寄っていて、非常に面白い内容でした(｀･ω･´) ｂ
ある意味では「今風」のやり方ではあるのですが、
そのバックボーンに「確立された技術」があるように見えましたし、
なによりとても「現実的」だと思います*6
- エンターテイメント事業本部
- 非ゲーム事業をやる
- ゲームの次の領域を探す
- マンガボックス
- Showroom
- アイドルのパフォーマンスを配信
- （文字列ではなく）アバターが視覚的にコメント
- UIでニコニコ等と差別化している
- etc...
- 一つの事業部で全部回している
- "やることが多い"
- 基本的な人員構成を揃えつつ、他の部署が全面的にバックアップしている
- DeNAのスクラム
- プロダクト
- みんなで必死に考える -> 作る -> 使われない
- ユーザにインタビュー -> ⚪︎⚪︎機能に需要が -> 作る -> 使われない
- "ニーズを検証する"
- 例1：チラシル
- 検証項目
- 暮らしの中で使ってもらえるか？
- 長期的に使ってもらえるか？
- 紙と同じように使ってほしい
- 練馬区限定でバイト募集 -> 社内に呼んで使ってもらう -> フィードバック
- 検証項目
- 例2：アプリゼミ
- 検証項目
- 長時間勉強して欲しい
- 長時間勉強するのに何が楽しいか？
- 親は子供が勉強しているかしりたいのか？
- 最小限のモックを作って親子に評価してもらう
- 検証項目
- 例3：peko -> USの大学生向け
- 検証項目
- 初対面でもコミュニケーションは成立する？
- 位置情報とか気にする？
- FBログインは使う？
- USの大学前でチラシを配ってテスター募集
- 2週間試してもらう
- ログを仕込んでおいて、何を使ったのかを調べる
- ヘビーユーザにインタビューもする
- アンケートだとFBログインを使いたいのは半分程度
- 実際に使わせると8割は使っている
- 定量化は重要
- 検証項目
- 企画の進め方
- プロデューサーとエンジニアが意思疎通して意思決定
- 9サービス中4サービスはエンジニアが立案
- 全ての意思決定にエンジニアが参加
- UserTesting,com
- リモートでアプリを使ってもらう
- 日本でも徐々に出てきている？
- アーキテクチャ
- 自社のデータセンター
- ソーシャルゲーで鍛えられたインフラ部隊
- たいがいのことは解決してくれる
- 必要ならAWSも
- ソーシャルゲーで鍛えられたインフラ部隊
- スケーラビリティ
- どんなにスモールスタートでも意識する
- インフラ基本構成
- (´･ω･)っ Mobageを支える技術 ~ソーシャルゲームの舞台裏~ (WEB+DB PRESS plus)
- 検討するところ
- DBの垂直分割 / 水平分割（シャーディング）
- 必要かはインフラチームと相談
- Baranモジュール
- インフラに特化した共通モジュール
- ノウハウの有効活用
- コミュニケーション
- ネイティブアプリ
- 通知
- 分析用のロギング
- ログの種類
- 広告
- リリースしても何も起こらない
- ほっといても30-40程度
- 広告を使ってユーザを流入させる
- FacebookAdやTwitterAdはお安い
- リリースしても何も起こらない
- FBAd
- キャラクター系 / 人物系 / アプリのUI系 -> どれが効果的か？
- アプリのUIを見せるのが一番クリック率高かった
- オフラインプロモーション in US
- バーで「ビールをおごるからアプリを入れて」
- キャラクター系 / 人物系 / アプリのUI系 -> どれが効果的か？
- 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周りの情報収集ですかね・・・(´-ω-)
*2: とはいえ、Rubyだって当初は「こんな遅い言語は使えない」と言われていたそうですが、今は時代が変わり、むしろメインストリームの一角です
*3: どちらにせよ、何年も先の話でしょう。でもRuby界隈の人なら考えそうな話で・・・
*4: GREEに比べると、圧倒的に「手堅い」イメージがあります。でなければ球団とか持てません
*5: とはいえ、GREEやソーシャルゲーに特化してしまったWebゲーム会社に比べればはるかにましかと
*6: 後に出てくるニコニコの事例は、たしかに「ハイレベル」ではあるのですが、まだ「教科書通り」のレベルから大きく離れていないというか・・・(´-ω-)
*7: C++の有名人を雇用（？）したりもしているようですが・・・Σ(ﾟДﾟ)ｶﾞｰﾝ
*8: Android版Firefoxのキャンペーンで当たったフォクすけぬいぐるみは、家宝として大事にしまってあります(*ﾟ∀ﾟ)=3
Developers Summit 2014 1日目 まとめ
2009年から参加してますので、今回が6回目のデブサミになります
Developers Summit 2014：開発者のためのITカンファレンス
今回のテーマは「Story」だったのですが、
これはとても大事なテーマだと思います
何かの技術を適用する際に、その意図や背景、適用すべき状況、
いわゆる「コンテキスト」がとても重要です
実際、今回の発表では、「こういう状況で使える」といったコンテキストの話や、
「現実にはこのように適用した」という事例などが多数ありました
正直、デブサミで聞いた話が、実際の業務で即座に生かせるかというと、
私を含め、たいていの方にとって相当敷居が高いと思います
でも、「今」適用できないとしても、「いつか」は可能かもしれません
だからこそ、「いつか」が具体的にどのタイミングなのかを知るのに、
適用に至るコンテキストやプロセスが重要なのだと思います
なお、どうでもいい話として、
今までは紙でメモを取ってBlogに起こしていたのですが、
今回からはiPad mini + Appleキーボードでデジタルにメモを取りました
基本的には問題なかったのですが、
不安定な膝の上での入力はやっぱり大変なのと、
メモが長くなってくるとEvernoteが落ちたりで、なかなか大変でした(´-ω-)
あと、Win/Mac/AndroidはATOKで統一しているのに、
iPadだけ違うので、のってきた時に限ってイライラしました
Evernoteとの同期機能もあったはずですし、
次に同じようなメモを書くことがあったら、
ATOK Padを買っておいてもいいかもしれません
http://www.justsystems.com/jp/products/atokpad_iphone/
さらにどうでもいい話として、
昨年まではメモそのまま＋αの形式でまとめてましたが、
今回からは内容に対する感想とか気になる点を中心にまとめます
というのも、最近は講演の後すぐに資料が公開されるため、
不確かなメモに頼るより、そちらを見た方が間違いないからです*1
ある意味普通ではあるのですが、
せっかくデジタルメモを取るようにしたのに、
それを使わないという矛盾が・・・Σ(ﾟДﾟ)ｶﾞｰﾝ
13-D-1 JavaからJavaScriptへ！HTML5適用から見えた次世代業務アプリケーション
エンタープライズ系の開発も今後HTML5になっていくというお話だったのですが・・・
おそらく、私が部屋を間違えたのだと思いますΣ(・ω・ノ)ノ
もちろん、業務系もHTML5になっていくという流れは間違いないと思います
だからといって、既存のやり方がもうダメってこともないはずです*2
現状でも、フロントエンドとバックエンドAPIは切り分けられている*3わけで、
フロントエンドがHTML5になったからといって、
バックエンドのJavaがすぐに変わるとは思えません
JavaにはJavaのメリットがあり、すぐにNode.js等に置き換わるわけでもなく、
HTML5を取り巻く技術環境にJavaが対応しない、というものでもないでしょう*4 *5
技術的概念と実装は必ずしも依存関係にあるものではありません
一番違和感があったのが、「NetbeansやEclipseを使わずGit」というお話です
「エディタ」と「バージョン管理システム」というカテゴリの違うツールを、
同じ文脈で比較されるのは違和感がありました
「JSPなんか捨てろ」という話もありましたが、これも実装手段の話でしかなく、
HTML5のコードをJSPで記述して出力してもいいはずです
「最新のツールや技術で開発していこう」ってメッセージはわかりますが、
「古いものを捨てていこう」には違和感があります
「マネージメント層」や「経営層」へのメッセージとしてはいいのでしょうけども、
「開発者」へのメッセージとしては違和感を感じた、ということです
なので、「部屋を間違えた」のかな・・・と (´-ω-)
13-B-2 グリーにおけるChef導入事例 ～既存の資産を活かし新しい技術を導入する～
エンタープライズ系の話は私には合わないと思ったので、
予定していたD-2からこちらに移りました
Blogで紹介されていた内容の詳細版とのことでした
グリーのインフラに Chef を導入した話 | GREE Engineers' Blog
最初からChefを使うと決めているケースはともかく、
普通は何か問題があるからインフラの一元管理を考え、
その手段の一つとしてChefを使うってことになると思います
実際、GREEでも最初は独自の管理システムを使っていたそうですが、
そこからChefにどう橋渡しし、共存しているかという、
現実的で参考になる事例だったと思います(｀･ω･´) ｂ
なお、資料があまりに良くできており、
そちらを見てもらえば全部けりがつくので、
メモ書きのまとめはしませぬ
13-B-3 社内システムの構造と設計、実装のはなし
実は、私の仕事はある意味「APIの整備」だったりするので、
この発表にはものすごく共感しました(｀･ω･´) ｂ
社内向けとしてもそうなのですが、Webサイトを運営している場合、
ユーザに提供するデータモデルと、社内に提供するデータモデルは紙一重だったりするので、
データ層でRESTfulなAPIを切っておいて、ビジネスロジック層で組み立てる、ということをしてます*6
しかも、View層とビジネスロジック層で言語そのものが違ったりしますが、
それでも問題なく動いてしまうのは、やはり「API」の力であり、
「REST」のすばらしさであり、「JSON」の柔軟性だと思います
発表にもありましたが、curlで気軽にテストできるってものすごい楽です
面倒な実装をAPIに閉じ込めておいて、
誰かに提供するときはcurlをsystemで読んでもらうとか簡略化もできますし
- Open Web
- OAuth
- WebAPIの制限（回数制限等）
- トラフィック/レスポンスタイム
- コストを誰が払う？
- 互換性の問題
- Close Web
- 社内サービス
- 機能＞性能
- ライフサイクル長い
- 使えるうちは使ってしまう
- ターゲットユーザ＝自分
- 問題点
- 情報と権限の分断
- 情報と機能が冗長
- 無駄が多い
- UXの欠如
- 作りが適当
- 「自動化」の障壁
- サーバごとに仕組みが違う
- 全部入りでアップデート不能
- "シンプルにしたい"
- 権限の分断を最小化
- 普通の会社なら権限はフラットで良い
- 参照は複数の方法を
- ブラウザ/API
- モジュール化
- 社内システムほど他システム連携を考えてAPI化
- APIが維持されていれば、裏側はどう変わっても構わない
- APIの互換性を保つ
- プロトコル
- テータ構造
- 意味的な一貫性（戻り値等）
- クライアント要件の普遍性・不変性
- "ドキュメントはどこかにいってしまう"
- 人の目でわかるフォーマット
- 運用できる＝アップデートできる
- 人の目でアップデートの成否を確認可能
- パフォーマンスより容易さ
- 言語を超えられる疎結合
- 動くことが大事
- まず動かす
- 必要になったら作る
- 機能を切り刻む
- 修正を最小化
- 追加する機能を細切れにすす
- 組み合わせて実現する
- 将来の要件定義はそもそも難しい
- 社内システムで新しいものを試す
13-C-4 iOSにAndroid、百花繚乱モバイル開発環境を比較する
先ほどのレポートでも書いたように、私の得意分野も仕事も、
どちらかといえばバックエンドAPIです
とはいえ、フロントエンドがあってのバックエンドであり、
大きな会社ならともかく、小さな会社では両方セット担当ってのはよくあるはずです
なので、フロントエンドの情報にも興味があります
とはいえ、AndroidではJavaを書き、iOSではObjective-Cとか、
正直いちいち面倒なわけで、
一度に書けるって怠惰ですばらしいと思うのですよщ(ﾟДﾟщ)
このセッションで誠実だと思ったのは、
全て「自分が触れたことがあるもの」に限定されていたことです
なので、比較されていた情報も、深掘りされたものが多くて参考になりました
個人的には「Sencha Touch」と「Xamarin」に興味をもちました
Delphiは・・・興味はあるものの、C++とかは使えないので(´･ω･`)
あとはやはり「Unity 3D」ですか
ここではあまり書けないのですが、某延期しまくりのネットワーク専用3Dゲーが、
どうもUnityで動いているようで、やはりゲーム界隈だと今は主流なんじゃないかと *7
- うまいこと両対応させたい
- HTML5＋JS
- LL+Framework
- Mono
- Xamarin
- Unity
- メリット
- Unityは事実上のデファクトスタンダード
- UnityはBoo（=Python）/JS（UnityScript）が使える
- デメリット
- おすすめ
- Xamarin：普通のアプリを作るには向いている（例：紅白アプリ）
- Unity：ゲーム
- 用途で使い分ける
- Native
- 最終的なおすすめ
- 一般的なアプリ：Xamarin（MSサポート） / Delphi
- エンターテイメント系：Unity3D
- 会社（ゲーム）ではUnityばかり
13-D-6 快適さはWebサービスの生命線！Webアプリのパフォーマンスを最高にするために心がけること
「Akamai」については皆さんご存じと思いますが、
サービスの概要について、もうちょっと突っ込んだ話がありました
HTMLそのものを書き換えたり、画像URLを書き換えたりと、
思っていた以上にドラスティックな仕組みになっているようですが、
ユーザからすると「同じように見えればいい」わけです
画像なんかも解像度を落とす等、相手の環境に合わせて自動選択・配信しているようですが、
さすがにそのレベルの仕組みを自前で汎用的に構築するのは難しいわけで、
その辺がお金をもらうポイントなんでしょう
- コンテンツをクライアントに表示させるまでの時間をいかに短縮するか？
- Tim Berners-Lee says：混雑が最大のWeb阻害要因になりうる
- MITで研究 => スピンアウトしてAkamai
- ルーティングのコントロールが難しい
- IXから1ホップでAkamaiのサーバにつながるようにサーバを配置している
- 最大風速21.6Tbps
- 1日のピーク10Tbps
- Walmartの論文
- コンテンツの表示が遅いほど注文に結びつかない
- but、サイトはどんどんリッチ化複雑化
- 「状況に応じて最適化する」
- AQUA Ion
- アクセラレーション
- 日本の回線は速い => キャッシュは効果が薄い
- それでも他の要因で速度を上げられる
2日目に続く・・・
*1: 決してメモを整理するのが面倒というわけでは・・・ないと・・・思ふ(´･ω･`)
*2: 「HTML5があればFlashはいらない」とじょぶずは言ってましたが、HTML5を捨ててネイティブにいったFBの事例もありますし、むしろAppleがどんどんプロプライエタリな方向に進んでいる気も・・・
*3: ・・・そうなんですね(´･ω･)？
*4: 実際、Java8は久々にJavaを触ろうかと思わせる、良い作りをしていると思います。既存仕様を生かしたまま、あれだけの変更を加えるのは大変だったでしょう
*5: そもそも、最近Scalaが人気だったりするわけで、ベターJavaの需要は十分にあるし、TwitterだってバックエンドはScalaです
*6: 昨年ちょっとだけ触れてます(´･ω･)っ http://parrot.hatenadiary.jp/entry/2013/09/03/112657
*7: そのゲーム、元々はPCゲーで長いこと評判だっただけに、クライアントの出来はいいのですが、ネットワークゲーが初めてということもあり、ネットワーク周りの設計が雑すぎたようで、クローズドβではあまりのひどさに閉口しました(´-ω-) 最新のテクニカルβはだいぶましになってましたが、ゲームとしてはまだ細かいところが見えてないのが難しいところで キャラ造形のクオリティは高いのですが・・・ さて、どのゲームでしょう？Σ(・ω・ノ)ノ
