Hatena::Groupasakura

浅倉卓司@blog風味? このページをアンテナに追加 RSSフィード

Error : RSSが取得できませんでした。

2004-12-23(Thu)

単価の高い記事

|  単価の高い記事 - 浅倉卓司@blog風味? を含むブックマーク  単価の高い記事 - 浅倉卓司@blog風味? のブックマークコメント

一番怒っていたのは、記者の姿勢、とりわけ取材量についてである。「一昔前の記者は現場をよく歩き、色々な人から話を聞いた上で記事を書いていた。現場で聞いたことに基づいていれば、たとえ耳が痛い指摘であっても、こちらは真摯に受け止めた。ところが今の記者は一人か二人の取材先から吹き込まれた情報を基にいきなり記事を書こうとする。『××は失敗のようですね』などど言ってくるが、そういうお前は××の現場に行ったのか、と怒鳴りたくなる」。

記者の基本

そんな中、毎日欠かさず読んだ記事の一つが、2003年4月から04年9月まで断続的に続いた同紙一面連載「働くということ」だった。なぜ毎日読んだか。それは、採算度外視で取材に法外なコストをかけた、恐ろしく単価の高い記事であることが容易にうかがえたからだ。

(略)

優れた新聞記者は、時代の意味を切り取って、それを新しい文字や言葉の組み合わせによって表現するものだ。一方、グーグルを駆使する上で難しいのは、検索キーワードの選択である。正しいキーワードを思いつけるかどうかで、得られる情報の質が大きく違ってくる。ある事象とそれにぴったりと合った言葉を連想できるかどうかが、個人の情報戦略における競争優位の源泉となりつつある。そのギャップを埋めることが、新聞の新しい役割となるのかもしれないなと、本書を読んで思った。

梅田望夫さんの書評

 雑誌や新聞に目を通さなくなったのは、「単価の安い記事」がウェブ上に溢れているからかもしれない。雑誌や新聞の記事もほとんどは単価の安い記事だし。

 逆に、ウェブ上にあるもののほとんどは単価の安い記事ばかりだ。ブログがもてはやされていても、結局は単価の安い記事でしかないしね。


 というわけで、雑誌や新聞が生き残る方法の一つは「単価の高い記事」の充実なんじゃないでしょうかね。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20041223

2004-12-22(Wed)

Class::DBI::Cacheable

| 18:47 |  Class::DBI::Cacheable - 浅倉卓司@blog風味? を含むブックマーク  Class::DBI::Cacheable - 浅倉卓司@blog風味? のブックマークコメント

 訪問者が多いうちに聞いてみよう*1

 Class::DBI::Cacheableは前の会社にいたときに使おうと思ってたんだけれど、Cache::FileCacheを使っているのでサーバが複数あるとupdateしたときに不整合が起こりそうな気がして使うのをやめた記憶があります。このあたりはどうなってるんでしょうかね?

 updateする可能性のあるカラムだけキャッシュしない設定があるとか、あるいはそういうテーブルには使うなってことなんでしょうか。


 この辺りが気持ち悪くて自前のCahce::FileCacheラッパを使ってたりするのですけれど。

 あと、MySQL*2を使ったCache::Cache*3ってないですよね? 上記みたいなケースでNFSを使うよりは良さげな気がするんですけれど。そうでもないのかな。


補足

 Class::DBIのパフォーマンスを気にしている方がいますが、まずはEssentialの設定を見直すことをオススメします。

 キャッシュなんかしなくても、数倍パフォーマンスが良くなりますから。

 Class::DBI::Plugin::Iteratorを使うならSELECT * にするのを推奨。


はてな開発の裏側

| 18:47 |  はてな開発の裏側 - 浅倉卓司@blog風味? を含むブックマーク  はてな開発の裏側 - 浅倉卓司@blog風味? のブックマークコメント

 個人的にはどうやってサーバを展開してるかが気になるのですが~。

 ハードじゃなくてソフトのほうね。

 例えばプログラムをバージョンアップさせるときに、某所のようにrsyncで散まいてるとは考えたくないのですけれど。


