2005年11月29日 火曜日

はてなブックマーク - なんでもかんでもExcel症候群

気がついたらこんな所にリンクを貼られてしまっているとは… 世の中恐ろしいものだ。今のところこの日記はblog的な要素(trackbackとかcommentとか)を持っていないことと、サーバの引っ越しをしたときに実行環境の差でBBSが動かなくなってしまったので、読んだ人の意見が取れない・・・(BBS自身は入れ替えたいけど、時間がねえ。) ちょっと悲しいが、まぁ良いか。
統計関係のワークシート関数のうちよく使うものだけは何とかしたいものだなあ・・・

2005年11月24日 木曜日

続・なんでもかんでもExcel症候群

Unixな機械からテキストファイルを直接持ってくると、改行がWindowsと異なるので、Excelで扱うのがちょっとめんどくさい。FTPできるときは、ASCIIで持ってくればDOS/Windowsなテキストファイルになるのだけど、世の中FTPできなくて専用のクライアントを共用されることもあって涙が出てくることがもうしょっちゅうあって困る。で、そんな_だめだめクライアント_に泣く泣くつきあわなければならないのだが、この際_なんでもかんでもExcelにお任せ_なのだ。
これからはASCIIモード転送のことは忘れて、すべてBINARYモード転送にしてしまいましょう。DOS/Windowsの世界ではUnixで作成したテキストは何行あっても、_たった1行のテキストファイル_と見なせるから、これを全部1つの文字列に取り込んで、ばらす方向で考える。ソースを示す。

2005年11月23日 水曜日

勤労感謝の日

今日は世間的には「勤労感謝の日」なのだが、僕の勤労を感謝してくれるような人なんていやしない。 働いていく上で襲いかかってくるのは、最近はソフトウェアなことしかやってないから、_ソフトウェア特許_とか_アイディア特許_だとかいった考えるだけでもうんざりするようなことしかありゃしない。ちなみに勤労感謝の日は皇室の新嘗祭にちなんだ祝日なので、_一般庶民の勤労を感謝している_と言う日ではないことを忘れちゃならない。

2005年11月22日 火曜日

なんでもかんでもExcel症候群

何でもかんでもPowerPoint症候群の弊害を日記で書いたのだが、それよりも世の中に広く広まっている病的な物と言えば、_なんでもかんでもExcel症候群_であろう。とにかく通常の表だけに飽きたらず、提出書類から報告書まで_何でもかんでもExcel_なのである。つまり「何でもかんでもExcel症候群」とはExcelだけですべての仕事が完結してしまう恐ろしい病気なのだ。
その病巣の由来を簡単に予想するとすれば、子供の頃に升目の入ったノートで漢字の書き取りをやらされ(つまりカーニングとかに無頓着になる)、読書感想文などの類は原稿用紙で書かされ、漢字は少ない文字数で情報量を詰め込めることからすっきりとした表が書きやすく、何でもかんでも_表にしないと気が済まない_という日本人の悲しい習性に由来する物であろうと思うのだ。
まぁUnixでEmacsしか使わないというのと似たような話ではあるのだが、典型的なEmacsユーザーが扱うのは汎用的なテキストファイルであり、Emacs LISPでがんがんプログラムを書く(設定ですらLISPを書かねばならないので、多少は誰でも書く物だ)人が多い用に思われる。Excelの場合は、XLS形式という特殊なフォーマット(最近のはXMLなのか?)を用い、適当なワークシート関数などを表層的に使いこなしている人が多く、Excelの基本技とも言えるピボットテーブルとかソルバーを使いこなしている人がどの程度いるかと問えば、結構怪しい物だ。
まぁ会社で働いているとこういう病的な世界と常に隣り合わせであり、いつも精神汚染を受けているのであるが、これを前向きに楽しむにはどうすればいいか? ということに焦点を絞り込んで生活しないとやってられないと言うことになるであろうか。
そんなわけでExcelをちゃんと使いこなすにはVBAで遊びまくればいいのであるが、テキストファイルとのつきあいもやめられない。Unixな環境に一度でも触れてしまうと、VBAのお気軽さを楽しんでいても感じる最大の問題点は_正規表現が使えない_と言うところがなやましい。これまで正規表現(とハッシュ)を使うためにVBAからだと駄目だと思い、Active PerlとかActive Rubyとか非VBAでCOMオブジェクトをさわれる言語を選択していたのであるが、書いたプログラムを使ってもらうのに_わざわざPerlだのRubyだのをインストールしてもらわねばならない_という痛い問題があった。Windowsで全然閉じていないのである。Mac OSXみたいにPerlとかRubyがインストールされていればこんなことは考えなくて良いのだが、PerlやRubyを使うのは_Windows的なやり方ではないのである_と言う結論に落ち着いた。
Windows的にどうすればいいのかと言う話なのだが、結局のところ現在のほぼすべてのオフィスにあるWindows環境で前提として良さそうな物は、Internet Explorer 6 SP2とExcelであろうと言うことになる。いろいろ調べているとIE5以降だと、WIndows Scripting Hostが使える。_まてよWSHにはたしか正規表現オブジェクトがあったぞ_と思い出して、さらにCOMで呼び出せるじゃんと言うことを思い出したので、一気にこの方面の悩みが解消した。要はWSHの正規表現オブジェクトをVBAのオブジェクトにしてしまえばいいのである。なんてこったい。こんなので数年悩んでたよ。とりあえず、あるディレクトリにある複数のファイルを選択して、そのすべてのファイルに、入力したパターンマッチをして置換を行うVBAプログラムを書いてみよう。

