ということで原因を探りにログをあさってみたところ、どうやら、MySQL自体は生きているものの、InnoDBストレージエンジンがメモリ不足で落ちている模様です。
確かに、インストールしたままで動かしていたこともあり、また、microインスタンスの総メモリは613MBなので足りなくなってもおかしくはありません。

そんな時、「確かMySQLの想定メモリ使用量を計算する方法があったなあ」と思い出したので、そもそも計算上どうなのよ、というのを再確認しようと思い立った次第です。

公式リファレンスには

innodb_buffer_pool_size + key_buffer_size + max_connections * (sort_buffer_size + read_buffer_size + binlog_cache_size) + max_connections * 2MB

となっています。
http://dev.mysql.com/doc/refman/5.1/ja/innodb-configuration.html
この計算式でざっくりデフォルト値を計算すると、だいたい400MBくらいになります。

また、O’Reilly本の計算式に基づくと
http://rental.off-soft.net/323.html
ということで1GBくらい、という計算になっているようです。
＃そういえばこの本、手元にもあった（笑）。

そもそもmicroインスタンスにApacheなどWebサーバとして最小限のパッケージを入れて動かしている状態で、MySQLが動いていなくても既に300MBくらいは使用しています。たとえv5系リファレンスの計算通りだとしても足りないわけです。

じゃあmicroインスタンスでMySQLは使えないのか、というともちろんそんなことはなく、単純に max_connections の値を減らせば、メモリの使用量は減ります。どの計算式を使ったとしても、結局のところ全体の数値が押し上がっているのは、「* max_connections」の部分で100倍されているからです。
ということで、 /etc/my.cnf などに

max_connections=10

と追加することになります。

もちろん、レスポンスには影響が出ます。
これ以上のレスポンスを求めるのであればもっと大きいインスタンス使ってね、ということなわけですね。
＃そこんとこどうにかなりませんか、と問われてもさすがにどうにも…。

結論から先に言ってしまうと、「隠しフォルダ・ファイル」への読み書きが発生するサービスへの使用は、うまく動作しない場合があるようです。
そこで、試したこと、断念したパターン、最終的にとった方法などのメモを書いておこうと思います。
問題のあるパターン、問題なく使用できているパターンともに、環境に左右されます。
s3fsやfuseのバージョン・forkはもちろん、OSの種類やkernelのバージョンなどによっては問題ない場合や、逆に問題の出る場合があると思われます。
基本的に、以下の結果は、
・CentOS 5.6/6
・Fedora 15/16
で検証したものです。

1. Sambaで使うには問題がある？

s3fsでマウントした領域をSamba共有に指定して使えれば、多少読み書きは遅くてもかなり重宝するだろう、ということで作成してみましたが、最終的にはあきらめました。
正確に言うと、Samba自体はなんとかなるのですが、OSXからの読み書きが正常にできません。
ログを見ると、.DS_Storeなど隠しファイルへの読み書きにエラーが発生しているようです。
OSX側で.DS_Storeを生成しないようにするという方法もありますが、
http://support.apple.com/kb/HT1629?viewlocale=ja_JP
OSXユーザー全員に「コマンド叩いて」というのは事実上不可能という環境だったため、断念しました。
WindowsだけならOKか、というと、これが謎の不安定具合。2007年ごろの開発MLには確かに「NFS使うな」という話が出ていましたが、今でもそうなんでしょうか？
http://lists.samba.org/archive/samba/2007-August/134280.html
http://lists.samba.org/archive/samba/2007-September/135357.html
余談ですが、Sambaは歴史が長いので情報が多い分、その分古いバージョンについての情報が圧倒的に多いため、最新版ではどうなのかがいまいち分かりづらい状況があります。
枯れている技術というのもあり、業務では最新版にはあまり手を出さないでしょうし。

2. WebDAVは問題ない

実は上記1の前に「速度はFTP＝Samba＞WebDAV」というとあるベンチマークを読んでいたため、WebDAVを選択肢に入れつつも先にSambaに着手していたのでした。
上記1の結果をふまえて、WebDAVも一応試してみることにしました。これも結論から先に言いますと、問題ありません。Sambaほど複雑な規格ではないので、さもありなんです。
読み書きのスピードは確かに速くありませんが、そもそもS3への読み書きのスピードが上限になるので、実用に耐えないというほどのものではありません。

3. Subversionのレポジトリとして使うには問題がある？

上記1で隠しフォルダ・ファイルへの読み書きに問題があることがわかっていたので、おそらく問題があるだろうとは思っていましたが、まんまと予想通りでした。
レポジトリを作ること自体はできますが、.svnなどのアップデートがうまくいかない模様です。

4. s3fsかs3fs-cか？

s3fsの最大の特徴は、他のS3クライアントと一部互換性が無いことです。s3fsはS3上にディレクトリを作る際、Content-type: application/x-directory の空ファイルを生成するわけですが、これが大多数の他のS3クライアントにはディレクトリとして認識されません（ディレクトリ＋同名の空ファイルとして認識される）。逆に、他のS3クライアントが生成したディレクトリはs3fsから認識できません。
s3fsへの読み書きがサーバ内で完結していれば問題はないわけですが、別途API経由でS3にアクセスする必要がある場合や、AWSコンソールでもファイルを操作する場合などは困ったことになります。また、サーバ運用開始時S3上に初期状態のファイル群を用意するような場合には、S3クライアントから直接UPしてしまった方が速いのに〜ということもありえます。
この点を変更したものとして、s3fsからforkしたs3fs-cというものもあります。また、s3fs-cがs3fsからforkした後のs3fsのバージョンアップ分をs3fs-cにパッチした、s3fs-cloudpackというものもあります。
どちらがいいか、ということは観点によって異なるとは思うのですが、今回はあくまで実務的な観点から互換性を重視して、s3fs-c系（s3fs-cloudpack）を採用することとしました。

…まあそういうことで、「S3が直接マウントできたらあんなことやこんなことが！」と思っていたんですが、現実はそう甘くはなかった、ということだったわけなんです。

1.「XMLViewで $this->set(‘_serialize’, ‘hogehoge’); したのに意図した通りのXMLが出力されない」

外部APIを叩く→受け取ったXMLをいったんパース→（中略）→別の外部APIへXMLを投げる

