悔しかったので翌日さっそく買い直し、再度チャレンジを試みるも、これまた失敗。マシにはなったもののホコリを起点とした気泡が…

と言うことで、3度目の正直でトライしたところ、今度ばかりは気泡も入らずようやく成功。
教訓として、保護フィルムを貼る時に気をつけるべき点をピックアップしておきます。

1. アクリルシートの様なちょっと厚みのある貼付補助シートがある物を購入する（安いのはシートだけしか無い）
2. （個人的には）スピーカー側から貼る
3. 貼り始めたら短時間でキメる
4. （大体の製品が）ちょっと気泡が入っても、貼り直したら大丈夫
5. 無風状態で（はいココ、テストに出るよ～）
6. 保護シートの上の保護フィルムはちょっと時間をおいてから剥がす

要は保護シートの説明書きを良く読んで、慎重かつ大胆に貼ればOkということなんですが…2回も連続して失敗する自分は不器用認定、ということで…orz

ちなみに項目1については、大体600円以上のシートがそんな感じみたいです。500円以下のは安さにつられそうになるけど（失敗するのを考慮すると思わず買いそうになる）、ピンセットでつまんで貼る位の気合いが無いと、接着面に指紋とかで失敗すると思います。
2は位置を決めやすい、3はオタオタしてると貼ってない箇所にホコリが乗る、5は3にも関連するけど空気の動きがあるとホコリが…ね。6は接着剤の成分が液晶面としっかり反応するのを待ってからの方が失敗無く剥がせるよってことで。

一応、3回目にして成功した時に使用した保護シートをご紹介。ちょっと切り抜き位置やサイズが甘めですが、貼りやすさ・気泡の入りにくさでは一番良かったです。

ページスラッグを利用してページごとのCSSを読み込むようにしていたので、ここで大はまり。で、ナニをどうやっても投稿ページで指定しているスラッグを引っ張れないので考えた案。

投稿ページを指定すると、そのページはis_page()がfalseになるので、（逆説的に）is_page() === trueの場合のみページスラッグを使ってCSSを指定し、falseの時は投稿ページと判断して、ブログ用のCSSを読み込ませる。

＃Ver2.7.1でのお話です。他にも別の解決策などあるかもしれません。

というかページテンプレートも指定できなくなるのは仕様なのか？

さてさて閑話休題。
既に稼働済みのシステムが内部エンコードはUTF-8で最後にShift_JISに変換して出力する仕組みをSmarty使ってやってた時、後から文字コードがEUCの別PHPを組み込んで下さい、とクライアントから連絡来た時に悩んだ時の記録。

クライアントからは
<? include("path/to/hoge.php"); ?>
を挿入して下さい、という連絡が。

Smartyには{include}というタグがあるので、文字コードが同じであればコレで行けたはず。
しかし今回はUTF-8で作ってあって、最後にfetchしてその出力をShift_JISに変換して最終出力するという荒技をやってたので、上記の方法を使うとUTF-8の中にEUCが入ってきて、それをShift_JISに変換するもんだから、もう何が何やら。DBとの絡みもあって、内部エンコードをEUCに変更するのはアレだし、DBからの変数をいちいちEUCに変更するのはもっとアレ。

ということで、この状況を打開すべく試行錯誤の末に辿り着いたのが以下の方法。

{include_php file="path/to/hoge.php" assign=output}
{$output|mb_encoding:"UTF-8":"EUC-JP"}
{include_php}のassign指定で変数に出力を突っ込み、その変数をSmartyの中で文字コード変換してUTF-8に揃えちゃう。これでテンプレートの中身がUTF-8に統一されるので後はウマー。

ちなみにSmartyのプラグインを作らないといけないので、
<?
function smarty_modifier_mb_encoding($string, $to = "", $from="auto")
{
if ($to == "")
return "";
return mb_convert_encoding($string, $to, $from);
}
?>
として、modifier.mb_encoding.phpというファイル名でプラグインディレクトリに保存します。

タブン別のもっといい解決策もあるかと思うけど、日曜の深夜に泣いた防備録として。

「地球が静止する日」を観てきた。良くも悪くもアメリカ映画。映像は面白いけど、内容は食傷気味な。やはり今年のNo.1映画は「おくりびと」ですよ、皆さん。

で、はまったはまったハマだショーゴ。

swfuploadを使ってアップロード部分を担当させ、複数のサムネイル作成などプロセッシング部分をclass.upload.phpにお任せする、最近のマイブーム的な作り方。さらにこいつらの駆動をAjaxで制御。

ということで、デバッグがやりにくい やりにくい。

サイズの小さい画像はすんなりアップロードされて、通常・サムネイル・モバイル用の3種類の画像を作成してくれる。が、ある程度の大きさ以上になるとアップロードはされてるみたいだけど、プロセッシングの所で落ちてる。しかもログを見てもエラーが出てない。マジまいっちんぐ。

ということでシラミ潰しの旅へ。
swfuploadは恐らく悪くない。デバッグモードをオンにしてログを吐かせてみると、特に問題は無い模様。

ということはやはり問題はclass.upload.php。
前述の通り、Ajaxで呼び出してるし$_FILEを与えてるのはswfupload。しかも途中で勝手に落ちるから、class.upload.phpが記録しているログも取れない、ということでトラップを仕掛けて途中途中でログをファイルに書き込ませるローテクで追ってみました。

落ちてる部分は、process関数のimagecreatefromjpeg。
ご丁寧に「@imagecreatefromjpeg」となってる箇所で落ちてました。

で、解決策。

php.ini の memory_limit を増やせ。orz

