amazonのトップページに、kindle近日発売！というバナーが。いよいよkindle＝アマゾンの電子書籍端末が発売で、それってイコール、日本語の書籍が電子書籍となってamazonで販売、kindleで読むことができるようになる。

amazonと各版元の話し合いに決着がついて、伊坂幸太郎とか宮部みゆきとかベストセラー作家の作品がkindleで読めることになった、のかな。

たまたま昨日、app storeでの電子書籍の企画の話をしたところ。シンクロニシティってやつなのか、電子書籍の機運が盛り上がってきたということなのか。

kindleもapp storeも、電子書籍は、個人がアマゾンやアップルストアといった販売網販売力を手に入れることになる。そこから先、知名度やブランディングなどの販売努力はまた別の話だけど、とりあえず土俵は用意された、ということ。

電子書籍は、紙代印刷代運送費などがないので、作って並べるだけなら、コストもかからない。ハードルがぐんと下がる。

なら早いもの勝ちだろ、作って並べてしまえ！と2010年にkindleのセルフパブリッシングで作ってアマゾンで並べようとしたときの記事

「寒い週末は上野公園とkindle遊び」http://t2aki.doncha.net/?id=1269767129

この時は日本語はまだダメだよ、ちょっと待ってろ、と却下されたけど、kindleが日本で発売となると、

https://kdp.amazon.com/self-publishing/signin

↑セルフパブリッシングも対応してくれるに違いない。期待大。情報収集しような、おれ。

ついでに、app storeにも個人で電子書籍をなんとかできないかな、と思って、iOS Dev Centerの登録もしてみた（既存のapple idの日本語部分（名前とか住所とか）が文字化けして dev center で登録できなかったので、apple idは新規に取得しなおした）

モリサワのmcbookなどは法人でしか契約できないし、それなりのお値段。調べてみると

SakuttoBook

というのがあって、本文にPDFを用意すれば、iOS用の電子書籍アプリになる、らしい。電子書籍アプリの器があって、中身を入れ替え差し替えする、という理解であってるかな。

リジェクトのところ、アプリ内課金のあたりがよくわかってないのでまだ調べる必要はある。とはいえ、調べさえすれば入り込めそうな気がする。がんばる。

ウチのmac miniはまだ寅さんなので、やるとなったら、雪豹か獅子にしないといけない。

電子書籍と紙の製本された書籍は別ジャンル別モノ。

紙の本が好きだけど、個人でも出版できる・発信できる手軽さは魅力。すげー魅力。なんだよなぁ。

今後のことを考えても、いろんなチャンネルを確保しておかないとなあ。

[10/30 13:11:54]

追記。2012年10月25日にKindleストアオープン！

さっそくその日のうちにKDPで電子書籍を出版した。

→「kindle KDPで電子書籍出版」http://t2aki.doncha.net/?id=1351350303

ここんとこ種まきばかりの、フリーランス＝無職状態だったんだけど、そのうちのひとつ、app storeで電子書籍の制作販売にいっちょかみできそうな。ていうことで企画持ち込み。

・400字詰め原稿用紙70～80枚（3万字程度）

・ライトノベルでちょいエロ／女がほげほげする実話エッチ系

・印税や、ミニマムギャランティ（見込み印税＝初刷り部数印税）などは交渉中

ぶっちゃけ。電子書籍は紙と、いろんなところでケタがひとつ違う。今app storeに並んでる電子書籍を見ると、ほぼ85円。紙の本の10分の１ですな。ただ、売れてる本などは4万部ぐらい出ている。いま時、紙の本だと1万部刷って実売6割だといい方じゃないか。

ラインナップを作って企画を持ち込みたいんで、絶賛原稿募集中、作家・ライター・イラストレーター募集中（企画や交渉などを一緒にやろうという編集のかたも）

メールか、電話をください。もう少し具体的にお話できます。制作販売元はすでにapp storeで実績のあるところなので、販売力は見込めると思います。

よろしくお願いします。

少し前まで仕事で毎日アクセス解析をしていた。

何のためにアクセス解析なんてのをするのかというと、ユーザーの興味はどこにあるのか、ユーザーをうまく誘導できているか、ユーザーが困っているのはどこか、を調べて、地道に地味にサイトを改修、リピータを増やしてひとの集まるサイトにするため。