ということをしようとしたら、なぜか最後のXML出力内容が壊れている？という現象です。
$this->set(‘_serialize’,'hogehoge’); はViewファイル無しで出力できるメソッドなわけですが、これで組み立てられるXMLは（当然ながら）シンプルな構造のXMLが想定されているはずです（ソースまでは見てないけど）。
ということで元のXMLを見てみたところ、RootにAtributeが付いてたんですね。
このような形式だと、たとえばsimplexml_load_stringでパースした場合、Atributeはデータ配列本体とは別のラベルが付いた配列に入ります。
XMLViewで壊れてたというよりは、ひとつ前の段階のXMLObjectが既に意図した構造ではなかった、というオチです。
_serialize で自動的に生成するのではなく、Viewファイルを用意して差し込み置換すれば、当然、複雑な構造でも意図したように生成できるわけなので、「Viewファイル作れ」という結論になりました。

2.「ディレクトリ移動したら500エラーが出る」

これはほぼこのまんまですが、いったんCakePHPで作っていたアプリケーションを、とある理由で別のディレクトリに移動したら、500エラーで動作しなくなってしまったというものです。

Apacheのエラーログに何も出てないのでこりゃCake側だろうなーとは思ったのですが、原因は、app/tmp/cache/persistent/cake_core_file_mapにカレントパス文字列を含むキャッシュが作られていたということでした。
つまり以前の置き場所を読みに行ってしまっていたということですね。
他のConfigをアップデートしたり、キャッシュファイルを消せば再生成されるということなので、キャッシュを消してOKということになります。

どちらもCakePHP2系の機能ということで、情報が少なめではあるんでしょうね。

さて、業務使用において「枯れている」ことは重要です。しかし、年月を経て、そのままの形での継続使用が不可能になってしまった技術もあるわけです。
たとえば、長いこと使ってきたファイルサーバを、容量の問題などで置き換えなければならないとします。
個人で使う場合はさまざまな選択肢がありますが、お客さんの業務環境への導入とした場合に、
・Windowsのエクスプローラで操作する
・NASをやめて外部サーバ上に置きたい
・コピー速度の著しい低下／価格の著しい上昇は認められない
というような条件を置くと、選択肢はほぼSambaかWebDAVしかないということになります。

（以下長い冒険の旅のダイジェスト版であるため、細かい検証結果や数値などは全力で端折ってあります）

転送速度からするとSambaを選びたいわけですが、そもそもSambaは意外と（？）設定がヘビーであることで知られています。特に今回、Sambaで提供する共有領域として、ネットワークマウントしたストレージを使おうとしたため、かなりの長い期間格闘することになりました。（NFSなどを共有領域にするとハマる、というのは昔から言われていましたが）
・速度面からSMB2.0にしたい→XP未対応
・OSXで書き込みできない→OSXはnetatalkで提供することに
・netatalkでも書き込みできない→NFS上に. AppleDB置いちゃダメ
・Lion未対応
・FSのマウント時にlockオプションは外す
・設定が煩雑に
・さらにユーザー管理ががが
という具合にダークサイドに堕ちそうになったので、いったんやめて、「そもそもWebDAVだとどうなのか？」を検証することにしました。

速度の面では「Sambaの1/2〜1/3」という資料もあったのですが、実際にやってみると、Samba（ネットワークマウントではなくローカルに書き込み）の80%程度の速度でした。しかも意外なことに、ネットワークマウントした領域へ書き込んでもあまり速度が下がりません。また、WebDAVは比較的シンプルな規格だということもあり、Windows/OSXの別無く読み込み・書き込みともに、さほど細かい設定無く行なうことができます。
WebDAVの最大の問題点は、Vistaの64bit版で扱いに問題が出る、ということです。正直現時点では使用されていないのでスルーします。

セキュリティ的にどうなのか、というと、FTP・Sambaと同じようによろしくはないです。設定によっては穴が開きますし、脆弱性もあります。
最低でもIPAによる調査報告は読まないと危険です。
http://www.ipa.go.jp/security/fy14/reports/webdav/index.html

さてこれで、ネットワークマウントした領域をWebDAVで提供し、エクスプローラやFinderで読み書きすることが可能となりました。

とりあえず要件を満たして使えるようにはなったので、ここから、「エクスプローラやFinderを使わずにファイルを扱う方法」（つまり何らかのアプリケーションを使う方法）を気長に浸透させるという仕事になります。
ということで、物語は冒頭に戻るわけです。そしてその問題には様々な要素・側面があるので、また改めて。

locale -a |grep ja

localedef -f SHIFT_JIS -i ja_JP ja_JP.SJIS

export ja_JP.SJIS

convmv -r -f sjis -t utf8 *

convmv -r -f sjis -t utf8 * --notest

そもそもソフトウェアライセンスは（当たり前ですが）使ってほしくないがために定められているわけではないので、ほとんどの場合にはライセンサーの「こういう広め方をしたい」という意図に沿って定められることになります。
そこで、ライセンシーから「こういう使い方ができるべきではないか」「これではこういう使い方ができない」等の不満が出る場合があり、論争になることもあります。

しかしたとえそれが論争になろうとも、横からその論争を見ている人間にとって、その論争を自由に判断して、自分の判断を決めることができます。これもまた自由です。
その論争が、「新たに使い始めようとする人の不利益になるからやめるべきだ」というのは、逆に、これから使い始めることを検討する人に対して、将来の不利益につながる事実を隠すことにしかなりません。

重要なのは、At your own riskを前提とした場合の、選択・判断に必要な情報です。
それがネガティブな情報に見えたとしても、人によってはむしろそれによって採用を決めるかもしれません。その選択を、他者が「誤りだ」と決めつけることができるでしょうか？

当事者目線としては「いや、これは本当に問題なんだ。そういうのとは違うんだ」という声が出るでしょう。
それはそれで良いことなんだと思います。そのように考えている人がいる、というのは重要な情報です。
しかし例えば「それは使用上問題にならない」と言う人がいたとして、「問題じゃないとか言うな！」と言うのは矛盾していないでしょうか。「問題になるか否か」を論争するのであればともかく。

「これから発展していくものをDISるな！」と言うのもどうでしょう。ほとんどのオープンソースのプロダクトは、そうして揉まれて改善されてきたのではなかったでしょうか。「その非難は的外れだ」と論争するならともかく。

オープンソースのメリットとは、プログラムソースが公開されること、誰もが自由に使えることだけではなく、そこに至るまでの経緯がオープンであること、でもあるはずです。
人間は自分と周囲のものを良く見せようとしてしまいがちです。しかし、その「美しくない」部分が明らかにされて成り立っているものは、道具として美しい、と思います。

この問題については、おそらく考え方の違いがあるでしょう。「その考え方はおかしい」という意見が出るかもしれません。
しかし、そのような意見や意識・観点の違いですら全て、その違いを意識していなかった人（おそらく自分含む）にとっての利益になり、新たな選択・判断の有効な情報になると考えているので、それはそれで良いことではないかと思います。

ProFTPD grew out of the desire to have a secure and configurable FTP server, and out of a significant admiration of the Apache web server.

yum install proftpd

proftpd-1.3.3c-1.el6.rf.i686.rpm ... 1.9MB proftpd-1.3.3g-1.el6.i686.rpm ... 3.4MB proftpd-1.3.4a-1.el6.rf.i686.rpm ... 2.1MB

proftpd-1.3.4a.tar.gz ... 7.3MB

proftpd-1.3.3c-1.el6.rf.i686.rpm ... rpmforge proftpd-1.3.3g-1.el6.i686.rpm ... epel proftpd-1.3.4a-1.el6.rf.i686.rpm ... rpmforge

CentOS公式ではないrpmでは、インストールの前に、configureオプションやインストールされる内容を確認した方が良い

mod_quotatab mod_quotatab_file mod_sql

mod_ban mod_ctrls_admin mod_exec mod_facl mod_geoip mod_ifsession mod_load mod_quotatab mod_quotatab_file mod_quotatab_radius mod_quotatab_sql mod_radius mod_ratio mod_rewrite mod_sftp mod_sftp_pam mod_sftp_sql mod_shaper mod_site_misc mod_sql mod_sql_passwd mod_tls_shmcache mod_wrap mod_wrap2 mod_wrap2_file mod_wrap2_sql

一方で、我々が知らない法律も多々あります。
通常、自分が直接関係していない業（おもに商売）に関わる法律は、ほとんど知ることがありません。
たとえば、飲食店を経営している人は食品衛生法について知っているでしょうが、私は飲食店で働いたことがないので、その中身をほとんど知りません。
そして、私がお店の人にならない限り、知っている必要はありません。

では飲食店の店員さんが全員、食品衛生法を知っている必要はあるでしょうか？
もちろん、「必ずしも必要ない」ということになります。
・許可／資格を得た人間がいること
・その人間が食品衛生法を知っていること
・設備やその他の従業員に対して食品衛生法に基づいて適切な指導を行なうこと
という前提によって、事業所と従業員全体が合法となるためです。
つまり、誰かが知っており、その人間の影響下にある者は全て「知っていてやっている」状態である、というのが前提になっているわけです。

さて、ようやくここでタイトルのデザイン・プログラムについての話題になります。
Webデザイナーは、自分や自分のプロダクトが影響を受ける法律を知っているでしょうか？

例を挙げると、どのようなデザインであれ「日本赤十字もしくはその許可を得た者」を表す以外の目的で、「白地に赤十字のマーク」を使用できません。
病院や薬局、「ヘルプ」を表すアイコンなどとして使用することはできないわけです。
これは「赤十字使用法（赤十字の標章及び名称等の使用の制限に関する法律）」に定められており、ジュネーブ条約に基づいています。
日本赤十字社もたびたび違法であることを呼びかけています。

経験上、この問いかけに対するレスポンスはだいたい次のようものに分かれます。

１）「知らなかった」「俺そういうのわからない」「俺は判断できない」
冒頭でも挙げましたが、その言い訳は通用しません。
「ある立場にはそれに応じた義務が付随する」という、非常に一般的な話だからです。
その立場に居続けたいのであれば義務を果たす、嫌であれば辞める、どちらかしかありません。

２）「これはこういう意図の広告表現なので違法とかそういうのとは違う」
広告業界団体のガイドラインにも「関連法規を遵守しなくてはならない」ということは当たり前のように書かれています。なぜ書かれているかを説明する必要はないでしょう。
意図が最重要なのは意図する人の頭の中だけであって、世に出る場合には世の中の優先順位に組み込まれるのが当たり前です。

３）「お客さんがこれにしろと譲らないので〜」
「赤十字使用法」にせよ業界団体ガイドラインにせよ、罰則はありません。
最終的には、違法なプロダクトをリリースすることをOKした人の責任です。その責任を負うのがその立場にある人の義務です。
もちろん、ほとんどの場合には、そのような判断がされることは無いでしょう。
が、実際には「なんか下っ端がうるせえことを言ってるんだけど黙ってさっさと作らせろよ」ということを言う人もいるので、「知っていながら世に出る」ということもあります。

３’）「お金をもらってる側だからしょうがない」
実際には、この件が問題になった場合、高確率で「作った側」が責任を問われます。
なぜならば、このような関係では多くの場合、「作った側」がその違法性を伝えた証拠が無いためです。

４）「そういうことはお客さんに言いづらいので〜」
意識する／せざるにかかわらず、「何かあった場合には自分が全ての責任を負う」のを認めることとイコールになるのです。それは言ってしまえば「自分の社会的立場を賭けて違法行為の責任を負う」ということです。負えますかね？

５）「人命にかかわることでもなし、そこまでやらなくても〜」
だからこそ、あえて「赤十字使用法」を例に出したわけです。

だからこそ我々は、言うべきこと・残すべき記録・決まらないと先へ進ませないということをウザがられながらもやるわけです。
もちろん、責任問題はお金の問題だというのもあります。
「日本は訴訟社会じゃないから〜」という人も多くて驚きますが、平成22年の簡易裁判所での民事訴訟件数は130万件強あります。1年間の出生数（100万人強）より多い数です。
これもまた「知らない」だけで、実際には日本でも訴訟はポピュラーな出来事です。

最後に個人的な思いですが、誰もが「知らない」「わからない」「俺じゃない」「言えない」と言いながらそれぞれの立場に居ようとする、そんな社会は、めぐりめぐって自分の命にもかかわりかねません。
これはモラルの問題ではないのです。理想を語っているのでもありません。
2011年に我々が見たものは、そういうものではありませんでしたか？

$this->Sample->function();

• Controller内のパラメータで読み込むModelを切り替える
• Controller内にはModel名をハードコードしない
• Modelはapplication/modelsディレクトリ内に設置したファイルにのみ記述する

$modelname='Hogehoge'; $this->load->model($modelname);

$this->load->model('Model_name', 'fubar'); $this->fubar->function();

$modelname='Hogehoge'; $this->load->model($modelname, 'fubar'); $this->fubar->function();

ちょっと前から見かけるようになった話がありまして、

夏目漱石は“I love you.”を「月が綺麗ですね」と訳した。二葉亭四迷は「死んでもいいわ」と訳した。

というものです。

夏目漱石の話はこれ有名でして、昔から国文学専攻の人だったら必ず聞くんじゃないでしょうか。学生時代、私も国文学科の知りあいから聞いて、さすが文豪！と感動したものです。
ただし英語教師時代のエピソードということで、本当にあった話かどうかわからないとされていますが。

さて、問題は二葉亭四迷の件です。
夏目漱石とはほぼ同世代の人ですし、ここまで対比されて広まるからには、昔から有名であってしかるべきだと思うのですが、聞いたことがなかったのです。

なぜ突然この話を目にするようになったかというとこれは結構明らかで、Twitterで繰り返しつぶやかれているからです。
http://twitter.com/#!/search/%E6%AD%BB%E3%82%93%E3%81%A7%E3%82%82%E3%81%84%E3%81%84%E3%82%8F

では最近になって誰かが何かに書いたとか発言したとか、そういうことでもあったんでしょうか？
ググってみると、「〜らしい」「〜んだって」と、伝聞が多いですね。

ここでネガティブな発想に襲われたのです。これ、本当なのかな？と。

かろうじて出典を挙げている人が発見できました。ツルゲーネフの「片恋」だそうです。
ほほう。それではと思ってAmazonで探してみたことろ、二葉亭四迷訳本は1955年の岩波文庫を最後に絶版になっているのです。そりゃ伝聞にもなります。探せばあるかもしれませんが。

ここでさらにネガティブな発想に襲われました。これって都市伝説じゃないのかな？と。

この時代の文献は国立国会図書館の「近代デジタルライブラリー」で見ることができます。
問題の個所は第16章、明治29年の版だとp.103、大正5年の版だとp.100です。

（略）私は何も彼も忘れて了って、握ってゐた手を引寄せると、手は素直に引寄せられる、それに随れて身躰も寄添ふ、シヨールは肩を滑落ちて、首はそつと私の胸元へ、炎えるばかりに熱くなつた唇の先へ來る…
「死んでも可いわ…」とアーシヤは云つたが、聞取れるか聞取れぬ程の小聲であつた。
私はあはやアーシヤを抱うとしたが…ふとガギンの事を憶出すと（略）

あったじゃないか！やっぱり都市伝説なんかじゃなかったんだね！と一瞬思ったのですが、そこまで素直にはなれないわけでして。

ではこの「死んでも可いわ…」の原文は本当に「I love you.」もしくはロシア語で「Я люблю тебя」なのか？というわけです。

ではまず英語版をあたってみましょう。
http://www.ibiblio.org/eldritch/ist/lear.htm#acia
（英語版は“Asya”というタイトルになっているはずなんですがこの版はなぜか“Acia”になっています）
場所（章番号）がわかっているので比較的早く見つかりますね。
上に挙げた個所の英語訳はこうなっています。

I forgot everything, I drew her to me, her hand yielded unresistingly, her whole body followed her hand, the shawl fell from her shoulders, and her head lay softly on my breast, lay under my burning lips. . . .
“Yours”. . . she murmured, hardly above a breath.
My arms were slipping round her waist. But suddenly the thought of Gagin flashed like lightning before me.

ふむ。「”Yours”…」ですね。

ではがんばってロシア語版をあたってみます。
http://ilibrary.ru/text/1097/p.16/index.html
これはなかなか難題ですが、章番号があるのでかろうじて可能です。
章の頭からの段落数と、会話文の形式から判断すると、おそらくこの個所だろうと思われます。

— Ваша… — прошептала она едва слышно.

「Ваша…」を翻訳してみると、「あなたの…」となります。
http://translate.google.co.jp/#ru|ja|%D0%92%D0%B0%D1%88%D0%B0…
となるとこれはもう明らかで、英語版の「”Yours…”」はほぼロシア語の直訳だということがわかります。

さて、結論です。

「二葉亭四迷は“I love you.”を『死んでもいいわ』と訳したか？」

答えは、Noです。
（少なくともツルゲーネフの「片恋」では…）

しかし、この文脈で、直訳すれば「あなたの…」となるところを、「死んでも可いわ…」とした二葉亭四迷の訳がすばらしいことには違いはありません。

……ただおそらく、二葉亭四迷がこのセリフで意図し、当時の読者が感じ取っただろうイメージは、「君のためなら死ねる」とか「死ぬほど好き」とかではなく、「心中」なんでしょうね。

好きな果物： <input type="checkbox" name="data[fruits][]" value="1"/>りんご <input type="checkbox" name="data[fruits][]" value="2"/>バナナ <input type="checkbox" name="data[fruits][]" value="3"/>パイナップル

$_POST['data']['fruits']

<input type="checkbox" name="data[好きな果物][]" value="リンゴ"/>リンゴ <input type="checkbox" name="data[好きな果物][]" value="バナナ"/>バナナ <input type="checkbox" name="data[好きな果物][]" value="パイナップル"/>パイナップル

希望 … 0x8a 0xf3 0x96 0x5d 頭脳 … 0x93 0xaa 0x94 0x5d 講評 … 0x8d 0x75 0x95 0x5d

注意: ここで言うところの文字とはa-z、A-Z、127から255まで (0x7f-0xff)のバイトを意味します。

mbstring.http_input=SJIS-win mbstring.http_output=SJIS-win mbstring.internal_encoding=UTF-8 mbstring.encoding_translation On

・URLは/example1/とする（example1.phpをmod_rewriteで書き換え）
・/example1/にアクセスされた場合、Cookieの内容を見て、
　・画面Aを表示する
　・/example2/へリダイレクト
　のどちらかの処理を行なう
・/example2/では画面Bを表示する
・/example2/の画面B内からFormを/example1/へPOSTしCookie発行
・/example1/の画面Cを表示

お察しの通り、よくあるログイン画面です。
ところが/example1/→/example2/に何度かリダイレクトされた後、/example2/の画面Bからログインしようとしたところ、/example2/へリダイレクトしてしまうわけです。

まず始めにCookieが正しく発行されていないことを疑ったわけですが、これはすぐ正常発行が確認できました。

そこで、/example2/→/example1/の処理の冒頭で停止させてCookieの中身を表示させてみよう、と思ったところ、処理が始まる前に/example2/にリダイレクトしてしまうのです。
処理が始まる前ということは、/example1/のプログラム側の問題ではないということになるわけで、mod_rewriteの動きを疑う流れになると思うのですが、RewriteRuleをコメントアウトしてもリダイレクトが収まりません。

さてこれは何だろうと悩んだわけですが、ふと、同じ挙動をChromeで繰り返してみても再現しません。
となるとこれはブラウザの問題である可能性が高くなるわけで、Firefoxのアドオンを全てOffにして、再度やりなおしてみました。が、やはり変化はなく、さて、あと消せるものは何かあったかなと設定パネルを眺めていたところ、そういえばキャッシュは消してなかったなと気付き、全消ししてみたところ、サクっと正常に動作したというわけです。

結果として、FirefoxではLocationヘッダでのリダイレクトについてもキャッシュしている可能性がある（もしくはキャッシュする場合がある可能性がある）ということになると思います。

さて、そもそもLocationヘッダはキャッシュしていいもんなんでしょうか？
原典を見てみましょう。RFC 2616です。

10.3.2 301 Moved Permanently
The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.
The new permanent URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).
If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
Note: When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request.