気になった点

 伊藤氏ははまぞうで利用したAWSのポイントとして「AWS正規表現でプログラムすること」を挙げた。はてなのようにページビューが多いサイトでは速度の問題がシビアであり、PerlXML関連モジュールはどうしても速度の面などで問題があるのだという。「Perl正規表現はとても優秀で、モジュールと比べても桁違いに早い。(速度という観点から)XMLモジュールよりも現実的なほうを実装している」。

 うーん。XMLモジュールでロジックをテストしてから正規表現による独自モジュールに変更、とかじゃないのか……。

 そもそもそんなにXMLを頻繁にパースする必要はない気もするんだけれど*4、2億PV/月=5,000PV/分*5だったりすると何かと問題があったりするのかもしれない。


 というか、90台のサーバって、どんな振り分けになってるんでしょ。

*1:もう少なくなってたりして。

*2:特にMySQLクラスタが良さそう。

*3:Cache::MySQLCacheかな?

*4AWSの結果はキャッシュしてるんでしょ?

*5:ピーク時はこの2~3倍くらい?

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20041222

2004-12-21(Tue)

CPANに登録ですか

| 18:48 |  CPANに登録ですか - 浅倉卓司@blog風味? を含むブックマーク  CPANに登録ですか - 浅倉卓司@blog風味? のブックマークコメント

FeedBack にも導入してみようかな。ちなむと、CPAN に up 希望です。

Class::DBI のパフォーマンスを上げる Class::DBI::Plugin::Iterator

 CPANに上げるのはいいんですが、誰かやりかた教えてください。

 ――と思ったらこんなドキュメントを発見。うーん、上げちゃっていいのか心配になります(苦笑)。

 あと、PAUSEにアカウントを作らなくちゃいけないような気がするのと、英語でドキュメントを書かなくちゃいけない*1っぽいのが難点かな。


 ちなみにClass::DBI::Pagerの改善がどうのというよりも、Class::DBI::Iteratorを使えば全件取得しないと勘違いして使っていたので*2、それの対策をしなくちゃなと思ってたのです。

 本当はClass::DBI::Liteとか作るつもりだったのでした*3


パフォーマンス

| 18:48 |  パフォーマンス - 浅倉卓司@blog風味? を含むブックマーク  パフォーマンス - 浅倉卓司@blog風味? のブックマークコメント

これ、全体のベースクラスでプラグインしてしまうと、数行のデータ読み込み時とかで遅くなっちゃうかもなので、このプラグインを当てたページ処理の時専用のクラス作って、ページ処理の時とかだけオブジェクトを再blessしてやったりしたらどうだろうか。

むしろオブジェクトの再定義分遅くなっちゃったりしちゃうのかな。

Class::DBIのパフォーマンスアップ

 ええと、数行の読み込みの時は圧倒的に早くなります。イテレータを生成するときはSQLを発行しませんから。

 むしろ全件一気に表示するときのほうがパフォーマンス的には良くないです*4。が、そういうときはイテレータを使わないと思うので、問題ない気がしてます。

 そうでもない?


細かくバージョンアップ

| 18:48 |  細かくバージョンアップ - 浅倉卓司@blog風味? を含むブックマーク  細かくバージョンアップ - 浅倉卓司@blog風味? のブックマークコメント

 新版上げました。

 改良点は

  • dataメソッドがまともに値を返すようになった。
  • delete_allメソッドの改善
  • 日本語ドキュメントの追加
  • 他、こまごまと

あたりです。確か。

TODO

 ドキュメントを英語にするのと、先読み(prefetch)を追加したらCPANに登録するのも良いかと思うのですが。思うだけで終わりそう……。

 ほか気付いてる点でまずそう(だけど動くからいいよね的)なのは、

  • SQLを発行してるトコはevalで囲んでおいたほうが親切かもね
  • sliceを使ったときの挙動をClass::DBI::Iteratorと同じにする(けど、あっちが変だと思う)
  • インデントはタブにしておいたほうがいい?

あたり。

*1:ちなみに日本語のドキュメントは適当に書きました。

