ひまつぶし雑記帖

AmazonPA-API5に移行で大騒ぎや

2020/1/26 [10:47:47] (日) 天気

amazonのAPIが2020年にバージョン5になります。
https://affiliate.amazon.co.jp/help/node/topic/GZBFW3F79Y7FADBL

…というのは薄っすら意識はあったものの、1/23に届いたメールタイトルに驚愕

「IMPORTANT UPDATE - 
Upgrade to PA API 5.0 before PA API 4.0 shuts down on March 9, 2020」

この「PA API 4.0 shuts down on March 9,2020」はさすがに見逃さなかった。
これまでずっと使い続けていたAPIのまさかの終了のお知らせだ。

去年2019年は、売上のないアカウントはAPIの使用制限がかかるようになり(売上のないアカウントは実質使えなくなり)困ったなあ、と思いつつも、たまーーーに、ポツリとクリック→購入があって使える日もあったんだけど、今回のAPIの変更は、そんな呑気なことを言ってるヒマはない。
まったく使えなくなるのだ。

てことで対応しなきゃまずい。とてもまずい。かなりまずい。
慌ててamazonのwebサービスドキュメントページをざっくり確認。
https://webservices.amazon.com/paapi5/documentation/

ver4とver5ではまったく違う。別人となる。
https://webservices.amazon.com/paapi5/documentation/migration-guide/whats-new-in-paapi5.html
取得するデータが、今までずっと変わらずXMLだったのに、ver5からはJSONになる!!びっくりマークをつけてもつけたりないぐらい驚天動地だ。
…てことは、現状使っている自作のスクリプトは全面的に書き換えが必要となる。

SDKを使ってお手軽に、とか思って探してみたところ、ver5に用意されているSDKは、Java、Node.js、Python、PHPの4つ。なんでperlがないねんっ!!
確かamazonはフロントのWEB側はperlだったはずだろう。今どきのWEBサービスには珍しくperlのサンプルもずっと用意してくれていたってのに、だ(残るはPaypalぐらいか)

JavaもNode.jsもわからんちんだし、Pythonもこれからの主役はこれか、ぐらいの遠巻き。
PHPがどうにか少しはいじれるので、サンプルをダウンロードして、perlに移植してみた。
サンプルに入っているDefaultApi.phpでエンドポイントやオペレーション名を拾って、WithoutSDKのサンプルコードで署名込みのヘッダーを作れるようにした。
PHPはどこからグローバルというか、スコープというのか知らんけど、把握するのにあっちこっち行かなきゃわからないから好きじゃなかったんだ、てのを再認識。

さて、これでそれっぽいリクエストを作れるようになったはずなんだけど。
売上のないアカウントなので、試せない。
売上のないアカウントには用はないamazonだ。

作ったスクリプトを使って。
ローカルのPCでリクエストを投げると
439 TooManyRequests というステータスと、JSONでエラーメッセージが返ってくる。
試しにレンタルサーバーに上げてそこからリクエスト投げると
503 とHTMLのエラーページが返ってくる。
どうやらどちらも売上のないアカウントだから相手にされない、ということっぽい。

一応、レスポンスのサンプルは公式ページにある。
でもなあ、こういうのって実際に何が返ってくるのか確認できなきゃ難しいんだよなあ。

てことで、大慌てで昨日一日ごそごそやってみた感想というか所感というかなんちゅーかほんちゅーか。

 
APIとかクロールとかで検索するとPython本が上位にずらーっと。
インストールぐらいしていっちょかみしといたほうがええか…。

まあ、最悪はamazonのデータを利用してサービスを公開していて安定稼働している他サイトからデータをいただくというクズなことをすれば、わたしのサービスが止まることもないんだけどね。うーむ。
image 

»電子書籍制作代行についてはこちら

書誌情報データを求めて三千里

2019/4/3 [09:18:16] (水) 天気

一昨日、新元号の発表があった4月1日に国立国会図書館の書誌データAPIが解禁となった。
今までも検索などに使えていたけど、データベースとしてガツガツ使うには登録が必要だったり面倒くさかったのが、4月1日からは誰でも自由に使ってもかまわんぜ!になった。

てことで、今さら国立国会図書館の書誌データAPIをごそごそ覗いてみた。