2005年11月17日 木曜日

「アルゴリズム+データ構造=プログラム」? 本当に?

福盛さんのプログラミングにおけるインターフェイスに関する考察。なかなか興味深く読ませていただいた。構造化の要件としての「アルゴリズム」と「データ構造」に加えて、プログラムになるには「インタフェース」も必要なのではないかという話。面白い視点だとは思うのだけど、はたしてそうなんだろうか?
プログラムという概念を考える際に人によってその規模が違うので、たしかに「アルゴリズム+データ構造=プログラム」というのは必ずしも自明ではない。(僕自身は「Σ(アルゴリズム×データ構造)=プログラム」ではなかろうかと思うのだけれども。) たとえば数行で記述可能な簡単なものから、Officeソフトのような大規模なものまで、どれもプログラムである。プログラムというものをどういうくくりで考えればいいのだろうか? 小規模なプログラムについては「アルゴリズム+データ構造=プログラム」と言う直感的な理解も可能であるが、福盛さんの考察は、構造化・モジュール化を進めた大規模なプログラムとなるとどうであろうかという論点であると思う。
僕はそもそも等号が成り立つような次元が同じ物ではないので階層化して考えたほうが自然だと思う。インターフェースやプログラムという概念は、「アルゴリズム」や「データ構造」のようなプリミティヴな存在であるか否か?という視点でかんがえたいのである。僕は「インターフェース」は「アルゴリズム」や「データ構造」とは同じ次元の存在ではなく、「アルゴリズム」と「データ構造」というプリミティヴな概念を演繹したようなもので記述可能ではなかろうかと思う。(公理論的アプローチなのかもしれないが…)
ではインターフェースというものをどう言う位置付けでおいておけばいいのかという話になるのであるが、インタフェースはその名のとおり、振る舞い(応答? 動作?なんて言うのかな)・データ・プログラム・外界との_相互作用_を考えた際にはじめて登場する概念だから、第1層目としてはアルゴリズム・データ構造、第2層目は第1層目の概念のみで記述可能であるインターフェース・プロシジャ・オブジェクト・プログラムというような階層的な理解でいいんじゃなかろうか? (プログラムを3階層目において置いた方がいいかな・・・整理悪いかも。)
ただしこれはプログラムの構成要素としてボトムアップして考えてみただけであって、実際のところプログラムが何でできているのかを考える際には実装詳細はどうでも良くて、インターフェースとその振る舞いが規定されていれば良いだけのような気がする。あとあの本はインターフェース云々以前の時代の本で、現代的なプログラミングとは若干の差があるのはあたりまえと思う。あくまで手続き指向な言語から構造化プログラミングへプログラミング・スタイルを切り替える提案をした本だという理解をすべきかと思うのだけど。ちゃんと読んでないから、なんとも。(Adaの本とかも今読むとふむふむと思うところはあるんだよねえ。Pascalに型総称性をいれてがちがちな仕様にしたらAdaになりそうだもんなあ。ただAdaにしてもPascalにしても好きではないな。)