無気力生活 (ノ ´ω｀)ノ ~゜

脱力系エンジニア。てきとーに生きてます。

BREAK TIMESの勉強会に参加してきたメモをまとめてみた

WEB 勉強会 BREAK TIMES

今年2014/8頃に開催された、PR TIMESさん主催の勉強会レポです。
前回のイベント情報はこちら: http://breaktimes1.peatix.com/

当時は、自分の転職とかその辺に時間取られて、メモを公開するタイミングが掴めず…。
かなり、学びや発見多かった勉強会だったために、メモをお蔵入りさせるが偲ばれまして、今回のこのタイミングでまとめてみた次第であります( ･`ω･´)

さっそく、メモのまとめを書いてきます。

PR Timesの紹介

まず最初は、 勉強会を主催したPR TIMESさんの発表です。プレスリリースの配信掲載サイトを提供している企業。
PRサイトを運用していくときのノウハウを、BreakTimesブログで公開しているそうです。

どうやって運営しているか

アクセス解析して、指標を元に改善していく PDCAを回して、運営していっている。

主に、Google Analytics使って、

  • ユーザーPV
  • コンバージョン 。

また、ベージ毎のPVや、ヒートマップ(ページ内のユーザーが見ている部分)のデータを抽出した上での最適化等、いかにコンバージョンを高くするか、に絞った改善などをも実施している。

サイト改善するときに指標を見て、どういうテストをしているか

ABテスト(サービス紹介ページ)

  • 以前は画像だったけど、動画いれてみるテストを実施
  • ユーザーが、途中で離脱していたけれど、この対応を入れると、下までスクロールしてくれるようになって、コンバージョン高くなった

多変量テスト

  • 複数のオプションを比較してやるABテスト
  • ABテストは2要素だが、これは複数要素の組み合わせ
  • 複雑なデータをとれるが、分析に必要なPVが少ないと、組み合わせが増えた分判断が難しくなる

ABテストの発展系。 より複雑な条件の上で、どのような動きをしているかを分析し、全体の傾向から改善部分を導き出すことが狙い。
条件が複雑になればなるほど、ケースの組み合わせが増えて、解析が大変になる。

多腕バンディット

  • Google Analyticsでも使える
  • パターンの表示割合を増やして、より最適な解が出るまで繰りかえしていく
  • 結果に基づいて表示を変えていくにしたがって、少ないコストで最適な解が得られる

多変量テストでは、ケースの組み合わせを増やして傾向をみる分析方法。
多腕バンディットは、出てきた結果を元に、更に踏み込んだ条件やケースに絞っていく。それを繰り返すことで精度高い分析を得られるようにした解析手法。

PR TIMESさんの発表では、PR TIMESさんが自社サービスの改善を行う際に、その改善部分を導き出す話を聞くことができました。
配信するプレスを、より高く、効果的に配信するためには、まず問題を見つけて、最適な手法で解決する。そのフローが大事ですね。

多腕バンディットを用いたプロダクト改善については、最近cookpadさんが記事をあげていました。興味のある人は目を通して見るとよいと思います
http://techlife.cookpad.com/entry/2014/10/29/102036

UI/UXとはなにか。 UI ≠UX

イベント開催前は、セカイラボの森脇さんが、UI/UXの設計の話をされる予定でしたが。 残念ながら、森脇さんが、体調不良で未参加となり…

代打で、日本ディレクション協会の小嶋さんが発表されていました。 小島さんは - フリーランスのディレクター - Webデザイナやって、ディレクターに というバックボーンを持った方です。その方が話すUI/UX論だったので、若干ディレクタ的な目線のお話が聞けました。



ここからメモ

UIとUXはレイヤーがちがうということ

UXデザイン

  • 去年くらいからバズワードってる
  • リサーチして、ユーザービリティ、インフォーメーションアーキテクチャをして…
  • どういうコンテンツを、どこに、どう置くのか

⇒ UXデザイン ！！ なんのこっちゃよくわからん

実用性を設計する = UXデザイン

たとえば、普段使う椅子。椅子といってもそれぞれ全くタイプが異なる。

  • 柔らかいならいいの？
  • キャスター付きで動くならいいの？
  • 革張りならいいの？

シックな内装に合う椅子、バーに合う椅子、コンサート会場に合う椅子… それぞれ、場、シチュエーションによって、最適な物が異なる

⇒ そういった設計をしていくのがUXデザイン

UXデザインのために考える事

  • コンテンツ全体の目的、用途を想定しておく。
  • ユーザーがどういう反応をするのか？
  • どういう行動をするのか？

問題の定義を明確にして、想定するユーザーに正しく価値を伝えることが大事。

UIデザイン

各機能に合わせた適切なUIを作るもの。UXデザインのレイヤーより、下に位置する。 まずは、どんなUXを与えていくか、ありき

  • 画面にとらわれ過ぎない！
  • 使う人の気持を考える。

UXとUI の 有名な事例

NORDSTROM (大きな百貨店) IPADアプリのUX改善事例

  • 実際の店舗にPC持ち込み ＋ 実際のお客さんに使ってもらって、即座にフィードバック→ 大量に付箋が貼られては剥がされていく。
  • 一週間で改善できるところまで、現地でやって開発に活かす方法。
  • すぐに本格的な開発には入らない。ペーパープロトタイプベース。
  • アプリだけでなく、アプリをどう触ってもらうか。テーブル台にのせて使ったりする？
  • アプリの使い方の設計。どういうシチュエーションで、どんなふうに？

ユーザーが実際に使っている、リアルな世界の問題を解決するために、開発を行っていく。

ここまでイメージをしながらちゃんとUIを設計する必要がある。特にスマホ。しっかり考えてやる、やらないで大きく差がつく。
広告の視点だけでなく、ツールとしての側面まで設計していくのは当然。

UX、UIとは、と安易に語られがちで、 ユーザーに価値を伝える最適な方法かどうか、はいつの間にか忘れてしまったりしてました。 この発表は、そういう視点を思い出させてくれる良い内容だったと思います。

実際にユーザーさんに使ってもらうことほど、良いデータが取れることはないので、プロトタイプ時点からユーザーを巻き込むことの大事さを、いい感じに理解できた発表でした社記

HTML5 概要 コードサンプル

この勉強会の目玉ともいえる、お話でした。 W3Cの中の人の話が聞ける機会は、本当に貴重。

講師は、Daniel Davis氏(http://html5experts.jp/ourmaninjapan/)。元Operaの英国人。 最初の触りで、英語セッションの雰囲気を漂わせつつ、参加者にある種の覚悟をさせてましたが、 本人、日本語ペラペラで、普通に話聞けました(；・∀・)

HTML5で新たに採択されつつある、仕様の話が多めでした。

当日の資料は公開されています。
http://breaktimes.hatenablog.com/entry/2014/10/14/194903

深く知りたい方は、この資料の方を見ると捗るかと思います。



ここからメモ

HTML5とはなにか

  • HTML：
    構成を決める
  • CSS：
    見た目を決める
  • Javascript：
    動きを決める

つまり、

HTML5 = HTML4 ＋ 新しい仕様 − 古い仕様

そもそもHTMLとは

HTML = Code onxe , rearch people everywhere.
⇒ PC、スマホ、問わず使える。汎用的な仕様。

大事なのは、正しいマークアップをすること - headerタグ等を適切に使うと、検索エンジンが有利に働く

現状では、ブラウザ差異が小さくなってきた。

ブラウザが標準化されてきた。どこでもそこそこ同じコードで動く。
まだ、完全に対応されているわけではないが、昔よりはかなりマシになっている。

HTMLは、WEBだけで使われている…わけでもなくなってきた

  • HTMLアプリでも、ハードを操作できるように。
  • 車等 、 ハードウェアをHTMLアプリで操作するような仕組みを、W3Cは作ろうとしている。(車関連のAPI策定、等)

WEB標準大事； みんながわかる = みんな使える

HTML5が目指す先。やろうとしていこと。

  • より簡単
  • よりはやい
  • よりフレキシブル

これまで以上にいろいろなことが、早く、簡単に実現できるようになる。

UserMediaAPI

  • ユーザーのカメラとマイクのデータ取得
  • 必ず、ユーザーに同意を求めるダイアログを出すようにしている。このタイアログは無効化できない。
  • 取得したカメラのデータは、javascriptで操作できるようにしている。
  • API仕様は、汎用的に使えるように設計している。

グローバルにある、navigatorオブジェクトを経由して、使用する。

  // 使用できれば使うし、ダメだったらエラー処理呼ぶように使える。
  navigator.getUserMedia({video:true}, successCallback, errorCoallback);

GeolocationAPI

結構前からある。4年前くらい？ ユーザーの現在場所を使って、地図情報が取れる。

navigator.geolocation.getCurrentPosition(callback: position);

Device Orietation API

デバイスの向き、加速度とか取れる
IOSが先立って実装。標準の方が遅れてた。 取得したデータをサーバーに乗っけて、いろいろできる。 車載ブラウザあたりで使えると、新しいことができる可能性が。

window.ondevicemotion = function(event) {

   // event.acceleraionオブジェクト = { x, y, z} が取得可能

   // event.rotationRateオブジェクト= { alpha, beta, gamma }が取得可能
 }

Systen Infomation API

システム情報を取得できるAPI。 気温、気圧、湿度、騒音、距離感

まだ全部はできていない。ので、ブラウザには対応していない。APIはできてる。 デバイスハードウェアが必要になってくるので、自由に使えるようになるまで、時間がかかりそう。

  naviator.system.monitor("Thurmal", successCallback);
  // event.thermal { state = 気温}

デバイスを介する兼ね合いもあり、データ取得が間に合わない場合は、なにもしないように動作する。

WebSocket API, WebRTC

リアルタイムでインタラクティブなデータ通信で、HTTP使うのは遅すぎる。

WebSocket： 使いやすい。けど、性能そこそこ。
WebRTC： 早いけど使いにくい

WebScoket

  • コネクションのackを、最初の一回だけやって、後はやらない。早い
  • 同時に送ることができる。受信もできる。
  • ただし、サーバーは経由する必要あり。

WebRTC

  • 最初の一回だけサーバー通信する。
  • あとはP2Pで通信するようになる。
  • サーバーを経由しないので、はやい
var socket = new WebSocket("ws://address");
socket.onopen = { }

SkyWayという、WebRTCを簡単に試せるサービスがあるので、簡単に試せる。

Offline Storage

複数やり方がある。

  • ServiceWorker
    API策定中
  • IndexedDB
    ブラウザによって動きが違うのでライブラリ推奨
  • LocalStorage
    現時点、すべてのブラウザで使える。信頼性が高い。
var online =  navigator.online;
window.lodclstorege["Name"];

LocalStorageは、5MBくらいデータ持てる。一時データとしては十分な容量。

Responseive Images

デバイスサイズによって、表示する画像を切替えるもの。 マルチデバイス対応が容易にできるようになる。

  • <picture>要素
  • srcset属性
    まだ入ってない。開発版ブラウザには入っていたりする。 ブラウザがサポートしてなくてもエラーはでない。画像がちゃんと表示される。
<picture>
  <source media='(min-width: 45em)' srcset='large.img'>
  <img src =""> <!-- 回避策 -->
</picure>

未来のはなし

HTMLでハードウェアを操作できるようになれば、 - スマートカーを実現して、走行データを収拾した後、渋滞予測やの算出など可能に。 - 無人ドローンを用いて、農場の監視を行い、蓄積したデータから、農場の管理を自動化したり。

現時点で、Hueという商品がある。これをWEBで操作できるようになると、面白いことができそう。

HTML5でやっていくこと、できることの解説が詰まった、濃い内容だったと思います。
当日は、実際にビデオチャットを、HTMLだけで実現するデモが織り交ぜられての内容でした。

そういえば、昨日、ちょうどHTML5 が勧告となった速報が流れましたね。
http://www.w3.org/2014/10/html5-rec.html.ja

この話を聞いたときから、ずいぶん進展があったようです。

今後、語られたいろいろなAPIが実際に普及し、使われることによって、 今現在では、スマートフォンしかできないことが、WEBにもできる。そういう時代がきそうな予感がします！

終わりに

で、なんで唐突にこのメモを公開する気になったかというと、

PR TIMESさんの勉強会が、近日開催されます！

http://breaktimes.hatenablog.com/entry/nite2



次回の内容も、かなり勉強になりそうですね。これを無料でやってくれるのだから、大変ありがたいことです(´ω｀)

良い勉強会なので、行ったことない人は、行ってみるとよいのではないかと思います！

自分は、絶賛炎上中で行けそうにないので、 行った方はレポして頂けると大変嬉しいです(´・ω・｀)

Ruby+Railsの開発で使っているもの、について書いてみる

ruby rails RubyMine

いろいろできて、いろいろ見えないRuby

今現在は、Rubyをメインに開発進めてる仕事してます(｀･ω･´) 前職はC#でWeb開発をしていたためか、なかなかRubyに慣れない日々が続いております。

暗黙的にメソッド生やされると、なにやってるか追うのが大変つらいので、用途絞って使って頂きたく候。
という、無駄なボヤきは、見なかったことにしてください。

そろそろ、仕事で触って2ヶ月くらいになるので、振り返り含めてまとめてみます。

エディタ

RubyMine使ってます。エディタというよりIDEですね。

vimにプラグインいれまくったり、Atomをいろいろイジってみたりといろいろやりましたが、コードの検索精度とかその辺が強力すぎるので、RubyMineに落ち着きました。
ゆとラーなので、楽な方に流れるのは、まあいつものこと。むしろ正義ですらある( ･`ω･´)