国立国会図書館サーチについて>API仕様の概要 
https://iss.ndl.go.jp/information/api/riyou/

わたしの、というかわたしが公開しているサイトの使い方は前にも書いた通り。
「ISBNをキーにして書誌データと書影URLを取得したい」
たとえば、スティーヴン・キングの『シャイニング』
ISBNは978-4167705633

これを国立国会図書館のAPIで探すには以下
https://iss.ndl.go.jp/api/opensearch?isbn=978-4167705633
→書誌情報のXMLが返ってくる
https://iss.ndl.go.jp/api/openurl?isbn=978-4167705633
→検索結果ページが返ってくる
https://iss.ndl.go.jp/api/sru?operation=searchRetrieve&maximumRecords=10&query=isbn%3d9784167705633
→書誌情報XMLが返ってくる(このsruはさらに細かく検索方法の指定もできる)

うちの場合、必要な書誌情報はopensearchで十分。
著者についてももろもろ考慮されて(同性同名や読みなど)おり、データのクオリティは信用できる。さすが。
https://www.ndl.go.jp/jp/data/faq/author.html

蔵書のある図書館の情報なども取得できるので、位置情報と合わせて「目当ての本がある最寄りの図書館」なんて検索も実装できるし、その手のアプリがすでにあるのは、国会図書館のデータが元ネタじゃないかな。

だけど、書影がないのはほんと残念。
本棚を眺める楽しみのひとつ、というか欠かせないのが表紙だもんなあ。
基本的な書誌情報は国立国会図書館で、書影・表示画像はamazonなどのショップサイトのURLを別途取得…とか1冊の本のために2回も外部にリクエストしてるとサイトの表示がもたつく原因になってしまう。

てことで、うちのサイトのデータ取得方法は現状のままとする。
国会図書館のデータはまた何か別の用途で利用させてもらおう。しっかりとしたデータは見ていて気持ちいい(データオタク)


ちなみに。
「一般社団法人 日本出版インフラセンター」という版元主導のところも3月25日に書誌データベースのサイトをオープンしたけど、APIもなく、手入力でポチポチ検索できるだけ、なのでスルー。
image

»電子書籍制作代行についてはこちら

paypalを使って電子書籍のダウンロード販売

2016/5/19 [16:17:41] (木) 天気

電子書籍元年が何度もきたおかげで、電子書籍(デジタルコンテンツ)のダウンロード販売がDRMもついてAmazonや楽天kobo、iBookstore、KADOKAWA☆BOOKWALKERに並べることができる時代となった。

また、電子書籍専門というわけではなく、デジタルコンテンツをダウンロード販売できるサイトも百花繚乱雨後筍で、コンテンツさえ用意できれば個人で簡単に販売ができる。

「デジタルコンテンツをダウンロード販売できるサイトを比較してみた」
http://writing-san.blog.jp/archives/32017213.html

また、ワードプレスにはダウンロード販売のためのプラグインまであって、販売チャンネルの選択肢はたくさんある。

「Easy Digital Downloads - ダウンロード販売サイトを簡単に作れるWordPressプラグイン」
http://netaone.com/wp/easy-digital-downloads/

集客力販売力、販売手数料や手間ひまを考えて自分に合うところにコンテンツを置けばいいし、そうすれば販売ページへのURLや購入ボタンをSNSや自分のサイトに貼りつけて告知できる。


ぶっちゃけ、わざわざ自分でダウンロード販売の仕組みとか作るのは時間と労力の無駄なのでオススメしない。
面白そうだ、という好奇心自己満足。それと、もしかすると、何らかの事情で他社サービスにコンテンツを置くわけにはいかないような場合に。

てことなので、以下はわたしの技術メモ。備忘録。
内容的には2010年の雑記とPayPalとのやり取りなどはほぼ同じ。
「paypalと電子書籍のダウンロード販売(その1)」
http://t2aki.doncha.net/?id=1277017233
「paypalと電子書籍のダウンロード販売(その2)」
http://t2aki.doncha.net/?id=1277130006
今回の雑記では自サバ側のこともメモしておく。


【じぶんちでの設定】
コンテンツをサーバーの所定のフォルダにアップロード。
サーバーのデータベースにコンテンツの商品登録。ここで商品にIDを付ける。
以下3つのスクリプトを用意
・ご購入ありがとうございますページのスクリプト
・IPN受信&データベース登録用のスクリプト
・ダウンロード用スクリプト