apacheの生ログが原典。

１

apacheのアクセスログを見ればスグにわかる。

・どのページに着地したのか。

・どこから来ているのか。

・ブラウザはなにを使っているのか。

２

apacheのアクセスログをもとに加工・小細工が必要。

・何ページ見ているのか。

・滞在時間。

・離脱したページ。

３

サイトの構成と合わせて見るべきこと。

・ページ遷移の関連性

・ページの最後まで見てるかどうか。

アクセスログ解析で把握するのは、大雑把にこの３つ。

１と２は単純に集計すれば出てくる。

概略を知るには、google analyticsなどアクセス解析サービスを使えばいい。ただ、この手のサービスは、サイト規模が大きくなると＝アクセス数が多いと、数字を足切りされたり丸め込まれたりすることがあるので、注意が必要。

３はページのURLを分類したりそれをもとに集計したり。

サイトの意図を強く反映した解析が必要なもので、市販のアプリやWEBサービスでは痒いところに手が届かない。サイト構成に現物合わせでスクリプトなりを作ることになる。さらに、特集企画などのページを作ってそこから購入に繋げる、なんてことはしょっちゅうあるので、その場その時に合わせて作らなきゃいけない。

てなことをやるにあたって、問題なのが、クローラとかロボットとか言われるアクセス。

googleやbingなどの検索エンジンがページをインデックスするためにアクセスしてくるんだけど、人間じゃないアクセスは、アクセス解析の邪魔。

通常、クローラはユーザーエージェントに bot や crawlerなどが含まれるので、Useragentを見て分別、クローラのアクセスを集計から外すことができる。

ところが、msnbotというマイクロソフト、bingのクローラは、ユーザーエージェントにクローラであることを示す単語が含まれない。ブラウザを使ってアクセスしている人間と区別がつかない。ipアドレスからホストをひけば、msnbot という文字がホスト名入ってるのでそこで初めてクローラだと判断できる。けど、ipアドレスからホスト名を取得する gethostbyaddr は、処理が重い場合がある。ウチみたいな辺境ならともかく、巨大なECサイトなど、アクセスログが膨大な場合、処理するのに時間がかかるのは困る。

たとえば一日あたり。ユニークユーザーが6000とかページビューが50万とかあるうち、雑音として入り込んでもしょうがないよね、という範囲ならいいけど。クローラ・ロボットはいろんな名前、カタチでやってくる。毎日アクセスログをチェックして新たなクローラがすり抜けて混じってないか見なきゃいけない。消耗戦。

ちなみに、apacheのログ解析の定番正規表現。これが最速らしい。

my $cols = [’host’，’time’，’method’，’req’，’http’，’res’，’ref’，’agent’]；
my %h；
@h{ @{$cols} } = 
$line =~ m/^(.*?) .*? .*? \[(.*?)\] "(\S+?)(?: +(.*?) +(\S*?))?" (.*?) .*? "(.*?)" "(.*?)"/；

いや、甲斐性無しは自分のことなんだけど、テキトーにカテゴライズしないと寂しいので私立文系を使わせてもらった。すまん。

このブログの amazonコンテナをajax取得にしたこともあって、思いつくところに埋め込んでみた。1998年からなので、ほぼ14年分で2400記事ほどをざっと眺めたところ。

技術的なネタはその時々、1年も経つと古くなっていてamazonを見ても該当するようなものはなくなっている。でも小説、結城昌治や星新一、司馬遼太郎なんてのは、まるで古びない。タイトルを見るだけでいちいち感動が蘇り、読んだ当時のことまで思い出す。映画も同じ。

今回ブログをいじっていて、もっとたくさん小説を読まないといけないし、もっとたくさん映画を観なきゃいけないなあ、と改めて思った。もう残りを勘定しなきゃいけない歳だ。

使い古された言葉だけど、フィクションは疑似体験、世界を経験することになる。フィクションを摂取したところで生活が潤うことはないけど、人生は豊かになるのだ。（先人の言葉に、衣食足りて礼節を知る、というのがあるけど、なかったことにしておく）

甲斐性無しでもそれなりにやっていける源泉がここにある。