とはいえ、使っている機能はそんなに多くないです。キーバインドも対して変えてないし。

仕事で使っているショートカットとか、

  • CMD + SHIFT + O
    Fileサーチ。検索したソースファイルに一発で飛べる。

  • CMD + B
    定義元ジャンプ。メソッドなどの定義している位置へ、一発移動できます。
    とはいえ、動的言語。完全な補完は無理で、複数同じ名前で定義している要素があると、候補の中から探す作業が必要になります。
    まーこれはしゃーない。

  • CMD + @
    一つ前のジャンプ元に戻る。CMD + Bした後によく使います。

こんなもん。

他の機能は、まだショートカット覚えきれてないので、Find Action(Sublimeのコマンドパレットみたいなやつ)を駆使してやりくりしてます。

リファクタリングの機能が強力なのは大変よいです！
ただ動的言語なので、稀に暴走して大変なことに…。リファクタ後は、必ずDiffチェックするようにしましょう。

Bash

IDE使うといっても、Gitコマンド使ったり、その他もろもろのツールを使う時は、やはり黒い画面を使う必要があるものです。
ある程度Bashの使い心地を向上しておいた方が、いろいろ捗ります。

Terminal.appは早々にやめて、iTerm使ってます。単純にカラースキームの変更が楽だから、ですね。