【PayPalでの購入ボタン作成・各種設定】
「トップ」→「販売ツール」のメニューにある「売り手の設定」から

→「PayPalボタン」
[今すぐ購入]サンプルボタンあたりを雛形に「ボタンの編集」で商品名や値段などを入れる。ここではオプションの商品ID(=データベースで決められたID)を入れるのを忘れずに。
ボタンを作ったら「コードをコピー」して自分のサイトの購入ボタンを設置したいところにコードをペーストする。

→「ウェブサイトの設定」(ウェブペイメントの設定)
・ウェブペイメントの自動復帰「オン」
・復帰URL:ご購入ありがとうございますページのURLを記入
・支払いデータ転送「オン」※IDトークンをコピーしておく
・暗号化されていないウェブペイメントの受領拒否「オフ」
・PayPalアカウントオプションサービス「オン」
・連絡先電話番号「オフ」
・エクスプレスチェックアウトの設定「いいえ」

→「即時支払い通知」(IPN)
・通知URL:IPNを受信するスクリプトのURL
・メッセージの配布:有効

→「PayPalボタンの言語コード化」
・「詳細オプション」→「UTF-8」


【PayPalとのやりとり】
image 
ユーザーの動きは以下の3つ。
1)ユーザーがオレオレサーバーの購入ボタンをクリックすると
2)PayPalの決済ページに飛んでそこでお支払い
3)お支払いが終わるとオレオレサーバーの購入ありがとうございましたページに戻ってくる。

ユーザーのお支払い終了と同時にPayPalからオレオレサーバーに購入データが飛んでくる。

購入データは以下の2種類。
データを取得して解析するためのサンプルコードがPayPalに用意されていて、そのまんま利用させてもらう。

3)PDT(Payment Data Transfer)

図では赤い矢印がひとつだけど、データのやりとりの実際は。
→PayPalからオレオレサーバーへ
・ユーザーが購入ありがとうございますページにリダイレクトされてくる時に、トランザクションを持ってアクセスしてくる
→オレオレサーバーからPayPalへ
・トランザクションと管理ページの「支払いデータ転送」の項目に記載されているIDトークン、コマンドをPOSTでPayPalにリクエスト
→PayPalからオレオレサーバーへ
・POSTした内容が正しければ一行目に「SUCCESS」と書かれたデータを返してくる

このPDTデータは
SUCCESS
first_nameJane+Doe
lst_name=Smith
payment_status=Completed
など、1行にひとつ「ネーム=バリュー」形式、NVP形式のデータとなっている。

※ユーザーが支払いを終えて待たずにすぐブラウザを落としたりするとデータ取得できない。購入ありがとうございますページにリダイレクトされてやってきて初めてデータのやり取りが生じる。

PDTデータ取得&解析のサブルーチン
※HTMLデコードと文字コードをutf8にしているところ以外はサンプルコードのまんま。


PDTデータのpayer_emailやitem_nameなどを「ご購入ありがとうございます」ページの「~様」や「~をご購入いただきありがとうございました」などの個別の表示に使う。
PDTデータのitem_number(商品ID)でダウンロード商品なのか、別の商品なのかを判定して、ダウンロード商品の場合はダウンロードURLを表示する。ダウンロードURLはユーザーのemailやtransactionidなど一意のものから作成している。


4)IPN(Instant Payment Notification)
ユーザーから見える言わば表側のPDTと違って、こちらは裏側。
ユーザーがお支払いを終えると管理ページで指定したURLにデータが飛んでくるので取りこぼしがない。
PDTはユーザーに見せるご購入ありがとうございますページに使う程度で、オレオレサーバーのデータベースに購入の記録を残すためにはこちら、IPNを使う。

図では赤い矢印がひとつだけど、データのやりとりの実際は。
→PayPalからオレオレサーバーへ
・購入データが送られてくる。いわゆるWEBのフォームデータで「&」で繋がれた「ネーム=バリュー」形式
→オレオレサーバーからPayPalへ
・送られてきた購入データにコマンドをひとつつけてPayPalにPOSTする
→PayPalからオレオレサーバーへ
・「VERIFIED」か「INVALID」か一行返ってくる。これ以外は調べる必要があるらしいが滅多になさそうだし、PayPalの管理画面で確認すれば良い。

