地下鉄は使い物にならない

正直なところ、地下鉄を利用している限り、現状ホームは入るけど、ホーム外は入らないのは当然として、一度切れてから再度エリアに入った際の、再接続に偉い時間がかかるのが難点。
この再接続を待っている間に、ひどいときには電車が発車してしまい、当然何も通信できずに次の駅まで待つことがありました。
もしスマートフォンを利用して、高速通信用にWiFiを使用しているのであれば、WiFiをOFFにして、3G通信のままにしていた方が、実はストレスが少ない状態でした。

WiMAXはホームでも現状ダメダメです。

気がついたらサスペンドモード

電池の消費を抑えるために、一定時間通信が発生しないと、ルーター側でサスペンドモードに切り替わるのですが、ちょっとアクセスできない間に切り替わってしまい、さあ使うぞ！と思ったらサスペンドモードです。1分お待ちください。という事がちょくちょくあります。
まあ、これは現状電池の持ちを考えると、厳しいところがあるのですが、すぐ使えないっていうストレスがたまります。

現在起動が徐々に高速化してきたので、だいぶましかなという感じです。

使う人が多すぎると、チャンネルが確保できない

これはIT系の大規模な展示会などでしか起こりませんが、有る特定のエリアで大量の人が使用しているため、WiFiの空きチャンネルが無くなって、まともに繋がらなくなることがありました。
このような場合には、正直主催者側が、無料で専用のWiFiのアクセスポイントを用意して、アクセスコントロールするしか無いとは思うのですが、現状だめだめな状態だと思います。

ビックサイトと幕張メッセ限定かなと思いますが、電車内でのアクセスポイントの増加数を見る限り、近いうちに身近な場所でも問題化すると思います。

本気で使うと電池が全然持たない

だいぶ改善しましたが、本気でヘビーに使ってしまうと、まだまだ電池の持ちが厳しいかもしれません。
朝から帰りまで普通に使うとなると、 フル充電+外部電源が必要な状態です。もっともこれは、スマートフォンにも言える状態ですが。

社内で遠慮無く充電できる環境は、かなり恵まれているんですけどね。

結論

正直高速通信は魅力だけど、邪魔ってのが、自分自身の結論です。
電池や帯域の問題がある程度めどがつけば、スマートフォンのテザリングに、ほとんどが吸収されると思っています。
そして、スマートフォンが無いけど、屋外でデータ通信が必要な人向けの商品になっていくと思います。

MP3プレイヤーが出るさらに前、携帯電話にWalkmanくっつければ、すごくいいのにと言って、 全く相手にされなかったのを思い出しつつつぶやいてみましたｗ

$ ab -n 100 -c 100 http://www.brolog.com/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.brolog.com (be patient)…..done

Server Software: Apache
Server Hostname: www.brolog.com
Server Port: 80

Document Path: /
Document Length: 60832 bytes

