Perl/PHPの最近のブログ記事

えー今日はメモです。 ポータルサイトにDBでデータを保持した訳ですから、次には当然検索機能を持たせるのですが、ここで複合検索で少しはまったのでメモしておきます。 正規表現で複数の半角スペースや全角スペースを１つの半角スペースに変換して配列にぶち込むのが味噌です。
SQLの部分もう少しシンプルに書けないかな。

<?php
if(isset($_POST["keywords"])){
$keyword = $_POST["keywords"];
// 変数$nameの値に含まれる全角スペースを半角スペースに置換して変数$keywordに代入
$keyword = str_replace("　", " ", $keyword);
// 変数$keywordの値の前後に半角スペースが含まれていた場合それを削除し、半角スペースが複数あった場合、正規表現を使ってそれをひとつに置換し、変数$keywordに代入
$keyword = preg_replace("/\s+/", " ", trim($keyword));

$array = explode(" ", $keyword);

$sql = "SELECT * FROM gym where";

foreach( $array as $val ){
// 検索条件を設定するコードをここに書く
$sql = $sql . " (name LIKE '%" . $val . "%' OR address LIKE '%" . $val . "%' OR open LIKE '%" . $val . "%' OR holiday LIKE '%" . $val . "%' OR price LIKE '%" . $val . "%' OR note LIKE '%" . $val ."%') AND";
}
$sql = substr($sql, 0, -4);
$sql = $sql . ";";

開発環境というよりは、ライブラリ・フレームワークの評価を行ないたいという事なんですが。
前の会社のしゃちょさんともよく何が最も生産性を高めるのに最適な選択（なんのフレームワークを使うべきか、いやそもそも使うべきか）なんだという事をあーだこーだ話し合ったのをよく覚えてます。前の会社では、今はなくなったMojaviというフレームワークを個人用にカスタマイズされたもので、ドキュメントも無い状態でいじる事になり、フレームワークの仕組みを覚えるのに、フレームワークの中身のソースを目で追うという信じられない、非効率な体験をした代わりに、副産物として、フレームワークの利用方法だけでなく仕組み自体を覚える事ができたのでした。
ただその時の体験はつらく、毎日頭を抱えていたので、フレームワークに対し、かなりネガティブな印象を持っており、そんなもの使わずに全部PHPの関数の組み合わせでやっちゃった方がいいと、まぁ今でも内心思ってます。
確かにフレームワークは一度覚えるのにかなりの負荷がかかる半面、一度覚えれば、その生産性は増し、特に大規模ポータルを複数人のチームでゴリゴリ開発する際は、もはやスタンダードな選択肢となっているようです。

長い前置きですが、システム・DBありの案件の打診を受けたので、下調べをしておこうかなぁと・・そういう訳です。
フレームワークを使うとすれば、Cakeに的を絞ってます。これがどんなもんか、まずは書籍でも読んでみます。
別にフレームワークを使わなければ作れないという訳でもないので、むしろ生産性・保守性が悪くなる可能性もあるし、その他のライブラリ周りもまとめて評価してみます

借りているサーバのリソースがかなり空いているので、利用したいと思い考えた末、
アイディアがまとまってきたので、ポータルサイトをたちあげてみようと考えています。
ビジネスをそこまで意識したものではありませんが。
なんのポータルかはまた、後日。・・・目新しいものではありません。

一昨日MindManagerを使い徹夜で整理した情報を元に、どの様に構築すべきか、
昨日は吉祥寺の本屋で立ち読み調査を敢行。
XOOPSやMovableTypeなどのオープンソースは、いまいち汎用的でないと判断し見送り、
得意のPerlもある程度大規模になると、いかがなものかなと思い・・
フレームワークやライブラリの充実したPHPでいく事に。

MVCのフレームワークを徹底比較している、良い書籍があったのでどのフレームワークを
利用するか比較検討。俄然CakePHPに惹かれるものの、MVCのメリットをそこまで体感
出来ていない為、結局PEAR＋Smartyのみでいく事にしました。

受託案件は、それはそれでやりがいのある仕事ですが、ポータルの仕様を好き勝手に
練れるこの時間はなかなかに楽しいものがあります。
ふわふわした段階でDBなどの詳細な設計に入ると後々、大幅な修正が入りかなりの
ロスになるので、アイディアをしっかりまとめきってから、設計に入りたいと思います。
（納期があるわけじゃないので・・・）

受託制作が優先なので、空いた時間を利用して完成の目処は3ヵ月後・・・。
開発の経過などを書けば、このブログの更新頻度も上がるでしょう。

CPANのライブラリ群の中から特にWEBクライアントライブラリを落としてきて、実際に動作を確認してみる。WEBの仕組みを再確認する意味でも、ビジネスに応用できるかを評価する意味でも有意義。

■HTTP::*
HTTP通信を扱う為の基本クラス群

■LWP
HTTPアクセスを司る

■WWW::Mechanize
ブラウザの挙動に準じたメソッド群→リンクを辿る、フォーム送信、前頁に戻るなど。他、Cookie操作を隠蔽。柔軟なロボット作成に便利。

■Plagger
・アグリゲータのフレームワーク
・各処理ステップをプラグイン機構化
・デコードなどの処理を隠蔽
・一般的な処理をプラグイン化
・定期的、定型的な処理に強い

■Gungho
・WEBクローラフレームワーク
・各処理ステップをプラグイン機構化
・HTTPアクセスを並列処理
・HTTPアクセス部分は隠蔽
・大量WEBデータ取得に強い

■HTML::Parser
・HTMLを解析する為の基本クラス群

■HTML::TokeParser
・SAX的なHTMLの解析
・1要素ごとにコールバック

■HTML::TreeBuilder
・DOM的なHTMLの解析
・HTML::Elementのツリーを作る

■HTML::TreeBuilder::XPath
・XPaｔｈによるHTMLの解析
・CSSセレクタを扱いやすい

■WEB::Scraper
・XPathによるHTMLの解析
・デコードなどの処理を隠蔽
・抽出結果の配列化を隠蔽
・初期化の設定は対象を指定するだけ
・プログラミングレスでPlagger的

ただのメールフォームを作成してFirefoxで動作検証問題なく、IEで検証したらエラー。

サーバサイドで処理するCGIなのになんでブラウザによって、結果が違うのかとまどっていたら、何の事は無い、IEのGETリクエスト時のクエリの長さの制限にひっかかっていただけの様でした。

いつのまにかメールフォームの入力項目が多くなって、クエリが長くなったんです。・・・ソースを追って損した。

URL に使用可能な文字数は最大 2,083 文字という事で、素直にPOSTで送信します。

関数単位だけど書いて残しておこう。
$attach　には作成したHTML形式のデータを格納

sub sendmail {
my( $mailto, $mailfrom, $subject, $body ) = @_;
open( MAIL, "| $sendmail -f $mailfrom -t" );

local $attach = "";
local $boundary = "-*-*-*-*-*-*-*-*-Boundary_" . time . "_" . $$;

### サブジェクトを jis にして、MIME エンコード
$subject = mimeencode( $subject );

### 添付するデータを、base64 でエンコード
$attach = &bodyencode($body, "b64");
$attach .= &benflush("b64");

#本文
local $message = "添付ファイルを開いて確認してください。";
&jcode'convert(*message,'jis');

########################## メールの組み上げ
### 全体のヘッダ
print MAIL "MIME-Version: 1.0\n";
print MAIL "Content-Type: Multipart/Mixed; boundary=\"$boundary\"\n";
print MAIL "Content-Transfer-Encoding:Base64\n";
print MAIL "From: $mailfrom\n";
print MAIL "To: $mailto\n";
print MAIL "Subject: $subject\n";

### メール本文のパート
print MAIL "--$boundary\n";
print MAIL "Content-Type: text/plain; charset=\"ISO-2022-JP\"\n";
print MAIL "\n";
print MAIL "$message\n";

### 添付ファイルのパート
print MAIL "--$boundary\n";
print MAIL "Content-Type: application/octet-stream; name=\"entry.html\"\n";
print MAIL "Content-Transfer-Encoding: base64\n";
print MAIL "Content-Disposition: attachment; filename=\"entry.html\"\n";
print MAIL "\n";
print MAIL "$attach\n";
print MAIL "\n";

### マルチパートのおわり。
print MAIL "--$boundary" . "--\n";

close MAIL;

}

最近ではPerlのCatalyst、PHPのCake、Ethna、Zendの参考書を
ザッピングしながら、作業効率／クォリティを飛躍的に高めては
くれないものかなぁと思案している訳であります。

結局フレームワークを導入する事の恩恵はよくわかるんですが、
それこそ大規模の案件とか複数人でとか、ずっと一つのフレームワークを使い続けるとかじゃないと、パフォーマンスを発揮する前に、覚えるだけでクタクタになってまう・・。

昔、他の人が作った完全オリジナルの自作フレームワークを使ってコーディングした時、フレームワークの挙動を調べながらの開発で能率が極端に悪くなったのを思い出す。

結局使いこなすなら、なんだかんだでフレームワーク自体のコード部分も追う必要あるだろうし。せめてデファクトスタンダードがあればいいんだけど、種類多いんだよなぁ。

今日はPerlでシステム開発をする過程で、過去につまづいた小ネタを。

レンタルサーバ等でPerlを用いてシステム開発をしている場合、レンサバにインストールされていないモジュールをuseで指定した場合、下記のエラーが出力される。Cron実行などでルートディレクトリが普段と異なる場合も、下記のエラーが出力される事がある。

Can't locate XXXX/Xxxxxxxx.pm in @INC (@INC contains:

そういった場合は、モジュールをCPAN等からダウンロードしてきて、プログラムファイル群配下のライブラリフォルダ(例：lib)に格納し、それもアップロードします。
あとは絶対パスでライブラリフォルダのパスを通せば、上記エラーは出なくなります。

use lib qw(/home/xxxxxxxx/xxxx/public_html/cgi/lib);