IPNデータ取得&解析のサブルーチン
エラーはIPNのデータをつけてメールするように。
VIRIFIED(データが正しい)場合でも以下の4点を確認する。
・支払いのステータス「payment_status」が完了「Completed」であることを確認
・すでに完了した取引の悪用防止のために「txn_id」が過去のものと重複していないことを確認
・不正アカウントに支払いされないように「receiver_email」がPayPalアカウントに登録したメールアドレスであることを確認
・価格が変更されていないか確認(商品IDなども)
確認できたらオレオレサーバーのデータベースに必要情報を登録して、ユーザーにお礼とダウンロードURLを書いたメールを送信する(自分にも同じものを送信)

※データ確認の部分やメールの部分以外はサンプルコードのまんま。



【ダウンロードについて】

ダウンロードはダウンロード用のスクリプトがファイルを返すようにしてある。
たとえば、わたしが自分だけで作ったコンテンツなんかはどうでもいいんだけど、表紙が依頼原稿だったり、アンソロジーでほかの人の原稿が入っていたりするとそうもいかない。回数や期間を無制限にするわけにはいかない。
なので、ファイルの置き場所=URLをそのままユーザーにお知らせできない。

ダウンロード用のスクリプトを噛ませて
・ダウンロードのURLは購入者ごとに違うものを作る
・ダウンロード回数を制御する
・ダウンロード期間を制御する
といったことを仕込んだ。

また、ダウンロードごとにIPやUserAgentを記録すれば、不正なアクセスやダウンロードできない事故などの問題解決にも役立つ。


以前の雑記にも書いたように、PayPalは管理ページに記録が残ってるし取引が生じたらいちいちメールも飛んでくるので、致命的な問題にはならないはず。サポートもびっくりするというか恐縮するぐらいに厚い。

残念なことに(法律的に?)日本では単純にクレジットカードだけで支払いはできなくなった(ペイパルへのアカウント・会員登録が必須となった)けど、個人での少額決済に手軽に使えるので助かるなあ。

»電子書籍制作代行についてはこちら

創作文芸見本誌会場HappyReadingに書誌情報APIを実装しました

2016/1/20 [23:35:34] (水) 天気

APIといえるかどうかはともかく。
創作文芸同人誌のプレビュー・立ち読みサイトのHappyReadingの作品ページに掲載されている書誌情報をXMLで提供するようにしました。
『創作文芸見本誌会場HappyReading』http://books.doncha.net/happy-reading/

今さらですが、HappyReadingはけっこうな量の入力項目があります。
にも関わらず登録いただいてるので、入力された情報をHappyReading以外(たとえばサークルや個人のサイト)で使えれば、読者さんへの告知の幅も手軽に広げることができるのではないかということでXML。

平たく言っちゃうと、自分のサイトやブログでも紹介したいのにまた同じことを書くのは面倒くさい!ということでXMLでの情報取得のAPIもどきをでっち上げました。

XMLで提供する登録情報は以下
image
・HappyReadingのページURL
・登録したアカウントID
・本のID
・タイトル
・発売日
・ページ数
・判型
・印刷形式
・頒布価格
・キャッチ
・著者(イラストレーター、編集者、デザイナーなど)
・サークル名
・サイト
・サイトURL
・アマゾンのASIN
・カテゴリ
です。
※表紙画像や立ち読みの情報は提供していません。

http://books.doncha.net/xml.pl?bookid=839
↑このURLにbookidを指定してアクセスすると書誌情報のXMLを返します
(Firefoxなどでアクセスしてもらえるとどんなものか見えます)

http://books.doncha.net/happy-reading/detail.pl?uid=14879977&bookid=839
↑bookidというのはHappyReadingの作品個別ページのURLのbookidのことです。

このXMLを取得してページに合わせて加工することになります。

http://books.doncha.net/happy-reading/detail.pl?uid=14879977&bookid=566
このHappyReadingのページのXMLをperlで取得、アレンジして表示したのが以下です。
image
http://hino-yutaro.doncha.net/?happyreading=566
※表紙画像と立ち読みは別途用意してます。

phpやperlを使って取得&加工するのが手っ取り早いですが、javascriptが使えればHappyReadingのXMLを取得できます。