10.3.3 302 Found
The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.
The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

これを見ると、
・301：「別のものを指定していない限り」キャッシュ可能
・302：Cache-ControlかExpiresが指定されている場合のみキャッシュ可能
となっています。（「別のもの」って何？）
ということは、301でリダイレクトしたらキャッシュされても文句は言えないわけです。
そもそも「Moved Permanently」なわけですし。

ここで、あー、と思い出しました。
そういえば、何を思ったのか、リダイレクトを301で書いていたのでした…。

ということで、FirefoxはStatus301ヘッダをキャッシュしている可能性があり、かつそれはRFC的には正しい挙動であるということになるかと思います。

自分が悪いからしょうがないというオチなんですが、確かにキャッシュすれば遷移は速くなるというブラウザ側の都合も納得しつつ、これはキャッシュしてほしくないところだなーと…。

echo() は実際には関数ではありません (言語構造です)。

(いくつかの他の言語構造と異なり) echo() は関数のように動作しません。

print print "hoge";

echo echo "hoge";

括弧は必要ありません。

void echo ( string $arg1 [, string $... ] )

echo("hoge","hoge");

echo "hoge","hoge";

you are not required to use parentheses with it.

MeCabで一般的に使われる辞書は
・IPA辞書
・unidic
・NAIST辞書
の3つです。

