さくらインターネットから、「ファイル数多すぎるんで削除してください」という連絡が来たのでなんのこっちゃと調べたら、 この間の設定変更で指定したセッションファイル格納用ディレクトリが溢れているという話らしい。おおっと。 でもって、話をよくよく聞いてみるとセッションが使用不可になったのも共用ディレクトリである「/tmp」に保存できるファイル数が10万ファイルまでに制限されているからだそうな。当たり前か。 本当のことを言うと、そう大したユーザー数がいるとも思えないサービスなのに溢れすぎじゃないかと思うけど、 設定を見返すのは後回しにしてとりあえず現状を改善しないと行けない。 よくよく考えてみて、「/tmp」ディレクトリのパーミッション的に階層化も出来そうにないし、 こりゃセッションデータをMySQLに格納するしかないかなと言うことで以下の設定を。
こちらの件に関連して。 [umbls] ログインできない不具合を修正しました。 – nplll 根本的な理由はさっぱり分からないのですが、なぜかさくらインターネットのサーバにてセッションが使用できなくなっていました。初めはプログラムのバグでログインできないんだと思って、自分が書いたコードやSymfonyの設定周りを洗っていたのですが、なんか何をどうやっても上手くいかない。それどころか、簡単なセッション処理のプログラムすら動かない。session_start()して、$_SESSIONを使って格納しただけなのに、保存されないのね。
<?php
session_start();
echo 'Welcome to page #2';
echo date('Y m d H:i:s', $_SESSION['time']); // 1970 01 01 09:00:00と表示されてしまう
?> | パーフェクトPHP (PERFECT SERIES 3) 小川 雄大 柄沢 聡太郎 橋口 誠 技術評論社 2010-11-12 売り上げランキング : 4615 Amazonで詳しく見る by G-Tools |
レンタルサーバではmemcachedなどを使用することが出来ないので、何らかのファイルキャッシュを使うことが多いと思うんですが、いくつかのサービスではPEAR::Cache_Liteを導入しています。
Cache_Lite
規模が大きくなるとI/Oがネックになるので、ファイルキャッシュはいずれ問題になってくるのですが、小規模なサービスであればこれで十分。
で、導入自体は極めて簡単なんですけど、気になったのはディレクトリ。UNIX系サーバでは1ディレクトリにおけるファイル数は10,000くらいなので、サービスを継続しているといずれキャッシュが作れなくなってしまう。でもCache_Liteの設定（インスタンス生成時にオプションを配列で渡す）ではディレクトリを渡すだけ。今は大丈夫だけど念のためディレクトリを構造化したいな…
と思ったら、ちゃんとその設定がありました。
マニュアルは細かく読まないとダメだね。
「食わず嫌い」とはアレなものでして、長いことPDOでfetchといえばFETCH_ASSOCと思ってたんですが、なんだよ、FETCH_CLASS超便利じゃん、と言うことに気付いたのでいくつか試行錯誤してみるなど。
まぁ便利さ言うならちゃんとO/Rマッパー使えこの野郎という話ですけど、設定が面倒なときもあってついあれなので…FETCH_CLASSとマジックメソッド使ってみたかった的なアレでひとつ。
RSSを始めとするXMLで使用できるる特殊文字の実体参照は、以下の5つだけです。 （何の定義も与えられていない場合）
自分でしっかり理解しているとは言い難いので自信がないけど一応メモ書き。
フレームワークを使わない管理から、俺俺フレームワークもどきに移行しかけていたのですが、そもそもフレームワークを設計する技量など無く便利な部分だけを抜き書きしただけ（autoload周りとか）だったので、これ以上カオスな状態にするのは止めようとフレームワーク導入を決定。導入するのは何にするかほんの少し考えたけど、CakePHPとZendFrameworkもよぎりましたが、CakePHPは複数プロジェクトを管理できないっぽかったし、ZendFrameworkは全然わかんないし、そもそもどれも解ってるとは言い難いので、仕事で使ってて少しはなじみがあるSymfonyを入れてみました（ただし、入れたのは1.4系。仕事で使ってるのは1.0系）。 インストールはここを参考にして、PEAR経由で。 さくらインターネットでsymfonyをインストール | ueblog
自信が無くてユーザー登録を使ったシステムの構築には二の足を踏んでいたのだけど、PEAR::Authを使えば比較的楽に構築できそうなので少し勉強して、作成中。作ろうかと思って結局止めたサービス（結果的にはPEAR::Authの試験実装になった）では、「新規登録→仮登録・メール送信→本登録」の流れや、ログイン・ログアウトのシステムまで構築できたので特に問題ないと思われ。
作ろうとしているサービスがあまりに小粒で、フレームワークを入れるほどではないと個人的には思っているのだけど、かといってなんもないのも微妙なので、フレームワークの中かのごく一部だけをかじったようなもの（つまりオレオレフレームワーク）をでっち上げてコーディング中（諦めてCakePHPでも入れなさいよという話ではある）。
試験実装の続きと言うことで、仕様が右往左往しており、いつになったら公開できるか全然未定で、そう言う意味で昨今のスピーディな開発の流れから完全に乖離したやるせない状況なのだけど（もしかしたら既存サービスのブラッシュアップになるかも）、まぁ趣味であって業務じゃないから良いかなという方向で。
最近のメーラーはUTF-8で受けれるよね、ってことで、メールフォームから自分が受けるメールについてはUTF-8でエンコードして受け取るようにしてみたのだけど、一部理解が足りずに上手くないことになってたのでメモしておきます。