眠る開発屋blog ある開発屋の雑感。日々勉強。

2008/11/2 日曜日

「ブログ論壇の誕生」読了とか

Filed under: 書籍 — タグ: — dev0000 @ 22:54:34

読んだよ。面白かった。

ここ1年ぐらいの間に話題になったことをぼちぼち取り扱っていて、
とりあえず毎日新聞の海外サイト騒動まで。

年金問題のアフィリエイトの話やトリアージ論争は知らんかった。
結構、インターネットっ子なつもりなんだけどね。

ブログ論壇は成熟した公共空間になりえるか否か?ってことだけど、
これはもっと便利なシステムが出てくるかどうかってところなのかな。
まだまだ便利になってほしいなと思うことはたくさんあるし。
足りないが故に起こっている混乱も多いしね。

ただ、ブログで盛り上がる話題って、明確な敵が存在している場合だよね。
重要な問題というのは、解決すべき困難がそこにあるだけで、そもそもどこにも敵なんていない筈なのに。
「攻撃を続け優劣をはっきりさせる」のが目的ではなく、
「互いに間違った部分はあるかもしれないが、この困難をよい方向に導こう」
といったようにディベートのリテラシーが育てあがってくればいいのかな。
これだけあーこーだ言える環境も整ってきたのであれば、
多分うだうだやっている間に鍛えられそうな気もする。

ORマッパーとか

Filed under: 技術メモ — タグ: — dev0000 @ 18:48:32

RDBが扱いづらい問題はO/Rマッパーで解決できる?

思考ログということで過程の文章なのでしょうが。

スキーマを事前に定義しておかないといけない

運用中の案件においては、これはあまり意識したことがないなぁ。
確かにオブジェクトに比較するとスキーマ定義は柔軟性に欠けるのかもしれませんが、
平気でフィールドを追加したり減らしたりということをしている。
あとフィールドはなるべく緩く作るようにしている。
MySQLで言えば、単に蓄積させておくデータについては、特に長さ等は指定しない。
型はtextかintを使うことが殆どで、検索対象となるものだけ若干考える。

データ型として配列が使えない

そもそも RDB というものが複数の表を取り扱うデータ形式だからだろう。
おそらく配列型の値を扱おうとしたら、通常、正規化して別テーブルにするのが正解ってことだろうし、
単なる永続化であれば、配列ではなく、オブジェクトとしてなんでも入る方法を選択すると思うので、

この場合、一般的にはシリアル化(serialize関数)して文字列として処理→DBから取り出した後に復元(unserialize関数)(PC用語で言うと圧縮、解凍みたいなものですね、サイズは変わりませんが)という方法が採られているようですが、

ということになると思う。

プログラミング言語との連携が弱い

SQLを扱っている次点でDSLだからね。そりゃそうだ。

O/Rマッパーについて、

あと、最初にデータベース定義が必要なところはどうも解決してないっぽいですね。

ダック・タイピングというか型なし言語というか、
「実際にそのフィールドが必要となるまで、そのフィールドは定義されていたり明示化されていなくてもよい」
ということだろうか。
memcached とかグローバルなハッシュ配列という認識なんだけど、
それに表の概念と永続化の概念をぶち込めばそれっぽいのができるのか?
或いは、既存のRDBであっても、ラッパー被せてそれっぽいのを作ればよさそう。

初心者にとって、プログラム言語とSQL言語のバイリンガルにならざるを得ない状況があって、それがプログラミングの壁を厚くしているような感じがします。

SQLの学習コストって、
各種フレームワークのORマッパー操作を学ぶことに比較すればそれ程高くない気はするんだけども。
とりあえず、概要と主要な4つ・・・SELECT、INSERT、UPDATE、DELETEの使い方を覚えればいいかな。
そうであれば、2日(16時間)ぐらいあれば学習できるだろう。
教える人間のコストを加えたとしても、
前準備(16時間)と実際の講義(16時間)を追加しても、結局 6日(48時間)ぐらいで済むのではないか。
新入社員研修で考えれば、それ程時間を要するとも思えない。

更に言えば、
ORマッパーの仕組みについては、
多くの言語やフレームワークで共通したスタンダードなものが残念ながらまだ出現していない状態であるのに対し、
SQLは確かにDBごとの方言はあるにしろ、ほぼ統一された仕様である。
現行の技術に対する大規模なり小規模なりのパラダイムシフトが起こったとしても、
生き残る可能性は非常に高いし、学習に対する費用対効果は比較的高いと思う。

Webプログラム以前でもMSAccessやVisualBasicなどでORマッパー的な概念はあったのだが、
結局それらの仕様が変化し発展していったというよりは、
必要に応じつつ言語特性に合わせた形で出てきた気がするし、
プログラム言語のスコープで扱われる以上、都度新しいやりかたを覚えるのは致し方ないのかもしれない。
であれば、どこまで学習するか?というのはやや微妙。

専門職としてプログラマを設定するのであれば、
SQLはやはりどこかで時間などを投資して覚えておくべき技術だろう。
専門職でないならば、そもそもフレームワークを覚えようってところが「アレ?」な気がするし、
プログラム以外に学習すべきことも沢山あるだろうしそこに学習時間を投資したほうがいいんじゃねーの、とか、
「プログラマじゃないけどプログラムしなくてはならないんですよ」という状況であれば、
「専門職をスポットで雇えばいいんじゃないの?」とは思う。

だいぶ元のエントリの本題とはずれてしまったなぁ。。。
それでも ORマッパーを便利だからどんどん使おうよ!と思うのは、
個人的には、デバッグのしやすさというか、言語スコープで問題点を見つけることができるからかなぁ。

openpearとか

Filed under: 技術メモ — タグ: — dev0000 @ 0:48:58

オープンなPEARチャンネルサーバ
openpear.org

とりあえず参加した!

Powered by WordPress