Hatena::ブログ(Diary)

備忘録(仕事と晩飯)

2017-10-12

アクセスランキング

三連休の中日に近刊検索デルタのアクセスランキングを公開した。

GAを取得→DBテーブルインポート→それを使って集計したりなんだり。

βの時はなんでもかんでもXMLにしていたが、今回はDBテーブルに入れるようにしている。とはいえ、できるだけDBにアクセスしないようにするにはどうしたらいいかとか、そんなことばかり考えてあれこれやってる。

ランキングそのものはうまく動いたものの、連休の中日ということで今ひとつアクセスが伸びなかった。タイミングって大事だなあ。

これで、次の大物はCSV。ランキングよりCSVのほうが難しくないので、次の土日にサクッと片付けてしまう予定。

三連休の思い出(忘れないうちに)

三連休は宿題三つをなんとかしようと悪戦苦闘。デルタランキングはなんとかかんとかほぼ完了(しかし、三連休の中日の公開で効果はさっぱり)。もうひとつ(本屋ブログ)はある程度まで。最後のひとつは手付かず(これは持ち帰り仕事だったのだが、連休明けに「手が空いたのでここまでやっておきました」という話があって感動。素晴らしい)。で、連休中に増えたひとつ(妻のお手伝い)は着手まで。

それはともかく、三連休の牛肉。

初日はステーキ。百グラム1500円の牛肉(一枚200グラムなので3000円)をいただいたので焼いた。フライパンだとムラができて難しそうだったので、ホットプレートを使用。まずは牛脂とバターでスライスしたニンニクを焼くところから。片面だけ軽く焦げ目が付く程度で引っ繰り返して蓋の代わりにアルミフォイル。焼きすぎない程度で皿に。ナイフで切った断面に赤みが僅かに残っていい感じ。ワサビ醤油で。美味しゅうございました。

次の日はやはりいただいた別の牛肉ですき焼き。まあ、こっちは外れはない。美味しゅうございました。

羊肉も好きだが、牛肉、いいのは美味いなあ。いただきものじゃないとこんな値段のは食わないのでいい経験だった。うまく焼けるか心配だったが、焼き加減も上々。大満足でした。

2017-10-09

心がしく―ッとなる映画

予備知識まったくなしで見た『ガタカ』は、心に残るいい映画だった。確認していないが、猛烈にイギリスっぽい映画だったので多分そうなんだろう。主役のイーサン・ホークは、きれいなベン・スティラーみたいな感じでとても良かった。ジュード・ロウは文句の付けようがない。ユマ・サーマンは苦手だがしょうがない。多分、忘れた頃に、また見る。

クラウド・アトラス』は、ペ・ドゥナハル・ベリーが有無をも云わせぬほど素晴らしかった。あと、音楽家の若僧が良かった。ただ、トム・ハンクスは何に出てもどうメイクしてもトム・ハンクスなのはどうしたものだろうか。ヒューゴ・ウィーヴィングもだ。それと比べるとヒュー・グラントは悪くなかった。でも、もう一度は見ないかもなあ。いや、やっぱり忘れた頃にもう一回見るかなあ。

その後に見た『ノーカントリー』は、1ミリも救いがなくて、最高にグッと来た。もう、とにかく絶望しかない。こんなにむき出しの暴力に満たされた映画はなかなかない。何度も見たい。主役の悪いおっさんは素晴らしいが、トミー・リー・ジョーンズも良かった。見直した。



2017-09-23

ISBNを入力していくと、書誌情報が表になる 〜 石田さんの話

FBでたまたま見かけた投稿で、「ISBNを入力していくと、書誌情報が表になる」サイトがあることを知る。どれどれと思って見に行ったら、亡くなった石田豊さんが立ち上げた「YOMUPARA」だった。

石田さんはYOMUPARAで読書グッズの販売をする中で、バーコードリーダーを扱っていた。個人の蔵書管理に使うと言う。「そんな人いるんですか」「俺がいる」みたいな話をしたようなしなかったような。

石田さんは『MySQL入門以前』という本を書いていて、出版の前に読者リサーチというか、実際に本の内容を使ってSQL(とPHP)を勉強する会を開催するので参加しないかと誘われた。いや、誘われたというより、「参加するよね」ということで製本したゲラを送られたのだ。当時、PHPも触ったことが無かった自分にはハードルが高いなあと思いつつ、できれば参加したかったのだが、今ひとつタイミングが合わずに不参加となった。

