初の電子書籍アプリ、21日にバイナリをアップロードして、ステータスが Waiting For Review になったんだけど、まだ何の音沙汰もない、iTunes Connect。

googleで検索してみると、初めての申請で４日程度。ところがすでに一週間。Mountain Lionのリリースなどがあって、レスポンスが悪くなってるのかもしれない。

SakuttoBookにOSのアップデートしても大丈夫？と問い合わせたところ、そっちはまあ大丈夫だろうけど、各種アップデータが揃うまで待つのが得策常套手段だと言う話。それとは別に、13日にアップデートを申請したアプリが26日にやっと審査通過で今かなり時間がかかっている、という情報が。

初のアプリよりアップデートの方が早いという話もあるので、今回申請している初アプリは、下手したら来月第２週ぐらいまで待たされるかな。せめて、来週中、と思ってたんだけど。app storeがどんなものか実際を知りたいので気が急く。

無事公開となったら、広報・集客にappbankなどのランキングサイト、レビューサイトに投稿する必要がありそうだ。ひと知れず公開しても、膨大な量のアプリに埋もれて終了してしまう。最初の時点で収録されてるのは小説一本なので、少し溜まったら、その手のサイトを探して投稿、ニュースリリース（？）をやってみよう。

運用面的にも、アプリ内課金の売り上げ報告はどうなってるのか、とか、アップルから日本の銀行への振込手数料がいろいろかかって5500円もさっぴかれてる、なんて記事もあるし。まだまだ実態把握しなきゃいけないことが多い。

ので、とっとと審査通して、公開してくれー！

[08/03 15:07:45]

8月3日にIn Reviewに変わって、初めての電子書籍アプリが、初めての reject を食らう→「app storeからリジェクト(却下）された」

初めての iPhone アプリは、果たしていつ公開できるんだろうか！？

app storeで小説同人誌の電子書籍アプリを、個人でも販売してみようと、とりあえず、アプリ＝PDFは作った。著者校正を済ませて、実機にインストールして、そちらでの校正も終了。あとは、登録してテストして、公開して、となる。

SakuttoBookに問い合わせてるんだけど、連休を挟んだので、レスポンスがまだない。購入前の問い合わせでは、休みでも即日返答がきたので、もしかすると釣った魚にエサは不要ということだったらガッカリだけど。

iTunes Connectへの登録は手順と手間の固まりで、サイトのマニュアルを読んでも、わかりにくい・面倒くさいのひとこと。これは代行業が成り立つわけだ。でも、言ってしまえば、手順と手間、なので、地道に地味にひとつずつやっていけばイケるはず。英語だらけのページでそれも困ったちゃんなんだけど、無視して日本語で問い合わせたら、日本語で返答がきて助かった。

いま、使ってる電子書籍アプリは、アプリ内にいくつもコンテンツを並べられる、アプリ内課金というやつ。もし原稿をお持ちで、app storeで販売してみたい、と思われたら、ぜひメールなど連絡ください。一緒に売りませんか？

ひとり細々と販売しても、誰も気づいてくれないので、何人もの作品を集めて、告知・広報した方が効率的かなぁと思います。よろしくお願いします！

今週の、打ち合わせというのか飲み会で、twitterやってる？facebookは？mixi？という話題も。

昔女の子だった方々に意外に不評だったのがmixi、それもmixiの売りだったはずの「あしあと機能」これがあるからmixiは伸びたと思ったんだけどなあ（あと当然、アダルトコミュ）元カレのところを踏んでしまった、とか、あまり関わりたくないのについ踏んで、とか。踏み返されたりメッセージが飛んできたりするのが嫌だ、と。その点、facebookはいい、んだそうだ。毎日facebookにン時間は費やしてるとのこと。

もうすっかりおっさんの半分オタクな男連中は、facebook の作り笑い的な無理矢理のリア充演技が耐えられない、と。普段牛丼食ってるくせに、たまにオサッレなカフェで食ったイタ飯（大きな皿の中央に、皿の直径の１／５程度しか中身が入っていない料理）の写真をのせて得意顔、とか。たしかにその通りで、わたしも、facebookは、なんかうさんくさいウソ臭い、という印象。

わたしはtwitterが今のところ一番気楽でいいんだけど、女子たちは誰が見てるかわからないから怖いという。あれ？キミら、さっきmixiのあしあとが嫌だとかいってなかったっけか。

自分の場合。

まずtwitterをチェック。という生活習慣。自分好みの2ch、みたいなもんだし

Facebook は、いまだに何がいいんだかよくわからない。

mixiは、終わったと思ってたんだけど、意外にまだ頑張ってる。ので、実際の顔見知り以外のマイミクを外して、公開範囲をを絞って使うことにした。

最近、LINEがスゲー、次はLINEだ、もしかするとfacebookを食うのはこれではないか、とWEB界隈が騒がしい。

よくわからないまま、それなら試しにインストールしてみた。

今週飲んだ元同僚や、今の知り合いなど、身近にすでに使ってるひとがいるのに驚いた、かも。あちこちに「購入ボタン」がある印象なので、間違えて購入しないように気をつけながら使ってみる。

[11/20 08:14:01] 追記。kindleやiTunesで展開中。これはこれで、なかなか面白いものです。

・アマゾン kindleストアに並べた電子書籍のリスト

手前味噌だけど、ホラーや青春もの、癒しの物語などオススメできます。短編だと100円からあるので、気楽に読んでみてやってください。

こちらはiPhone電子書籍アプリ「小説同人誌Select」

https://itunes.apple.com/jp/app/id546230414?mt=8

小説同人誌Selectというこのアプリは無料で、中に有料の小説が収録されてます。無料サンプルもあるので、まずは立ち読み感覚でダウンロードして、気に入ったらその作品を購入してもらえるととてもうれしいです。

[更新]2026-02-02 08:45:07

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

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

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*?))?" (.*?) .*? "(.*?)" "(.*?)"/；

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で画面遷移なく直観的に使えるようにしたり、機能豊富でやろうとしてることは大賛成だし、かなり面白い。でも、ここも速度が出てない。一度公開してしまってる機能を引っ込めるのはちょっとアレだけど、整理して速度を見直すか、速度が出てなくて待たされてる感を少しでも軽減できるような効果を検討するとか、お願いしたいところ。

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

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