LLDiverの見どころ

久しぶりに書くのですが今年で14回目のLLイベント LL Diver をお手伝いしております。

スタッフを申し込んだ時点ではこんなに忙しくなるとは思っておらず、あまりお手伝いできなかったのですが「ご紹介」という形で3つのセッションにご協力することができました。

http://ll.jus.or.jp/2014/wp-content/uploads/2014/05/lldiver.logo_.jpg

1.

あんちぽくんさんはGMOペパボの技術責任者として「みんなと仲良くする」「ファンを増やすこと」「アウトプットすること」という3つの軸に準じた評価をされ「GMOペパボ株式会社の技術責任者に就任いたしました」「ペパボの2014年上半期エンジニア評価について」などのエントリをあげてらっしゃる方です。 この方が「新人研修」をどのように設計しているかはとても興味深いところです。

2.

hiroki_daichi さんは

とおっしゃっていますが、Qiitaにたくさん投稿しているかたです。

これらのQiitaの投稿は目にしたかも多いのではないでしょうか。

多岐にわたってQiitaを上げているhirokiさんに様々な質問をぜひぶつけたいところです。

3.

一時期ドワンゴの技術者退職エントリが続いた時の状況を立て直したかについてmeso さんが質問を受け付けてくださいます。 現在は、下記の記事にあるようにドワンゴでエンジニアが働く環境の整備や採用、教育、技術広報を担当されています。

どしどし質問を投げつけましょう!

前日だぞ!!

と @hourin さんの叱られそうですが、上記の他にも禁断とも言われている「誰得なエディタセッション」や夜の部は酒を入れなければ聞けないようなセッションまで魅力あるセッションが盛り沢山です。 まだまだチケットは余っていますので(汗)、ぜひ足をお運びください!

Hadoop Conference Japan 2014に参加しました

Hadoop Conference Japan 2014に参加しました。

最近あまり触ってなかったのですが、また案件で利用するニーズが出てきたので最新情報の収集目的です。

今日の収穫としてはこんな感じ

  • Apache Spark
    • 一週間の活動量がすごい
      • 500 patch updates / w
      • 200 updates / w
      • 140 thread / w
      • 80 merged patches / w
  • Facebook Presto
    • プラガブルよさ気
    • Facebookの中で使われてるリポジトリ←すごい
    • 各種DBマージして使える
    • DBに投げるときにすでにクエリを入れてフィルタリングしてから取り出すこともできる←mongohadoopでも実装してたの懐かしい
  • BigQuery
    • 公開してるBigQueryと中で使われてるのは同じ(リソース競合あり)
    • お高いお金を払えば専有できるリソースもあるって
    • DataFlowパイプライン処理のダッシュボード、流量とかソースからのLAGとか出てて素晴らしい。リアルタイムを謳うなら「どの程度」リアルタイムなのか出さないとな、と思った
    • millwheelの論文読みたい
    • flumeJava
  • HBaseは死火山←これはあんまり信じてない
  • YARN使いたかったらHadoop 2.4系使わないとスケジューラで困る(CDH5はHadoop2.3 + patchだから大丈夫)
  • YARNの初期設定はCDHHDPVMから設定ファイルも初期ディレクトリ構成もパクればいい。Ambariでもいいけど、直接設定見て書き換えられる方がrecipeにも書きやすい
  • hivemallアルゴリズムすごく多くてすごいAROWとかCSWとか
    • Apache Incubatorになるかもとか
  • DATABRICKS CLOUDのダッシュボード便利そう

その他

  • Sparkはオンメモリで高速にぶん回すこと考えるといろいろジョブ作成前に考えたりするから大変そう(溢れたらSpillしてくれるとはいえ)
  • Prestoはジョブが落ちるけど、そっちの方が潔い気もするし、各種のDBとマージして処理できるのは助かる感じある
  • Hive回して中間データを保持しておいてそいつをSpark/Prestoで処理する+直近データのみESとkibanaとかそういう構成が良さそう

今日のハイライト

mackerel meetupに参加しました

mackerel meetupに参加しました

状況

現在は、とあるプロダクトで導入してモニタリングやアプリケーションメトリクスも関係ないけどサーバに紐づけて見たりしています。 実験的には、プロセス監視も1 or 0を定期的に返すことでできていますが、プロセスをスタックグラフで見るのはつらいす。

Mackerel meetup

フリークアウトかっこいいよ!!

ちょっと早くついたのですが、id:moznion さんとか @netmarkjp さんとか @koemu さんとかと雑談してたら始まってた