あと、今自分がどのブランチにいるか、がひと目で分かるようになっていると捗る。

Git使って開発していると、頻繁にブランチを行き来するので、間違った操作しないように、注意するのは大事なことです。間違ってmasterブランチにpushすると大変面倒なことになりますしね…。

自分は、Git-Promtとか使って、常に表示できるようにしています。
http://mironal-memo.blogspot.jp/2012/08/git-completion.bash.html

使用するためには、.git-prompt.shを、homeに配置します。

 curl -l ”https://raw.githubusercontent.com/git/git/master/contrib/completion/git-prompt.sh" > ~/.git-prompt.sh

設定は.bash_profileにこんな感じで。

source ~/.git-prompt.sh
GIT_PS1_SHOWDIRTYSTATE=true
PS1='@\u \W$(__git_ps1 "[\[\033[32m\]%s\[\033[0m\]]")\$ '

こんな感じに表示されるようになります。べんり！！

f:id:gdgd-shinoyu:20141027010849p:plain

SQLクライアント

コマンドラインつらい(；ω；`)なのでGUIでも操作できるやつを使います。
大昔にRails使った開発やったときは、某Phpmyadminとか使ってましたが、辛い。

Sequel Proがマジ便利です。全部これで済ませられます。個人的には鉄板なツール。

他にも、MySqlWorkbenchとかあるのですが、使い勝手がそれほど良く感じなかったので、すぐ乗り換えましたね…。なんかストレス溜まるんですこれ。

Gem

汎用的に使えるやつを上げてみる。大体、どんなプロジェクトでも、汎用的に使えると思います。
作成元か、使い方を載せてるリンクを同時に貼っておきます( ･`ω･´)

Better errors

Railsのエラー画面を綺麗にするやつ。RailsでWeb開発するときは必携ですね。
http://morizyun.github.io/blog/better-error-gem-rails-ruby-rack/

hirb

rails-console(irb, pry)でActive Record結果を整形して表示することができます。
http://blog.dakatsuka.jp/2011/05/14/hirb-rails-console.html

pry

Ruby-Console irbを機能拡張したもの。実行結果のハイライトや、shellを実行できる機能、他の便利なGemが使えるようになること、等メリット多めです。
http://morizyun.github.io/blog/pry-command-rails-ruby/

pry_rails

rails start でpryが起動するようになります。
http://qiita.com/yaotti/items/c6e850010f36acedb0e1

railsは、標準だとirbを立ち上げるので、Railsでもpry使いたいときは必須です。

pry_byebug

ラインデバッグできるようになります。
https://rubygems.org/gems/pry-byebug

コード上に、binding.pryと書くと、そこを通ったタイミングでブレークするようになります。
unit_testや、Rakeタスク通すときにも、止まるようになるので便利。

ただ、これruby2.0以上でしか使えないので、それ以外の環境では、pry_debuggerなるものを使います。使い勝手はどちらも同じ感じですね