解析結果は入力する文章の傾向によってかなり左右されることが過去わかっているので、いくつか文体の異なるテキストを用意して解析させてみました。

１）新聞記事
まず、辞書を作成するために多くの新聞記事が利用されています。よって、新聞記事に近い文体の文章は、どの辞書でもかなり近い結果になります。

２）エンタメ誌記事
ほぼ同じですが、「教科書的でない語」の分解に若干差が見られます。
例：IPA辞書・NAIST辞書「修羅場」unidic「修羅／場」

３）専門誌記事（食品）
一部の語に差が見られます。
例：IPA辞書・NAIST辞書「小麦粉」unidic「小麦／粉」… IPA辞書・NAIST辞書「乳製品」unidic「乳／製品」
数詞の扱いにも若干差があります。
例：IPA辞書「2011年」unidic・NAIST辞書「2／0／1／1／年」

４）専門誌記事（女性向け商品）
複数の連続するカナの名詞を1語と見なすか否かに差があります。
例：IPA辞書・unidic「ヒロイン／メイク／シリーズ」NAIST辞書「ヒロインメイクシリーズ」 … IPA辞書・NAIST辞書「アイラッシュカーラー」unidic「アイラッシュ／カーラー」
また該当記事にURLが含まれていたのですが、特にドメイン部分の認識は差があります。
例：IPA辞書「http／://／ameblo／.／jp／/」unidic・NAIST辞書「http／:／/／/／ameblo／.／j／p／/」