Introduction to Mackerel via @motemen

構成

term

  • Org: 課金単位になるらしい
  • Service
  • Role

  • Metricを収集して時系列で可視化

status

  • standby
  • working
  • maintenance
  • retired

監視 (experimental)

  • アラート(Webで確認するだけ)
  • Coming next: メール通知

カスタムメトリクス

API (v0)

  • ホスト情報の一覧
  • ステータス更新
  • 退役

@stanaka

  • 監視・通知
    • 6月: 基本的な監視・通知
      • メール
    • 7月: 応用的な監視・通知
      • 通知手段
  • アプリケーションメトリクス
    • レスポンスタイム・エラーレート
    • fluentd使う
    • ラベル・形状のカスタマイズ(7月)
  • グラフ拡充

    • グラフの外部貼り付け(iframe) 7~8月
  • 8月か9月に正式化

  • ユーザ権限管理強化

  • クラウドとの連携強化
  • Docker周りと連携

  • カスタムメトリックプラグイン

  • チャット連携

    • hubot-mackerel

Q&A

  • 何代まで耐えられますか?
    • 1000台は耐えてる、1万まで行けるんじゃないか
  • AutoScale環境でもっと使いやすく
  • デフォルト表示を切り替えられると嬉しい→検討します
  • メトリクスをCloudWatchに流したい→REST API経由でできるようにします
  • OSSプロジェクトへの無償提供はありますか?→前向きに検討したい、個別相談させて
  • 価格体系は?→基本、従量で応相談で月額課金

要望・質問

  • スケジュール・タイムラインの追加
  • 表示メトリクスの記憶をして欲しい
  • チャートタイプの種類が欲しい
  • プロセス監視はするの?
  • 課金は?

所感

  • 自前で持ってもいいんだけど正直、手間ではあるのでコスト次第では全然使いたいツール
  • agent一発でOKで、送信プラグインも今後は増えそうだし、データ取得のAPIも出そうなので色々できそう
  • server -> fluentd -> mackerel や server -> mackerel -> 何か という組み合わせで適材適所で組み合わせてみたいところ

node-mackerel

とここまでだったら、 @koume さんのブログを見ればいいので node-mackerelを作りました。 postMetricもちゃんと動きます。

タイトルの横の[]travisに入れようとしたのですがなんかtravis-githubの具合が悪いっぽくて登録できなかった。後でやる。

最近、deferredを使い続けているのでその復習も兼ねて。

Docker/Droneを試してみる

:D な会社の友達たちが「いみゅーたぶるいんふらなんちゃらの合宿やるわー」って話してたので、そんな面白いことはぜひ外部からの参加も可能にするべきだ!って憤慨しながら突っ込んだら「くればおk」って言ってくれたので合宿参加しました。

概要はこんな感じ

Immutable Infrastructure 的ななにかをやる

キーワード
・Vagrant
・Docker
・Mesos
・Serf
・Sensu ?
・Jenkins
・とかとか

やること
・上のキーワードをてきとうに組み合わせるとなにかおもしろいの出てくるかも
・Jenkins × Docker とか
・Mesos × Vagrant とか
・ただ触ってみるだけでも良いとおも

主催者の @sonots さんは上記のような概要書いたくせに全然関係ないfocuslight(の主にドキュメントページ)をやってた

僕は、とりあえずdockerだけ予習してから参加した。 (ちなみに実家から母が来てたんだけど、いろいろあってリスケとかしてもらったのもあって妻にまるなげして参加した。なので、帰りにヒカリエでケーキ買って帰った)

やろうと思ってたこと

  • focuslightのRRDToolAPIからデータを抜いてD3化→brew installできなかったのでやめた
  • droneを試す→まあ、動いた。gitlabとか追加できるようにコードを読み漁ってたところで終わり

focuslight

  • brew install rrdtool→こける
  • brew install gobject-introspection が原因ぽい