*2:だってIteratorのドキュメントにそれっぽく書かれてるから。Pagerのほうにはちゃんと注意書きがされてたんですけどね……。

*3:高級な機能は必要ないので……。あー、1か月くらい前か。結局放置してたんだけど。

*4:そゆときのためにallメソッドを作っておいたのでそちらをどーぞ。

kokogikokokogiko2004/12/21 01:08はじめまして。有用なモジュールありがとうございます。
>>数行のデータ読み込み時とかで遅くなっちゃうかもなので
>むしろ全件一気に表示するときのほうがパフォーマンス的には良くないです。
その通りでした。
何かボケてました。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20041221

2004-12-20(Mon)

Class::DBI::Plugin::IteratorのTips

| 18:48 |  Class::DBI::Plugin::IteratorのTips - 浅倉卓司@blog風味? を含むブックマーク  Class::DBI::Plugin::IteratorのTips - 浅倉卓司@blog風味? のブックマークコメント

 簡単にベンチマークをとったところ、search等*1でマッチした件数に対して実際に使うのが半分以下で、sliceすればほぼ確実にパフォーマンスが上がるみたいです。逆にnext等を使うとかなりパフォーマンスが落ちます。

 ということで、Class::DBI::Pagerは内部でsliceを使っているので、一緒に使うといいでしょう。

package Films::FavoriteFilms;
use base 'Class::DBI::mysql';
use Class::DBI::Plugin::Iterator;
use Class::DBI::Pager;
__PACKAGE__->connection($dsn, $username, $password, $options);
__PACKAGE__->set_up_table('favorite_films');

package main;
my @data = Films::FavoriteFilms->pager(10, 1)->retrieve_all;

みたいな感じ。というか、Class::DBI::Pagerを使っているなら一緒にClass::DBI::Plugin::Iteratorを使うのがオススメ。

 Class::DBI::Plugin::Pagerと違って既存のコードを書き換えなくて済むし、他のPluginも使えるのがポイント。


 もちろんClass::DBI::Pagerを介さずに

package main;
my @data = Films::FavoriteFilms->retrieve_all->slice(0, 9);

としたほうが軽いです*2

*1:retrieve_allやsearch_whereなど。

*2Class::DBI::Pagerはcountする分重い。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20041220

2004-12-19(Sun)

Class::DBI::Plugin::Iterator

| 18:49 |  Class::DBI::Plugin::Iterator - 浅倉卓司@blog風味? を含むブックマーク  Class::DBI::Plugin::Iterator - 浅倉卓司@blog風味? のブックマークコメント

 ダウンロードできるようにしました。

 ちなみにテストは適当です。ドキュメントもありません。


使い方

package Films::FavoriteFilms;
use base 'Class::DBI::mysql';
use Class::DBI::Plugin::Iterator;    # ←これを追加
__PACKAGE__->connection($dsn, $username, $password, $options);
__PACKAGE__->set_up_table('favorite_films');
1;
__END__

 これだけです。

 あとは何も変更する必要はありません。Class::DBI::AbstractSearch等のプラグインを使っても大丈夫。


Class::DBI::Iteratorとの違い

  • dataメソッドは空を返す。本当は全部のデータをfetchして返すべき?
  • sliceの戻り値がスカラーの場合は、Class::DBI::Iteratorオブジェクトを返す。また、ポインタが移動しない。

制限

 SQLのLIMIT ... OFFSET ... 構文を使っているので、それが使えないSQLでは動きません。

 Class::DBI::Plugin::Pagerみたいにするのが良いかとは思うけど。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20041219

2004-12-18(Sat)

Class::DBI::Plugin::Iterator とか作ってみた

|  Class::DBI::Plugin::Iterator とか作ってみた - 浅倉卓司@blog風味? を含むブックマーク  Class::DBI::Plugin::Iterator とか作ってみた - 浅倉卓司@blog風味? のブックマークコメント

 ちゃんと1件ずつ取得するようなIteratorを作ってみた。

 毎回SQLを発行するので件数が少ないときは重くなる*1。まあ、sliceを使えばその範囲をまとめて取得するので、それほど問題はないでしょう*2

 場合によってはsearchした瞬間の結果じゃないのが難点かもしれないけど*3、それが嫌ならLOCKするか配列として取得するのがいいんじゃないでしょうかね*4


