開発環境

開発者にとって開発環境を整えるのは、昨今経済的に大きな負担です。

Windowsの場合MSDNを購入するのが最適ですが、これが安くはありません。
開発者が多数であれば全員にそろえるのは会社にとっては頭の痛い問題です。
開発ツールとしては、MSDNだけでなくたとえばSpreadやDreamweaverやPhotoshop
更にはインストールツールの費用もかさみます。

Java環境ではNetBeansやEclipseが無料ですので、
できればJavaで仕事をしたいと考える開発者もいるかもしれません。

Windowsの世界では、Expressエディションが無料ですから、
これはこれで助かります。
SharpDevelopはマイクロソフトが提供するオープンソースで、
これもなかなかしっかりしています。
特にC#-VBのコンバーターが付いていますので、いつか使ってみたいと思います。

インストールツールはWixを注目しています。
これも確かマイクロソフトがベースを提供しています。
インストール条件をXMLで記述しますので、
とても透過性に優れていて好感をもっていますが、
何より情報が少ないのが残念です。
現在の欠点としてプレインストール(SQLサーバー等)の設定が出来ないと思いますが、
Visual Studioとの組み合わせで解決策があるのではないかと期待しています。
VSのインストールプロジェクトで唯一不満なのは、
インストールの途中でプロダクトIDの入力を求める部分の作りで、
公開されている手法は単純すぎるので、プロテクトになっていないのです。
この点が解消されるのであれば、VSのインストールプロジェクトだけで済ましたいくらいです。

さて、私自身数年間MSDNを使っていたのですが、
直近ではMSDNではなくVisual Studioのみ購入しで仕事をしてきました。

そろそろVS2010を使いたくてMSDNの購入を検討していたのですが、
マイクロソフトのAction Packに開発環境が付属していることが分かりました。

Action Packは主に販促用のパッケージだと思いますが、
Development バージョンにはOSやVSの最新版がついています。
とりあえず開発で必要なすべてのツールがそろっているようで、
価格も求めやすく設定されています。
早速注文しました。

FrontPageの後継でしょうか、Expression WebというWeb開発用のツールもあるようです。
わたしはもっぱらDreamweaverを使ってきましたが、
古くなったのでExpression Webを試してみるつもりです。

OOPの工夫

私はFarPoint社のSpread Sheetを多用します。

シートの行を削除したり、コピーやペーストをあちこちの画面(Form)で使いたくなります。このコードをそれぞれの画面で書いていたのでは、メンテナンス上よくありません。

VBでは、共通関数をModuleに書くことはできますが美しくありません。

コントロールに新しい機能追加する一つの方法は、そのコントロールを拡張するカスタムコントロールを作ることです。

しかしカスタムコントロールの作成は少し大げさでメンテナンスに手間取りそうなので別な方法を考えます。いま、これらの処理を受け持つクラス(仮にMySpreadとします)を一つ作ります。

FormではSpreadを配置し、Spreadのデザインやデータの入出力はすべてFormで処理します。MySpreadではSpreadに対応したContextMenuStripのインスタンスを作成し、右クリックしたときのプルダウンメニューの処理をこちらで行うことにします。

FormでMySpreadのインスタンスをつくり、Form上のSpreadとのリンクを付けておきます。

MySpreadの中で行削除や、コピーアンドペースト等のメソッドを準備してやれば、各Formでこれらのコードを書く必要はありません。