Warning: No developer tools installed.
You should install the Command Line Tools.
Run `xcode-select --install` to install them.
==> Downloading http://ftp.gnome.org/pub/GNOME/sources/gobject-introspection/1.38/gobject-introspection-1.38.0.tar.xz
Already downloaded: /Library/Caches/Homebrew/gobject-introspection-1.38.0.tar.xz
==> ./configure --prefix=/usr/local/Cellar/gobject-introspection/1.38.0
==> make
./g-ir-scanner: line 29: `    def on_exception(exctype, value, tb):'
make[2]: *** [GLib-2.0.gir] Error 2
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

READ THIS: https://github.com/mxcl/homebrew/wiki/troubleshooting

/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/open-uri.rb:277:in `open_http': 404 Not Found (OpenURI::HTTPError)
    from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/open-uri.rb:616:in `buffer_open'
    from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/open-uri.rb:164:in `open_loop'
    from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/open-uri.rb:162:in `catch'
    from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/open-uri.rb:162:in `open_loop'
    from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/open-uri.rb:132:in `open_uri'
    from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/open-uri.rb:518:in `open'
    from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/open-uri.rb:26:in `open'
    from /usr/local/Library/Homebrew/utils.rb:264:in `open'
    from /usr/local/Library/Homebrew/utils.rb:281:in `each_issue_matching'
    from /usr/local/Library/Homebrew/utils.rb:293:in `issues_for_formula'
    from /usr/local/Library/Homebrew/exceptions.rb:178:in `issues'
    from /usr/local/Library/Homebrew/exceptions.rb:209:in `dump'
    from /usr/local/Library/brew.rb:118

このあと、mac os xのboot2docker使って ubunturrdtool入れようとしたけど、それでもこけてたので、時間もったいないし辞めた

drone

f:id:muddydixon:20140223150138p:plain

docker daemonが必要らしい

  • 参考
  • sudo sudo docker -H 0.0.0.0:4243 -d
  • sudo DOCKER_HOST="tcp://localhost:4243" start drone わーい

f:id:muddydixon:20140223150147p:plain

ログ

/var/log/upstart/drone.log

droneのsqlite3

/var/lib/drone/drone.sqlite

ubuntu@~$ sqlite3 /var/lib/drone/drone.sqlite 
SQLite version 3.7.17 2013-05-20 00:56:22
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .tables
builds     members    repos      teams    
commits    migration  settings   users    
sqlite> 

table

table 備考
builds ビルドのログが入っている。stdoutの中に全文保持
members 所属チームと役割を保持
repos リポジトリ設定
teams チーム設定
commits リポジトリのコミットログを保持
migration よくわからない
settings drone自体の設定
users ユーザ
  • users
table|users|users|2|CREATE TABLE users (
   id                INTEGER PRIMARY KEY AUTOINCREMENT
  ,email             VARCHAR(255) UNIQUE
  ,password          VARCHAR(255)
  ,token             VARCHAR(255) UNIQUE
  ,name              VARCHAR(255)
  ,gravatar          VARCHAR(255)
  ,created           TIMESTAMP
  ,updated           TIMESTAMP
  ,admin             BOOLEAN
  ,github_login      VARCHAR(255)
  ,github_token      VARCHAR(255)
  ,bitbucket_login   VARCHAR(255)
  ,bitbucket_token   VARCHAR(255)
  ,bitbucket_secret  VARCHAR(255)
)
  • teams
table|teams|teams|6|CREATE TABLE teams (
  id        INTEGER PRIMARY KEY AUTOINCREMENT
  ,slug     VARCHAR(255) UNIQUE
  ,name     VARCHAR(255)
  ,email    VARCHAR(255)
  ,gravatar VARCHAR(255)
  ,created  TIMESTAMP
  ,updated  TIMESTAMP
)
  • members
table|members|members|9|CREATE TABLE members (
   id      INTEGER PRIMARY KEY AUTOINCREMENT
  ,team_id INTEGER
  ,user_id INTEGER
  ,role    INTEGER
)
  • commits
table|commits|commits|13|CREATE TABLE commits (
   id           INTEGER PRIMARY KEY AUTOINCREMENT
  ,repo_id      INTEGER
  ,status       VARCHAR(255)
  ,started      TIMESTAMP
  ,finished     TIMESTAMP
  ,duration     INTEGER
  ,attempts     INTEGER
  ,hash         VARCHAR(255)
  ,branch       VARCHAR(255)
  ,pull_request VARCHAR(255)
  ,author       VARCHAR(255)
  ,gravatar     VARCHAR(255)
  ,timestamp    VARCHAR(255)
  ,message      VARCHAR(255)
  ,created      TIMESTAMP
  ,updated      TIMESTAMP
)
  • builds
table|builds|builds|15|CREATE TABLE builds (
   id        INTEGER PRIMARY KEY AUTOINCREMENT
  ,commit_id INTEGER
  ,slug      VARCHAR(255)
  ,status    VARCHAR(255)
  ,started   TIMESTAMP
  ,finished  TIMESTAMP
  ,duration  INTEGER
  ,created   TIMESTAMP
  ,updated   TIMESTAMP
  ,stdout    BLOB
)
  • migration