ちなみに

 Class::DBI::Plugin::Pagerに書き換えようと言っていたのになんで作ったかというと、書き換えが思ったより面倒だったのと、思っていたより簡単に作れたから。

*1:どの程度の件数でメリットがあるのかは不明。

*2:逆に、Class::DBI::Iteratorのsliceは->nextをループで廻してるので効率が悪い。なんでmapや配列のスライスを使ってないのかは謎。

*3:これはClass::DBI::Plugin::Pagerでも同じはずだ。

*4:っつーか、ウェブアプリならセッションに突っ込まない限りあまり問題ない気もする。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20041218

2004-12-17(Fri)

Class:DBI::AutoLoaderの使い方

| 18:50 |  Class:DBI::AutoLoaderの使い方 - 浅倉卓司@blog風味? を含むブックマーク  Class:DBI::AutoLoaderの使い方 - 浅倉卓司@blog風味? のブックマークコメント

 mixiで「Class::DBI::AutoLoaderの使い方がわかんない」と書いてる人がいたけれど、何が分からないんだろう。

 サンプルに書かれているとおり、

  use Class::DBI::AutoLoader (
        dsn       => 'dbi:mysql:database',
        username  => 'username',
        password  => 'passw0rd',
        options   => { RaiseError => 1 },
        tables    => ['favorite_films','directors']
        namespace => 'Films'
  );

とすれば、Class::DBIを継承したFilms::FavoriteFilmsとFilms::Directorsが作られるって話でしょ。具体的には

package Films::FavoriteFilms;
use base 'Class::DBI::mysql';
__PACKAGE__->set_db(Main => $dsn, $username, $password, $options);
__PACKAGE__->set_up_table('favorite_films');
1;
__END__

みたいなことを自動でやってくれるんでしょう*1

 tablesを指定しなければ、そのデータベースにある全部のテーブルで上記のようなことをするので楽チンだけど、その分オーバーヘッドが大きくなるとか、まあ細かい注意点はあるかもしれませんが。

 標準のメソッド以外を使うことも出来るけど*2、そんなことするならAutoLoaderを使う意味はないか……。

*1:ソース読んでないけど。

*2:packageで追加すればいいだけなので。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20041217

2004-12-16(Thu)

QDBMをMySQLのストレージエンジンに出来る?

|  QDBMをMySQLのストレージエンジンに出来る? - 浅倉卓司@blog風味? を含むブックマーク  QDBMをMySQLのストレージエンジンに出来る? - 浅倉卓司@blog風味? のブックマークコメント

 そんなことをして嬉しいのかは分からないのですが、「MySQLの新しいストレッジエンジンの実装」とか読んでちょっと気になった。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20041216

2004-12-14(Tue)

編集は大事だけれど、

|  編集は大事だけれど、 - 浅倉卓司@blog風味? を含むブックマーク  編集は大事だけれど、 - 浅倉卓司@blog風味? のブックマークコメント

サイバー世界に溢れる玉石混交のソースの中から「碧玉」を探し出すのは大変な事だから、真にクオリティの高い記事を提供してくれる「媒体(パッケージ)」と「そのブランド」には、読者は「お金を払うべき」だし、提供する側も人集めなんかに利用せずに「お金を取るべき」だと思う。

そう、クオリティの高い物は、Webにも散在する形で沢山ありますが、責任を持って取りまとめ、読者に「塊」で提供するという行為自体が「絶対有償」であるべきです。

(お金も掛かるし。誰もが大金持ちなら、何でもかんでも無料でも良かろうが...)

■2004/12/12■

 大ざっぱには同意。この『読者に「塊」で提供するという行為』というのが「編集」という作業でしょう。

 問題になるのはどうやってペイしてもらうか=ビジネスモデルを構築するか、ということだと思いますが、ウェブでお金が動いてるのは今のところ広告か物販だけって感じですからね……*1

 ま、ウェブ上のビジネスモデルは出版じゃなくて放送だってのが現状なのかもしれないですが。


