いいシステム / 文章力 / 博士の愛した数式 / 得意科目、好きな科目 / プログラミングしてるときの自分 / COMのProdID - Adobe Illustratorの場合 / COMのProdID ‐Adobe Photoshopの場合 / バージョン命名規則 / いいシステム(2) / いいシステム≒シンプルなシステム / シンプルなシステム≠不自由なシステム / 今日の更新は過去最高回数かも

いいシステム

もう4年くらい前にPostgreSQLで構築したWEB/DBシステムがまだ動いている。

そのDBはテーブル数こそ少ない(10個くらい)ものの、メインとなるテーブルには毎日数百〜数千件のデータがインポート(INSERTおよびUPDATE)され、他のテーブルとの外部結合や全文検索を含むSELECT文が毎秒数回〜数十回走る上、同じくらいUPDATE文も走る。

その上、どうやら僕の手を離れてからはデータが溜まる一方らしく、メインのテーブルのレコード数は少なく見積もっても数十万〜数百万件にはなっている。

にも関わらず、未だにレスポンスに変化なく高速稼動しているPostgreSQLは本当に凄い。

DB設計/構築面で気をつけたことは下記の通り。

• EXPLAINで確認しながら適切なインデックスを作成。(重そうなSQL文に対しては特に念入りに)
• 毎日データ更新後にVACUUM。(PostgreSQL 7.xなので。8.xだとそんなに頻繁にやらなくてもよい？)
• 速度が優先されるテーブルは、あえて第三正規化を行っていない

データベースにおいて速度を決定するのはハードウェアとDB設計とDBエンジンだ。しかし、そのデータベースを維持するのは日々の運用だということを忘れてはいけない。日々、面倒を見るシステム管理者という縁の下の力持ちがいるからこそデータベースは動くのだ。システム管理者マンセー。

それはともかく、教科書通りのそこそこの設計と、いいハードウェアと、いいDBエンジン、それにいいシステム管理者に恵まれたそのシステムは「いいシステム」だと思う。

というのは開発者視点の自分が見た「いいシステム」。ユーザ視点での「いいシステム」はまた今度(といって書いたためしはないけど)。

文章力

起承転結もへったくれもない駄文を書き散らすこの文章力の無さをなんとかしたい。最近切にそう思う。思うだけではなんともならないので、できるだけ本を読むことから始めることにした。

博士の愛した数式

昨日から読み始めた。今190ページ。

今のところ一番印象に残ったのはルートの

「ママが博士を信用しなかったからだよ。博士に僕の世話は任せられないんじゃないかって、少しでも疑ったことが許せないんだ。」

という台詞。なぜだかちょっとだけ目頭が熱くなった。

得意科目、好きな科目

得意科目は数学だったけど、それは得意なだけで好きではなかった。今考えてみると、好きな科目は国語だったのかもしれない。

一学期が始まってすぐに国語の教科書を読み終わっていたし、他の教科の授業で暇なときには国語の便覧を眺めていた。小学生のころは図書室でルパンとかシャーロックホームズとか偉人伝なんかを読んでいたし、技術書しか読まないが未だに図書館には良く行く。そういえば、本を読まなくなったのは中学に入る前にパソコンを始めてからだ。

とはいえ、作文は何を書けばいいのかわからなかったし、古文漢文は読めないのでつまらないし(感情移入できるくらいに読めれば別かもしれないけど、「いとおかし」とか言われても感情移入できない)漢字も苦手で文法も面倒で嫌いなので、やっぱり得意科目ではない。

得意なことが好きなこと、なら良いんだけど。なかなか上手くいかない。

プログラミングしてるときの自分

プログラミングしてるときの自分は、よく「楽しそうだね」と言われる。

「得意」で「好き」だから？

多分、それほど「得意」でもなく、それほど「好き」でもないが、両者のバランスがいいんだろう。

COMのProdID - Adobe Illustratorの場合

Adobe Illustrator 9.0のScripting PluginによってインストールされるCOMのProdIDは「Illustrator.Application.1」。Adobe Illustrator CSの場合は「Illustator.Application.2」だった。

これって、たまたまその順番でインストールしたからそれぞれ「.1」「.2」になってるだけなんじゃ…。アプリ側から「Illustrator.Application」で呼び出すと9.0のCOMが使われる。

COMのProdID ‐Adobe Photoshopの場合

電波…とどいた? 200401 中旬より

