眠る開発屋blog

例えば、社内の通常業務として、社員１人が１ヶ月に１つWEBサービスを立ち上げるのを、
R&Dの一環として強制的に行わせている会社があるとすれば、1年後にはどうなるか。
社員が１０人いれば１００個WEBサービスが立ち上がるわけだが、その中から当たるものが幾つか出てきてもおかしくない気がする。

サービスなんてそれくらい気楽に立てればいいのだ。
考えるな、感じろ、そして作れ。
業務計画を立てる時間が勿体ない。
なぜならその間に陳腐化してしまうかもしれないから。

新しい方法論とか技術とか嬉しくなって飛びつくのは分かるけど、
余裕のない案件に導入するのはどうかなって思うよ。

お医者さんにも、
新しい治療方法をどんどんやりたがる人と、
古いけど割りと信用性の高い治療方法を行う人の２通りあって、
それぞれ一長一短なんだけども（後者はリスク回避）、
新しいことを取り入れたからって何かがすげー変わるっていうのはマレなんだし、
あまり期待満々に人に話すのもどうかと思うよ。

というかね、
やっぱりR&Dと通常業務の領域をどこかで意識しつつきっちりと分けなきゃダメだな。

DBのコネクションプーリングって、（接続コストの遅さという）スペックの限界をロジックで乗り越えるという点で、
なんだか一昔前のカラーパレットアニメーションと同じ匂いを感じる。

ってことはそのうちなくなるってことか。
そもそもC/S全盛の頃はこんなテクニック一般的じゃなかった気がするんだけども。
なんだかDBベンダーが本来努力すべき部分が押し付けられて今に至っている気もするんだけども。

列項目数がマチマチだったり、
相関関係がグダグダだったりするオブジェクトとか見て、
「正規化したのをまんま列に落としても意味ねーから、丸ごとシリアライズして列に入れてしまえよ」
っていらいらすることありませんか。

シリアライズLOBパターンっていうらしいです。
オブジェクト内の属性に対し、検索がかからなくなるのが痛いですが、
逆に検索する対象項目でなければそれはそれでいいってことです。

とりあえず、PHPだと、serialize、unserializeっていう関数があって、
オブジェクトをDBにぶち込むのにたまに使用されている。

オープンソースのphprojektでも同様の手法が用いられてる箇所がある。
確かユーザ設定をsettingsという列に丸ごと突っ込んでいたハズ。

Jemplateがちょっとした話題になっているみたいだけど、JKL.Hinaなんてのもあるよ。

JKL.Hina は JavaScript 用のテンプレート展開ライブラリです。
HTML ページ内に予め用意したテンプレートと、JSON なデータを与えて
テンプレート展開処理を高速に行います。
DOM を利用しているため、今のところ300行弱とソースも短いです。

AjaxPagesなんてのもあるみたいだし、JavaScriptテンプレートライブラリって結構あるみたいだね。

２、３年前の話。
某システムの打ち合わせで駆り出されたのだが、
そのシステムを構築した大手SIerも会議に参加していて、
色々とそのWebシステムの留意事項や疑問点などをあーだこーだと指摘したことがあった。

彼らはシステム構築自体についてはしっかりとした考え方（少なくても当時の自分よりかは優秀）を持っていたと思うけど、
それでも色々と指摘するポイントがあったのは多分Webに不慣れだったのだな、きっと。

で、会議も終わりのときに彼らのリーダっぽい人が言った言葉。
「今後とも色々と教えてください。宜しくお願いします」

大企業所属の人達特有の「余裕感」のなせる業かもしれませんが、
（本音は違うかもしれんけどそんなことは関係なくて）
こういうことをきちんと言えるのは技術者･･･ってかビジネスマンとしてものすごく偉いなぁ、と思いました。

というか、人の「持っていること」に対し、敬意を払うポーズすらしない技術者が如何に多いか。
「知っていても知らない振りをする」重要性を学ぶべき、だとは思う。

（こういうのに美徳を感じるのは日本人だからかな。でもリップサービスが重要なのは万国共通な気もするけど）

個人的にちょっと違うかなぁ、と思うけどよく見ること。自分の考えが間違っている可能性も高いけど。

