Excel

.NETの呼び声

最近、VBAでのプログラムにほとほと嫌気がさしてきたのであるが、お仕事関係ではMicrosoft WindowsというかMicrosoft Officeの呪縛を逃れることは出来ない。それ故プログラム環境としてVisual Basic for Application(VBA)を使うことになるのであるが、不満は多いので使っていてなんだかだめだめだなぁと思うことを列挙してみよう。

• _必ずExcelやWord文書の付録_みたいなものになる。文書を開くときに何となく厭な気分になる。(回避法はあるけれど。)
• 当然コードの_履歴管理をするのが大変_。(何が楽しくてVisual Source Safeを使わねばならないのか。頼むからCVSやSubversionを使わせてくださいな。)
• 正規表現が使えない。(がーん。 かなり不便。)
• 正規表現を差し引いてもテキスト処理がいまいち。(変形CVSなテキストを読むのがもう大変。)
• しょっちゅう関数の名前がだぶる。(名前空間をサポートしてくださいよ。僕のボキャブラリが寂しいだけ?)
• 使えるデータ型が_恐ろしいくらい貧弱_。(未だに基本な型と構造体と配列くらいしかなく、ハッシュやリストのような現代的な言語でサポートされているデータ型は_当然ない_。)
• クラスは作れるが、継承は出来ない。(勘違いしている人は多いけれど継承はOOPの必須事項ではない。)
• スレッドって何だっけ?
  という具合で、結構痛いところが満載なのである。そこまで使い込んでいるんだったらVisual Source Safeというか、OfficeのDeveloper Editionを買えばいいじゃんと言う意見もあろうが、僕はお仕事のためにわざわざOffice Developer版を買うほど酔狂な人間ではありません。 ちなみに家のPCにはOfficeをインストールしてません。家に帰って_Excelのアイコンを見るのも厭です_。ということで、会社で買ってくれないものを使う気にはならんのです。
  かといって、Windows Scriptの上で動く現代的なスクリプト言語であるActivePerlやActiveRubyは、_デフォルトでインストールされない_ということもあって、プログラムを使ってもらうという前提の開発では、管理が発生するためにメインの言語として選べない。(ExcelはどのPCでもバージョンは同じであることを前提に出来るが、PerlやRubyのバージョンなどの管理は職場で誰がするの?)
  ひょっとしたらVBA自身は、Office2003でVB.netのような言語の現代化が行われるのではないかと多少期待したのだけど、VBA自身はVBA 6.3から6.4にアップデートで余り変化はないみたい。(がっかり。 まぁ無論会社ではOffice2000までしか使ったら駄目ということになっているので、Office2003は使えないのだが。)
  という状況で、なんだか良い解法は無いなぁと思っていたのだが、先日のTCP/IP勉強会で、PostgreSQL方面の高橋さんより、「そういう話なら、.NETが良いよ。」という話を聞いたので、早速試すことにした。
  よく.NETのページを眺めていると、.NET Framework SDKには、コマンドライン版のC++とC#とVBのコンパイラが付属してくるのね！ てっきり、C#やVB.netで遊ぶにはVisual Studio .NETを買わねばならないのかと思っていたのであるが、僕が組むプログラムの規模ではVisual Studioには手を出さなくてよさそう。
  ダウンロード・インストールをしている間にWebをさまよえば、_フリーの統合環境は転がっている_もので、Javaの開発環境から進化して、C++やC#やPerlやRubyやXMLなどの編集が行えるJavaで書かれているEclipse(エクリプス)や、C#の開発環境に特化しつつVBの開発環境にも使えそうなC#で書かれているSharpDevelop(SharpDevelop-JP)といったオープンソースな環境が出回っているので、なんだか簡便な開発環境が整いそうである。
  今日はつらつら.NETのドキュメントとC#やVBのサンプルソースを眺めているわけだが、眺めているだけでも上記の問題は解決しそうである。例えば順に並べるとこんな感じ。
• ソースコードは_ただのテキストファイルになる_(当然)
• 当然コードの管理にCVSやSubversionを使える。
• Microsoft .NET Framework ではPerl5のような正規表現がサポートされている。
• テキスト処理はようわからんが、コンソールアプリを書けるからたぶん大丈夫でしょう。(調査中)
• 名前空間をサポートしている。(僕のボキャブラリが寂しくても_安心だ_。)
• コレクションクラスが_充実している_。(ハッシュもリストも_当然ありますよ_。)
• VBでも継承ができるようになった。(VB7からは継承が出来るようになりました。)
• スレッドを考慮したプログラムも当然書ける。
  という具合。ガベージコレクションもしてくれるのですか。メモリ管理関係も結構楽になるのかしら… しばらく眺めて勉強してみることにするが、MSと仲良く付き合うには、_過度の期待はしない_ことと_仕様はどうせすぐに変わるもの_と思って、_適当に勉強すること_と言うのが重用である。どうせ勉強しても長く持たないバッドノウハウだらけになるに決まっているのだから。
  今日の日記はリンクをいっぱい付けてみた。疲れたなぁ。