約4300×2900ピクセルの画像では memory_limit = 64 MB では太刀打ち出来ず。128 MB まで増やせば何とか乗り切ってくれました。
しかし、レンサバになるとこの部分がイジれる訳もなく。ということで根本的な解決策としてはアップロード画像を総ピクセル数で制限掛ける、という事か。

でもswfuploadにはファイルサイズ制限しかないので、file_size_limit に適当な値をセットしてお茶を濁すか、class.upload.phpでピクセルサイズ制限掛けるか。後者の場合、一旦アップロード完了を待たないと駄目なので、ユーザビリティや回線的にはNGな方向で。
サーバー環境やシステムの内容に応じて、値は調整してください。

で、Tips。
Flash　Player10に対応したSWFUpload ver.2.2.0ですが、ダイアログ呼び出し部をマウスオーバーでハンドカーソルに変えたい場合、
button_cursor : SWFUpload.CURSOR.HAND
だそうですよ。

SexyLightbox2（以下SLB）はajaxでhtmlを引っ張ってきてゴニョゴニョを勝手にやってくれるので、最近SLBどっぷりだしシステムにも組み込んじゃえ、と今作ってるシステムのフォームをajax駆使して表示してみたりしたらセキュリティの問題も（モロCSRF弱くなる）出てきて、対応策考えたり（ワンタイムトークン仕込んだり）で結構面白いことになってるんだけど、バッチリはまりましたよ、罠に。。。

入力フォームのtextareaにリッチエディタを付けましょう、とのクライアントとの会話。
TinyMCE組み込んじゃえばいいんでしょ？前にもやってるから余裕余裕。ajaxで読み込んだ後に仕込めばいいんじゃんよ？とか思ってたんだけど…

罠1。
Ajaxで読み込んだ要素に対してTinyMCEを適用させる場合、ちょっといつもとは勝手が違う。しかも最初に参照した記事は情報が古い…ということで調べた結果を覚え書き。

1. ページに以下のコードを組み込みますよ。これはいつものTinyMCE組み込みに似た感じね。
   tinyMCE.init({mode:"none"}) ;オプションなんかの設定もここでしておこう。
2. ajaxで要素を引っ張ってきてDOMツリーへ参加させちゃいます。例えばその要素の中に<textarea id="desc"></textarea>的な物を含ませておいたとします。
3. tinyMCEをそのテキストエリアに適用させます。
   tinyMCE.execCommand('mceAddControl', false, 'desc') ;第3引数で指定したIDをtinyMCEが探しに行って、その要素に適用してくれますよ。
4. で、編集やらなんやら終わった後に、追加したテキストエリアを抹殺してしまう前に
   tinyMCE.execCommand('mceRemoveControl', false, 'desc') ;として、解放してあげましょう。

ということだったんですが…

罠2。
SLBで読み込んできた要素が、どうもDOMにぶら下がってない？ちゃんと追加されてるかどうか調べるためにdocument.getElementById('desc') ;
で探ってもundefined…orz
タイミングの問題かと思って、色々トラップ仕掛けてみるもいっこうに罠に掛かってくれず。

ここで一旦ふて寝（シエスタ）して頭をリフレッシュ。今度はjQueryで要素を引っ張ってきてDOMへぶら下げてみる。

成功する。全く問題なく。

jQuery.ajax({
    dataType: 'html',
    url: 'get.php',
    function(data) {
        jQuery('#disp').append(data) ;
        tinyMCE.execCommand('mceAddControl', false, 'desc') ;
    }
}) ;

SLBはmootoolsがベースで、読み込んだ要素もmootoolsに処理させてるみたい。どうもそこら辺が原因らしい。

mootoolsのソースも読み解いていけば解決策が見えてくるのかもしれないけど、JSerでも無いしこれ以上本筋から離れた作業するヒマは無いので、ここいらで止めときます。
ついでに、SLB使ったり使わなかったり中途半端が気持ち悪いので、今までダイアログで開いてた箇所を全てjQueryで置き換える予定。

あぁぁぁぁぁぁぁぁぁぁぁぁorz

ま、気を取り直してダッシュしますか。。。

追記）
データ挿入にもajaxで行う場合、

var desc = jQuery('textarea[@name=desc]').val() ;

というのが効かなくなるので、

var desc = tinyMCE.get('desc').getContent() ;

とする必要があります。tinyMCEのバージョンが3.xの場合、

var desc = tinyMCE.getContent('desc') ;

です。

普段は小規模DBしか組まないのでER図も必要ない位で、頭の中でDB構築完結させてしまってるのだけど、珍しく中規模くらいになってくると説明にも使えるようにDBDesigner4とか使ってます。印刷とかも出しやすいし。

ということで、国産の使い勝手は如何に？

こんな物をみつけてしまいました。

値段も手頃だし、試しに買ってみようと思います。作業中に凝ってしまう肩にも効果的だったり、寝てる時の気道確保などにもなるそうです。アゴを動かすことで、首や肩の筋肉も連動するから血流が良くなり、肩こりしにくいんですって。
ただでさえ首ヘルニアが定期的に暴れてくれるので、こちらにも何らかの好影響が出てくれればいいのですが…

腐れIE6がっ！！！

IE6なんて世の中から消えてくれればいいのに。
と思いつつ、アクセスを見てみるとIEでのアクセスが45％。その中でIE6が55％…orz

みんな！FirefoxかChromeを使おうよっ！快適だよ？軽いよ？速いよ？使いやすいよ？IE6からブックマークのインポートも簡単だよ？なぜそんなに使いにくいかつバグ放置プレイブラウザを使い続けるのさっ！

誰ですか！PlayStation3でアクセスしてるのはっ！ｗ

ToDo：Windows Mobile ネイティブアプリのパノラマビューアーを製作。