それほど頻繁に接点があったわけではない。が、なんとなく、気にはなっていた。

MySQL入門以前』のゲラに付属していたCD-ROMは自分の環境では使えなかったのだが、ゲラは何度か通読した。が、すぐに忘れるほうなので……。

YOMUPARAの話は『MySQL入門以前』より前だった。デモも見たな、そう言えば。バーコードリーダー使ってまで蔵書管理したい個人というのがイメージできなかった。実は今でもそれは変わっていない。

石田さんが亡くなる直前まで書いていたWeb連載、最後の方は読むのが怖かった。

石田さんが亡くなった後、いよいよ実際にPHPSQLを触るようになってしばらくしてからまたゲラを開いてみた。なるほど、という感じ。気がつくと石田さんが「入門以前」と定義していた段階は越えていた。と、同時に、「この本を使って勉強してもよかったかもな」と、そう思えた。基本が丁寧に書いてある本だった。

昨日、本当にたまたま「ISBNを入力していくと、書誌情報が表になる」サイトのことを知って、それが石田さんのYOMUPARAだとすぐに気付いた。というか、YOMUPARAと書いてあるから気づくも何もないのだが。

FBの投稿は「今まで便利に使っていた「ISBNを入力していくと、書誌情報が表になる」サイトが急にエラーを表示するようになった」という内容だった。実際に試してみるとAMAZONAPIから書誌情報を取得するjavascriptのエラーだった。

石田さんと出逢った頃の自分なら、このエラーを見ても何もわからなかっただろう。けれど、今は何がどうなっているか、ある程度は分かる。

入力されたISBNを使ってamazonAPIを叩き書誌情報を取得する、そこは、はっきりとわかった。javascriptじゃなくてPHPでも同じことはできる。amazonAPIではなく、openBDを使おう。表にするのはどうしたらいいか。取得した書誌情報DBに貯める? いや、そうじゃなくて、入力されたISBNだけをPOSTで渡してカンマでつないでopenBDのGETで書誌情報を一括で取得すればいい。それをforeachで回して表にするだけだ。

open_bib

一時間ちょいで作った。どうですか、石田さん、という気分。

でも、けっこうあちこち齟齬があって夜中に作り直したりもした。

ニヤリと笑って「甘いな」と言われた気がする。

精進いたします。

ToDoあれこれ

●open_bib -1になっちゃうのが何故か調べて解決するのは時間がかかりそうなので後回し。改行で区切ったISBNの一括入力を。

●近刊検索デルタ 先週出来なかった静的ページの仕組み変更と表紙画像のランダム表示、ランキングまでなんとかしたい。

重版出来ですYO! RSSからのインポート自動化、登録受付フォーム。

●CcodeRR 広告載せよう。

●妻が作って販売している楽譜販売サイト構築 年末まで。

●趣味の○○ 1月まで。

●持ち帰り仕事 本当はこれが最優先。

やりたいことが多過ぎて時間が足りない……

2017-09-17

ジャンル・形態・読者対象、出版社別ではない「分類」の可能性

トーハン/書店店頭にWEBマンガアプリ棚を新設|流通ニュース

書店店頭にwebマンガアプリ棚を新設する施策がスタート

要は、「Web発の漫画の単行本が増えたが、(読者が)店頭で探しにくいので、まとめて展開することにした」というお話。