pry_doc

通常、Rubyでは、Deepな領域であるC側のコードを見ることができません。
pry_docsを使うと、pry上でではありますが、このコードを見ることができます。 http://qiita.com/joker1007/items/42f00b12c65bbec0e50a

メソッドの内部構造を知ることは、効率のよい開発をするために必須だと思っています。
なにかわからんことあったらガンガンコード読むと、いろいろと捗るようになります( ･`ω･´)

pry-stack_explorer

pry上で、コールスタックが参照できるようになります。デバッグに重宝します。
http://shirusu-ni-tarazu.hatenablog.jp/entry/2012/11/04/180908

動いているのに、そのメソッドなりクラスが見つからない、メタプログラミングなダークサイド臭のエラー特定するとき、あると大変助かります。

rails.erd

ER図をかいてくれるツール。
http://qiita.com/satton_maroyaka/items/55e6cf42bd677c94d0d5

開発中に、テーブル定義書的なドキュメントを作るときに使えます。
また、モデル間のRelationを見るためにも必携ですね。 実テーブル自体が、リレーション持っていなくても、RailsのAssociationに従って図を生成してくれるので、Railsを使うときは、これ使った方がよいですね。

spring

railsの起動を早くしてくれるやつ。
http://blog.livedoor.jp/sasata299/archives/51925482.html

裏側でrailsのプロセスをあげっぱなしにしておいて、それを使うようにすることで、起動時のライブラリロードとかの、あれこれを解決してくれるようです。

終わりに

Rubyは良い言語ですが、それは、たくさんのRubistが公開してくれている情報や、Gemが豊富にあるからだと思っています。

それだけ、開発者を惹きつける何かがあるんでしょうね。

自分は、「型付け欲しいなぁ・・・」とかボヤきつつ、Scalaの方を見てたりしていますが。

まだそれを理解できるところまで、Ruby深く触っていないので、まずはいろいろと使い倒してみたいと思っています( ･`ω･´)

Rails+MySql→Rails+MariaDBで、mysql2 Gemでエラー出る問題

雑記 Rails

Spiderエンジンとかその辺の検証をするために、開発で使ってたMySQLをMariaDBに変更した時の話。

Spiderエンジンについては、開発者の方のスライドを見ていただければ。

要は、シャーディングをアプリではなくDB側で解決させてしまおう、というコンセプトのシロモノ。
まあ、このへんはある程度検証できたら、まとめるので今回は置いておく(｀･ω･´)

問題は表題の通り。環境は、Rails4.0.8 + Ruby 2.1.1。
すでに入っていた Mysql 5.6をbrew uninstall mysqlで削除した後、brew install mariadbする。おもむろにmysql.server start

ローカルオンリーのため、テキトーにrootで。

mysql起動させたので、rake db:migrate && rake db:seedやるとこんなエラーが発生しました。

rake aborted!
Incorrect MySQL client library version! This gem was compiled for 5.6.20 but the client library is 10.0.13-MariaDB.
./config/application.rb:7:in `<top (required)>'
./Rakefile:4:in `<top (required)>'
(See full trace by running task with --trace)

どうやら、SQLクライアントのmysql2のGemが、導入したMariaDBには対応していなかった模様(´・ω・｀)

gem uninstall mysql2 後、 再度、gem install mysql2なり、bundle install 実行で、mysql2入れなおすと、エラーが解消しました。

導入されているDBによって、Gemの自動判別とかやってくれてるんですかね。

データ分析担当者向けセミナー 「gloops流データアナリストの部署間連携術」に行ってきた

データアナリスト ソーシャルゲーム

昨日、2014/10/8に開催された、gloopsさんのデータアナリスト向けセミナーにいってきました(｀･ω･´)

私はただの1エンジニアではあるんですが、今後自社プロダクトの分析環境つくる仕事が待ってそうな気がするので、データサイエンティストの皆様の中、混ざりこんでまいりました。

仕事が長引いて、遅れて参加になったのが残念(｀；ω；´) CMの効果測定話聞きたかったなぁ… とはいえ、後半の部署間連携の話しはガッツリ聞けたので、かなり有益だったと思います。

gloopsさん、話には聞いていましたが、かなり徹底してデータ解析に力入れている感を感じました。ここまで徹底的にやれると、プロダクトの改善がはかどりますね。

ここから、セミナー内容のメモを元に、雑多なまとめを紹介します。

2014/10/15
先週くらいになるんですが、Social GameInfo さんが素晴らしいまとめを公開しております。こっちの方がよく纏まっているので、詳しい内容はこちらへ。 【セミナー】データアナリストが他部署とうまく連携するコツは「問題設定」…『スカイロック』の大規模プロモーションを題材に | Social Game Info

プロダクトと一緒に、どう走っていくかの話

いまやグループスさんの看板コンテンツとなった、「スカイロック」のCM配信と、それに付随するゲーム施策の話。

キャラデザがアレだとかいろいろ話題になった作品ですが、天下の集英社がなにも言わんとこみると、許可はもらってる感じなんですかね。それはそれとして。

スカイロックのユーザー獲得のため、CMをマスで配信していたそうです。割りとゴールデンタイムに配信してた印象。自分も何回か見たことあります。
CM配信と合わせて、ユーザー獲得のための施策を22本ほど平行して走らせていたそうです。普段が8本ほどらしいので、かなり多めの施策を走らせていたみたいですね。

この施策を決定するために、ディレクタとデータアナリストが、どのような施策を打つか調整していたそうです。 gloopsさんでは、

「HBU」

という指標を第一に行ったとのこと。
この指標は

  • 直近30日間で、ほぼすべての日数を遊んでいるユーザー

を意味しているそうです。この数値が高ければ高いほど、ユーザーが楽しんで率先して遊んでいることになる。
なので、この数値を向上させていくことが、プロダクトの成長につながる、とのこと。

つまりHBUを向上させる≒「継続率」の向上、が言えるのですが、この数値を向上させるのはかなり難しいとのお話でした。

