CROSS2014 やるよ!
※ 明日なのになんでいまごろかいているのか、というのはお察しください
今年もCROSSというイベントを開催します。 プログラムはとてもハイパーな感じなのでお手すきの方は当日券も有りますのでぜひいらっしゃっていただければと思います → チケット
CROSSとは
Webテクノロジーに関わる人たちが「CROSS(クロス・交流)」することによって、「技術」「年代」「個人・企業」の間で多くのコミュニケーションの機会を創出し、Webテクノロジーに関わる人たちが今日より少しでも広く深い見識を得る場を提供することを願って「エンジニアサポートCROSS 2014」を開催いたします。
上記のことが書いてありますが、開催のモチベーションは、まさに自分のような「頑張りたいとおもってあがいている技術者」が対象です。
- ある技術に詳しくなりたいから専門家(先人)の話を聞きたい!
- ある技術はそれなりに触ってみて、もっと使い込んでるひとの話を聞きたい!
- 自分がふだんやっていることを改善したい・バッドノウハウ・グッドノウハウをしりたい!
- 組み合わせの妙を知りたい!
偉そうに言うと「視座を高める成長の機会を提供したい」です。
クロスでススム、クロスで変わる
今年はテーマとして「クロスでススム、クロスで変わる」を掲げました。 「交流」「議論」を通して、明日への知識・人脈をひとつでも得て、変わる機会になってくだされば幸いです。
そのためにお願いしたのが、次のセッションです
普段の業務で困っていること「テストどうするんだ!」「Webアップ作るときにこれってうまいやりかたなの?」を知ることが出来る内容です。
どのセッションも魅力的ですのでこれらのセッションだけをプッシュするわけではないのですが、コードの書き方・テストの書き方など悩んでいる方はぜひご参加ください。
アンカンファレンス
去年、アンカンファレンスを実施して、ぜんぶのコマが埋まるほどの盛況っぷりでした。 絵的には「鳥肌実x4」のようで阿鼻叫喚のすばらしい時間でした。
ただ、実際に話してくださった方の多くはすでに発表された経験のある方のように見受けられました。 本音では「見たことない人がすげー面白い話をする」を期待していました。 というのも、弊社にもいるのですが(ステマ)、「とても素晴らしい技術」を持ちながらもそれを平常業務としているので価値を過小評価している方がとても多いと思っています。 議論をするととても奥深い話がでてきて非常に勉強になることが多いです。
私はそういった方々が話すのを聞きたかったのです。 聞きたいのです!!
まとめ
セッション見てください→プログラム
まじすごいです!!!
僕はあまり一箇所のセッションを見られないで歯噛みする思いですので、みなさん、代わりにブログを書いて教えて下さい!!
明日お会いできることを楽しみにしております!!!!
参加もしなかったけど、スコアとベンチの回数を可視化した
ISUCON3 チームごとのベンチマーク試行回数 というエントリを id:sfujiwara さんがあげていたので結果とあわせて可視化してみた。
id:sfujiwara さんも書いてる通り、あんま関係ないっすね
というのが確認できました。
- こちらが全体
- 生ハム原木のスコアが高すぎるので抜いたやつ
Sumallyのconsole.logが可愛くあざとい件
普段の癖でSumallyを開いた時にWeb Inspectorを立ち上げるとconsole.logにメッセージがあることに気がついた。 なんだこれww
「We need couple of talented geeks. Are you the one? Check this out」
「探しものはなんですか?見つけにくいものですか?HTMLの中も、JSの中も、探したけれど見つからないのにまだまだ探す気ですか?それより僕と働きませんか?」
「コードやHTTPの通信を見て、まだまだ改善の余地あるな、と思ったあなた!僕らのチームに参加しませんか?」
「おおっと!Web Inspectorでチェックですか!そういう精神好きです。僕らのチームに参加しませんか?」
「We want you for our engineering team. Check this out」
うまいけど僕はそこで上記の画像を回収してそっとWeb Inspectorを閉じました。 閉じました。
D3を書くときの小さいTips
marginの扱いがダルい
div > svg > g
としてその中にいろいろ追加していく、というのがベストだと思っていますが、marginの取り扱いが割とだるい。よくあるのが
d3.select('div').appned('svg') .attr('width', width + margin * 2) .attr('height', height + margin * 2) .append('g') .attr('width', width).attr('height', height) .attr('transform', 'translate('+margin+','+margin+')')
とかだと思うけど、この時点で割とイライラしているのでMargin
作った
class Margin constructor: (args...)-> @top = 0 @right = 0 @bottom = 0 @right = 0 @width = 0 @height = 0 if args.length is 1 @top = @right = @bottom = @left = args[0] else if args.length is 2 @top = @bottom = args[0] @right = @left = args[1] else if args.length is 3 @top = args[0] @bottom = args[2] @right = @left = args[1] else if args.length is 4 [@top, @right, @bottom, @left] = args @width = @right + @left @height = @top + @bottom toString: ()-> return [@top, @right, @bottom, @left].map((d)-> "#{d}px").join(" ")
これを使うとCSSと同じようにmarginを指定できます。
var margin = new Margin(100, 50, 30); // 上100、下30、左右50 d3.select('div').appned('svg') .attr('width', width + margin.width) .attr('height', height + margin.height) .append('g') .attr('width', width).attr('height', height) .attr('transform', 'translate('+margin.left+','+margin.top+')');
attrを無限に書くのがダルい
よくあるのが
circle = svg.append('circle') .attr('cx', 10) .attr('cy', 10) .attr('r', 5) .attr('fill', 'grey') .attr('stroke', 'blue') .attr('stroke-width', 3);
これにstyleも同じようにするのがうんざりする
なので、attrs
を作った
attrs = (obj)-> ()-> for k, v of obj this.attr(k, v) this
これを使うと
circle = svg.append('circle').call(attrs({ cx: 10, cy: 10, r: 5, fill: 'grey', stroke: 'blue', 'stroke-width': 3 }))
オブジェクトで定義できるので楽です。(.attr()
って無限に書かなくても済むし、なにより、この設定を変数化してもっておける!わーい
可視化における代数処理
このポストは「The grammar of graphics」の5章「代数(algebra)」を(つまみつつ)訳したものです。
5. 代数
代数(algebra)という言葉はアラビア語の「al-jebr」という単語が語源であり、「修復」または「破損した部品の再結合」を意味しています。本章ではグラフに埋め込まれるフレームに対する仕様(specification)を作成するための変数の組の修復(restore)と平衡(balance)に焦点を当てます。 仕様の最初のパートでは、変数の組に関わる代数表現表現を含んでいます。 統語表現の規則を振り返り、ついで典型的な表現の例を紹介します。
5.1 統語論(Syntax)
5.1.1 記号(Symbols)
企業は代数における操作される対象を表すために用いられます。変数の組における記号は
5.1.2 演算子
5.1.2.1 Cross (*)
5.1.2.2 Nest (/)
5.1.2.3 Blend (+)
先行箇所
2.1.7 代数
代数(algebra)は、1) セット、2) セットへの演算子、3) これらの演算子の組み合わせに対する規則の集合です。 この定義は、実数に対する算術の基礎となっている古典的な代数学に対して、より一般的で限定的・抽象的な講義の代数学を含んでいます。
演算子は変形の概念を一般化したものです。セットXに対する演算子は、X x X x ... X として定義された関数で X を返します。 演算子は、unary または monadic (ともに単項)、binary または diladic、または n-ary です。 代数規則は、演算子の結合の仕方を指定します。 例えば、規則 R の 演算子 "+" は 「(a, b) |-> a + b」を意味します。
2.1.8 変数 (variables)
変数 X は「f : O -> V」のマッピングであり、次のような3つ組を考えます。 X = [O, V, f]
- 変域 O はオブジェクトのセット
- 値域 V は値のセット
- 関数 f はV に属する要素OをVに関連付ける
f の下で O は、X の値を含みます。 可能な値 x を x ∈ V として示します。オブジェクト o (o ∈ O) の値を X(o) と示します。 V が区間のとき、変数は連続です。V と有限な整数の組が等価の時、変数はカテゴリカルです。
変数は多次元であることもあります。 X は p の1次元変数からなるとき、p次元の変数になります。
2.1.9 変数セット (varset)
X = [V, O~, f]
- 変域 V は値のセット
- 値域 O~ はオブジェクトのバッグ(元の重複を許す=>同じデータを含むことが可能)
- 関数 f はV に属する要素OをVに関連付ける
変数セットにおけるグラフィック代数の演算子の定義を簡潔にするために、変数に対してマッピングを反対にしたものです。 同時に、変数のオブジェクトのセットと変数セットのバッグのセットを入れ替えました。 一度以上オブジェクトに対して値をマッピングすることを可能にするために、値域にバッグを利用しました。
2.1.10 フレーム (frames)
変数セットのp次元ドメインとなるすべての可能な値の範囲にあるタプルのことをframeとします。
YAPC::Asia Tokyo 2013に参加&発表&レポートしてきました
YAPC::Asia Tokyo 2013に参加&発表&レポートしてきました。
登壇者・スタッフ・招待合わせて、1131人もの参加者が集まるPerlの祭典「YAPC」。 去年までは一参加者でしたが、今年は発表する機会もいただけたので、20分ですがトークしてきました。
発表
内容もさることながら、裏で「YAPC::Asia Tokyo 2013 特別座談会」、「Perl入学式 @ YAPC」があり僕も聞きたかった「Perlでレコメンデーション」が会ったりと、聞きに来てくれるひとは少ないんだろうなぁと思っていましたが、なにがどうしたのか思った以上に聞きに来てくださったので嬉しかったです。
内容は、1) 可視化の目的、2) 探索的可視化のためのツール、3) DataCubeというモジュール紹介、という誰得な感じのするものでしたが、響くところには響くと信じています。
ちょっとだけモジュールのことを話すと、これちょっとだけメソッドを生やしただけでほとんど「Data::Nest」のラッパみたいなものです。
むしろ、こっちのほうが使い勝手よくてkeyを指定するとNestしてくれます。
use Data::Nest; my $data = map { {age => int(random(60)), gender => int(random(2))} } (0..10); my $nest = new Data::Nest(); my $result = $nest->key("age")->key("gender")->rollup("count", sub { scalar @_; })->entries($data); # [ # { key => "1", values => [ { # {key => "0", values => [条件に当てはまるHash], sum => 13} # {key => "1", values => [条件に当てはまるHash], sum => 11} # .. # }] # ]
便利。
レポーター
今年は調子に乗ってレポーターにも参加しました。 最初からレポーターをしてくださっている @hiratara さんがすごくまとめてくださったので、それなりに大変でしたが全然ストレスなく楽しんでレポートできました。
メモや写真は大量にあるもののそれなりの分量に抑えるのが大変でした。 私は次のセッションを担当しました。誤字脱字・内容の過不足・修正等あればいってください。
- 学術分野におけるPerlの活用例
- 大規模Perl初心者研修を支える技術
- SPDY、HTTP/2.0の使い方
- perl な web application のためのテスト情報
- はてなのサーバ管理ツールの話
- Mojoliciousでつくる!Webアプリ入門
二日目に自分の発表があったため一日目に固め打ちをしたせいで、初日の疲労は大きかったですw
セッション
レポートしながら聞いていました。
- OJTの担当でgitを教えて、Perlを教えて、DBを教えて、WAFなしでLAMPでなにかを作らえる、というのをやることが多いのもあり、DeNAの研修が興味深かったです。
- まきさんの本当にあったレガシーな話はとても代役とは思えない内容で、身震いしながら聞いていました。
- monocerosはもう少し見てみる
- とくひろむさんのHTTP::Body::Builderとyappoさんのやりとりはテンポ良すぎてひどいw
ほかにもたくさん見たいのもあったのですがマルチトラックだと悔しいですね!
YAPC
「お祭り!」を感じさせる仕掛けがいっぱいあって、CROSSをやる上で参考になることがたくさんありました。
くしいさん、まきさんが引退するという発表で驚きましたが、きっとまきさんもおっしゃってた「新しい芽」が引き継いでくれると信じています。 くまがいくんとか、くまがいくんとか(若くないけど
おまけ
- 後輩を連れてこれてよかった。ぼっちじゃなかった!
- songmuさんとtypesterさんと挨拶出来た!
- 一日目、あれだけ企画してくださっているのに、お弁当抽選に漏れた結果ぼっち飯になりました。
- 二日目、YAPCに向かってる駅で下駄が割れました。不吉すぎる・・・
grammar of graphics / three stages of graphics creation
この記事は「grammar of graphics」についての理解のためのメモです。
可視化の作成において3つの段階にフォーカスを当てる。
- Specification
- Assembly
- Display
1. Specification
ユーザのアクションをフォーマルな言語に置き換える作業を指す。 ユーザはこの言語に気づいていないかもしれないが、可視化の要請を理解するための自動化システムのためには必要。仕様を定義する他の方法は、可視化の深い文法について説明することでもある。 絵画とは違い、可視化は高度に組織化され制約されたルールセットを持っている。 もちろん、絵画も独自のルールを持っていて、特に写真やビデオのような実際の絵では。 とはいいつつ、芸術家はこの独自のルールを強調するために規則を曲げる特権を持っている。 特殊効果技師は、日常で観察しているものよりもビデオや仮想場面が真実であるように騙す事もできる。 可視化ではそうは行きません。私達は僅かな規則とツールだけしか持っていない。データを偽造したり、統計的な可視化の目的に違反することなしには、オブジェクトの位置や色(これらはデータの属性を表現している)を替えることはできない。データを正確にかつ適切に表現するために。 つまり、可視化システムの核は仕様に基づかなければならない。
統計的な可視化の仕様は6つの宣言で表現される。
- DATA: データセットから変数を取り出すデータ操作のセット
- TRANS: 変数の変形 (例: rank)
- SCALE: スケール(基準、階級化)の変形 (例: log)
- COORD: 座標系 (例: 極座標)
- ELEMENT: グラフと装飾的(aesthetic)属性 (例: color)
- GUIDE: 1つ以上のガイド (例: 軸、凡例)
本書のグラフの殆どで、明示的な定義を行うために、可視化の構文的仕様を書き加えてある。 この仕様言語の古いバージョンは、単一の代数処理のすべての側面を取り込んである。 注釈は不格好で特異的だ。しかしながら、要素としてこれらを分離した。 これらの要素はデータをオブジェクトと結びつけ、これらのオブジェクトを含むシーンを特定する。
2. Assembly
シーンとその記述は異なっている。シーンを表現するという目的において、正確に描画するために私達はその幾何的な配列・形状(geometry)、レイアウト、装飾を調整する。 統計的な可視化のプログラムは、仕様の要素から実際のシーンと合わせて描画し、モデル化するのと同様に、幾何的なシーンに組み上げられなければならない。 本書では、シーンの組み上げよりお仕様について多くを説明しているが、表層的な特徴と深い構造を混同しないためにも仕様について学ぶ一方で、組み上げについても重要視して考えなければならない。 仕様からシーンをどのように組み上げると、結果的な振る舞いにどのように影響をあたえるか。 シーンは動的にも静的にもなりうるし、外部のデータか独立したデータなのか、装飾可能なのか不変なのかは、私達がどのように組み上げるかに依存している。
3. Display
可視化を知覚するために、グラフは装飾的な属性や表示システム(紙やビデオ、ホログラムなど)を利用して描画されなければならない。 現代のオペレーティングシステムでは、いくつもの描画メソッドを利用することができる。これらはよく定義され抽象的なインターフェイスが好ましい。 プロダクションでの可視化は、基本的な描画能力とは異なった、その領域での要件がある。 動的な可視化や科学的可視化は、対照的に、burushingやdrill-down、zooming、linking、その他のデータと可視化を結びつける操作などが可能な洗練されたデザインが要求される。 Becker and Cleveland (1987)、Cleveland and McGill (1988) 、Cook and Weisberg (1994)、 Swayne et al. (1998) はそれぞれの要件について紹介している。最近では、仮想現実ディスプレイや没入型環境などがタッチや音といった装飾を可能なまでに拡張している。