今日のVBAとの闘い

前回のVBAとの闘いでは、Cで言うところのsscanf()みたいな関数がないので、テキストファイルからの入力は不便じゃのうという話だった。普通のExcelのユーザ(VBAを使いこなしている人はすでに_普通の人ではないと言う意見はあるが_)は、CSVなファイルもExcelで開いてから、VBA側でセルを参照して値を取り出すのかな? 僕はそういうデータ構造を考えないプログラムを書く趣味を持ち合わせていません。
今回の闘いは、まともにCollection系のライブラリが欲しいという話。ちょっと考えてみると、文字列をKey、構造体をValueとするHashを使えれば、一発でおしまいという話だったのだが、VBAやVBっていまいちCollection系のデータ構造がまるでないので、いかんせんいろいろと貧弱すぎだなぁと思うのよね。結局配列で非常に安直な実装にしたのだが、どうにかならんもんかね。VBプログラマはデータ構造なんて考えてプログラムをしないのかねぇ。で、あらかたプログラムを書いた後に、

プログラムを書く時って…

自分だけで使うプログラムを書く時は適当に書き始めるのだが、僕の場合、お仕事でプログラムを書く時は最初の1行目を書き始めるまでの時間が異様に長い。今後の保守性だとか、環境の持続性だとかに縛られるので。MSさんがもうちょっと後先考えてくれれば良いんですけれど。ころころ変わりすぎて、MSのツールを投げ捨てたいんだけど…
VBAはこれまでさんざん書いてきたけれど、個人的にはかゆいところに手が届かないので悩ましいのであるが、さらにExcelやWordの文書の中に入っちゃうので、ソースの履歴管理に問題があるので、あまり使いたくないのです。ただIDEはMS-Cのころからこんな感じなので、それなりに使い慣れているせいか、悩ましい存在だったりする。(オブジェクトのメソッドやらプロパティを打ち込むのもめんどくさいので、あれだけ補完入力が効いてくれると便利なので。)
ということで、今日はこれから書くプログラムのデータ構造を決めるのに結構な時間を要し、とりあえず基礎の部分を作って1日おしまい。スロースタータなんですねぇ。
ちなみにMSのツールを捨てられないのは、よけいなインストール作業を繰り返すことになるからなのね。少なくともExcelはどのPCにもインストールされているので、これになかなか勝てないのです。

GNU R

まじめな統計計算を滅多にしないので、Excelで十分かと思っていたが、ずいぶん前から直らないバグが結構あり、場合によって_Fatal_なので、Excelでの統計計算にあきれていた。かといって、proprietaryな統計計算パッケージ(たとえばSとかS Plusとか)は非常に高価で入手不可能であるため、Excelを我慢してうまく使い続けてきたが、GNUのSとも言うべきRの日本語化が結構な勢いで進んできたので、これはしたりと思ったわけである。Rって何?と言う人もいると思うので、以下にR Projectのページに載っている説明文を載っけてみる。

今日は一日中データ解析に励む

今日は地震のあとに収集した装置のデータ解析に励んだ1日だった。(正確には昨日の夜からやっているのだが。) 地震のようなクリティカルな状況に追い込まれると、通常の解析手法に付加価値を付けてよりやりたかった解析の手法を思いつくのだから、追い込まれると結構いろいろできるものだと思ったわけだが、さすがに定常作業でやるのは大変だから、プログラムを書かなきゃなぁ。(まぁ実験の方法ももっと精緻化しなければならないから、いろいろ仕事が発生しそうだけど、そういう仕事は僕にとって苦ではないのです。)
でもさすがに寝てないとき以外はExcelの画面を眺めっぱなしだったから、さすがに疲れた。家に帰って日記を書いているときも画面を眺めているわけだから、_もっと休んでおけ_といろんな人に言われそうだなぁ。(メールも何通も書いているしね。)

言語の勉強のためにインタプリタを書く?

うーむ、最近Raccの勉強中。Rubyを勉強するためにRaccでインタプリタを書いてみようと言うことで、いろいろ遊んでいる。今のところはRaccの256本に掲載されているBASICもどきな言語を学びつつ、もっと別の文法を持つインタプリタを書いて遊んでみたいなぁ。(BNF記法実に深い…)
いずれにしてもそろそろ正規表現をまともに取り組まないとならないなぁ。

VBAでプログラム書き