コンピュータが使われるようになってインターネッツに覆われて、いろんなものが身もふたもなくなった。性格や病気はヒトゲノムとか脳内物質で解明できる。ボイジャーは太陽系を出て外宇宙を探査する。今までわからなかったものに、名前がつくラベルがつく。語りえざるもの、なんて悠長なことを言ってるヒマもない。誰もいない樹海の中、なんてところはなくなっていく。

恩田陸の「夢違」じゃないけど、今まで見えなかったものが見えるようになり、聞こえなかったものが聞こえるようになり、名前がなかったものに名前がつく。

それでも、フィクションは作られていくんだから、アミノ酸なみに、人間が生きていくために必須の成分。てことで、やっぱりたくさん小説を読まなきゃいけないんだな。

--------

「私、例えばね、日本人みんなが幽霊という存在に心から納得してその存在を信じたら、きっと幽霊も可視化するようになるんじゃないかと思うんですよ」

「ほう」

鎌田が感心したような声を出した。

「夢札の場合、見えないものが見えるようになってしまった。夢って存在するんだ、みんなの意識に共通点があるんだと納得して、それが常識になってしまうと、それ以外の見えないものも存在して不思議ではないと考えるようになるんじゃないでしょうか」

googleさまの記事によるとページ表示は最悪でも２秒以内、理想は１秒以内。amazonに関する記事だと表示が0.1秒遅くなると売上が1%落ちるし、googleの記事だと表示が0.5秒遅くなると検索数が20%落ちる。らしい。

かたやECサイトだし、もう一方は検索で広告商売なので、こうしたデータからすると、表示速度は売上直結死活問題。コミュニティサイトやブログ、ニュース系サイトなどはそこまでシビアじゃないと思うけど、待たされるのはストレス、に違いはない。

情報設計とか、ユーザビリティとか、機能面とか、デザインとか、いろいろ言われて、サイト作りに盛られていく。この過程で、組織内の大きな声の人間や、正論クンの言うとおりになってしまって、表示速度のことに気づくのが、ほぼサイトが完成する公開直前のテストだったりして仰け反ることになる。

そりゃ、そんな機能あったらいいよね。キャッチーで人目をひくよ、このデザイン。動線確保のためにショートカットリンクは常に表示だよ、やっぱり。

なんてことやってると、表示速度は、確実にコンマ何秒かずつでも遅くなっていく。サーバーの設定で頑張って、プログラムで頑張ってるのに、わざわざ遅くなる要因をつけ足してることに変わりない。

どんな魅力的なサイトでも使ってもらってなんぼ。アクセスしてページが開くのに、ひと呼吸もふた呼吸も待たされたんじゃ、面倒で離脱する。リピータになってくれてるのに、いつも使ってるうちにイライラがたまって、そのうちアクセスしなくなる。

てことで、この雑記帖みたいな辺境も、twitterやamazonからデータを取得するコンテナが増えてくると、その分表示速度が落ちてくる。なので、ごそごそいじって、ajaxでの取得に切り替えた。ページ全体の表示とはまた別扱いなのが、ajaxのいいところ。今まで4秒ぐらいかかってた表示がぎりぎり2秒台まで短縮できた、かな（前職のダウンロード配信サイトでは、ストップウォッチを片手に表示速度をチェックして、速度が出ないので公開延期になったりもした）

てな細工を先日やったこともあって、表示速度について、電子書籍検索サイト「電子書籍を探すなら hon.jp」のAPIをちょっといじってみて気になった。ここは、電子書籍を総ざらいで検索できるのでかなり便利なサイト。perlでごそごそいじってウチに組み込もうとしたところ、速度が出ない。RESTのURIをそのままブラウザに入れても、レスポンスがかなり遅い。6秒程度かかるケースもある。

↓たとえばこんな検索

キーワード：山田風太郎・ジャンル：国内文学・ハードウエア：iphone

ユーザーページも、本を起点にユーザーを結びつけたり、ajaxで画面遷移なく直観的に使えるようにしたり、機能豊富でやろうとしてることは大賛成だし、かなり面白い。でも、ここも速度が出てない。一度公開してしまってる機能を引っ込めるのはちょっとアレだけど、整理して速度を見直すか、速度が出てなくて待たされてる感を少しでも軽減できるような効果を検討するとか、お願いしたいところ。

文句ばかりつけたけど、電子書籍検索に関して、このサイトは本当にオススメ！

あと、やっぱりなんちゅーか。電子書籍に統一のコードがないのが（？）困る。