table|migration|migration|28|CREATE TABLE migration (
    revision NUMBER PRIMARY KEY
)
  • repos
table|repos|repos|30|CREATE TABLE repos (
   id          INTEGER PRIMARY KEY AUTOINCREMENT
  , slug        VARCHAR(1024) UNIQUE
  , host        VARCHAR(255)
  , owner       VARCHAR(255)
  , name        VARCHAR(255)
  , private     BOOLEAN
  , disabled    BOOLEAN
  , disabled_pr BOOLEAN
  , privileged  BOOLEAN
  , timeout     INTEGER
  , scm         VARCHAR(25)
  , url         VARCHAR(1024)
  , username    VARCHAR(255)
  , password    VARCHAR(255)
  , public_key  VARCHAR(1024)
  , private_key VARCHAR(1024)
  , params      VARCHAR(2000)
  , created     TIMESTAMP
  , updated     TIMESTAMP
  , user_id     INTEGER
  , team_id     INTEGER
)

droneとJenkinsの違いとかを考えながら触ってたんだけど、Jenkinsは「いまある環境+α」を検証するのには良いと思う。Docker / Vagrantでごにょごにょやってテストする、とかもいいと思うけど、droneは「(そもそも必要な依存関係とかを解決した)コンテナを用意して、その上でテストが必要なやつだけを検証する」のは非常に簡単だし、環境とアプリ・ライブラリのテストを完全に分離できるという意味で俺的エポックメイキングな感じでした。

会社でも使ってみたいと思います。

プロビジョニングとオーケストレーション

@sonotsさんからいろいろ聞きながらの自分の中の理解

  • プロビジョニング:マシン単体における(アプリのインストールも含めた)設定の変更(初期化含む)
  • オーケストレーション:機能を実現する、複数のマシン群の「台数」の変更(構成の変化は今後。例えばDBの水平分割に伴うディスパッチャー層の追加とか)

@sonotsさんまじニフティ

雑感

  • @sonotsさん「Jenkinsみたいにslave/workerは使えるの?」→しらね
  • @tohae さん「ぱーるかけちゃうからよくないわー」
  • @yosuke_furukawa さん → @takus さん 「なに勝手にご飯食べてるんすか?」

:Dの会社、怖い会社

執筆とイベント主催(と業務と育児)を同時にやってみてわかったこと

今回、D3の本を執筆しつつ、CROSSというイベントを主催しつつ、通常の業務のリーダー(という平社員)をしつつ、2児の父として振る舞った末、完全にオーバーキャパで各所に迷惑をかけてしまいました。

  • 書籍の進行が延び延びになって共著者・出版社に迷惑をお掛けしました
  • CROSSの進捗管理とかチェックが甘々になって各担当者と登壇者と協賛各位にご迷惑をお掛けしました
  • 足りない能力を時間で補ったしわ寄せが業務にいき、パフォーマンスが出なくご迷惑をお掛けしました
  • 家族旅行中も執筆をしてるは、土日の夜は家にいないわ、平日は朝も夜もいないわで、妻と子どもたちに申し訳ありませんでした

謝って「これで終わりー」というのはただの批判防止の言葉でナンセンスなので原因と再発防止策を考えてみます。

問題と原因

  • オーバーキャパシティ
    • ほぼすべての原因がこれになります。能力不足というと思考停止のようで良くないとは思いますが(結果的に)3ヶ月半で285ページ、829名参加のイベント主催、後輩育成もままならない中での業務、代えのない父親としての役割、をすべて完璧にこなすことはムリです。ムリ

というと、またも思考停止になるので、一応、あそこでこうしておけば、という各所の振り返りをしておきます→将来の自分のためにも、あとこういう状況になってしまうヒトのためにも

  1. 進捗が大幅に遅れてしまった
    • (執筆期間の)見積の甘さ
    • スケジュール工程管理を適切に行うことができなかった
  2. 内容を期初期待していたクオリティにもっていけなかった
    • (特に自分での査読期間)チェック期間を確保しきれなかった←スケジュール的に食い込んでしまった
    • メンバーに依頼するときに曖昧に指示を出してしまった
    • 事前の内容の詰めが甘かった←「こういう風にしよう」と決めていたことを定期的にチェックし、計画的な軌道修正を行うことができなかった

再発防止策