Public Class MySpread

    Private WithEvents m_Spd As FpSpread
    Private m_Sheet As SheetView

    Private m_ContextMenuStrip As New ContextMenuStrip
    Private WithEvents m_tsmi挿入 As New ToolStripMenuItem
    '  m_tsmiコピー、m_tsmi切取、m_tsmi貼付、 m_tsmi削除 等以下省略

    Private m_activeRow As Integer
    Private m_コピー元 As Integer
    Private m_コピー中 As Boolean

    Sub New(ByRef Spd As FpSpread, ByVal shtIdx As Integer)
        m_Spd = Spd
        m_Sheet = Spd.Sheets(shtIdx)

        m_tsmi挿入.Text = "挿入"
        m_tsmiコピー.Text = "コピー"
        m_tsmi切取.Text = "切取"
        m_tsmi貼付.Text = "貼付"
        m_tsmi削除.Text = "削除"

        m_ContextMenuStrip.Items.Add(m_tsmi挿入)
        m_ContextMenuStrip.Items.Add(m_tsmiコピー)
        m_ContextMenuStrip.Items.Add(m_tsmi切取)
        m_ContextMenuStrip.Items.Add(m_tsmi貼付)
        m_ContextMenuStrip.Items.Add(m_tsmi削除)
    End Sub

    Private Sub FpSpead_CellClick(ByVal sender As Object, ByVal e As FarPoint.Win.Spread.CellClickEventArgs) Handles m_Spd.CellClick
        If blninit = False Then Exit Sub
        activeRow = e.Row
    End Sub

    Private Sub tsmi挿入_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles m_tsmi挿入.Click
        m_Sheet.AddRows(activeRow, 1)
    End Sub

    ' 	以下省略

    Private Sub tsmiコピー_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles m_tsmiコピー.Click
    End Sub

    Private Sub tsmi切取_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles m_tsmi切取.Click
    End Sub

    Private Sub tsmi貼付_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles m_tsmi貼付.Click
    End Sub

    Private Sub tsmi削除_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles m_tsmi削除.Click
    End Sub

End Class

実はこの話は以前ご紹介しました、[複数コントロールのセットを何度も使う]と内容的には同じことです。この原始的方法は、結構役立ちます。

とはいえOOPの工夫をもっと体系的に研究する必要があると考えています。デザインパターンを少し勉強しましたが、デザインパターンの技術を採用する場面が余りありません。

私のOOPの勉強は10数年前のJavaに始まり、確か2002年ころから.NETを使用してプログラムを書いていますので、特にVB.NETは目をつむっても書けるくらい慣れ親しんでいますが、デザインパターンはほんの一掴みほどしか利用していません。

理由がよくわかりません。一つには私が、デザインパターンを使いこなすほど勉強していないからだと思いますが、開発している内容も向き不向きがあるかもしれません。

ライブラリ等似たような話題が沢山あって、それらを体系的に構築しなければいけないケースでは、確かにインタフェース(に代表されるデザインパターンの技術)をうまく使う必要があると思います。が、10万行にも満たない事務アプリでは、似たようなクラスあるいは幾層もの階層をもったクラスを余り使いません。このようなケースでデザインパターンを使った高級な技術の必要性を感じていません。

それともう一つ現実的な問題として、そのプロジェクトに投入できる技術者の質と量の問題があると思います。マンパワーを十分かけた大きなシステムならいざ知らず、数万行のアプリケーションの作成では、高級な技術者がそろっているわけではありませんので、難しいコードを使うと後々メンテナンスの維持ができなくなる恐れがあります。その意味でできるだけ分かりやすい原始的コードを書く必要があります。

プログラムの評価の本で、[バグを抑えるためにはローテクを使え]というような文章を読んだことがあります。

確かにそうかもしれないと思っています。

だからといってデザインパターンのような体系的なプログラム技術が不要と言う訳ではありません。十分勉強して機会ある毎に利用すべきだと思います。

(ただし、趣味から言うと、私はデザインパターンより、泥臭いがしかし示唆に富んだJoshua Blochの[Effective Java]の方が好きで、さしあたり、この本を熟読玩味するところから始めようと考えています。)

My Golf

このブログの副題では、「.NET、 LINQ、 XML、CMS そして少しの脱線と」となっていますが、
泥臭くプログラミングしていると、
プログラムのお話で取り立ててご紹介するようなことも思いつかなくて結局「少しの脱線」ではなく、
脱線だらけになっています。