PhotoShop 5.0 から COM コンポーネントだそうな。これ、インストールが適切にされてないようで、OLE View から TypeLibrary の中身が見れない(^^; タイプライブラリ自体はインストールフォルダにおちてます。 “Photoshop 7.0 Application” という名前のものがこっち。使い方は SDK に記述されてるとのこと。 Scripting Support をいれると、これとは別に “Photoshop Application” という名前の別オブジェクトが登録かかります。”PhotoShop.Application” というアプリケーション名はこちらが奪ってしまうので、旧版の COM でアクセスする人は、”PhotoShop.Application.7” とフル名でアクセスする必要あり。新版のフル名は “PhotoShop.Application.7.1” です。 Photoshop CS ではどうなってるのかな？

Photoshop 5.0なのにフル名は”PhotoShop.Application.7”で、Photoshop 7.0のフル名は”PhotoShop.Application.7.1”らしい。

“Photoshop.Application.7”というのはProgIDである”PhotoShop.Application.7.1”からデフォルトのバージョン番号「.1」を除いたVersionIndependentProgidである(ややこしい)ような気がするんだけど、COMについて不勉強なのでまだよくわからない。

バージョン命名規則

バージョン命名規則で思い出したのでメモ。

japan.linux.com | バージョン番号の衰亡

わかりにくいと思うバージョン番号

追記:よく考えたらどれもバージョン番号じゃなくて製品名なわけだけど。ま、いいや。

• Intel CPUのプロセッサナンバー
• Adobe製品のCS/CS2
• Macromedia製品のMX/MX 2004

Macromediaは最新バージョンになって番号に戻した。

マクロメディア「Studio 8 日本語版」はケータイやビデオなどに注力–RSSもサポート - CNET Japanより

「どのバージョンを自分が使っているかわからないなど、ユーザーをだいぶ混乱させていることがわかった。それからずっとバージョン番号を付与してきたFlash Playerのバージョンと、Flashオーサリングツールのバージョンとの混乱もあって、シンプルにすることがもっともいいと考えて単純にバージョン番号を付けることにした」（Guerard氏）

まったくもってその通りだと思う。というか「MX 2004」て。まぁ、製品名にも流行廃りがあるからマーケティング的にしょうがないんだろうけど。

でも、MacromediaはAdobeに買収されてしまった。新バージョンはMacromedia Dreamweaver CS3だったりして？(嫌杉)

いいシステム(2)

ぱっと思いつくそれぞれの立場の「いいシステム」

• ユーザにとっては「使いやすい」
• 管理者にとっては「手間がかからない」
• 経営者にとっては「コストが安くて効果が高くて、リスクが低い」

東証とか銀行などの金融系のシステムはわずかなバグがクリティカル。冗長性がないとリスクが高い。「ソフトウェアは二重化できない」というのは何か違うと思う。

いいシステム≒シンプルなシステム

いいシステム(2)を書いていて、昨日のKISSの法則を改めて考えてみる。

• シンプルならば使いやすい
• シンプルならば手間がかからない
• シンプルならばコストが安い
• シンプルならば(ちょっとの効果でも)効果が高い(と言える。ような気がする)
• シンプルならばリスクが低い(操作をミスる可能性が低いから)

効果については一考の余地あり。

シンプルの逆はポジティブな言い方をすれば多機能(なシステム)、ネガティブな言い方をすれば複雑(なシステム)、だろうか。それぞれに多機能を当てはめてみる。

• 多機能ならば使いやすい？
• 多機能ならば手間がかからない？
• 多機能ならばコストが安い？(間違いなく高い)
• 多機能ならば効果が高い？
• 多機能ならばリスクが低い？(もしかしたら、熟練のオペレータが様々な機能を駆使してリスクを低く・・・できるか？)

複雑を当てはめると明らか。

• 複雑ならば使いにくい
• 複雑ならば手間がかかる
• 複雑ならばコストが高い
• 複雑ならば効果は低い
• 複雑ならばリスクは高い(操作をミスる可能性が高いから)

追記：多機能と複雑はニュアンスだけじゃなく意味も違うな・・・。

シンプルなシステム≠不自由なシステム

シンプルを褒めすぎたので、シンプルなシステムの暗黒面(？)について考えてみる。

シンプルなシステムを作るのは難しい。なぜならば本当に必要な機能だけを見極めることが必要になるからだ。ユーザにとって必要な機能が一つでも欠ければ、それは「使えない」システムになってしまう。

だから本当に必要なものを慎重に検討する。設計段階においては機能を追加することよりも機能を削減することに時間をかける。あれば便利だから機能追加、というのは設計段階においては怠慢だ。重要なのは優先度。

先のエントリにおいて多機能、という言葉は適切ではなかったかもしれない。よりポジティブにとらえれば、機能が多い＝汎用的であるとも言える。

今日の更新は過去最高回数かも

今日の「いいシステム」から始まるエントリは20日23時から今(21日2:50)までの4時間で書いている。時間当たりのエントリ数としてはこのメモでは最高かも。さすがに疲れて最後のほうは今読み返しても「？」だ。