ここ3年ほど保守している仕事に使っているExcel VBAのマクロなのであるが、当初の開発目標をおおむねクリアできたような気がする。やはり自分が使うツールの改良は楽しいし、自分が作ってきた種々のツールのコードをライブラリの共通化による統合が行えるとなかなか快絶な喜びだ。唯一悲しいのはVBAであると言うところか。VBAがやっぱり好きになれないと言うところとCVSでコードの管理とかできないじゃんと言うところが悲しい。
VBA周りで考えていきたいのは、_VBAからActiveScriptRubyのオブジェクトとやりとりできないものか_と言うことと、上記のマクロのclassライブラリ化かなぁ。Rubyを使えればテキストデータのパースをRubyにやらせて、Excel出力をVBAなんて事ができそうだし、後者はコードをOOP風に整理しておきたいんだよなぁと思うのだ。どうなんだろう。気が向いたら調べていこう。

今日はお休み

ようやくお休みになった。なんだか風邪を引いた模様。のどが痛い…

VBAを使う理由

昨日の議論の続き。じゃ_なぜにVBAを使っているのですか?_と言う話も言及しておこう。
本来VBAでできるものは、Active PerlやActiveScriptRubyで書いた方がよりスマートにかける。こないだも苦労したが、VBAは文字列処理が非常に弱いので、テキスト処理を得意としている言語でやった方がスマートにかけるプログラムは多い。
じゃなぜ?と言う話は簡単で、VBAで書く物はお仕事でしか存在しないからだ。(僕は家のPC用にOffice2000のライセンスを2個持っていますが、インストールしてません。) ただみなさんに「ActiveScriptRubyをインストールしてくださいね」と言うのと、インストールしてもらう利点を説明するのが、めんどくさいからだ。(だってExcelはすでにインストールされているものね。)
ただ最近ExcelのシートにマクロをつけるよりはAddinとして配布すべきだと思い至ったので、最近僕が作るマクロはAddinになるようにしています。使っている理由はただそれだけです。VBやVBAというかMSの生成物に美しさを期待するのは愚の骨頂なので、適当におつきあい。それが正しい姿であろうと思うのだ。書きたい言語で書いていいよと言われれば、絶対選択しない物であるのは確か。

今日は資料作成

今日は明日説明するためのさくっと資料を作成。我ながら数年ぶりにWordなどを使ってみた。(大概の説明用資料は、ExcelかPowerPointで作るからなぁ。) やっぱり文章を書く時はワープロがお気楽で良いなぁとしみじみ思った。無論エディタでざくざくHTMLやLaTeXの方が楽と言うのはあるけれども。

やっぱりVBAは嫌い

今日はなにげにVBAでテキスト処理プログラムを書いてみた。汎用なカンマ区切りテキスト処理を行いたいのだが、ちょっと変なファイルで、最初の項目だけコロンで区切れられているファイルで、レコード長は最初の項目で決まるので、普通のストリーム入出力なら、

• 一行読み込み
• 受け用の配列に取り込み(Cで言えば sscanfとかを使うのね)
• 内容に応じて、適当に逐次データ処理
  となりそうなものだが、そうはいかないところがVBAの凄いところ。こういう処理をする関数やステートメントが存在しないのよ。おそらく可変数の変数をもらう関数が書けないせいだと思うが、配列使えよって言う感じ。さらに連想配列がないのもつらいねぇ。(Excel VBAの場合、シート上にデータをおいた方が早かったり。何か違う気がする。) 結局、
• 一行読み込み
• 行の頭から1文字ずつ読み込んで、区切り記号が出て来たところで、前の区切り記号からの文字を配列に取り込み
• 行の末尾まで繰り返し
  というなかなか楽しい処理を行う羽目に。何と素晴らしい。なぜにここまで低レベルの処理を書かないとならないんだか。さすがMS。苦労したおかげで、何とか思い通りの処理を書けそう。
  もうテキスト処理が得意な言語で書けば良いじゃんと言う話があるんだが、最終的な出力はExcel文書でrubyにしてもperlにしても、新たに処理系をインストールしてもらわないとならないので、できない状況なのよね。もっと便利にならないものかね。もっと良い方法があったりして…

またまたVBAと戦う

この間とは違うマクロの改良を行うべく、またまたVBAと戦うことになった。今回は表示周りに手をかけずにロジックを付け足すというものであったから、結構簡単にいった。それでも表示部分をもっと再利用性のよいライブラリになるようなものにしておかないと、またまた保守できない・する気にならない状態になってしまう(すでに中身を変更する気はないけども)ので、もう少し時間をかけていじっていこうと思う。業務に必要なだけに困ったものだ。(そもそもExcelに依存していることが問題なのね。)