５）ブログ記事
主に顔文字の扱いが異なります。
例：IPA辞書「(≧∇≦)」unidic・NAIST辞書「(／≧∇≦)」… IPA辞書・unidic「(^。^;)」NAIST辞書「(／^／。／^／;／)」

６）企業IR系文書
unidicに分割多めな傾向があります。
例：IPA辞書・NAIST辞書「株式会社」「オンライン」「NTT」unidic「株式／会社」「オン／ライン」「N／T／T」

７）お役所文書（省庁通達）
辞書作成の際に使用されているのかもしれませんが、あまり差がありません。名詞にはほぼ違いが見られませんが、一部いわゆる活用形の分割が異なるようです。
例：IPA辞書・NAIST辞書「主たる」「において」unidic「主／たる」「に／おい／て」

８）英文（若干フォーマルな文書）
いじわるではありますが、日本の伝統芸能について書かれた英文（日本語のローマ字表記が混ざったもの）を分解させてみました。
圧倒的にIPA辞書の精度が高いようです。NAIST辞書は「is」「as」などの短い語を1文字づつに分解する傾向にあるようです。unidic辞書は所々英単語を抽出していますが、抽出される語とされない語の違いが、結果からはよくわかりません。

こうして見てみると、「分解する」という点ではunidicの性能が高いことが分かります。今回の検証ではあまり見られませんでしたが、標記ゆれの許容も幅が広いようですし。
もともと形態素解析エンジンの役割はそれぞれのエンジンの目的・意図に従って「分解する」ことであって、使われる際にどちらが都合が良いかという観点ではないわけです。

しかし、形態素解析を「サクっと走らせてそのまま使いたい」という用途の場合、（特に名詞の場合に）ある語を「別々の語」として認識するか「ひとつの語」として認識するか、ということは、分解後の利用に影響を与えることになります。

今回検証してみた限りでは、IPA辞書がわりと汎用的に「そのまま使う」のに向いているような結果でした。解析させる文章の傾向によっても変わると思うので、どの辞書が適しているか、想定文章をそれぞれ解析させてみて決めるのが良いのではないかと思います。

ということで、時計合わせは次の２つの手順で行ないます。
１）ゲストOSの時計をホストOSから独立させる
２）ntpサーバにより外部の時計を参照する

１）

echo ’1′> /proc/sys/xen/independent_wallclock

として時計を（ホストOSから）独立させます。
また、再起動後のために/etc/sysctl.confに

xen.independent_wallclock = 1

と追加しておきます。

２）
物理サーバを使用しているとそれほど大幅に時計がズレることはあまり経験しませんが、
仮想サーバでは、時計がズレやすい傾向があるようなので、
時計を切り離した後は、必ずntpdを設定しておきます。

yum install -y ntp
ntpdate -b -u ntp.nict.jp
/etc/init.d/ntpd start
/sbin/chkconfig ntpd on

（/etc/ntpd.confの設定内容については割愛）
同期の状況は

ntpq -p

でチェックします。

参考：
https://forums.aws.amazon.com/thread.jspa?threadID=67855
「ゲストOSではntpを使わなくていいと思っていたがTokyo Regionで5分以上ずれ…」
という質問（Tokyo Regionとそれ以外で違いがあるのか？）には答えられておらず、
個人的にはそこがかなり気になるのですが、結果的には「ずれてたらゲストOSでntp使ってください」ということになっているようです。

さて、このswfmillですが、結構長い間、0.2.12にKLabパッチをあてて使用されていました（0.2.12はSJISが扱えない＋FlashLiteがSJISだったため）。

ところが0.3.1がリリースされてKLabパッチが取り込まれたため、さてこれを使おうとすると、インストールできません。
正確には、configureは通るのにmakeが通りません。
バグ報告を見ると、0.3.1リリースの数日後（2010/7）には上がっているものの、動きは無いようです。
https://bugs.launchpad.net/swfmill

検索してみると、ソースファイルを書き換える例がいくつか出てきます。特に商用では正直ソースを書き換えるのはあまりやりたくないわけですが、そうも言ってられず。
makeのエラーからソースをたどり、数ヶ所程度の書き換えでmakeが通るようになりました。

しかし、この時私の目の前にはまだまだサーバが何台も残っていたわけです。まさか全部手作業で書き換えるのはありえない、というわけで、パッチを書いてみました。
swfmill.0.3.1.v2.patch
swfmill-0.3.1.tar.gzを展開したswfmill-0.3.1上で

patch -p0 < swfmill.0.3.1.v2.patch

を実行後、

./configure && make && make install

でmakeが通ると思います。
※2011/8/25追記：
makeが通ってできたバイナリで一部commandが正常動作しないようでしたので公開を停止しました。
※2011/8/27追記：
patchを修正・再UPしました。

※このパッチはAmazonEC2上のCentOS5.6でのみ動作確認済みです。他の環境では動作確認していません。
※このパッチを使用した結果について一切の責任を負いません。

yum install mysql
として、インストール候補一覧が出てy/N選択待ちになったところで、インストールしようとしているバージョンをメモっておきます。
[N]で終了させて、
yum install -y mysql-5.5.15
というようにまずmysqlだけインストールします。
その後、
yum install -y php-mysql （その他もろもろ）
とすると、意図したバージョンに揃ってくれます。

もう複数バージョンでインストールされてしまっている、という場合は、
yum remove mysql
としていったん消してからやり直すことになります。

で、CentOS（というかその元になっているRed Hat Enterprise Linux）でのPHPはここしばらく5.1系が入っておりました。
しかし、5.1→5.2→5.3の間では微妙な規模の機能変更・追加があったため、
開発サイドの気持ちとしては、今後のことを考えると5.3にしておきたい、ということなわけです。