ユーザーがゲームをやめるタイミングは、ユーザー自身が感じたことがトリガーとなるため、施策単位でコントロールすることが不可能であると。
また、「この施策があれば万全だよね」という、銀の弾丸まがいのものは存在しないため、闇雲に施策を打っても改善していかない。

gloopsではどうやったか

そこで、gloopsさんでは、プロダクト側と、自社データアナリストが連携して、

  • どのタイミングで、ユーザーが飽きてしまうのか？
  • ユーザーのレベルや、セグメント毎に、なにか関連があるのか？

を分析して、今回のCM施策に役立てたそうです。その時の指標として、例に出されていたのが、

  1. ゲーム内の強さが、ある数値を超えると、継続率が伸びる
  2. ゲーム内のクエスト進行度が、一定より上になると、継続率が伸びる

の2点だそうです。これは普段の運営で蓄積したデータを使って出した指標です。
この指標を元に行った施策で、セミナーで紹介されたものはこんな感じでした。

  • 未インストール者向けに、強キャラクタと進化アイテムを配布する、ログインボーナス
  • 離脱ユーザー向けに、カムバック限定パネルミッション
  • 既存ユーザー向けにも特殊な施策(ここ聞きそびれました)

ユーザーの属性毎に、異なる施策を用意するようにしていますね。

分析と施策

ここで、ちょっと前に書いた、データアナリストの分析結果を思い出してください。
前に戻るのも面倒だと思うので、さくっとコピペ。

  1. ゲーム内の強さが、ある数値を超えると、継続率が伸びる
  2. ゲーム内のクエスト進行度が、一定より上になると、継続率が伸びる

これです。この指標が、即ち「継続率が高いユーザー」の条件です。CM施策はこの条件に合うように、

  • 初心者ユーザーが、一定以上の強さに、すぐ到達できるように、強いキャラクタ配る
  • 離脱ユーザーが、また継続してくれるように、パネルミッションに、クエスト進行度絡みのミッション含める

を狙って打たれました。これすごいですね。仮説があって、データ分析して、最適な施策を導き出す。

実際、この施策を実行した結果、期間中のHBUが1.5倍。売上が期間平均1.1倍ほど、向上がみられた、とのことでした。

分析内容の共有はどうするべきか　- データアナリストがコストハウスにならないために -

さて、このような成果を出した、分析と施策のコラボレーションですが、普通こんなにうまく回るとは思えないです。
データアナリストと企画陣で、データの見方や、必要としている情報が異なりますからねぇ…。
どのように、うまくデータの話共有を行うかどうか、の話題がありました。

データアナリストが分析したデータを、そのまま渡すとどうなるか。
おおかた、膨大なデータにあふれて、どこを見るべきか、の判断に時間かかるようになります。

そうすると、企画陣は、せっかく解析してできたデータを、読まずに放置しがちになってしまいますよね？企画担当者も、プロダクトの改善や、新規施策策定に忙しいですから。しかたない。

では、そのデータをいかにして企画陣に見てもらうか。

gloopsさんでは、企画担当者が分析したデータから、企画陣が興味を持ちそうな、施策に直結したデータに加工して渡しているそうです。 企画担当者も、どんなに忙しかろうが、自分の興味ある、担当している施策に関するデータを、読まずに放置することはないです。

gloopsさんでは、データアナリストに必要な条件として、以下3つ、挙げられてました。

  • 伝えたいことを明確にする
    期待されている、要求されているモノを適切に伝える方法を知っていること
  • 解析する対象自身を知る
    自身のプロダクトは、どのように使われているか、を理解する
  • データを共通認識させる
    データアナリスト以外が、データとどう向き合うか、の意識づくり

もっと自分たちのプロダクトを知り、その分析結果をわかりやすく伝えられるか。データをチームで利用できる空気になっているか。データが正しく理解されるように報告できるかどうか。

最初から全部カバーすることは大変ですが、ここまでできれば優秀なデータアナリストになれそうですね。

総評

仕事切り上げが遅くなり遅れていったため、前半部分のメモがなかったりするんですが、後半の部分だけでも、かなりボリュームがあるセミナーだったと思います。
ただ、今回のセミナーでは、具体的な体制づくりの話には、多く触れられなかったことに、物足りなさを感じたり。これから体制作っていく人にとっては、この部分が一番聞きたいところじゃないかなー、と思いました。