上記に関連するかもしれないと思ったのでメモ

http://www.itmedia.co.jp/news/articles/0412/14/news087.html より:

 学生は簡単に手に入る情報にあまりに慣れてしまい「1時間も2時間もかけてまでとびきり良い情報源を見つけることなど考えもしない」とニューヨーク州立大バッファロー校の情報科学教授であるアレックス・ハラベス氏は言う。

 「図書館の場合、自分にあった本のありかを教えてくれる図書館員に100ドル払うという人はどこにもいない」とConsumer Reports WebWatchのディレクターであるボー・ブレンドラー氏は言う。

しかしそれでも、そのような共同で作られる情報リソースのほうが、たった1人の人物が取り仕切って作る情報より、事象をより正確に描写できると考えているインターネット利用者もいる。

*1:ゲームも期待はされているけど、それほどお金が流れているわけではないし。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20041214

2004-12-13(Mon)

Class::DBIのTips

| 18:51 |  Class::DBIのTips - 浅倉卓司@blog風味? を含むブックマーク  Class::DBIのTips - 浅倉卓司@blog風味? のブックマークコメント

 Perlでのパフォーマンス計測は気になりますので、何かいい方法があれば知りたいです。普段はabとかwget -rとかDProfでお茶を濁してますが、上手い方法だとは思えないし。


 それはそれとして。

 Class::DBIを使うときは

$class->columns(Essential => @cols);

を明示的に設定しておきましょう。

 Class::DBIのドキュメントではcolumnsにAllを設定すれば*1Essentialに設定されることになっていますが、標準だとPrimaryのカラムしか返しません。

 なので、Primary以外のカラムにアクセスすると余計なqueryを投げることになります。

 これを避けるためには、

$class->columns(Essential => $class->all_columns);

とかしておいたほうがいでしょう*2

 常に全部のカラムを読み出していいのなら、

$class->set_sql(Retrieve => <<'');
SELECT *
FROM   __TABLE__
WHERE  %s

としておくのも手です*3


Class::DBI::ColumnsGroupのバグ?

sub add_group {
	my ($self, $group, @names) = @_;
	$self->add_group(Primary => $names[0])
		if ($group eq "All" or $group eq "Essential")
		and not $self->group_cols('Primary');
	$self->add_group(Essential => @names)
		if $group eq "All"
		and !$self->essential;
	@names = unique($self->primary, @names) if $group eq "Essential";

	my @cols = map $self->add_column($_), @names;
	$_->add_group($group) foreach @cols;
	$self->{_groups}->{$group} = \@cols;
	return $self;
}

となってるので、Allで設定すればEssentialにも設定されそうですが、肝心のessentialが

sub essential {
	my $self = shift;
	my @cols = $self->group_cols('Essential');
	@cols = $self->primary unless @cols;
	return @cols;
}

となっていてprimaryを返しちゃうため、結果的に

	$self->add_group(Essential => @names)
		if $group eq "All"
		and !$self->essential;

が成り立つことはないんですね……。

 ここは

	$self->add_group(Essential => @names)
		if $group eq "All"
		and !$self->group_cols('Essential');

にすべきじゃないのかな?

*1:$class->columns(All => @cols);とすれば。

*2:もちろんEssentialなカラムを選別するのが一番でしょうけど。

*3:僕はこうしてます。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20041213

2004-12-11(Sat)

Class::DBI::Plugin::Pager

| 18:52 |  Class::DBI::Plugin::Pager - 浅倉卓司@blog風味? を含むブックマーク  Class::DBI::Plugin::Pager - 浅倉卓司@blog風味? のブックマークコメント

 Class::DBI::Iteratorの中身を見て全件取得してるのでイマイチだと思っていたら*1Class::DBI::Plugin::Pagerは全件取得しないとのこと。

 ちゃんとあるんだね*2

 Pagerとして使わなくても、全件を引っ張りたくないときには便利じゃないかな。とりあえず手元にあるコードは全部書き換えるか……*3