私は50歳過ぎてからゴルフを始めたのですが、
口の悪い級友が「ゴルフのハーフのスコアは、結局始めた年台以上にはならないのだよ」といいました。
(30歳台で始めればハーフ30台、40歳台では同じく40台、50歳台では50台という具合です)

私は「そんなことがあるか。
1年でシングルになった人だっているのだから。
シングルとは言わないが、1年で90(ラウンド)位にはなってみせる」と意気込んで始めたのですが、
それから随分経つのに未だに90を切れないでいます。

理由はいろいろあると思います。

理由1. 
やはり歳をとると体の柔軟性がなくなり、
下半身の安定性に欠けてくるので正確にまた強くボールを打てません。
これはどうにもしようのないことで、それを補うには徹底した練習しかありませんが、
それほど練習する時間も体力もないので、これを改善することはできません。

理由2. 
これまでいい先生に出会いませんでした。
ゴルフを始めたとき、折角だから先生にチャンと付こうと思って、
ある先生に1年くらい毎週見てもらっていたのですが、
私には彼の言うことがわかりません。
ゴルフのスウィングは一瞬のできごとなので頭で考えることと口でいうことと、
実際に体で体現することが異なります。

先生が自分で思いいうことが、実際に彼の動作を正しく表現しているのか問題ですし、
その言葉を聞いた生徒が先生のいうことを正しく理解したか問題ですし、
更には聞いたことをその通りできるかどうか問題です。

人それぞれに体格も体力も体の使い方の癖も違いますので、
「自分流」を口で説明しても相手に伝わらのいのです。

理由3.ゴルファーの性格。

私はゴルフに向いていない性格かもしれません。
私は何事も理詰めで考えます。
これはゴルフに向いていません。

考え、徹底的に練習すればいいのですが、
考えそれに見合った練習をしないのは最悪です。
「テイクバックはこうあげて」
「トップでのクラブの角度はこうで」
「手の位置はこの辺りで」と理屈はよく分かっているのです。

テレビ観戦は好きですし、
ゴルフの「この一冊であなたもシングル!」というような本を何十冊も持ち、
ビデオやDVDをおそらく20本以上は持っていて、練習もそこそこするのですが、
頭で考えることと体ですることとの乖離が大きいのです。

ゴルフのスウィングは一瞬のプレーですので何よりも思い切りが大切なのです。
テイクバックの動作を始めてから色々考えるのは最悪なのです。
スウィングでは頭1、体9位の役割でなければいけません。
私は頭9、体1ですから、これではうまく打てるはずはありません。

私は、昨年秋から近くのダンロップゴルフスクールに通っています。
ここのいいところは、毎回ビデオで自分のスウィングが見えることです。

私は見る目は持っているのですから、
自分のスウィングを見ればいかにひどいものか誰からも言われないでもよく分かります。

問題はここからです、
分かったからできるわけではないので、
自分では言われたことを一生懸命やっているのですが、
ビデオを見るとうまくありません。

「テイクバックでトップの位置はここに上げて」から体が動くのですから、
そこから「ヨイショ」とオーバースウィングが直りません。

毎回毎回先生から同じことをいわれます。

「分かっているよ」

でも、ダンロップゴルフスクールでは一貫した指導方針で分かりやすく、
しかも本人が確認できますので、
欠点を気をつけて練習していけばある程度進歩があるだろうと考えています。

Fortran, Lisp, C そして Java

私がコンピュータの世界に入ってFortranを少しかじった程度のとき、
先輩からLispで人工知能研究用のParserを作るように命じられました。
Fortranの逐語的プログラムは理解していましたが、
ポインタでつながったデータ構造やそれを操作するLispプログラムがいったい何をしているのか理解出来ず、
なにがどうなっているのか混沌の中で仕事をしました。

Lispは原則として逐語的コードではなく、すべては再帰コード(リカーシブコール)で処理します。
XSLTの再帰コードを書くとき役に立ちましたが、Lispとはそれ以来縁がなくなりました。