Concurrency Level: 100
Time taken for tests: 2.725 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 6111000 bytes
HTML transferred: 6083200 bytes
Requests per second: 36.70 [#/sec] (mean)
Time per request: 2724.592 [ms] (mean)
Time per request: 27.246 [ms] (mean, across all concurrent requests)
Transfer rate: 2190.34 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 261 1218 636.6 1552 2308
Processing: 0 696 662.2 619 2289
Waiting: 0 523 544.3 492 2047
Total: 660 1914 612.4 1993 2723

Percentage of the requests served within a certain time (ms)
50% 1993
66% 2350
75% 2450
80% 2472
90% 2510
95% 2555
98% 2693
99% 2723
100% 2723 (longest request)

圧倒的な改善。まあ、予想通りなんだけど、DB Cache Reoadedとか効いているのかなあ？とちょっと思ったり。
というか、ここまで速度差が出ると、標準の機能としてWordPressに出力キャッシュを搭載する必要が来ているんじゃ？と思う。標準で提供できるレベルになれば、いくつかのプラグインとの不整合とかも、何とか調整できそうな気もするしねえ。

とりあえず、ある程度レスポンスよく出来たので、このプラグイン類のセットで、仕事用のサーバーを設定してみようかなと。まあ、どう考えても、あまりにも一般的なセットで落ち着いた気もしないでもない。

$ ab -c 100 -n 100 http://www.brolog.com/
This is ApacheBench, Version 2.0.41-dev <$Revision: 1.141 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/

Benchmarking www.brolog.com (be patient)…..done
Server Software: Apache
Server Hostname: www.brolog.com
Server Port: 80

Document Path: /
Document Length: 60346 bytes

Concurrency Level: 100
Time taken for tests: 33.678507 seconds
Complete requests: 100
Failed requests: 91
(Connect: 0, Length: 91, Exceptions: 0)
Write errors: 0
Non-2xx responses: 2
Total transferred: 6276041 bytes
HTML transferred: 6253317 bytes
Requests per second: 2.97 [#/sec] (mean)
Time per request: 33678.509 [ms] (mean)
Time per request: 336.785 [ms] (mean, across all concurrent requests)
Transfer rate: 181.96 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 9 14 2.7 14 19
Processing: 3126 16295 7988.2 16859 31081
Waiting: 2443 15150 7881.2 15455 30474
Total: 3136 16310 7990.2 16875 31100

Percentage of the requests served within a certain time (ms)
50% 16875
66% 20712
75% 23592
80% 24305
90% 27182
95% 29011
98% 29684
99% 31100
100% 31100 (longest request)

　 　　_, ._
　 （　ﾟ Дﾟ）
　　( つ旦O
　　と＿)_) 

　 　　_, ._
　 （　ﾟ Дﾟ） 　　ｶﾞｼｬ
　　( つ　O. __
　　と＿)_) （__(）､;.o：。
　　　　　　　　　　ﾟ*･:.｡

・・・一応、静的ファイルでも・・・

$ ab -c 100 -n 100 http://www.brolog.com/sitemap.xml
This is ApacheBench, Version 2.0.41-dev <$Revision: 1.141 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/

Benchmarking www.brolog.com (be patient)…..done

Server Software: Apache
Server Hostname: www.brolog.com
Server Port: 80

Document Path: /sitemap.xml
Document Length: 55375 bytes

Concurrency Level: 100
Time taken for tests: 0.614033 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 5976628 bytes
HTML transferred: 5948308 bytes
Requests per second: 162.86 [#/sec] (mean)
Time per request: 614.033 [ms] (mean)
Time per request: 6.140 [ms] (mean, across all concurrent requests)
Transfer rate: 9504.38 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 9 10 1.3 11 15
Processing: 94 335 142.6 346 571
Waiting: 31 247 148.9 242 496
Total: 103 346 143.3 357 583

Percentage of the requests served within a certain time (ms)
50% 357
66% 420
75% 467
80% 481
90% 546
95% 570
98% 580
99% 583
100% 583 (longest request)

とりあえず普通みたいだ・・・。ということは・・・かなりPHPとWordPressへのチューニング必須だなあ・・・。それなりに高速化のプラグインは入れているんだけど、ちょっと泣けてきたって事で。

導入

http://wordpress.org/extend/plugins/db-cache-reloaded-fix/ からファイルをダウンロードし、解凍後 WordPress のプラグインディレクトリにアップ、もしくは管理画面のプラグインの項目から、DB Cache Reloaded Fixで検索してインストールして終わり。
そしてプラグインの設定画面から有効化して終わり。

すごく簡単なはずでした。が、見事にはまりました。今回はまったエラーは次のパターンでした。

Caching can’t be activated. Please chmod 755 wp-content/db-cache-reloaded-fix/cache folder

エラーの内容に wp-content/db-cache-reloaded-fix/cache のパーミッションを755にしてね～ということだったので、ディレクトリを作成、パーミッションも755にしてこれでOKだね！と作業しました。

動かない！じゃあググれ！

状況が変わりませんでした。
よくあるお約束なので、じゃあ777でどうよ？ということでパーミション変更。これなら書けるだろうということで、見ていたのですが、やっぱり駄目。
仕方が無いのでいろいろググってみると

WordPress高速化プラグインDB Cache Reloaded Fix – サツぽろ、ニッキ。 http://1day.sorezore.net/2011/09/20/13190/

キャッシュは動作していません。wp-content フォルダのパーミッションを 755 に変更してください。
とエラー出る場合は、サーバーのコントロールパネルでPHP5.1.6以上のバージョンか確認してみるとよいかも。

PHP自体は5.3系なので、関係ない。

DB Cache Reloaded導入でWordPress3.1を高速化（coreserver,xrea編） | 某氏のたわごと NEXT
http://1day.sorezore.net/2011/09/20/13190/

xreaやcoreserverではPHPがセーフモードで動作するため上記の方法では導入できません。

さくらのVPSで、セーフモードでもないので関係ない。でも、やっぱりここでもキーはパーミッションと実行状態。

他にもいろいろ見てみるけど、ほぼ全て問題なく動作している模様。
でも、そういうサーバーについては普通のレンタルサーバーっぽかったので、よけに悩む事になりました。

じゃあ、動くサーバーでどうさせようか

むだに悩んでもしょうが無かったので、実際に簡単に動作するのか、他のレンタルサーバーで動作しているWordPressにインストールして実験してみることにしました。

・・・なんの問題なく動作しやがった・・・。＠さくらのレンタルサーバー ビジネスプロ

ちょっと頭抱えたくなったのは置いておいて、WordPressもプラグインもPHPもバージョンがそろっているので、環境的にはかなり近い状態になりました。
とりあえず動いているプラグインの状況を確認してみると、

wp-content/db-cache-reloaded-fix/cache

無いんですけど？
はい？って事でもしかしてと思いました。
そしたら、 ありましたよ。

wp-content/plugin/db-cache-reloaded-fix/cache

ってのが・・・。

頭痛い・・・。

と、上記を踏まえ、以下のようにすることで、問題なく動作するようになりました。

chmod 777 wp-content/plugin/db-cache-reloaded-fix

終わり。

以下解説

WordPress上で作成したディレクトリ/ファイルの所有者 apache
FTPでアップロードした際のディレクトリ/ファイルの所有者 ftpuser

よくあるレンタルサーバーのように、上記が同じユーザーの場合には問題なく動作します。
このサーバーのように異なる場合には、WordPress上での自動インストールや、普通にFTPでアップしただけでは、プラグインのディレクトリに対してapacheが書けないからエラーになっていました。なので、apacheが書き込めるように、パーミッションの変更を行いました。
もしくは、 db-cache-reloaded-fixディレクトリの所有者をapacheに書き換えてしまう方法もありますが、これだと管理画面でのプラグインのバージョンアップが面倒になってしまうので、あんまりお勧めできないかなと。
で、今回最大の問題点だったのは・・・

出力するエラーのディレクトリ名間違っているやんけ～～～！！！

ということでした。

昨日ふと思って、これ新刊で買う気にならないよな～的な本を、ネット系の古本屋（フルイチオンラインとかブックオフオンラインとかネットオフ）でリスト化してウィッシュリスト・入荷通知設定していて気がついたのですが、共通の検索キーとして使えるデータが無いということでした。

タイトルについても、各サイトによってばらばらに登録されており、ISBNコードについても、13桁での登録だけで、10桁は持っていなかったり、ハイフンが入っていたり、入っていなかったりと、一意を認識するキーデータとしては不十分な状態になっていました。
これは新刊メインのamazonやら楽天ブックスでも同じ状態です。
これらかのことから、共通フォーマットが存在していないのでは？と思いました。

しかし、POSで管理しているような、書店の商品情報まで新刊が出るたびに、いちいち手打ちで登録しているとは思えないので、何らかの形で共通のデータベースはあると思うのですが、なぜこれがネット上のデータと一致していないのかという不思議があります。

各出版社が新刊を発表・出荷する段階で、何らかの形で情報をデータとして提供していると思うのですが、このデータはなぜ利用されていないのでしょうか？
また書店と取次の間で、特に大規模な書店の場合には、受発注が電子化されているのは自然な流れなので、何らかの共通データはあると考えます。

なので、まずはこのあたりを何とか共通化して、ぶれの無い状態で検索や管理などをさせて欲しいと思います。
そしてこのデータを共通のAPIとしてサービス化することで、次の電子書籍に向けてのユーザーである読者に対しての、利便性を提供していく基礎データにするべきだと思います。

電子書籍化した場合には、キーワードによる検索での書籍購入への行動になるため、このあたりの情報をきちんと整理する必要があると思います。
出版社側でタイトルや作者名、あらすじなどのメタ情報をきちんと整理・規格化し、配信することでユーザーが書籍を見つけやすくする事が可能になり、Blogなどで紹介する際にも、共通データベースや出版社からAPI経由で提供することで、現状Amazonだけに流れている、ネット上での購買の流れを変化させることが出来ると思います。
たとえばBlogなどで紹介された書籍を、そのままネット通販でも、電子書籍でもなく、書店で買いたいという人は、一定数居続けると思うので、そのような人には、バナーなどからワンクリックで、ウェブアプリやスマートフォンアプリなどに欲しい書籍情報を転送。実書店ではウェブアプリやスマートフォンアプリから、バーコードを表示させて書店内に設置してある、書籍検索システムから書架を検索させるなどが可能です。

電子書籍が普及していった場合、既存の店舗が品揃えで勝つことは不可能なので、書籍と同時に電子書籍を店頭で売るような仕組みを用意するしか無いと思います。
ネットでの決済の場合、未成年者の決済の問題や、カードの利用を嫌う層が一定数居るため、実店舗での決済を用意しサービスを提供できるようにします。

方法としては、スマートフォンのFeliCaやNFCなどのチップに無線通信を利用し、決済後に携帯端末のチップに認証データを送信、 スマートフォンの書架アプリからチップにアクセスし、購買済み書籍を認証し書架アプリ上に書籍データをダウンロードし閲覧を可能にするような流れがスマートかと思います。
この書架アプリは、amazonのKindleアプリ、appleのiBooksなど想定しています。
FeliCaやNFCが使えない場合には、チップに書き込む部分を2次元バーコードや、20桁の認証数字などを、レジのレシートなどで発行することで、対応することが可能と思います。
この形であれば、自動販売機のような形にすることが、さらにスマートになると考えます。
書店内の目についた書籍を、販売機などでいちいち入力するのは面倒なため、よく電気店などである、注文カードのようなものを用意し、それを読み取らすことで、簡単に検索させることが出来ると思います。
FeliCaやNFCの場合には、カードライターを用意しておき、タッチパネルなどで選択し、ライターからチップに書き込むことが可能なので、こちらも手段としては容易になります。

書店側としては、売り上げに対して書籍アプリの提供元からアフィリエイトのような形で、キックバックをもらう形で報酬を用意するか、書籍アプリへ外部購入データをそのまま乗せることが出来るような形が用意できないと、この方法のモデルは成り立たないので、弱点になるでしょう。

電子書籍を買うような人が、書店に来るかどうかと言う問題ですが、ピンポイントにこの本が欲しいという人は、実店舗で買うことはほとんど無いと思います。
そのため、逆の発想で書店で電子書籍を買う場合、ネット上での注文より価格を僅かでもいいので安く設定するという方法が有るかと思います。
最初から出かけたくない、今すぐに欲しいという層は、現時点でAmazonなどでの通販を利用するため、その書籍に対しての見込み客としては、非常に弱いため、アピールするだけ徒労に終わると考えました。この場合のアプローチすべき人は、元から本が好きな人や、その書店の書架が好きな人、そして少しでも安いものが欲しい人です。

元から本が好きな人は、もし本そのものが売り切れていた場合でも、電子書籍で一時的に満足してもらうことが可能です。このような人の場合、電子書籍購入後でも、再入荷時に本自体をまた買ってもらえる可能性があります。
書店の書架が好きな場合には、他の本にも興味を示してもらえる可能性が高いため、積極的にいろんな本を紹介することがキーになります。
少しでも安い人については、行動原理がはっきりしているので、なるべく書店内での回遊をしてもらい、他の本への興味を持ってもらうことが重要です。

書籍と電子書籍が並んだ場合、今のハードカバーから新書、文庫本という流れが無くなるかと思います。
というか、このような再生産をするくらいなら、最初からハードカバーと電子書籍で出し、電子書籍の価格を文庫本の設定価格で出版するのが、いろいろな意味でもよいと考えます。
そもそも文庫本化まで待つような人は、ハードカバーは絶対に買いませんし、それまでに機会損失するくらいなら、先に売るべきだと思います。
また、書籍に対する支出がおそらく減ると思いますが、電子書籍になった分だけの額が丸ごと減るのでは無く、他の書籍に対しての購買に繋がると思うので、このあたりは出版社と作者の判断かなと思います。
最初から単行本を想定して出版している、マンガとかライトノベルは価格は変わらないと思います。

そしてこの流れが進んでいった場合、一部の本についてはある意味嗜好品的な、美術品とかに近い形に発展していくかなと思います。
そして古本屋は本当の古書を取り扱っているところ以外で、安い本・売れ線の本を回すような所は、 大半は廃業に追い込まれるのではと思います。

以上ふと思ったことをまとめてだらだら書いたら、すっごくちょうぶんになったと言うことで、ここまで読む人が居るのかな？と自分で書いていて思いました。
まあ、えらい人は当然こんなことすでに思いついて、実際動いているんだろうな～と思いつつ、ただの感想って事で。

まあ、お約束のようにネットでこれどうやるんだろう？として、検索してヒットしたコードを試しに貼り付けて、動かないな～ってよく見ると、まあ何らかのエラーがあるわけで。
その中でも閉じるセミコロン「;」とかダブルクオート「”」とかはすぐ気がつくんだけど、なにげに一番凶悪なのが、全角で入っているシングルクオート「’」とかダブルクオート「”」・・・。
ええ、見落として30分くらい悩みましたよ・・・。
一応、HTMLのコードとしては、ダブルクオート「”」だと「&quot;」とHTMLエンティティ表記だと、「&#34;か&#8221;」、シングルクオート「’」のHTMLエンティティ表記だと「&#39;と&#8217;」となるわけで。

手で入力するとき、これで入れろとは言わないから、システム側でもう少しどうにか出来ないもんかとふと思っただけなんだが、面倒なのかなあ・・・？

$filename='/tmp/foo.txt';
	ob_start();
	echo "var:\n";
	var_dump($var);
	$out=ob_get_contents();
	ob_end_clean();
	file_put_contents($filename,$out,FILE_APPEND);

引用元
var_dump()の結果をファイルに書きたいこともあるよね　だからob_*() – ただのにっき
http://d.hatena.ne.jp/captino2003/20080716/1216216985

すっごくあっさり終了してしまい、ちょっと拍子抜け。
まあ、ここからはテンプレートというか、テーマとかの作り込みをどれくらい簡単にできるかな？とかなのだけど、サンプルのサイト、どっかに転がっていないかな？

すごくちっちゃいサイトで更新頻度があまり高くなく、そして担当者があんまりリテラシー低くない場合、こういう方が良いのかもと思ったので、ちょっと試してみることにする。

find . -type d -print | xargs chmod 755

ファイル

find . -type f -print | xargs chmod 644

頼むで～と思う今日この頃。

1. 料金
   ほぼあたり。
   Softbankの値下げはなかった。見た目auの方がほんの少し高い。
2. 従量制
   はずれ。
3. 回線
   予想がにに売れてないみたいで、Softbankよりつながる。早いって落ちなので、はずれ。
4. テザリング
   あたり。
5.  メール（SMS,MMS）
   SNSのCメールはあたり。ezwebのアドレスは、基礎技術がIMAPだったため、メールアプリでのIMAP接続ができるようにすることで、対応。よって半分あたり。
6. 緊急地震速報
   あたり。
7. SIMカード
   マイクロSIMで、どうもSIMロックレベル2がされていないので、docomoやSoftbankのSIMロックレベルと同じ模様。なので、はずれといっていいと思う。
8. LismoとiTunes
   当然あたり。
9. おサイフケータイ
   当然あたり。

んでもって。

• iPhone同士なのに、通話料がかかる。
  さすがにそこまでの話にはならなかった。が、auがホワイトプラント同じ内容のプランを出してきたのは、ちょっとびっくりした。
• 通話しながらネットができない
  予想通りSoftbankがこの部分を積極アピールして、通話しながらネットができるんですよ～ってアピール。が、auもWiFiならできますと。そしてほかの突っ込みはSoftbankはそもそも電波入らないだろ～との突っ込み。
• WiFiスポットの差
  今のところ特に聞かない。が、そのうち出てくるかな。エリア拡大のためLivedoorスポットを買収するなど、積極展開も少し見せた。

ってことで、だいたいこんな感じ。完全に予想外したのは、ezwebのメール対応だったな～。まあ、Softbankの初期のi.softbank.jpと同じ扱いだから、MMSとしてのezwebではないので、ちょっと使い勝手は落ちるんだよね。おまけにPush Notification使えないから、15分毎にアプリ側から新着を取りに行く、悲しい仕様になってしまったのは残念だね。
年明けの工事でMMSにするのか、Push Notification仕込んで、Push通知できるようにするのか、それが見物だということで。
ちなみに一番の予想外は、iPhone5でなくiPhone4Sだったということで、今回は終わり～。

R.I.P Steve Jobs