気になる点

 search_whereは使えるけど、searchは使えないのかな? そのうち調べよう。

 もし仮にそうだとすると不便なので、searchにも対応するパッチを作らなくちゃね。


前の会社の人へ(読んでれば)

 えーと、以前はClass::DBIの戻り値をscalarにしておけば全件取得しないと思って実装してたんで、気が向いたらClass::DBI::Plugin::Pagerで書き換えるたほうがいいかもしれません。

*1:わざわざIteratorにするんなら全件取得しないと思うでしょ、普通。あるいはClass::DBI::mysql等のDB専用のものがあるなら、そちらでは全件取得しないようにIteratorを変えてると思うじゃん。

*2:もっとも、登録されたのは比較的最近みたいですが。

*3:全件取得しないようなラッパも作りはしたんだけどさ。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20041211

2004-12-07(Tue)

Parse::RecDescent

|  Parse::RecDescent - 浅倉卓司@blog風味? を含むブックマーク  Parse::RecDescent - 浅倉卓司@blog風味? のブックマークコメント

 途中で「自力でパーサを書いたほうが*1」「Parse::Yappを使ったほうが*2」などの誘惑に耐えつつ、とりあえずパーサを書く。

 文法定義文字列にUTF-8が入っているのはまずいっぽい。

 いや、いちおうUTF-8に対応してるんで、変数などで渡せば日本語もちゃんとパースできるんだけどさ。


 大ざっぱにはできたので、あとはブラッシュアップとデバッグですかね……。

*1:昔書いたし。

*2:Yaccは最長一致なのであまり悩まないで済む。重いけど。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20041207

2004-12-06(Mon)

マガジンデータ2004

|  マガジンデータ2004 - 浅倉卓司@blog風味? を含むブックマーク  マガジンデータ2004 - 浅倉卓司@blog風味? のブックマークコメント

 もはや広告とは縁がなくなってからこういうものを購入するのもなんですが。

 今回から印刷証明付きのものといわゆる公称部数が混ざっているわけですが、公称部数は本当に倍がけだったのね……。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20041206

2004-12-01(Wed)

VirtualPC上でOSの新バージョンの確認

|  VirtualPC上でOSの新バージョンの確認 - 浅倉卓司@blog風味? を含むブックマーク  VirtualPC上でOSの新バージョンの確認 - 浅倉卓司@blog風味? のブックマークコメント

 久々にOSのインストール。たるい。

 足りないモジュールが山ほどあるので付け加える。めんどう。

 さらに足りないPerlのモジュールをCPANから入れる。本当にたくさんあるな……。


 とりあえず動くっぽいことは確認。

 他にもBINDとかSMTPとかPOP3の設定も確認しなくちゃいけないけれど。


ConceptSearch

|  ConceptSearch - 浅倉卓司@blog風味? を含むブックマーク  ConceptSearch - 浅倉卓司@blog風味? のブックマークコメント

 ようやくジャストシステムの検索エンジンが復活するみたいです。

 もうちょっと早く発売されていればなぁ。6,000円+2,000円という価格設定も微妙。

 試用版とかが公開されて実際に使えば印象が変わるかもしれませんけれど、昔ちょっと触った時は重かった印象があるのです。今はSearchXの軽さに慣れちゃっているから、昔と同じだとちょっとつらい。

 メールソフトのShurikenとかBecky!に対応しているのは評価できるのですが*1

*1:この点でGoogleDesksearchは実用には使えないのです。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20041201
2004 | 01 | 02 | 03 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2005 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 08 | 09 | 10 | 11 | 12 |
2007 | 02 | 03 | 04 | 05 | 06 | 07 | 10 | 11 | 12 |
2008 | 02 | 03 | 04 | 06 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2011 | 01 | 02 | 03 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2012 | 02 | 03 | 04 | 05 | 07 | 08 | 10 | 11 | 12 |
2013 | 01 | 05 | 07 |
2014 | 01 | 02 |
2016 | 01 |
2017 | 01 | 05 |