次回も、セミナー開催頂けるとのことだったので、また次回に期待して、参加したいと思います( ･`ω･´)

開発環境(mac)を:beers:まみれにするためにやること

https://assets-cdn.github.com/images/icons/emoji/unicode/1f37b.png

やるたびに忘れるので、個人用メモ程度に。

Homebrew

自家醸造しないと始まりません。サクッといれる。
rubyとcommand line tools for xcodeが必要らしい。RubyはデフォルトでOK。
command line tools for xcodeは導入課程でインストールが要求されてた気がする。まあダメだったら入れる感じで。

ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)"

インストール後、以下コマンド実行。なにか問題あるならエラーなり警告がわかりやすく表示されるので解消しておく

brew doctor

こんな感じで使います。

brew install git

インストールしたモジュールは、/usr/local/Cellar/配下に置かれる(変更はできる)
また、/usr/local/bin配下にシンボリックリンクが置かれる

Homebrew-Cask

brewコマンドで、Chromeのようなアプリケーションを入れられるようになるやつ。
brewコマンドでインストール

brew install caskroom/cask/brew-cask

# アプリインストール
brew cask install google-chrome

インストールしたアプリケーションは、デフォルトだと/opt/homebrew-cask/Caskroom/に配置される。パスは通っているらしく open -a アプリ名 とかで起動できる。

caskroom/versions

Homebrew-Caskはアプリを入れてくれるけども、英語しかない。ユトラーなので日本語ないとつらい。そこでcaskroom/versions。 brew caskの別バージョンアプリをインストールできるようになるやつ。 *1
これを導入することで、日本語パッケージがリポジトリに含まれる。

brew tap caskroom/versions
brew cask install thunderbird-ja

*1:参考: http://www.d-wood.com/blog/2014/03/27_5895.html

デジタルマーケティグ普及の旗手となるかっ!? 株式会社テクロコへ行ってきました

会社紹介

私は、株式会社テクロコ を応援しています
https://www.wantedly.com/companies/techloco



こんにちわ！ 最近、いろんな会社さんのお話を聞きに回っております。 事業の話や今後の目標等のお話、その会社さんの熱意に触れられる。そうところを楽しみに聞かせて頂いてます。

さて、もちろん、そういう良い話だけでなく、困っているお話も伺うこともあります。 よく話題になるのが、 エンジニア不足 の問題です。


近頃、個人でもいろいろサービスを開始できる環境が整ってきたこともあり、様々な企業さんが参入しています。
ただ、優秀なエンジニアは、いろんな企業さんで取り合いになってしまい、なかなか確保できません。
どの企業さんも、人材確保には躍起になっていまして、
ソーシャルでの採用活動を行ったり、エンジニアによりよい環境を用意したり、等、いろいろな試みをしています。

そういった、エンジニアにやさしい環境 をつくった or つくろうとしている企業さんを応援するべく、

勝手に記事を書いていこう

という企画です。 ※掲載許可は頂いております
今後、定期的に会社見学して、いろんな企業さんの紹介をやっていこうと思っています。


さて、この企画、第一号です。
株式会社テクロコ！!

先週の、大雨があった日に行ってきましたorz 油断して傘持ってこなかったせいで、道中コンビニに全力ダッシュするハメになったのは秘密(´・ω・｀)

テクロコさんは、
Web広告業界の大手企業、株式会社オプト さんのグループ企業です。
他のグループ企業さんに、マーケティングツールを開発して卸す事業をしています。
その卸したツールは、グループ企業さんが導入支援した上で、ユーザー企業さんが使われています。

アドテク業界は、今後大きくなっていく業界だと言われています。
参考: http://www.meti.go.jp/statistics/toppage/report/bunseki/pdf/h19/h4a0803j2.pdf
これまで、CMや紙ベースだった企業さんが、より手軽に打て、高い効果が期待できるネット広告に流入しています。 そうすると、その広告を配信する企業や、効果を測定する企業の需要が高くなります。

テクロコさんも、自社開発の分析ツールにおいて、ユーザーさんが順調に増えており、今後さらに導入が広がっていくと思われます。 自分の作ったサービス、ツールがたくさんの人に使われていく。そういう体験はすごく嬉しいものだと思います。

さて、このテクロコさんですが、
今後、マーケティングツール以外にも、様々なサービスを行っていきたいとのこと。
そのためのエンジニア、を募集しているんですが、採用活動に苦慮しているそうです。

どうしても、

  • 目立つサービスを作っている企業
  • スーパーエンジニアがいる企業

に、行ってしまい、なかなか応募が来てくれないんだそうです。

現在、所属するエンジニアさんは、数名程で、組織を作っている途中とのこと。
その組織を引っ張っていけるコアメンバーを募集しているそうです。

一から、会社を育てて見たい人、環境を作ってみたい人には、 大変やりがいがある環境だと思います。

テクロコさんの、エンジニアの私から見て、良い所を上げてみます。

  1. 残業が少ない
    最近、このような募集が増えてきています。
    長く残業して開発するより、早く帰って自主学習する。それを仕事に活かしてもらったほうが、意義があると考える企業が増えているようです。
    テクロコさんも、同じ考えなんだそうです。
  2. 福利厚生が充実
    広告系サービスの会社ですからね。そこらの企業より充実しています。
  3. 今後、大きく伸びる業界
    企業が生産活動を行い、ユーザーさんに届けるため、広告は必要不可欠。ゆえに、今後なくならない業界だと思います。
    手堅い業界は強い!

この記事をみて興味が湧いてきましたら、
次に自分が戦っていくフィールドに、選んでみてはいかがでしょうか？
http://www.green-japan.com/job/27133

第二回ゲームサーバー勉強会に参加してきた

ゲーム開発

7/19(土)に開催された、ゲームサーバーに特化した勉強会についてのメモです。

広くてきれいな場を提供していただいたGREEさん、ありがとうございました。 そういえばGREEさんに入るのは、今回が初めてですね( ･ω･)

今回の勉強会では、以下のようなお話を頂きました。

  • データベースの再入門
    (@nsega様 )
  • 分割と整合性をがんばる話 ソーシャルゲームの整合性対策
    (株式会社gumi 小林様)
  • MMOのサーバーについて「剣と魔法のログレス 〜いにしえの女神〜」の実装例 (株式会社Aiming 山藤様)

スライド資料はまだ公開されてない模様でしたが、一部共有をして頂けるとの事だったので、公開され次第リンク貼っておきます。
今回、書いているメモは、あくまで私個人のメモから抜粋しているので、正確でない部分があるかもしれません。その部分はご指摘いただければと思います。( ･`ω･´)

結構、分量が多くなってしまったことを反省…その分濃い勉強会でした。

データベースの再入門

初心者しかいないと仮定した説明をします、との前置きがありました。内容もDBを使うにあたっての基本的なお話が中心でした。

nsegaさんは、MongoDBの人で有名な方です サーバーサイドの開発、直近だとネイティブもやってるそうです。 DBはPosgtre、Mysqlをよく使うそうです。

2014/08/27
資料が公開されている旨いただきましたので、貼っつけておきます。

ここからメモ

データベースについて

データベースを扱うためには、データの定義を明確にする必要がある。
論理的、物理的問わず、最初に定義を固めておく。

DBMSと、問い合わせするためのSQLには、以下のような種類があり、目的が異なる。

  • DDL (Create等の)データ定義言語
  • DML (Insert等の)データ操作言語
  • DCL (Rollback等の) データ制御言語

複数人で同時に操作する、壊れたら大変なデータ、を扱うときはDB。
DBを使うケース = 検索性重視、障害時のリカバリを迅速に行う、整合性を保証したい場合