では5.5までPHP5.3はソースインストールしていたのかというと、
（そうする場合も多かったとは思いますが）
みんないわゆる「野良レポジトリ」を頼ることになったわけで、
たとえばremiなどを
yumのレポジトリに追加してupdateするとphpが5.3になるというわけですね。

＃ソース自体がコミュニティによって書かれてるわけで、
＃「野良レポジトリ」って言い方はどうなのよという話ですが。

さて、そんな状況の中、RHELの5.6ではPHPを5.1.x→5.3.xにせずに、
・php：5.1.x
・php53：5.3.x
という2つのパッケージに分離されました。
そのまま移行するには影響が大きすぎるという判断なんでしょうかね。

これによって自動的にCentOS5.6でもphp53というパッケージが生まれたわけですが、
・php53-pearが無い
・php53-mcryptが無い
のです。これは地味に痛い。
pearは細かいupdateでphp53に対応するわけですが、
mcryptは場合によっては無きゃダメと言われてしまうことがあるので困ってしまうわけです。

今回の記事は「php53とremiとどっち使ったらいいですか？」と聞かれたので書いてみているわけですが、
最終的には…

・野良レポジトリを使って良い状況かどうか
→よければremiにしておく
・必要なライブラリがあるかどうか
→php53に無ければremi確定
・今後ライブラリを追加する可能性があるか
→ある日突然「○○っての入れて」とphp53に無いライブラリを入れろと言われる予感がする場合には最初からremi導入の努力を最初にしておく

というロジックで選びます。
ふざけてるわけではなく、商用でのこういう選択条件は、
（批判をするつもりは毛頭ありませんが）
技術よりも会社のポリシーとか担当者／決済者の気持ちとか、
そういったことになることが結構多いわけです。

ということで、今日も今日とて、CentOS5.3のAMIを見つけてきてインスタンスを作成したわけです。

SSHで必要な環境に整えて、さて必要なファイルをUPしよう、とSFTPでアクセスしたのですが、
接続直後に切断されてしまいます。
クライアント側のログを見ると、接続は確立しているのにすぐCloseしてしまっているようです。
接続が確立しているということは、認証鍵は機能しているようなので、
これはサーバ側のログを見てみるべきでしょう。

ということで /var/log/messages を見てみます。
sshd[1001]: error: subsystem: cannot stat /usr/lib/openssh/sftp-server: No such file or directory

驚愕の事実発覚。
SFTPはSSHDによって、サブシステムとして起動するわけですが、これが存在しないと。

sshd_configを見てみましょう。

vi /etc/ssh/sshd_config

Port 22
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 768
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
PasswordAuthentication no
PrintLastLog no
TCPKeepAlive yes
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes

OpenSSH自体は存在するようなので、とりあえずsftp-serverのありかを探してみます。
find / -type f -name sftp-server
すると次の場所にあるようです。
/usr/libexec/openssh/sftp-server
（当たり前といえば当たり前な在りかですね）

先ほどのsshd_configのSubsystemを
#Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp /usr/libexec/openssh/sftp-server
と書き換えて、
/etc/init.d/sshd restart
でSFTPが起動するようになりました。

まーこれがCommunityAMIの落とし穴でもあり醍醐味でもあるということでしょうかね。

$config['maintain_ratio'] = TRUE; $config['height'] = 50; $config['width'] = 50; $config['master_dim'] = ‘width’; $this->load->library(‘image_lib’, $config); $this->image_lib->resize();

切り抜きメソッドは、次のように切り取る場所を指定する X および Y 軸 (ピクセル) を設定する必要があるのを除いて、 リサイズメソッドと大体同じように動作します:

$config['x_axis'] = 50; $config['x_axis'] = 50; $this->load->library(‘image_lib’, $config); $this->image_lib->crop();

$this->load->library(‘image_lib’, $config);

convert -resize 50×50+25+25 file_org file_dist

convert -resize 50×50-10-10 file_org file_dist

$config['x_axis'] = -50; $config['x_axis'] = -50; $this->load->library(‘image_lib’, $config); $this->image_lib->crop();

$cmd .= ” -crop “.$this->width.”x”.$this->height.”+”.$this->x_axis.”+”.$this->y_axis.” \”$this->full_src_path\” \”$this->full_dst_path\” 2>&1″;