• DBはとりあえずなんでも論理削除。
• テーブル名は日本語。
• WEBのコンシューマ向けエラー画面に平気でシステムエラー番号を出す。
• ApacheチューニングだったりSquidなどプロキシキャッシュの採用とか考慮せず、メモリの効率化でなんとかしようとする。
• 一度動いたシステムは止められないと最初に設計しつつも、改修の時はシステムを止めてもらうことを期待する。
• なんでも一つのシステムに閉じ込めようとする。口が裂けても「その機能はExcelで十分ですよ」とは言えない。
• 「SELECT * FROM 〜」はデータの転送量が増えるのでとりあえず禁止。
• オブジェクト指向だと継承が大好き。
• コンシューマ向けWEBシステムのURLがやたらと複雑。
• なんでもかんでも設定ファイル化する。
• なんでもかんでもDBかする。
• っていうか、ソースに「データ」が混じることを極限まで嫌う。
• 再利用性を高めるが故に視認性の極めて悪いソースを書く。
• どんなにロジックが複雑でも、関数にはreturn文が一個しかない。
• システムの解は常に一つしかないと信じている。

Livedoorと東証を比べるのも可哀想とか読んでふと。

世界が違うとはいえ、Livedoorやはてなの身軽な開発で行われた官公庁システムや基幹系システムなんかも見てみたいなあとか思ってみたりもする今日この頃。

WebとSIerの領域侵犯が激しくなってきて、
SIerの方法論のほうが強いのかな、と思っていた時期もあったのだけども、
どうやら全くもってそうではないらしい。

Webシステムとは、実は運用体制も含めての品質管理なのだが、SIerは完全に後手後手に回っている印象がある。
（東証システムも「トランザクションの上限値の予測不可能なCSシステム」ってことで旧来型よりも実はその性質はWebシステムに近い気がする）
別の言い方をすれば、SIerが本来得意としてきたであろう「初期開発」というビジネスモデルは全くもってそのWebの構築というスタイルに対応しきれていない。

「イノベーションのジレンマ」で取り上げられる多くの事例と同様の現象が発生しているのでは。
よく聞く話だけども「予算が割に合わない」ということで、Webシステム構築等は大手SIerが手を出しにくい領域になってきてる。
LightWeightな言語を得意とする会社などはそういった業務をフックにして、どんどん自分達の「方法論」を拡大させていっているのだろう。

「3年で陳腐化するWebサイトの構築には軽量言語のほうが向いている」

まぁその通りなんですが。

とりあえずシステムがリプレースされる理由。

• ビジネス要件が変わったから。
• ハードやOSのバージョンアップに合わせて。ベンダーのサポート期間も終わっちゃったし。
• 担当が変わったから。

「担当が変わったから」っていう理由が意外と多い気がする。
新任のシステム担当がまず第一にやることって、まず過去のシステムを徹底的にこき下ろして、
「自分が担当になったからにはより素晴らしいシステムにしますよ」的なものじゃないですか。
そういう話をもう何度聞かされたことか。

WEBサービス（HTTPプロトコル）ばかりもてはやされる今日この頃ですが、
メールプロトコル（SMTP)もまだまだ便利に使えるとは思う。
ニワンゴなんてのもあるしね。

ということで、maildo.phpというメールによるちょっとしたタスク管理ツール。

動作内容

1. あらかじめ予定等を登録する必要があるので、
   １行目が「YYYYMMDD」または「MMDD」で２行目以降に予定を書いたメールを該当するメールアドレスへ送信して登録する。
2. 登録済みの予定を全て見たい場合、「a」とだけ本文に書いたメールを送る。
3. 今日の予定を見たい場合、「n」と本文に書いたメールを送る。
4. 今日以降の予定を見たい場合、「f」と本文に書いたメールを送る。
5. また、通知サービスとして、定期的にあらかじめ登録した予定を通知するメールが届く。

設定方法

1. 適当なレンタルサーバを借りる。
   さくらのスタンダードプラン(月額500円)とかで動かすのをとりあえず前提にしているが。
2. PEARのMail_mimeを使える状態にしておくこと。
3. 受信専用のメールアドレスをひとつ作っておくこと。
   更にそのメールアドレスにメールが来た時、プログラムが動くように、.forwardとか.mailfileterに設定しておくこと。
4. 通知サービスが欲しい場合、cron等に’php q maildo.php send’と設定しておくこと。
5. 適当なデータディレクトリを作っておく。
6. 環境に合わせてソース内のメールアドレスとかデータディレクトリの名前等を変えておく。
7. ソースをサーバに配置する。

考えてみなきゃいけないこととか

1. 一応送信元メールアドレスのチェックはしているが、･･･ヘッダーって偽装できるからなぁ。
2. 携帯メールにどこまで対応できるかはやってみなきゃ分からない。絵文字とか。
3. 時分まで対応したほうがいいんだろうね。

っていうか、200行もないんで、ソース解読したほうが早いと思う。
単機能なだけあって、そんなに難しいこともやってないし。