必要なデータを探すときは、インデックスがパフォーマンスにかなり影響する。DBで使われるインデックスの特性を理解すること

  • B+Treeインデックス
  • ハッシュインデックス
トランザクションを重視する理由
  • データ更新の並列性を保つ
  • データの整合性を保障する
レプリケーション
  • DBのデータを複製できる。障害が発生しても、ある程度、データが元に戻せる。
  • マスタ-スレーブ構成。Update等の更新は、マスタに対して行う。
    マスタの変更は随時、スレーブに配信する、アプリからのReadはスレーブから。

RDBMSとNoSQLについて

  • RDBMS

    • データの一貫性保つことが得意。SELECTでの複数条件を使った柔軟な検索ができる。
    • 苦手
      • たくさんの通信があるとつらい。
      • インデックス作成などの、構成変更で時間がかかる
      • カラムのパターンが、固定しづらいケースだと苦手
      • 汎用的に使おうとすると、予備カラムが増殖してやばい
      • 結果を早く返すこと苦手(トランザクション効くとどうしても)

  • NoSQL

    • 何種類かある(KV型、ドキュメントベース型、カラムファミリ型)
      • データ分散しやすい。大量データもOK。
      • スケールアウトさせやすい(分割が楽)
      • 安いサーバーでも十分
    • 苦手

お互いが不得意なことを、無理に置き換える必要はない 。適材適所が大事。DBかKVSの選択は、要件を解決するための手札でしかない。

KVSの使いどころは、タイムライン表示とか、リアルタイムランキング。 セッションステートとしても良い感じ 。

データベースを使った使用事例

データモデリング大事。あとで矛盾があっても、手戻りは基本できない。
これから勉強する人は、IPAのデータベーススペシャリストの勉強が、おすすめできる。

  • データの種類と管理方法

    • マスタ系データ
      アイテムとかモンスターそのもののデータ。頻繁にかわることはあまりない
      • M_xxxのようなプレフィックスつけて管理してる
    • トランザクション系データ
      ユーザーデータ。頻繁に更新追加が行われるもの
      • T_xxxのようなプレフィックスをつけて管理してる

  • ER図自動生成
    ジークレストではEclipse使っているので、ERMaster使って、ER図からクエリ自動生成してる

Tips

  • ER図レビュー、ソースレビュー、クエリレビューやる

    • 実行計画を見る
    • リクエスト回数が多すぎないか(ORM使っているとある)
    • 事前に事故防止ができる
    • わかってるエンジニアのアサインが必須になる

  • レプリケーション設計

    • 最初からDB負荷を分散できる
    • レプリケーション遅延を見越して設計する必要ある。マスタ反映後スレーブ反映しているので、若干遅延が出てしまう。タイミングによって、変更が反映されていない情報が取れる問題が。
    • そのため、時にはせっかくスレーブに向けてたSelectクエリを、Master側に向ける必要も出てくる

  • シャーディング

    • 水平分割： レコード単位で別DBに向ける
    • 垂直分割： 1テーブル内の、更新が多い項目だけを別テーブルに切り出す。
      シャーディングすることによって、DB性能、管理しやすさ、可用性に優しくなる。ただ、テーブルJoinが難しく…設計で考慮することが、増える。

  • 開発

    • フロントとサーバーサイド分けずに、一人でやったほうが効率いい
    • API定義書とかつらい。全部自分で作ることで、コミュニケーションレスでできる。楽に。
    • ただし、両方できる人は貴重…

分割と整合性をがんばる話 ソーシャルゲームの整合性対策

gumiの清水さんのお話でした。ソーシャルゲームの運用を通して、いろいろ工夫されたことを中心に、話されてました。

gumiさんは、python使ってることで有名な、SAPですね。 最近、大口の資金調達で話題になっていたりもしました。

ここからメモ

負荷対策

新規サービスが大ヒットして、負荷が限界に…
当時の、AWS最高インスタンスでもダメだったので、単純なスケールアップでは対応できなかった。サービス側で色々改修した。

  • Player系データを、単独のDBサーバーに。
  • 機能単位で、DB先を変更していたものを、Master、Trade、Guild、Friendをそれぞれ別サーバーに分割する方法に変更(垂直分割)
    • 性能限界にぶち当たるたびに試行錯誤してた。
    • 外部キーを外して、別DBに移す作業をひらすら実施。
  • 一つの機能に負荷が集中して、対処不可能に
    • KVSにも、じゃんじゃん流す

複数ユーザーが、同時に使う機能は、分割することが難しい - Player情報系は負荷が多く、分割難しい - ロックの粒度で負荷変わらない... なので、Player毎に、接続先DBを変更する、水平分割を行って解決。
ユーザー増えたらサーバー増やす→ 性能限界の問題は解消できた。

しかし、複数DBをまたがせると、

  • 多発する不具合
  • 消えた更新、消えたカード
    トレード機能で、カードを他のユーザー所有に変更するとき、カードから、ユーザーのヒモ付を消すようにしていた。
    → このユーザーが、分割キーだったので、分割キーを消すことで、このカードはどのDBに置くべきか、判断つかなくなった。
    結果、他のユーザーの資産が影響受ける問題に。
    → 水平分割した時は、分割キーは消しちゃいけない

トランザクション

  • 不整合と戦う
    一から抜本的に対応

    • 負荷は水平分割で対処
    • XA Transactionによる一貫性担保
    • ロックによる排他制御

  • 水平分割を前提とした構成にする

    • プレイヤーデータはPlayer用のShardにまとめる。
    • ただし、ギルドテーブルだけは、全ユーザに対する網羅的なアクセスが発生するので、これは1DBサーバーにまとめるようにした。
    • マスタデータはJsonにして、デプロイ時にメモリ上に展開するような方法に。

  • DBのみで実装する

    • プレイヤーのデータはすべてDBに
    • 自動回復系ステータスもDB
      　いままではKVSに格納→Redisを水平分割してた→ 人が動くたびにデータが生成されるので、サーバーを都度増やす自体に、つらい。
      　DBだけ更新、KVSだけ更新が発生していて、どちらかが、漏れる事故があった。
    • 何か問題が起こると、ユーザーに特になる場合は裏技として2chで祭られ、ユーザーが損する場合は、CSが爆発。
    • なので、トランザクションを重要視してた。
    • 正規化を徹底