はてなやFC2といったブログの場合は「HTML編集」などにしてページの好きな場所に以下のコードをコピー&ペーストすればXMLを取得してページに表示します。
先頭の「data-book="XXX"」の部分にHappyReadingのbookidを記入。


「はてなブログ」で確認。
・「編集 見たまま」でアップロードした画像を貼り付けたり、記事を作ります。
・「HTML編集」でHappyReadingの登録情報を掲載したい部分に上記のコードを(bookidを記入して)貼り付けます。
image
・「プレビュー」
image
素気ないリストでの表示なので、スタイルシートでデザインします。
・id が #happy-reading のリスト(ul)となっていて。
 liに「title」「creator」「size」「printing」「pages」「price」「published」「category」「catch」「circle-name」「site-url」「amazon」「to-happy-reading」というクラスをつけてます。
表示or非表示や文字サイズ、色などをCSSでカスタマイズできます。
(わたしはデザイン力がないのでテンプレートを作る気力が…)


ハマったところがあったんでメモ。

Javascript、ajaxで別ドメインにあるXMLを取得するためにはjQuery側とサーバー側で設定が必要だった。

・jQueryのajaxのパラメータ「crossDomain」を true にする。
・サーバー側(今回の場合xml.pl)スクリプトのHTTPヘッダに
「Access-Control-Allow-Origin:*」
「Access-Control-Allow-Headers:Origin, X-Requested-With, Cotent-Type, Accept」
の2行が必要だった。

(スクリプトに付加したヘッダはなにやらセキュリティ的に不穏な感じなので、formデータのチェックを厳密にしておいた)

»電子書籍制作代行についてはこちら

twitterのOAuthについて改めて

2013/11/24 [10:43:06] (日) 天気

perlでtwitterのOAuth認証するまで概略。
(今まで何度か書いたと思って探したら、スゲーテキトーなことしか書いてなかった)
「OAuthとは」てのはわたしもよくわかってない。詳しいサイトがたくさんあるので興味のかたは検索して調べてください。

大雑把に。
ユーザーを識別するのに、IDとパスワードが必要になるんだけど「野良サービスにメールアドレスやパスワードを登録するのはどうなの?」「いろいろなところにIDやパスワードを登録しても忘れちゃうし」ということで不安だし不便。サービスを提供する側としてもユーザーのIDなどを管理するのはリスキー。
そこで、twitterやfacebook、yahoo、mixiなどすでに利用していて信用できそうなサイトにログインしたら、そのまま他のサービスも使えるようにする・twitterなどがユーザーを保証してくれるのがOAuth認証というやつ(言葉はたぶん間違ってる)

ウチの「創作文芸見本誌会場HappyReading」http://books.doncha.net/happy-reading/ で使っている。

1 同人誌の登録ページにログインする
2 twitterのログイン画面に飛ぶ
3 twitterでIDとパスワードを入力する
4 ウチのページに戻ってくる

2のこんな画面は見たことがあると思う。
image
・ユーザーはtwitterのアカウントがあれば、twitterのID・パスワードでウチも使える。
・ウチとしてはユーザーのIDやパスワードを管理しない(知らないまま)なのでリスクが少ない。



準備
https://dev.twitter.com/apps

↑まずはアプリをここで登録をする。
(WEBだったらCGIなどのサービス)

登録するとOAuthに使うパラメータというかトークンが設定されるのでメモ。
・Consumer key
・Consumer secret
・Access token
・Access token secret

以下のURLもメモ。
・Request token URL
 ttps://api.twitter.com/oauth/request_token
・Authorize URL
 ttps://api.twitter.com/oauth/authorize
・Access token URL
 ttps://api.twitter.com/oauth/access_token
・Callback URL
 http://example.com/test.cgi
 (これは自分が登録したWEBサービスなど)


その1
consumer key と consumer secret、callback URLをパラメータに持ってtwitterにトークンを要求する。
ttps://api.twitter.com/oauth/request_token に以下のHEADERをつけてGETでアクセス。