見積の甘さ

  • [書籍] 見積はもっと多めに取るべきでした。思っていることの最悪1.5倍は確保しておくほうがよいです。(調査から含む場合)SI的には3倍とか聞いたこともあります。ただ、元々の締め切りなどもあるので、この辺りどうしたらいいのかむしろ教えてほしい側です。この話を突き詰めると「無能だからだ!」に帰結してしまってあまりよろしくない気がします。
  • [書籍] D3でコードを書くあたり(つまりほぼ作業)はなんとかなるなと思ってなんとかなったのですが、自分の中でまだフワフワとしていてエビデンスやサポート意見を論文・書籍を当たる時間が膨大にかかってしまいました。調査系が入る場合はさらに多く見積もりをして、難しければその他の部分の分量を減らすことを検討したほうが良い

スケジュールの工程管理を適切に行うことができなかった

  • [イベント] スケジュール線表を丁寧に更新し、メンバーにきちんと共有するべきでした。Redmineでメモ程度にしか作成しておらず、突然締切日直前に「あれどうなってる?」とか問い合わせるとかほんとによくない。進行に応じて、そのスケジュール感はもっと細かく厳密にすべきでした。サイトの更新などで担当者・セッション担当の方々に迷惑をかけました。
  • [書籍] 10ページ程度の寄稿であれば不要だったのですが、この分量の場合は、主観でもよいので割合を共有し、問題が発生していることを伝える+感じてもらう(見える化する)べきでした
  • [書籍] マイルストーンは切っており見直しのタイミングでのリスケを行っていたのですが、上記「見積の甘さ」「根性論的ななんとかします」のせいで あんちべさんも書かれている通り、その場その場で延期してしまった

チェック期間を確保しきれなかった

  • [書籍] 見直しをする期間を自分の中では1日寝かしてから読み直す、とかを期初確保していたんですが、業務で終電になったり、子どもたちの喧嘩をなだめていたり、寝かしつけで寝落ちてしまったりと、なかなか確保しきれなかった。こういう事自体をリスクとして余裕を持ったスケジュールを組むべきだった

メンバーに依頼するときに曖昧に指示を出してしまった

  • [イベント] 各担当に「これこれこういう感じでやってください、今年はこの範囲であれば各人の好きにやってください」と依頼したが、担当によっては不安だったり不明確だったこともありクオリティに差が出てしまった(クオリティが低かった場合は僕の指示が曖昧かつフォローがなかったためです)。受付とかはノリノリで前日に筆で団体名を書いていたがサイトや企画要素はきちんとフォローすべきだった。また、こちらも打ち合わせの中で「ここまではいついつまでです」というものを(ある程度)細分化し、それらをマイルストーンとして管理すべきだったかと反省しきりです。

フォローメンバ・担務依頼

  • [イベント][書籍] 私はスケジュール管理・TODOチェックなどがうまいわけではないので、そういったところを助けてもらえるメンバを予めお願いできればよかったと思います。苦手なことをがんばってやるべきことに支障をきたしたら本末転倒
  • [書籍] すでにCROSSと業務でアップアップだったので、あれなのですが、身近な人で査読をお願いできればよかったと反省しています。「身近」というのは別に仲がいい、というのではなく、一番厳しいヒト(あんちべさんも相当厳しかったですが)に定期的に査読をしていただければなあと今思います。ただ、文章的には8割書いて(実作業としては推敲などが無いので5割くらい)放置→少し手直して→みたいなのが続いていたのでそれはそれでご迷惑をかけていたかもしれません。

再発防止策としてのまとめ

  • 見積はもっと大きく取る
  • チェック期間は死守する→たぶん、これのために内容削ったりスケジュール遅延させるほうが良い
  • イベントは担当者を付けたからといって終わりではなく、もっと手厚くフォロー、特に作業の細分化・スケジュールなどでサポートすると効果的な気がする
  • 全体のフォローの担務をつけるのはありだったかも(海外の企業では、4人とかの少数チームにフォローを専門とするメンバーが入るケースもあるらしい)
  • 身近な人に査読をお願いする

まとめ

再発防止とか言ってますけど、当時はやっぱりアップアップでした。 妻にもあたってしまったり、イベントの事務メンバにイライラしたり、はては出版社の方やあんちべさん、ずっとサポートしてくださった本郷さんにも矛先を向けてしまったり、ほんとにオーバーキャパよくないです。 普段できない経験ができてよかったですが、内容ももっとあれをかければとかああやっておけばとか考えると尽きないですし、ご迷惑おかけした方々にも本当によくないので、そうならないように頑張っていければと思います。