「Webは無料でマネタイズは紙の本の出版」というのは以前からよくある手法で珍しくもない。懐かしい『電車男』とかもそうだし、数多く刊行されたブログ本も、ケータイ小説もその流れ。最近でも{Twitter発」とか。ボーデジタルのコンテンツのマネタイズとして「(紙の本の)出版」は王道とも言える。

今回のこれはコミックだが、上述のブログ本ケータイ小説とは少し事情が異なるように思う。「雑誌に連載して単行本化」が、「Webに連載して単行本化」に置き換わりそうな勢いだ。すぐにではないかもしれないが。

そうした「電子書籍」的な話は得意な人がいると思うのでそれとして。



自分は、「出版社別ではないくくり方」の可能性が気になる。

漫画に限らず書店の商品管理において「出版社別」というのは案外便利な方法だ。店頭での陳列はもちろんだが、在庫のチェックも売れ筋の補充も(返品も)、出版社単位でのオペレーションは割りと効率的だ。コミックや文庫・新書の場合はさらに「レーベル」という単位もある。が、あくまで出版社別の下位に位置する分類だ。出版社別の上位に位置する分類は「コミック」「雑誌」「文庫」「新書」「児童書」「学参」「文芸」「実用書」「専門書」といった、出版物の形態と大まかな対象を表すものになる。

専門書や児童書などでは出版社別ではなく、内容や読者対象によって陳列している店舗も少なくない。が、例えば「叢書」や「シリーズ」など、出版社別に陳列したほうがわかりやすいものはそうしているはず。そして、在庫チェック・補充・返品など商品管理は「出版社別」に行うことになる(常備があるとその傾向は強まる)。

コミックや文庫・新書のように既刊の点数も売上も大きく、かつ新刊の刊行点数が多いジャンルでは、「出版社別」での陳列と管理が行われている。一覧表での在庫チェックは出版社毎でなければ難しい。補充も同様。並べる順番も、一覧表での管理を前提に、出版社による分類(多くの場合は出版社が付けたコード)で並べることが多い。

その中でも特にコミックは、出版社だけでなく、雑誌=掲載誌との関連性が重要になっている。連載で読んで単行本を買うという読者は少なくない。少年・少女漫画の場合は、単行本しか買わない読者であっても「この漫画はそもそもどの雑誌に連載されているのか」は案外知られている(はず)。つまり、雑誌と連載漫画が紐付いている(但し、最近の、映画やアニメ化をきっかけに単行本が売れる漫画の場合はそもそも連載で読んでいないうえに雑誌ではなく映画やアニメと紐付いているので雑誌の名前はあまり出てこないことも多い)。

雑誌と連載漫画が結びついているというのはコミックの販売促進において非常に重要だ。書店店頭の限られた棚を奪い合う際に単体の漫画ではなく「雑誌連載」で束になれる強み。コミック雑誌の連載漫画の単行本はそこから大きなメリットを得ていた。

今回の「Web漫画の単行本化をまとめて展開」は、出版社の垣根を越えているだけでなく、「雑誌と連載漫画」に対応する「Webと連載漫画」という関係性を書店店頭に、そして多分、取次の物流に、持ち込んだことが大きい。(コミックにおいて)出版社別は雑誌別だった。それが崩れる。いや、「置き換わる」可能性が生まれている。



これはコミックだけの話ではない。

「出版社別ではない分類の可能性」は、何度も繰り返し言及されてきただけでなく、実際に試みられてきた。が、店舗でのそれが大きな流れになりきらない最大の理由は「商品管理のオペレーション」だろう。それだけでなく、例えば判型や装丁バラバラで、むしろ探しにくい場合もあるのも理由かもしれない。

ネット書店が出てきて大きく変わったのは実はそこだ。ネット上では判型や装幀の違いは余り大きな問題にならない。また、データベース上のデータは「出版社別」ではない分類や並び替えが可能だ。ネット書店ではオペレーションの問題は無い。バックヤードと「Web画面」で商品の並び順が一致している必要はないからだ。

著者別で並び替える(抽出する)も、ジャンルや内容別で分類するのも、ネット書店では可能だ(そのための分類としてCコードがイマイチなので現物を見てひとつひとつ分類する必要があるという巨大な手間はあるものの)。

しかし、リアル書店においては、相変わらず「出版社別」のくくりから脱するのは難しいように思える。

のだが、ここへ来て最近増えてきた「セレクト型書店」では、店舗の規模が小規模であることを逆手に「アイテムを絞り込む」有効性が見直されている。セレクト型書店においてアイテムの絞り込みを出版社別に行うのはナンセンスだ(特に、コミック・文庫・新書・専門書を扱わないのであれば)。必然的に、そこでは「出版社別」以外の分類が不可欠になる。というか、その書店そのものが、ある種のカテゴリであり、並んでいる本は「その書店のカラー」という分類なのだろう。小規模書店のカラーとはそもそもそういうものなのかもしれない。

そうした、「セレクト型書店」における「カラー」も確かに分類のひとつだが、「雑誌と連載漫画」のような「マスセールスのための分類」とは少し違う。

今回の「Web漫画からの単行本をまとめて展開」は、マスセールスでの「出版社別(雑誌別)とは違う分類」の提案になる。取次(トーハン)もそれに乗るということだ。今後、他のジャンルなどで似たような展開が行われるかどうかが気になる。

ジャンル・形態・読者対象、出版社別ではない「分類」の可能性

トーハン/書店店頭にWEBマンガアプリ棚を新設|流通ニュース

書店店頭にwebマンガアプリ棚を新設する施策がスタート

要は、「Web発の漫画の単行本が増えたが、(読者が)店頭で探しにくいので、まとめて展開することにした」というお話。

「Webは無料でマネタイズは紙の本の出版」というのは以前からよくある手法で珍しくもない。懐かしい『電車男』とかもそうだし、数多く刊行されたブログ本も、ケータイ小説もその流れ。最近でも{Twitter発」とか。ボーデジタルのコンテンツのマネタイズとして「(紙の本の)出版」は王道とも言える。

今回のこれはコミックだが、上述のブログ本ケータイ小説とは少し事情が異なるように思う。「雑誌に連載して単行本化」が、「Webに連載して単行本化」に置き換わりそうな勢いだ。すぐにではないかもしれないが。

そうした「電子書籍」的な話は得意な人がいると思うのでそれとして。



自分は、「出版社別ではないくくり方」の可能性が気になる。

漫画に限らず書店の商品管理において「出版社別」というのは案外便利な方法だ。店頭での陳列はもちろんだが、在庫のチェックも売れ筋の補充も(返品も)、出版社単位でのオペレーションは割りと効率的だ。コミックや文庫・新書の場合はさらに「レーベル」という単位もある。が、あくまで出版社別の下位に位置する分類だ。出版社別の上位に位置する分類は「コミック」「雑誌」「文庫」「新書」「児童書」「学参」「文芸」「実用書」「専門書」といった、出版物の形態と大まかな対象を表すものになる。

専門書や児童書などでは出版社別ではなく、内容や読者対象によって陳列している店舗も少なくない。が、例えば「叢書」や「シリーズ」など、出版社別に陳列したほうがわかりやすいものはそうしているはず。そして、在庫チェック・補充・返品など商品管理は「出版社別」に行うことになる(常備があるとその傾向は強まる)。

コミックや文庫・新書のように既刊の点数も売上も大きく、かつ新刊の刊行点数が多いジャンルでは、「出版社別」での陳列と管理が行われている。一覧表での在庫チェックは出版社毎でなければ難しい。補充も同様。並べる順番も、一覧表での管理を前提に、出版社による分類(多くの場合は出版社が付けたコード)で並べることが多い。

その中でも特にコミックは、出版社だけでなく、雑誌=掲載誌との関連性が重要になっている。連載で読んで単行本を買うという読者は少なくない。少年・少女漫画の場合は、単行本しか買わない読者であっても「この漫画はそもそもどの雑誌に連載されているのか」は案外知られている(はず)。つまり、雑誌と連載漫画が紐付いている(但し、最近の、映画やアニメ化をきっかけに単行本が売れる漫画の場合はそもそも連載で読んでいないうえに雑誌ではなく映画やアニメと紐付いているので雑誌の名前はあまり出てこないことも多い)。

雑誌と連載漫画が結びついているというのはコミックの販売促進において非常に重要だ。書店店頭の限られた棚を奪い合う際に単体の漫画ではなく「雑誌連載」で束になれる強み。コミック雑誌の連載漫画の単行本はそこから大きなメリットを得ていた。

今回の「Web漫画の単行本化をまとめて展開」は、出版社の垣根を越えているだけでなく、「雑誌と連載漫画」に対応する「Webと連載漫画」という関係性を書店店頭に、そして多分、取次の物流に、持ち込んだことが大きい。(コミックにおいて)出版社別は雑誌別だった。それが崩れる。いや、「置き換わる」可能性が生まれている。



これはコミックだけの話ではない。

「出版社別ではない分類の可能性」は、何度も繰り返し言及されてきただけでなく、実際に試みられてきた。が、店舗でのそれが大きな流れになりきらない最大の理由は「商品管理のオペレーション」だろう。それだけでなく、例えば判型や装丁バラバラで、むしろ探しにくい場合もあるのも理由かもしれない。

ネット書店が出てきて大きく変わったのは実はそこだ。ネット上では判型や装幀の違いは余り大きな問題にならない。また、データベース上のデータは「出版社別」ではない分類や並び替えが可能だ。ネット書店ではオペレーションの問題は無い。バックヤードと「Web画面」で商品の並び順が一致している必要はないからだ。

著者別で並び替える(抽出する)も、ジャンルや内容別で分類するのも、ネット書店では可能だ(そのための分類としてCコードがイマイチなので現物を見てひとつひとつ分類する必要があるという巨大な手間はあるものの)。

しかし、リアル書店においては、相変わらず「出版社別」のくくりから脱するのは難しいように思える。

のだが、ここへ来て最近増えてきた「セレクト型書店」では、店舗の規模が小規模であることを逆手に「アイテムを絞り込む」有効性が見直されている。セレクト型書店においてアイテムの絞り込みを出版社別に行うのはナンセンスだ(特に、コミック・文庫・新書・専門書を扱わないのであれば)。必然的に、そこでは「出版社別」以外の分類が不可欠になる。というか、その書店そのものが、ある種のカテゴリであり、並んでいる本は「その書店のカラー」という分類なのだろう。小規模書店のカラーとはそもそもそういうものなのかもしれない。

そうした、「セレクト型書店」における「カラー」も確かに分類のひとつだが、「雑誌と連載漫画」のような「マスセールスのための分類」とは少し違う。

今回の「Web漫画からの単行本をまとめて展開」は、マスセールスでの「出版社別(雑誌別)とは違う分類」の提案になる。取次(トーハン)もそれに乗るということだ。今後、他のジャンルなどで似たような展開が行われるかどうかが気になる。

2017-09-12

近刊検索デルタとCcodeRR

8月末になってやるやる言っていた「近刊検索デルタ」、なんとか9月1日に公開。ボロボロだがエイヤッと公開してしまったほうがいいに決まっている。

もう初日からあちこちボロボロで直しまくり。openBDのAPIからのインポート(cronで定時に実行)ですら直す。問題が無ければ、検索・ランキング・CSVダウンロードに着手したいところだが、そうは問屋がおろさない。なんとかかんとか動いてる状態で維持。なかなか厳しい。

最初にはまったのが「日付」問題。キレイにYYYYMMDDで入ってるデータだけじゃないのは分かってたけど、予想以上に問題満載。かなり苦労しつつも強引な手段でなんとか解決、出来たと思う。次にはまったのが著者名なんだけど、これはもうすぐにお手上げ。分類も苦戦中。オリジナル分類そのものはうまく動いているけれど、本当にそれで良いのかはまた別問題。ライトノベルズも、サブタイトルでもレーベルでもシリーズでも分類できないものは無理。

大きくハマったのが「刊行中止」の扱い。openBDからは消えてしまうらしい。こちらの都合なんだけど、バルクインサートの過程でISBNが引き継げない状態があるので、結局「無いことがわからない」という状態に。かなり困った。複雑な仕組みで解決できるのはわかったけれど、それだとインポートの速度が遅くなる。どうしたものか。

サクラインターネットのcronは「プログラムの実行が60秒以内」という制限がある。そこに収めるのに四苦八苦。かなりいい線いってたけど、微妙に60秒を超える回数が増えてきた。ので、分割。「あんまり頻繁にcron動かすな」という制限もあるようなので恐る恐る動かしている。お金があればAWSとか使って解決するのだろうか。そのあたり、よくわからない。

稼働から一週間、9月9日にCcodeRR公開。以前動かしていたCcodeRの発展。案外良い(自画自賛)。

9月11日、検索機能運用開始。重み付けは次の課題にした。これも案外よいではないか(自画自賛)。

2001年9月11日は眠れずにずっとCNNを見ていた。二機目の衝突はほぼリアルタイムで見た。何か恐ろしいことが起こっていることに怯えながらも、どこか遠くの出来事に思えた夜。

2011年震災を経て、9月11日、近刊検索デルタの前身である「近刊検索β」の公開日。