その2
consumer key と consumer secret に問題がなければ、oauth_tokenを取得できる。
twitterのログインページ(上図 ttps://api.twitter.com/oauth/authorize)にoauth_tokenをパラメータにつけてリダイレクトする。



その3
twitterのログインページでアプリを承認をすると再びウチのページに戻ってくる。
その時、oauth_token と新たに oauth_verifier というパラメータを付けてくる。



その4
oauth_verifier をパラメータに追加して ttps://api.twitter.com/oauth/access_token にPOSTでアクセスする。
postのcontent


問題がなければ、oauth_token と oauth_secret と screen_name が取得できる。

後はこの oauth_token と oauth_secret を使って(セッションなど利用して)ユーザーがウチのサービスを使えるようにする。


補足:OAuth のパラメータ
URL
METHOD
oauth_callback
oauth_consumer_key
oauth_nonce(一意のランダムな文字列)
oauth_signature(署名)
oauth_signature_method(署名の方法 HMAC-SHA1)
oauth_timestamp(タイムスタンプ timeの出力)
oauth_version(oauthのバージョン)

署名の作り方についてはこのあたり→  「token secretの保存」 (2009/12/26)


ここんとこ、ツイート1のスパムアカウントからのフォローが断続的に続いて、いちいち手動でスパムブロックするのが面倒になったので、一括スパム報告するスクリプトを作ってみたら…OAuthなどずいぶんいろいろ忘れてたので、備忘録。
もの忘れが激しい。とほほ。

»電子書籍制作代行についてはこちら

ツイートとレビューを取得する

2013/2/24 [10:07:32] (日) 天気

この雑記帖スクリプトでは、公式APIが使いにくい・デザインが合わないブログパーツなどに関しては、HTMLから直接取得している。

twitterの「その他」→「ツイートをサイトに埋め込む」
この機能は便利なのに、表示・デザインに自由度がなくて、サイトに埋め込むと
image 
このありさま。どっちが本文でどっちが引用(ツイート)なのかわからない我が侭な自己主張。ユーザビリティ、デザイン的にこれはない。
twitterとしては、表示をコントロール下において広告などで収益を視野に入れて展開したい、んだろうけど。サイトはこちらのもの。大きな顔をされては困る。

Amazon AWS の API でレビューが取得できなくなっていた(もう2年も前の話。今さら気づくのんきな父さん)
商品情報に含まれているのは、ユーザーレビューがあるかないか(true false)ユーザーレビューページのURL(24時間の期限付き)。このURLをインラインフレームで埋め込んでね、ということらしい。インラインフレーム表示させると、サイトの統一感を壊してしまって、楽天のチラシのような見た目になってしまう。
Amazonとしては、レビューの品質を上げるためにレビューをコントロール下において、レビューの精査・削除などしていきたいんだろう。

しかたないので、twitterもAmazonも公式APIを使わずに、HTMLを解析して取得、スタイルシートなど調整して、サイトにおさめるようにした(スクリプトのソースはちょっと内緒。HTMLのどこを見てるかあまりおおっぴらにするのは良くない=ルール違反かなあ)


見やすいサイト、使いやすいサイトは、サイトに掲載される情報の分類がきちんとわかりやすくレイアウトデザインされていて、動線も明確でリンクをクリックしたら何が起こるのかわかりやすくなっている。

アートは感性・デザインは理屈。サイトもデザインと同じで、どうしてこの位置にこのブロックがあるのか、なぜ動線はこっちに向けてるのかなどなど、いちいち説明がなければならない。

情報設計=インフォメーションアーキテクチャ=IA というらしい。初めて聞いたときは、また妙な、きっとくだらないカタカナ言葉でひとを騙そうとしやがって、だったんだけど本を読んでみると、IAに関してはWEBに関わるひとにとって必須。

 

 

»電子書籍制作代行についてはこちら

profile

profile

 
doncha.net
名前:
飯田哲章
mail:
t2aki@mrh.biglobe.ne.jp
twitter:
t2akii

WEBサービス制作/電子書籍制作

検索
<<2023/6>>
    123
45678910
11121314151617
18192021222324
252627282930

リンク

WINDOWS版サウンドノベル
おかえりください PC WINDOWS版サウンドノベル
『おかえりください』体験版

[5 Page] »
1 2 3 4 5

TOTAL:2936

2023 (12)
1 (1)
2 (5)
3 (1)
4 (1)
5 (3)
6 (1)
2022 (16)
1 (1)
3 (2)
6 (2)
7 (1)
8 (4)
9 (2)
10 (1)
11 (2)
12 (1)
2021 (12)
1 (3)
2 (1)
6 (1)
8 (2)
9 (1)
10 (1)
11 (2)
12 (1)
2020 (18)
1 (2)
2 (6)
4 (1)
6 (1)
7 (2)
8 (2)
12 (4)
2019 (17)
1 (3)
2 (4)
3 (2)
4 (2)
5 (1)
6 (1)
8 (1)
10 (1)
12 (2)
2018 (21)
1 (3)
2 (2)
3 (2)
4 (1)
5 (1)
6 (6)
8 (1)
9 (1)
10 (2)
12 (2)
2017 (32)
1 (2)
2 (1)
4 (2)
5 (1)
6 (6)
7 (3)
8 (5)
9 (3)
10 (2)
11 (2)
12 (5)
2016 (41)
1 (5)
2 (5)
3 (2)
4 (3)
5 (4)
6 (6)
7 (2)
8 (2)
9 (3)
10 (1)
11 (4)
12 (4)
2015 (99)
1 (11)
2 (12)
3 (9)
4 (6)
5 (8)
6 (8)
7 (3)
8 (5)
9 (16)
10 (6)
11 (1)
12 (14)
2014 (112)
1 (16)
2 (5)
3 (6)
4 (12)
5 (16)
6 (19)
7 (9)
8 (6)
9 (4)
10 (8)
11 (6)
12 (5)
2013 (145)
1 (24)
2 (15)
3 (18)
4 (23)
5 (14)
6 (11)
7 (7)
8 (11)
9 (5)
10 (4)
11 (6)
12 (7)
2012 (103)
1 (1)
2 (1)
3 (4)
4 (3)
5 (7)
6 (26)
7 (17)
8 (5)
9 (8)
10 (10)
11 (11)
12 (10)
2011 (54)
1 (4)
3 (7)
4 (4)
5 (14)
6 (6)
7 (3)
8 (3)
9 (1)
10 (4)
11 (2)
12 (6)
2010 (70)
1 (12)
2 (7)
3 (6)
4 (6)
5 (3)
6 (10)
7 (6)
8 (4)
9 (3)
10 (4)
11 (3)
12 (6)
2009 (144)
1 (15)
2 (12)
3 (12)
4 (6)
5 (15)
6 (6)
7 (10)
8 (9)
9 (17)
10 (12)
11 (14)
12 (16)
2008 (148)
1 (10)
2 (6)
3 (10)
4 (11)
5 (13)
6 (10)
7 (13)
8 (19)
9 (18)
10 (12)
11 (13)
12 (13)
2007 (106)
1 (7)
2 (5)
3 (3)
4 (7)
5 (5)
6 (9)
7 (8)
8 (13)
9 (18)
10 (11)
11 (8)
12 (12)
2006 (158)
1 (28)
2 (28)
3 (25)
4 (7)
5 (9)
6 (7)
7 (12)
8 (13)
9 (10)
10 (7)
11 (6)
12 (6)
2005 (350)
1 (31)
2 (26)
3 (26)
4 (27)
5 (29)
6 (30)
7 (32)
8 (30)
9 (30)
10 (32)
11 (29)
12 (28)
2004 (292)
1 (24)
2 (24)
3 (29)
4 (27)
5 (28)
6 (25)
7 (26)
8 (24)
9 (12)
10 (19)
11 (26)
12 (28)
2003 (318)
1 (22)
2 (25)
3 (21)
4 (28)
5 (28)
6 (28)
7 (28)
8 (29)
9 (26)
10 (29)
11 (28)
12 (26)
2002 (317)
1 (29)
2 (26)
3 (26)
4 (25)
5 (28)
6 (30)
7 (27)
8 (21)
9 (25)
10 (27)
11 (28)
12 (25)
2001 (277)
1 (17)
2 (21)
3 (23)
4 (20)
5 (31)
6 (18)
7 (26)
8 (25)
9 (29)
10 (19)
11 (24)
12 (24)
2000 (53)
6 (9)
7 (4)
8 (2)
9 (3)
10 (1)
11 (15)
12 (19)
1999 (3)
7 (1)
10 (2)
1998 (18)
9 (9)
10 (7)
11 (2)