XA Transaction

分散トランザクション。

  • XAに参加するいずれかのDBで問題起これば、ロールバック可能
  • 複数DBをまたいだトランザクションいける
  • フレームワーク側が対応していなかったので自社開発
  • Preapared後のデータコミット時に、コミット途中で死んだら？
    • 裏でCron回して、コミットされていないやつを、解除するタスクを回そうとしていた。
    • DBのバージョンアップで、Prepared状態で固まっていると、自動でロールバックする対応が入ったので、結局使わなかった。
    • が、DBが死んだ際に、復旧のため使った

デッドロック

  • トランザクション掛けた、Updateが2回、クロスしたりする起きる。 解決できないので、サービス側でレコードロックをするようにした。
  • innoDBはインデックス使ってレコードロックかけれる
  • Whereで抽出する際に、インデックスが張っていれば、レコードが特定されてそこだけ行ロックできる
  • インデックスがないと、行が特定できないのでテーブルロックが走る

発生した事例では、テーブルにインデックス貼ってなかったせいで、テーブルロックがかかる。そのため、デッドロックで、DBサーバーのCPUが張り付く問題が発生した。
また、無駄インデックスが残っていると、意図しないインデックスが使われて、思いもよらないロックが取られることがあった。

回避するためには、処理時に

  • ロックの順番を統一すること
    • DBまたがってる場合、DB順もソート
    • 別のテーブルにまたがってる場合、テーブルもソート
  • 参照に、更新処理まぜない(あればSelect、なければInsertSelect)のケース

MYSQLは親切。同じDB内のデッドロックを検知して解除してくれる

  • 片方をロールバックして、いい感じにしてくれる
  • DB分割している場合、他のDBのデッドロックは、検知できないので自力でロック解除できない

まとめ

  • KVSに移すのは問題の先延ばしにしかならない
  • デッドロック対策の前に適切なインデックスを
  • インデックスショットガン、ダメ絶対
  • プロファイラ大事

MMOのサーバーについて「剣と魔法のログレス 〜いにしえの女神〜」の実装例

Aimingの、山藤さんのお話です。

近頃、ランキングで目立ってきている、あのログレスの、実装についての内容でした。
今、目立つタイトルだけに、会場の期待度もかなり大きい印象でした。

MMOのタイトルらしく、通信周りの工夫の話が、大きくウェイト割かれていたように思います。

ここからメモ

ログレスのサーバー

フロントエンド側のサーバー、バックエンド側のサーバーを、それぞれ、階層分けて冗長化している。 WANを縦につなぐ、同階層での接続はしていない。

フロントエンドサーバー

  • ユーザークライアントが、直接接続するサーバー
  • 通信を2種類使いわけている。

バックエンドサーバー

  • ユーザークライアントは接続しないサーバー。
  • フロントエンドサーバー間の、データやりとりを、Socketで行っている。
    サーバー中では、DBとのやりとりも行っていた。
  • サーバーはC++で実装している

Socket

  • サーバープッシュが必要な箇所で使用。
  • レスポンス速度が要求される、常時接続、差分更新
  • 利点
    • オペレーション都度の、接続コストが発生しない
    • 一回の、送受信量を少なくできる
  • 欠点
    • バッテリー消費(セッション維持するとどうしてもつらい)
    • 回線切れに弱い
    • ソフトウェアで対応しないといけないことが増える
    • セッション維持している関係上、ロードバランサー使ったスケールアウト難しい

HTTP

  • サーバープッシュがいらないところ
  • レスポンス速度を要求しないところ
  • 必要都度、通信、切断、
  • 一括更新

実装例

  • キャラクタの移動

    • 歩けない場所の制御、等あるため、サーバーでも管理する
    • キャラクタが動くと
      • 描画範囲外で、見えなかったものが見えるように
      • 見えなかったユーザーも見えるように

  • 見えなかったものが、見えると、どうなる

    • 自分の行動を他のユーザーにも反映しないといけない
    • 見えてる人がとった行動を、自分に反映しないといけない 人が増えることによってやりとりするデータが増えていく

  • 移動すると、

    • 描画通信範囲の更新を繰り返す
    • 移動フロー
    • クライアントで移動開始
    • サーバー側に目的値と到達点を送信
    • サーバー側で移動の妥当性を検証
    • 周辺のプレイヤーに送る

移動の都度、サーバー介すると反応が悪くなるので、いろいろと工夫が必要。

  • 他の人は多少遅れても気にならない
  • クライアントだけで移動させてしまうと、通信範囲の計算できない
  • クライアントだけで移動させると、マップの当たり判定無視できてしまう。
  • チート問題が付きまとうので、サーバー側の妥当性は検証必須

チャット

文字ベースコミニュケーション

  • キャラクタの、チャット送信でのポップアップはSocketで表示させている。
    • チャットの吹き出しは見える人だけ見えればいよね
    • 吹き出しは発言後なるべく早く画面にだしたい
  • チャット履歴はHTTPで
    • チャットログは、オフライン時のやつも見れる必要がある
    • コミニュケーションの途切れを防ぐ

実際に起こった問題と対応

  • 一台のサーバーにログインできるプレイヤー数が限られる
    • エリア毎に別サーバーで割り当て。で分散。
  • クライアントは、裏で、フロントエンドサーバー間の接続を、切り替えながら動いている
    • この切替時のサーバー負荷が大きい
    • ユーザー移動が大量に起こると、バックエンドが時間かかってローディングが終わらない
      • サーバーをラウンドロビンして、解決
      • 影響範囲はバックエンドとフロントエンドの通信部分だけ。
        クライアントには影響なしで修正できた。構成が分離されていることによるメリット。