— system/libraries/Image_lib.php 2011-03-28 16:25:12.000000000 +0900 +++ application/libraries/Image_lib.php 2011-06-08 23:52:47.000000000 +0900 @@ -577,7 +577,17 @@ if ($action == ‘crop’) { - $cmd .= ” -crop “.$this->width.”x”.$this->height.”+”.$this->x_axis.”+”.$this->y_axis.” \”$this->full_src_path\” \”$this->full_dst_path\” 2>&1″; + if($this->x_axis<0){ + $x_axis = $this->x_axis; + }else{ + $x_axis = “+”.$this->x_axis; + } + if($this->y_axis<0){ + $y_axis = $this->y_axis; + }else{ + $y_axis = “+”.$this->y_axis; + } + $cmd .= ” -crop “.$this->width.”x”.$this->height.$x_axis.$y_axis.” \”$this->full_src_path\” \”$this->full_dst_path\” 2>&1″; } elseif ($action == ‘rotate’) {

Some dirty trick is changing the source Code: require_once -> require

if ( ! function_exists(‘get_mime_by_extension’)){ function get_mime_by_extension($file){ $extension = strtolower(substr(strrchr($file, ‘.’), 1)); global $mimes; if ( ! is_array($mimes)){ if ( ! require_once(APPPATH.’config/mimes.php’)){ return FALSE; } } if (array_key_exists($extension, $mimes)){ if (is_array($mimes[$extension])){ // Multiple mime types, just give the first one return current($mimes[$extension]); }else{ return $mimes[$extension]; } }else{ return FALSE; } } }

_once の振る舞い、およびそれが _once なし版とどのように異なるのかについての情報は、 include_once() のドキュメントを参照ください。

この関数の動作についての情報は include() のドキュメントを参照ください。

読み込まれるファイルで定義された関数がある場合、 これらは、return()の前後によらず メインファイルで使用できます。 このファイルが二度読み込まれた場合、PHP 5は関数が定義済みであるため 致命的なエラーを発生します。 一方、PHP 4は return()の後に定義された関数については、 エラーを発生しません。 ファイルが読み込み済みであるかどうかを調べ、 読み込まれるファイルの内容を条件分岐で返すかわりに include_once()を使用することを推奨します。

hoge.php <?php return “hoge”;

test.php <?php var_dump(require_once((dirname(__FILE__).”/hoge.php”))); var_dump(require_once((dirname(__FILE__).”/hoge.php”))); var_dump(require((dirname(__FILE__).”/hoge.php”)));

string(4) “hoge” bool(true) string(4) “hoge”

include() は、ファイルを見つけられない場合に warning を発行します。 一方 require() の場合は、同じ場合に fatal error を発行する点が異なります。

require() は include() とほぼ同じですが、失敗した場合に E_COMPILE_ERROR レベルの致命的なエラーも発生するという点が異なります。 つまり、スクリプトの処理がそこで止まってしまうということです。 一方 include() の場合は、警告 (E_WARNING) を発するもののスクリプトの処理は続行します。

if ( ! function_exists(‘get_mime_by_extension’)){ function get_mime_by_extension($file){ $extension = strtolower(substr(strrchr($file, ‘.’), 1)); global $mimes; if ( ! is_array($mimes)){ if (defined(‘ENVIRONMENT’) AND is_file(APPPATH.’config/’.ENVIRONMENT.’/mimes’.EXT)){ include(APPPATH.’config/’.ENVIRONMENT.’/mimes’.EXT); }elseif (is_file(APPPATH.’config/mimes’.EXT)){ include(APPPATH.’config/mimes’.EXT); } if ( ! is_array($mimes)){ return FALSE; } } if (array_key_exists($extension, $mimes)){ if (is_array($mimes[$extension])){ // Multiple mime types, just give the first one return current($mimes[$extension]); }else{ return $mimes[$extension]; } }else{ return FALSE; } } }

CodeIgniterでは、コントローラ・モデル・ビューともにサブディレクトリに配置することができます。
http://codeigniter.jp/user_guide_ja/general/controllers.html#subfolders

しかし実際には、コントローラだけは、application/controllers直下のディレクトリ内にソースファイルが存在しなければ動作しません。
たとえば、
application/controllers/api/get/hoge.phpを
/api/get/hoge
と呼び出すことはできないわけです。

となると、このようなURLを作りたいと思った場合に、直球で考えると、application/controllers/apiディレクトリにgetコントローラを作ってメソッドを全てぶらさげないといけないのか！？と思ってしまうわけですが、これはルーティングの仕事なのだろうと思います。

上の例でいくと、
application/controllers/api_get/
というディレクトリを作っておいて、
application/config/routes.php
に
$route['api/get/(:any)'] = “api_get/$1″;
とすれば、
/api/get/hoge
で
application/controllers/api_get/hoge.php
を呼び出せるようになるわけですね。

メソッドの数が少なければ（＆コード量が少なければ）getコントローラ1つでまかなえるとは思うのですが、最初っからそれなりの数になってしまうことが予想される場合や、後から機能追加が予想される場合には、ソースごと分けたいですよね。

CakePHPなどだとバッキバキにルーティング設定をしたりするようですが、CodeIgniterでのルーティング設定は基本的に「indexメソッドをURLから取る」というシンプルな目的に使われることが多く（自分だけかもしれないですが）それほど使わない印象があるので、メモった次第です。

まず何をしていたかというと、OAuthのテストをしようしていて、
curl・php-curlがうまく動かないという現象がありまして、
どうやらcurl-ca-bundleがおかしいとエラーがでていました。
port clean curl-ca-bundle すれば良いという情報もあったのですがこれでは復旧せず、
結局 port selfupdate をかけて正常に port install curl が入りました。

ところがこの後、CodeIgniterが全然動かない
という奇妙な現象に陥りました。

Apacheのerror_logを見てみたところ次のようなありさま。

dyld: lazy symbol binding failed: Symbol not found: __mysqlnd_end_psession
Referenced from: /opt/local/lib/php/extensions/no-debug-non-zts-20090626/mysql.so
Expected in: flat namespace

dyld: Symbol not found: __mysqlnd_end_psession
Referenced from: /opt/local/lib/php/extensions/no-debug-non-zts-20090626/mysql.so
Expected in: flat namespace

[Sun Apr 03 02:17:00 2011] [notice] child pid 214 exit signal Trace/BPT trap (5)
dyld: lazy symbol binding failed: Symbol not found: __mysqlnd_end_psession
Referenced from: /opt/local/lib/php/extensions/no-debug-non-zts-20090626/mysql.so
Expected in: flat namespace

dyld: Symbol not found: __mysqlnd_end_psession
Referenced from: /opt/local/lib/php/extensions/no-debug-non-zts-20090626/mysql.so
Expected in: flat namespace

[Sun Apr 03 02:20:05 2011] [notice] child pid 335 exit signal Trace/BPT trap (5)
dyld: lazy symbol binding failed: Symbol not found: __mysqlnd_end_psession
Referenced from: /opt/local/lib/php/extensions/no-debug-non-zts-20090626/mysql.so
Expected in: flat namespace

dyld: Symbol not found: __mysqlnd_end_psession
Referenced from: /opt/local/lib/php/extensions/no-debug-non-zts-20090626/mysql.so
Expected in: flat namespace

さてこれでMacPortsのMySQL関連がどこかおかしくなったことはなんとなくわかりますが、ググってみても情報が出てこないのです。

こんな時には基本に立ち返るというわけで、

port upgrade mysql5-server

upgrade対象無し。

port uninstall mysql5-server

php5-mysqlがエラーを吐いている様子。

port uninstall php5-mysql

uninstallできないとなると…

port deactivate php5-mysql

deactivateは出来たようですね。

port install php5-mysql

なにもエラーなく終了しました。

/opt/local/apache2/bin/apachectl restart

なにごともなく表示復旧しました…。

phpMyAdminが動いてCodeIgniterが動かない、というのはなぜだろう？
ということで後でソースを見てみることにします。
今日は取り急ぎここまでということで。

とりあえず弊社が使用・関連している会社・サービスから。

さくらインターネット
http://www.sakura.ne.jp/news/archives/20110314-003.news

AWS（Amazonクラウド）
http://status.aws.amazon.com/
（現時点では個別の発表は見当たらない）

Google Apps
http://www.google.com/appsstatus#hl=ja

iSLE (GMO)
http://home.isle.ne.jp/news/2011/110314.html

@ymc (GMO)
http://www.ymc.ne.jp/news/#20110314

ラピッドサイト
http://www.rapidsite.jp/news/2011/index.html#20110314

ニフティクラウド
http://niftycloud.cocolog-nifty.com/blog/2011/03/post-e6cb.html
http://niftycloud.cocolog-nifty.com/blog/2011/03/post-7eff.html

i2ts
http://www.i2ts.com/news/2011031101.html
http://www.i2ts.com/news/2011031401.html

ところがこれまで、GoogleアカウントではGoogle Appsと同じメールアドレスで登録することができていた（ややこしいですが）わけでして、そのようなGoogleアカウントを持っていた人にとっては、Google Appsのアカウント移行が後回しになったのです。
で、事前のアナウンス通りに2010年末から以降が開始されたのですが、これが結構中途半端なことになっていて、いくつかのサービスでアカウントが壊れたような状態になってしまっていました。

しかしこれが使えないというのもまた実際問題困ってしまうことがあるので、各サービスごとに不具合を解消する手だてをとってみました。以下はそのまとめ（時系列）です。
お約束ですが、やった結果どのようになっても責任は取れません。

Google Appsダッシュボード
・自分のアカウントを含めて「移行を開始」する
・Google Appsからログアウト

Analytics
・別アカウントを用意し、全てのプロファイルに管理者権限で追加

Bookmark・Readerなど
・エクスポートして保存しておく

Googleアカウント
・全てのサービスを解除
・アカウントクローズ

（この間最大24時間放置）

Google Appsダッシュボード
・自分のアカウントが「移行済み」になっていることを確認
・「コア Google Apps スイート」以外のサービスを有効にする

Bookmark・Readerなど
・サービスによってはログイン時に「アクティベートしろ」と言われる（あいまい）
・ReaderについてはDLしておいたxmlファイルをインポートする

…と、ここまできたところで、だいたいのサービスにログインができるようになっていたのですが、
Analyticsだけはログインしてもエラーが発生します。
調べてみると同じような人が結構いるようですが日本語では結局情報が無く、
Analyticsフォーラムの英語版で発見。
http://www.google.com/support/forum/p/Google+Analytics/thread?tid=0b017663252c211c&hl=en

1. From the Google Analytics home page, click Product
2. On the Product page, under Product Family ->Analysis and Optimization, click Website Optimizer
3. Activate the Website Optimizer feature.
4. Finally, go back to the Google Analytics homepage and you will be able to create and access analytics accounts! Woohoo! :-)

ウェブサイトオプティマイザーにログインしてみると、Analyticsでエラーは出なくなりました。
が、もちろんプロファイルは全て空。

そこで、Analyticsに別アカウントでログインし、元のアドレスをプロファイルごとに追加してやればAnalyticsが使えるようになります。

Bookmarkにはファイルから直接のインポート機能が無いので、
http://www.google.com/support/toolbar/bin/answer.py?hl=ja&answer=43305
などを使用してブラウザなどをいったん経由させる必要がありますね。

Google Appsで利用しているメールアドレスでGoogleのサービスをどこまで利用しているかによって、この方法で解決するかどうか変わるかもしれません。
また、Google側での「移行」処理がいつまで行われるかによってはこの情報もすぐに要らないものになるのでしょうけれども…。

メーカー側の事業として見たら、既存の端末にいかほど導入されているか、ということよりも、Androidのように、これからどれくらい導入されていくか（しかもその見込みが明らかにそれなりに期待できる）という方に傾くでしょうから、しょうがないなとは思うのですが。

オープンソースになったあたりから、既存の端末をベースに発展ができるかと期待していたのですが、ハイエンド機向けにはMeeGoもあるし、当面はちょっと難しいことになりそうですね。

注視しているもの：

・docomoのSIMロック解除がどのように実施されるのか
→iモードとの接続をどうするのか。

・Android
→今後出るであろうケータイでの採用について。

・キャリア公式サイト制度
→どう方向転換するか。

気にしているもの：

・KDDIの社長さんが替わるのでauの戦略がどうなるか
→新機軸打ち出さないわけにはいかないだろうし、かといって物理的な制約もいっぱいあるわけで。

・auが10/18に発表するという「禁断のアプリケーション」
→どの方向に禁断なのか、ということによって、何に顔を向けているのかが現れるのではないかと。

・Baiduなどの海外勢
→携帯を重視してアプローチしているようなので。

・周波数帯
→まだ先ですがターニングポイントになると思うので。

・Symbian Foundation
→Sony EricssonとSamsungが手を引きぎみなので。

がっかりしているもの：

・Flash Lite 4
→FlashPlayerとの統合の話は出ていたのに…。

ケータイに関してはほとんどの場合、技術は後から動くので、こういうことを日々気にして生きています。

記事の内容を読むと、
・世界的にシェア低い
・スマートフォンに押されている
・Android使えば世界に打って出られるんじゃないか？
・VAIOみたいなブランドを打ち出すことは可能なんじゃないか？
というような内容でした。

個人的には、メーカーがどうこうというのは正直どうでもいいんじゃないかと思っています。だってお金になると思ったら誰だってやるわけですよ。

スマートフォンじゃないケータイでAndroidが出せるかどうかなんて、キャリア次第なわけです。そもそも、日本の携帯電話メーカーにはキャリアからお金が出ていたわけで、受託開発で余計なもの入れられないというのは携帯電話とか関係なくあたりまえの話なわけです。
半ば受託開発で作られた製品と、自社開発して売り込まれるパッケージとはポジションが違うわけで、受託開発で固まっている市場にパッケージが切り込む、という図式はどの業種にでも見ることができるはずです。

なのでどちらかというと、フルスクラッチvsパッケージという構図や、日本ではフルスクラッチ開発されたシステムが好まれる傾向にある云々（本当かどうかは微妙ですが）などというあたりの話とリンクして論じられてもいいものではないかなーと思うわけです。

記事中に「米国のテレビ産業のようになってしまうかもしれない」というドコモの人のコメントが出てましたが、アメリカのTVメーカー潰したのは日本のメーカーなわけで、これと同じように他国のメーカーが日本の携帯電話製造に参入して潰しちゃうかもね、という文脈なんでしょう。
少なくとも現時点では、海外メーカーはフルスペックのケータイをほとんど出していません。日本国内向けに作らなくてはならないので。そのこと自体が参入障壁として問題にされてもいます。
なのでこの発言は、参入障壁を作っている側の人の発言と見ると、面白いものがあります。ある種各方面への脅しとも受け取れるわけで（笑）。

ケータイに関する報道はほとんどが機種中心に語られています。
機種（＋メーカー）が最も目に見えるところであるのは確かですが、そこを話の中心にしてしまうと、実際に関わっている重要な要素が全部見えなくなってしまうと思うのです。
今回の記事はそうした報道の中では非常にすばらしいものではありますが、なぜ上記のような問題が正面切って取り上げられないのか、常々疑問に思っていたりします。（受けが悪いんだろうか…？）

そんな時、日本でも選挙がはじまりました。
はたして、2010年のこの段階で、日本の各新聞社はどのようにこの流れをとらえているんだろう？と気になってみていました。

が、結果は…大手サイトはおしなべてFlashで開票結果を表示していました。
使っちゃいけないと言うつもりはありませんが、考え方の違いは大きいなと思う次第です。
Flashでそれを表示することは、おそらく当事者からするとプロ意識なのでしょう。実績を重んじる姿勢であったり、ごく古い環境にある閲覧者への配慮であったり。と同時に、事実をわかりやすく伝えるという使命に最大限注力した、ということなのだと思います。

しかし、それは世の中に情報を発信することのプロとしては、どうでしょう？
iPhoneを挙げるまでもなく、現にFlashを再生できないデバイスが数百万台以上存在するという事実についてはどう考えているのでしょうか？
BBCの判断には、世の中の流れを敏感に察知してそれを自ら示す、というプロ意志が感じられるのです。そしてそれが本当のプロ意識ではないかと思うのです。

たとえば「IEの古いバージョンを使っているユーザーが不都合が無いように」というような話はよく聞きますが、情報を発信するプロ意識があるのであれば、それがいかに危険な状態であるかを閲覧者に警告するくらいでも良いはずです。
ただやみくもに分かりやすく角のたたない立場に徹しているとしたら、それは単純に自分のやりたいことをやっているに過ぎません。

相手が求めることをするのが相手のためになるわけではない、というと誰もが否定しないと思いますが、実際に当事者になった場合、プロ意識という言葉によってかえってメリットを失う結果になっていることは多いと感じています。