Lispから解放され、
Fortranで3Dグラフィックのプログラムを書いていましたが、
Fortranは何故かあまり好きではありませんでした。
パンチカードで1桁目はコメントフラグ、7桁目は継続行フラグ、
8桁目からコードを書くとかの約束事があまりにもカッタルかったからかも知れません
(今はこの制限は解除されていると思います)。
それとやはりプログラムの分岐の基本はgotoなので、
プログラムが読みにくかったからだと思います。

そういえば一時Prologという言語が人工知能の研究で注目され、
少し書いてみましたが、まとまった成果をあげることはできませんでした。

Wirthの[Algorithms + Data Structures = Programs]を読んだおかげで
Pascalを知ることができましたが、処理系を持っていなかったので、
後にデルファイに接するまでPascalを動かしたことがありませんでした。

その後パソコンが世の中に出現したとき、Cコンパイラも発売されましたので、
カーニハンのCを勉強しこちらは気に入り(多分Pascalの経験があったためと思います)、
始めははパソコンで、後にはUNIXでCのプログラムを結構長く書きました。

Cではポインタが面白く、データヒープの中をポインタを移動し、
そこでキャストするとintでもdoubleでもstructureでも抽出される仕組みが、
とても愉快で得意になって多用しました。
ポインタが関数呼び出しに使うなど痛快の限りです
(ご存知の通り、このポインターがプログラムを暴走される主要な原因でもあります)。

その後UNIXで大きなシステムに取り掛かりましたが、
当時はプログラムはすべて英数字のみで、変数や関数名の長さに制限がありましたので、
概してこれらの名前は無機的になり、コメントを適当に入れる作業は重要でした。

Javaは10年以上前に少しかじりました。
その後私はもうWindows一本で行こうと思っていましたので、Javaにふれることはなかろうと、
Javaの本は本棚の奥に積んいました。

実際私の周りではJavaを使う機会はあまりありません。
イントラネットではJavaを使うことはありますが、レンタルサーバでは大抵Javaは使えないし、
Windowsアプリケーションでは、まずJavaを使うことはありません。

突然(私にとっては突然)iPadが評判になり、私もMacがどんなものなのかと興味を持って、
Mac OSを購入しました。
最近のMacはUNIXベースだということだし、開発環境ではJavaがメインのようなので、
いたずらしてみたいと思ったのです。

しかし、購入した後でインターネットを調べると、MacOSを簡単にDOS V機にインストールできないことが分かりました。
Biosに代わるEFI-Xというブート用ハードを購入すればいいようですが、今のところそこまでやる気はありません
(EFI-XでMacを動作させるのは違法のようです)。

JavaはWindowsでは最近はNetBeansで練習プログラムを書いていましたが、
Eclipseが軽そうなのでEclipseに切り替えて、
暇をみつけてAndroidで携帯用のプログラムを作ってみようと考えています。
Eclipseは簡単にWindows(XP、Vista共)環境にインストールできました。

C#はJavaのいいとこ取りだから、C#を書くのとJavaを書くのと大差はなかろうと考えています。

昔Javaを勉強したとき、何故か習得に手間取りました。
一つは、アプレット等の話題が面白くなかったのと、
自分自身がオブジェクト指向の言語を始めて本格的に勉強したからだと思います
(その前に、C++を少し「勉強」したのですが、
VC++のフレームワークが余りにゴチャゴチャしていて嫌気がさしていました)。
それに何より必要に迫られていなかったので気乗りしませんでした。
加えて、当時はEclipseのような手ごろなIDEがなくて、
すべてコマンドを打っていたことも勉強がすすまない大きな要因だったかも知れません。

それでも「この際オブジェクト指向を習得しなければ」と思い私がとった方法は、
「やる気になるまで本を買う」ということで、次々に20冊程の本を買いましたら、
さすがに後には引けなくなり、なんとかものにすることができました。

勿論これは.NETプログラミングに、大いに役立ちました。

どちらにしても、これからはWindows以外もwatchしておいた方がよさそうだと考えています。

