\Image::load($filename_full); ->output('jpeg');

\File::download($filename_full,$filename);

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

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

さて、ようやくここでタイトルのデザイン・プログラムについての話題になります。
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の落とし穴でもあり醍醐味でもあるということでしょうかね。

<form id="jsonForm" action="json-echo.php" method="post"> Message: <input type="text" name="message" value="Hello JSON" /> <input type="submit" value="Echo as JSON" /> </form>

// prepare the form when the DOM is ready $(document).ready(function() { var options = { target: '#output2', // target element(s) to be updated with server response beforeSubmit: showRequest, // pre-submit callback success: showResponse // post-submit callback // other available options: //url: url // override for form's 'action' attribute //type: type // 'get' or 'post', override for form's 'method' attribute //dataType: null // 'xml', 'script', or 'json' (expected server response type) //clearForm: true // clear all form fields after successful submit //resetForm: true // reset the form after successful submit // $.ajax options can be used here too, for example: //timeout: 3000 }; // bind to the form's submit event $('#myForm2').submit(function() { // inside event callbacks 'this' is the DOM element so we first // wrap it in a jQuery object and then invoke ajaxSubmit $(this).ajaxSubmit(options); // !!! Important !!! // always return false to prevent standard browser submit and page navigation return false; }); });

<form id="jsonForm" action="#" method="post"> Message: <input type="text" name="message" value="Hello JSON" /> <input type="submit" value="Echo as JSON" /> </form>

// prepare the form when the DOM is ready $(document).ready(function() { // bind form using ajaxForm $('#jsonForm').ajaxForm({ // dataType identifies the expected content type of the server response dataType: 'json', ,url: 'json-echo.php' // success identifies the function to invoke when the server response // has been received success: processJson }); });

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

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

同じ団体のバナーが先々週くらいにも出ていたのですが、この時とくらべて、画質が非常に悪いのです。
前回のバナーは、実はレクタングルの位置にはありましたが、その横幅のまま縦に長いものでした。形が違うのでレギュレーションが違うのかもしれませんが、普通に考えると大きいバナーの方が容量の制限は厳しいはずで、実際のバナーの画質はその逆になっているのです。

実は、これで思い出したことがあります。

とある会社のとある案件で、初めてのルートでのバナーを出すことになった際、他のルートでは問題なく受領されたバナー画像が、ある特定のルートでは拒否されたことがあります。もちろん、バナーが表示されるメディアが同じであれば、入稿仕様は同一です。

ではなぜこのような違いが生じるのかというのは単純な問題で、広告主が原稿をメディアに渡すまでの間には様々な人が関与する中で、この仕様が「規則」であるのか、「目安」であるのか、という解釈の相違が発生するのです。
「規則だからこれに100%適合していなければ受け取らない」という人と、実情を知って「だいたい合っているからとりあえず受け取る」という人の２種類の人がいて（前者は少ないとは思いますが）、互いに「ダメな人」「お役所仕事」と言い合っていたりします。

大手メディアサイトになればなるほど、1Byteの違いがネットワーク負荷にかかわってきますので、そういった面では、画像の容量を増やされると困ります。
しかし、広告としての面では、あまりにひどいクオリティの画像が画面を占めても、見た目として困るわけです。

ダメかお役所かという問題はさておいて、この相違によって影響を受けるのはまず広告主と広告を見る人、つまり「お客さん」と「お客さんのお客さん」になるわけで、この感じ自体がお客さんを無視した状態だなーと思う次第です。

仕様は当然のことながら容量をわずかに上回ることは想定されていたりもしますし、メディアは広告主のために、現時点での仕様が厳しすぎるのであれば拡張を検討する意志があります。
しかし、間にいる人たちが何も言わなければ、メディアが新たな広告スペースを作り出さない限りそのままとなります。Webサイトの場合はリニューアルするまでそのまま、ということになります。
仕様がアップデートされるのは、確かに仕事としてはめんどくさいことかもしれません。しかし、これもまた商売なので、逃げられるわけではないでしょう。

Webでの広告は、たとえば効果測定がきっちり数字で出るとか、一見システマチックに見えるにもかかわらず、実はものすごく人に左右されることがあって、しかもそれがそれほどお客さん（＝広告主＋そのお客さん）に得にならないことがあるので、その辺がアヤシげに見えてしまうところなのになあ、と思う次第です。