「無能だからすみません」というのと限りなく近いかもしれなくて情けないですが、「調子に乗って身の丈以上の仕事引き受けすぎるなマジで」ってのが一番の反省と再発防止策だと思っています。

「エンジニアのためのデータ可視化[実践]入門 ~D3.jsによるWebの可視化」を執筆しました

僕のような人間が書いていいのか、とは執筆前・執筆中・そして執筆が終わった今もずっと思っていますが、兎にも角にも書き終わりました。

エンジニアのための データ可視化[実践]入門 ~D3.jsによるWebの可視化 (Software Design plus)

エンジニアのための データ可視化[実践]入門 ~D3.jsによるWebの可視化 (Software Design plus)

2月20日に書店に並ぶそうです。

内容について

うまく伝えられているかはわからないですが下記のようなことを意識して書きました

  • データ可視化は情報との対話であり、「データに存在する事実を掬い上げやすく加工する」「データに存在する事実を効率的に伝える」作業そのものである
  • データ可視化はデータ処理(収集・保持・分析・解析)と企画者(施策・経営)のコミュニケーションを円滑にするものである

上記を実現するために必要な知識として次のような内容を紹介しました

  • データ可視化の歴史
  • 代表的なデータ可視化の種類(端的にいうとグラフの種類)
  • データ可視化のための用語「データ」「視覚記号」「データ変数」「視覚変数」
  • データ変数の尺度・水準、視覚変数の特性の対応関係
  • 可視化が受容可能な視覚変数の数、つまり可視化で表現できる変数の数

また、可視化を行うときにやりがちな失敗(要素数が多い円グラフ、3D円グラフ、絵グラフ、不揃いな軸・変数)や探索的データ可視化についても盛り込みました。

そして、最後に12のケースに対して、実際にD3.jsで可視化を作成するサンプルコードを付けました。

D3でのデータ可視化のサンプル

実際の業務でも作成していそうな以下の12のケースの可視化をD3で作成するサンプルを紹介しました。 複合的なグラフやインタラクションなどはなかなか(代表的な可視化ツールとして)エクセルでは作成が難しく、D3での作成にメリットが大きいサンプルだと感じています。

  • 基本的な折線グラフの作成
  • 時々刻々と入力されるデータをアニメーションで反映させる方法・時系列範囲を指定してフォーカスする可視化の作成
  • 顧客属性などのアトリビューション分析 (ツリーマップ)
  • 離脱率を可視化する (折線グラフ・バブルチャート)
  • ヒートマップを用いた購買価格帯の推移の可視化 (ヒートマップ)
  • ニコニコ動画の投稿日時・コメントの投稿日時の可視化 (ヒートマップ)
  • アクセスフローの可視化(sankey チャート)
  • 税金はどこにいったの模写
  • 単語の解析結果の可視化(棒グラフとワードネット)
  • 両箱ひげ図 (箱ひげ図)
  • 状態遷移図
  • 決定木

最後に

私は、データ可視化の専門的な教育を受けたわけでもありませんし、素晴らしい技術者でもありません。 しかし、データ可視化という分野はまだまだ市民権を得ている技術分野でもないため、私のような人間に執筆の機会がいただけたのだと思っています。

と書いたとおり、優しく議論させていただければと思います。

で、事前の言い訳会「こういう話をじつはこういう経緯で書いたよ」とか「サンプルの真意はこんなだよ」を説明する会を開きます→Zusaarはこちら

あまり聞いたことがないと思いますので、可視化の理論とD3のデモを話そうかと思っております。

謝辞

共著者のあんちべさん、レビュアーの本郷様、市原様、井戸さん、春山様、山根様ありがとうございました!

2013年+2014年頭の活動

いまさらですが、2013年の活動の振り返り

「2ヶ月に1つはなにかアウトプット!」豊富に挙げて頑張ってみました。 また、35歳になる歳なので、出来る限り多くのことをやろうと決めました。

発表・イベント

書籍・勝手に資料作成

結論

告白しておくと、CROSS2013の時に @tagormois さんが「今年はいろいろやることにしたんだ(キラッ」とおっしゃっていたので、僕もやってみよう!って思ってこの抱負を挙げてできるだけ・・・と思って頑張ってみました。 ただ、結果としては、凡庸な僕ではあまり大きな成果も挙げられなかったですし、どれも半端になってしまいました。 今年は少し腰を据えてひとつ作りたいと思っています。