フレームワークというか

tech

デザインパターンとかフレームワークとか、大変興味を寄せている。
これら二つとも、言ってみれば
「どーせどのプロジェクトでもショッチュウ使う機構なんだから、あらかじめ作っておけばぁ？」
見たいなもんだと思う。

ま、そんな発想は古代からあるわけで当然なんだけど、でも改めて自分を見て「やってる？」と聞かれると、「ん〜」である。

やっていないと言えばウソなんだけど、やっていると胸張っていえるほどはやっていない。
これじゃイカンね。

今までのプロジェクトを考えたとき、少なくとも以下のカテゴリはほぼ確実に使用する。

  • 設定ファイルの読み込み
  • DB接続/切断
  • ログ集積
  • SQLによるデータ管理(INSERT/UPDATE/DELETE)
  • SQLによるデータ利用(SELECT)
  • cron予約
  • at予約
  • メール配信
  • リンクカウンタ(URLのクリック数収集)
  • 認証管理(管理者ページは管理者だけ！とか)
  • ダウンロード(よーあるのがデータのエクスポート CSVを生成しつつダウンロードさす)

生まれて初めてこんなの書き出した・・・。
確かにどのプロジェクトでも使う。これらはやっぱり雛形というか、パーツ作っておかないと
もったいないなあ。

時にメール配信なんて一言で言うとたやすいが、もうなけるほどおおはまりすることが多い。
というのは何気に
「携帯３キャリアにも対応させてくださいね」
なんていわれたときだ。地獄を見る。

キャリアにより、機種により、挙動が変わったりすることがあるのだ。
通常の日本語メールというのは、PCでも携帯でもISO-2022-JPを使えば大抵は文字化けしない。
が、意識をしないといけないのは、

上記二点をよく踏まえてから、メール送信部分で正確にiso-2022-jpにしなければ、化けるのだ。
当然と言えば当然だけれども。

だから内部コードを決めて(たとえば必ずeuc-jp + LFとか)、メール送信時には確実にEUC-JP→ISO-2022-JPにする、という手続きを踏んだほうがいい。私の経験則では、だ。

ということでこの部分もうまいことパーツにしておくといいかもしれない。
メールといえばお客さんによって
「このメールの送信に失敗したら、それをログに保存しておいて」
と、まあ簡単に言う人もいる。

これもまた難しい。
１通のメールをトラッキングすることは非常に難しいのである。というより、通常に送信しているならば、確実なトラッキングはできないだろう。
メール送信のエラーというのは種類が多い。メールボックスの容量が一杯だとエラーが帰ってくるし、もちろん無いはずのメールアドレスに送信してもエラーが帰ってくる。
しかもタチが悪いことに、送信した瞬間にはそれはわからない。数秒〜数時間、悪ければ数日後にエラーメールとして帰ってくることがある。

これをシステムで認識することは難しいというのは、察していただけるのではないだろうか。
このことについて言及を深めてしまうと、現在の会社の守秘義務に違反してしまうのでここまでとする。

言うは易し、行うは難しということを肝に銘じておかなければ、メールはなけますぞ。

ちなみにちょっと参考サイト

携帯にメールを送るときの注意点
http://bythebay.web.infoseek.co.jp/pc/mojibake70.html