アーカイブ : 2012年 8月
VPSにqmail & vpopmail & clamd & spamassassinでメール環境を作っていたのだが
重い！メモリを大量に食う！
ので、他に何もできなくなる！
…ということで、一旦止めた。
/home/vpopmail/etc/tcp.smtp
:allow,QMAILQUEUE=”/var/qmail/bin/qmail-scanner-queue.pl”
↓
:allow,QMAILQUEUE=”/var/qmail/bin/qmail-scanner-queue.pl”
多分これでcdbを作成し直して、qmail再起動。
動いてるっぽいし、大丈夫っぽい？
今日は新規開発を一旦やめて、ソースコードレビュー。
とは言っても、開発者本人が別人になったつもりでプロジェクトを眺め返しただけの話だが…
しかし、成果はかなり大きかったかも。
ファイル構成やらファイル名やら関数名から定義名まで大量に手を入れたが、
おかげでパッと見で構成からどれが何をしているかまで格段に見やすくなった。
しっかり基本設計していても、結局開発中に様々な都合で仕様変更になって
その時に成り行きでやってしまう部分は、後で見返すと統一性に欠けていたり
システム全体から使う際の利便性に欠けていたりするようで。
そのあたりを時間をかけてじっくり調整することができました。
以後の拡張性についても検討したつもりだし。
うん、大満足。
勢いでガッツリ作ってしまうのも良いのですが、
こうやってたまに見返すのも良いもんですね。
…まぁ、そんなの土日くらいしかできないんですけどね。
・Modelもディレクトリに入れられる件
controllerに関しては、Routeさえ設定すれば
application/classes/controller/directory/filename.php
と設置できるよ、と書いてあるんだけど、
modelに関してはこういう記載がなかったんだけど…
普通に
application/classes/model/directory/filename.php
で問題なし。
で、ロードする際に
new Model_Directory_Filename();
としてやればよい。
・その際にORMモジュールで使用するモデルについて
例えば、application/classes/model/table/table.phpを
ORMで使用する、とかいう場合は、
orm.phpの_initializeと、factory の２つのfunctionに手を入れればOK。
initialize()
// $this->_object_name = strtolower(substr(get_class($this), 6));
$this->_object_name = strtolower(substr(get_class($this), 12));factory()
//$model = ‘Model_’.ucfirst($model);
$model = ‘Model_Table_’.ucfirst($model);
こんな感じ。
おかげで非常にディレクトリ構成がすっきりさせられた。
うん、どうせMVCモデルにするならここまでやりたかったんだ。
大満足。
色々やってみたのだが、結局kohanaのRequestクラスでは
ユーザーエージェントを変えたり、レスポンスコードを受け取ったりすることが
できないので、PEARのクラス名などを書き換えることで対応。
class HTTP_Request → class PEAR_HTTP_Request
function HTTP_Request → function __construct
同じく、HTTP_Responseに対しても同様の処理をして。
require_once Kohana::find_file(‘pear’, ‘HTTP/Request’);
error_reporting(E_ALL & ~E_NOTICE & ~E_DEPRECATED & ~E_STRICT);
$req = new PEAR_HTTP_Request($url);
って感じにしたら、無事に動いた。
まさかPEARとkohanaでクラス名の衝突があるとは。
それでこんなくだらない時間を割くことになるとは。。。。。
なんかもう、こういう事もあるのかと…
PEARのHTTP/Requestを使用して作ったプログラムをベースに
kohanaに実装し直そうと思い…
require_once “HTTP/Request.php”;
の代わりに、
require_once Kohana::find_file(‘pear’, ‘HTTP/Request’);
にして。
kohanaがシステムでerror_reportingを自動で書き換えてるので、
error_reporting(E_ALL & ~E_NOTICE & ~E_DEPRECATED & ~E_STRICT);
と入れてDEPRECATEDではじかれるのも対応して、
$req = new HTTP_Request($url);
でうるさく言われたから
$req &= new HTTP_Request($url);
にしても、別のエラー出てきやがって、
なんじゃこりゃー！？
と思ったら、kohanaの中に既にあるのね、HTTP_Requestっていうクラスが。
とりあえず、ここでPEARを使用するのを断念。
面倒だけど、全部
$request= Request::factory('http://example.com/post_api')->method(Request::POST)->post(array('foo'=>'bar','bar'=>'baz'));
$request= Request::factory('http://example.com/put_api')->method(Request::PUT)->body(json_encode('the body'))->headers('Content-Type','application/json');
あー、もう。
悲しい限りだ。。。。。しっくりくる部分と、しっくりこない部分が。。。。。
・しっくりくる部分
SQL関係は書くの楽ですね。
ORMモジュールを使っていても、
$datas = ORM::factory(‘table’)
->where(‘hoge’,’!=’,’abc’)
->order_by(‘id’,’ASC’)
->find_all()
;
とかやってやれば、
SELECT tables.* FROM tables AS table WHERE hoge != ‘abc’ ORDER BY id ASC;
ってなってくれますので。
SQLの組み立てが直感的に楽ですね。
というか、結構便利なモジュールが揃っていて助かります。
Auth、ORM、paginationは即使用可能でした。
cacheはちょっと実感沸かないのでスルーです。
Authも実装まで少し時間かかりましたが、まぁかかったと言っても２～３時間ですか。
「実際に認証させる部分」のSQLさえ書ければ、あとはロジックを組むだけですので。
いやぁ、これ結構便利ですわ。
くっだらないトコロに気を取られて結構時間を食ってしまった。
・タイムゾーンの設定とか
application/bootstrap.php内を編集。
date_default_timezone_set(‘Asia/Tokyo’);
setlocale(LC_ALL, ‘ja_JP.UTF-8’);
I18n::lang(‘ja’);
としてみた。
…まぁ、I18nに関してはja.phpが存在しないので意味がないというか、
そもそもI18nができたところで、普及に必要なのはL10nだったりM17nだったり
するのだろうけれども。
…普及というか、今の自分に必要、というか。ｗ
とりあえずタイムゾーンの設定してやるだけで、ログの表示時間がしっかりするので
開発する気になるというもんです。
・mod_rewrite
とりあえず、デフォルトで置いてあるsample.htaccessをそのままリネームして
.htaccessとして使用。
これでURIの中にindex.phpが入ってしまう不格好から開放される。
さて、開発はじめましょうか。
・FuelPHPについて
なんか書籍も出ていて相当流行っているみたいですね？
CI後継というかCI開発者が携わっているらしく、 使い勝手も近いみたいですね。
インストールもコマンドラインが使える&sudo権があるなら楽勝みたいですし
結構興味はあります。
なんといっても日本語で情報が山ほど出てきますし。
kohanaでやってみる予定の案件が終了したら手を出すかも？出さないかも？
といったところです。
私的には、○○出版社さんから書籍を出されている方のお名前を拝見して
ビビりましたが。
だってCI徹底入門書いてる方なんですもん。。。。。
テンプレートエンジンはBlitzにしようかとも思ったんだけれど、
PECLを使わないといけない手前、レンタルサーバでは使えないので
何か適当なテンプレートエンジンを使おうかと思ってます。
それはさておき、kohanaのインストールについて。
手順はいたって簡単で、公式からzipをダウンロードしてきて
解凍して中身を公開ディレクトリにアップする。
で、そのまま公開ディレクトリ内のindex.phpにアクセスすれば
Environment Tests（環境試験）が始まる。
例えば、Cache Directoryのテストに対して
The /home/xxxxx/public_html/application/cache/ directory is not writable.
みたいにエラーが出てくれる。
当該ディレクトリに書き込み権限をあげないといけないわけだ。
Your environment passed all requirements.
Remove or rename the install.php file now.
という表記が出ればテスト的にはOK。
install.phpを削除かリネームすれば、kohanaがちゃんと稼動してくれる。
あとはOptional Testsについて。
PECL、ｃURL、mcrypt、GD、MySQL、PDOは追加機能で使うから
これも使用可能かどうかチェックしてくれる。
暗号化やら画像処理やら必要であれば、それぞれ確認しておくと良いかと。
導入時のサーバ側のテストとしてはかなり優秀ですね。
まぁ後は基本的なMVCモデルの通りに組んでいけばOKです。
modelはapplication/classes/modelに、
viewはapplication/viewsに、
controllerはapplication/classes/controllerに、
それぞれphpファイルを設置していきます。
超基本的な部分としては、こんな感じですか。
さて、modelにtraitを使ってどんな楽しい事ができるのか…
楽しみです。
新しい案件が決まりかけたところで、そろそろ会社としてメインで使用する
フレームワークを決定すべき段階に来たのかなと考えてみました。
今まではPHPでベタ書きしてしまえば良いや、というスタンスでやってきたのですが
（いかんせんボリューミーな案件がそんなになかったので）
業務を安定して処理していく為に、少しずつ地盤を作っていかねば、ということで。
元々、会社員だった頃は「自作フレームワーク」に縁があり、
その会社さんが自作したフレームワークを使用する、という事をいくつかしたのですが
いかんせん
・その業務に特化したフレームワークになる
・習得にもその業務特有の知識を要する事が多い
・フレームワーク製作者のスキルレベルが反映されてしまう
・コーディング以外の事が考慮されているか疑問（負荷、処理速度など）
など、良いことも悪いこともあるわけでして。
いっそのこと、何か社内メインフレームワークを制定してしまおう、と思ったわけです。
まだ弊社はどの分野にも特化する必要がない立ち位置ですし、MVC、OOPを生かせるような
フレームワークであれば、その後の別の言語への発展も楽かもしれませんし。
とりあえず、CakePHPやSymforny、Zend Frameworksなど候補はたくさんあるのですが、
私的に縁があったCodeIgniterに手をつけよう、と思っていました。
が、やめました。
PHP5でやりたいし、せっかくtraitも使えるPHP5.4を用意したのですから…
ということで、CodeIgniterの派生である「kohana」を使用していこうかと思います。
まだ未インストールですが、ネットでサクッと調べてみた限りの長所と短所を。
長所
・CodeIgniterベースでPHP5完全対応
・CIの知識がそのまま生かせそう
・一応サンプルコードもついている
短所
・CodeIgniter同様、テンプレートエンジンが存在しない
・日本語系のドキュメントがほぼ全く存在しない
ドキュメントに関しては、いずれ自分が書けるくらいまで成長すれば良いので
（ちょっとポジティブ過ぎでしょうか…。まぁでもこれくらいじゃないと。）
CIの知識だけで何とか行ってみようかと思います。
Kohanaについては、このblogか、他の場所になるかもしれませんが…
少しずつ書いていけたら良いなと思います。
mono-lab様のmonochromeを使用させて頂きました。
すごく記事自体が見やすく、素晴らしいデザインだと思います。
ありがとうございます！
laboは当分このデザインで行くと思います。。。
WPのデザインを作る労力が、今の私には惜しいのです。
そしてデザインは超苦手なのです。。。。。