訳のわかること 2

「建築家の訳のわからない話を断罪したい」というのは穏当ではありません。

もう少し優しくいえば、「建築家の思考プロセスをコンピュータ上で白日の下に曝け出したい」という願望がありました。
もちろん無謀なことですが、ただ「それは無謀だよ」でなく、どこがどうして無謀なのかを見たかったのです。

 

取り掛かるべき作業は、二つあります。
一つは思考のプロセスを展開してみせる、道具としてのロジックです。
その究極の限界は計算可能性の議論で分かりました。

現実的に大切なのはコンピュータの勉強です。
当時は、汎用コンピュータにパンチカードを積む時代でした。
(私は少し恵まれていて、テクトロ社の端末ディスプレイで作業することができました)

やっとFORTRANが使える程度で某研究所に就職し、LISPの仕事を少ししましたが、
LISPのデータ構造の意味さえよくわかりませんでした。
プロダクションシステムを使った医用のマイシンがある程度の評価を受け、ミンスキーのフレーム理論が注目されていましたが、挑戦する道具立てに関しては早くも前途難でした。

もう一つ取り掛からなければいけない作業は、建築のデータや建築についての知識がどのようになっているのか。
その表現は、もちろんコンピュータの道具立てと深く関連しますが、そのまえに、日常言語でもいいのでそれらを整理しなければいけません。
行き着く先は、建築とはなにか、知識とはなにか、言語とはなにかです。

科学哲学、分析哲学、言語哲学、はてはカントまでかじりましたが、「わかった」より「分からない」が増す一方でした。

たとえば、有名なニュートンの方程式があります。
F=ma (F:力、m:質量、a:加速度)
「『あらゆる』場合に真である」とどうしていえるのか。
有限回の実験で「証明」したのか。
理論なのか。理論とはなにか。

1 + 1 = 2 と
ニュートンの運動方程式と、「明日は雨が降る」と「あの人の名前はA君です」と正しさは同じなのか。

これらの正しさの根拠は同じではない。
カントは「純粋理性批判」で綿密に知識について分析しています。

私は数年間、気が狂いそうなほど考えました。
しかし、分からないことだらけです。

結論を出しました。
「カントでさえ、多くの批判に曝され、完璧ではない。
まして私にはカントほどの粘着性はない。
ゲーデルほどの天才でもない。

しかも取り掛かるには遅すぎた。
凡才はこれが限界だ。
これで終わりにしよう」

私は、自分にできることを、精一杯やっていくことにしました。
知識工学がナショナルプロジェクトになる何年も前のことでした。

余談ですが、大学の建築設計の課題は、私にとって仕事をこなすのに生涯最高の訓練になりました。
課題の提出期日は厳守です。設計図とパースという説明用の絵を提出します。
4年生になると、自分は図面一枚を仕上げるのに何日何時間必要か分かってきます。
今回の提出図面は何枚になるか、それによって提出日の何日前まで考える時間があるか逆算します。
そして、許された時間一杯、「ああでもない。こうでもない」と考えに考えます。
設計では絶対的正解はなく、色々な案を練り、何かを生かし何かをあきらめなければなりません。
そして持ち時間一杯考え尽くせば、不満であってもその時点での案をまとめなければいけません。
後は、何日かカンテツし朦朧とした状態で課題を提出するのが常でした。
仕事をこなすとは、そういうものだと思います。

 

私は、フランスの作家カミュが好きです。
有名なのは「異邦人」で、これは映画にもなりました。

彼は不条理の哲学を唱えます(「シジフォスの神話」、「反抗的人間」)。
「世界は不条理に包まれている。
絶対的真理はない。
人生をよりよく生きるより、より多く懸命に生きるしかない」

小説「ペスト」では、医師リューが懸命にペストと戦っていきます。
彼の思想がもっとも分かりやすく表現されていると思います。

(因みにカミュはタレントのセイン・カミュの大叔父でノーベル文学賞を若くして受賞しています)