Java

.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と仲良く付き合うには、_過度の期待はしない_ことと_仕様はどうせすぐに変わるもの_と思って、_適当に勉強すること_と言うのが重用である。どうせ勉強しても長く持たないバッドノウハウだらけになるに決まっているのだから。
  今日の日記はリンクをいっぱい付けてみた。疲れたなぁ。

日帰り出張

今日は某社まで日帰り出張です。(アンカー打って良いのか?) つ、疲れた。

SICP

先日某MLで話題になった「計算機プログラムの構造と解釈」を仙台の書店で探索したのだが、ここ最近の仙台の書店で欲しいと思った本はすべて在庫として持っていないことが分かった。この本も見つけられなかったので、八重洲ブックセンタにて購入。(ここでも危うく見逃すところだった。) この本は巷で「Wizard Book」と呼ばれている有名な本である。
原書は「Structure and Interpretation of Computer Programs」で、本文はWebで読むことが出来る。非常にありがたい本なのである。原書のWebを読めば分かると思うが、僕の貧しい英語力でも文章の良さを理解できる非常に素晴らしい文章なので、出来れば原書を読むのが正しいと思う。この本を日本語で読めるという_気軽さ_も必要だと思うので訳書を購入。おそらく原書も買うことになると思う。
僕の経験では、国内の著者が書いた自然科学・工学の分野の日本語の教科書で_文章の良さを感じる_本を_読んだことがない_。僕の貧しい英語力で英文の素晴らしさを感じることが出来る教科書を見てしまって、思わず日米の教育水準の違いに愕然とせざる得ない。(ちなみに前回愕然としたのは「Feynman：Lectures on Physics」で、ちらちら読んだのはもう10年以上前の話だ。) こういうあたりに国語教育の問題点(物を書く教育をしないことや、読むことに関しては小説の偏重していることや、論理的な討論をする演習をしないことなど、他にもいっぱい)を見いだしてしまうのだが、そんなことを言っても僕の国語力もかなり怪しいので、こういうComfortableな文章を読みあさって日本語にフィードバックするしかないのですな。精進が必要ですな。
話がそれてしまったが、一言で言えば_この本は凄い本_である。(おおざっぱな意見すぎて失礼すぎるか。) 内容は難しいと思うが、こんなに面白いと思って読める本はなかなかない。SchemeなどのLISP系な言語は実際の仕事に直接役立つかと問われれば、おそらくすぐには役立たないと思う。ただ_役立つ/役立たないという思考軸だけが世の中の本質ではない_と思うのである。_読んで・手を動かしてソースを書いて楽しい・面白い_ということの方が遙かに重要だと思うのである。
ということで、しばらくこの「魔法使いの本」を読みつつ、魔法使いの弟子になってSchemeの呪文で遊ぶことになりそうである。もしCやC++やJavaやVBでしかプログラムを書いたことがないと寂しい経験しか持っていないと言う人には、_全く異なる物の考え方_をかいま見るためにもこの本を読んで、LISP系の言語をさわるべきなのかなとLISP万年初心者の僕も思うのだから、必読の書といえるのだろう。
帰りの新幹線でひたすら読む。1.1.4 Compound Proceduresあたりからだんだん深みに誘われてくる。とりあえず、帰りの新幹線で読んだ範囲で目から鱗だったのは、1.2.2 Tree RecursionのFibonacci数列の計算で、再帰を使った計算はFibonacci数列の漸化式から理解できるのだがこれは非常に効率が悪い。Fibonacci数列の計算を反復的なステップで計算するあたりでなるほどと思い、1.3 Formulating Abstractions with Higher-Order Proceduresで、Schemeの教科書を読んでいまいち想像が沸かなかった高階手続きといままでLISP系の本を読んでlambda記法のありがたみがいまいち分からなかったが、何となく見えてきたこと。理解するためにちゃんと手を動かさないと駄目だと思ったところ。とりあえず第1章だけでも読んで手を動かすところ満載なのである。

毎週土曜日はハマリだなぁ

今日はちょっとしたトラブルをきっかけに芋蔓式にどんどん大きなトラブルを引き当ててしまった。気が付いたら、結構な時間になってしまい疲労感だけ残る。毎週引き継ぐ仕事のみが多くて大変申し訳ないのである。

デザイン・パターンを勉強しなければ…

最近、プログラム関連の記事やら本を読んでいると_「なんたら・パターン」と言ういかにもデザイン・パターン用語_を見かけるようになって、「？？？」となることが多いので、ぼちぼち勉強しておかないとだめかなと思っているのです。
どの本を読めばいいのかと言う話を考えていると、さすがにGoF本は難しそうなのでやめにして、やっぱり結城さんの「Java言語で学ぶデザインパターン入門」(ホームページ)を種本にして、Javaのソースを読みつつ、rubyに移して勉強すれば、良い勉強になるかもと思っているのですが、実際のところどうなんだろうか…
たまには言語に依存しないプログラミングの方法論を勉強しておかないと駄目かなと思っています。まぁ実装方面にすぐ走れなくても、人が何を言っているのか理解できないとそれまでなので早急に勉強しておかねばと思うところと、手持ちのネタは多いほどいろいろできるものなので。
明日本屋巡りをしてみようと思いつつ、RubyでデザインパターンだったらRubyの作者のまつもとゆきひろさん自身が書かれている「オブジェクト指向スクリプト言語Ruby」に書いてあるよんという話を聞いて、久しぶりに眺めてみた。内容は、第5章の後半がデザイン・パターンの話ですな。Observer/Proxy(Delegator)/Iterator(Cursor)/Strategy/Singleton/Template Methodが解説されていますねぇ… (ここまで読んでなかったんだな。なかなかこの本を読みこなせて無いなぁ。この本結構目から鱗なところがあって楽しいのだが…)

RelaxNGの勉強をしようかと。

今回のコンテンツの見直しで、元々やろうと思っていたXML化の推進をしないとやっていられない状況になってきました。ぼくはXHTML 1.0のFramesetが嫌いな人なので、今のようなページ構成になっています。しかしそれぞれのページで部品として共用している部分を書き換えることになると、手修正だけではやってられないと言うことで、XMLで書いた部品を寄せ集めてXHTML 1.1(or XHTML 2.0?)にレンダリングした方が良さそうです。
最近の流行りであれば、真面目にXMLに突っ走るならCocoon 2みたいな物を使うか、よりお手軽なZope、もっとお手軽な方向としては、XOOPSのようなWeb Applicationか、がらっと変えてtDiaryみたいな日記ツールとかblogなツールを普通、選ぶのだろう。
ただ今のところ動的なサイトにしたくないのと、JavaやpythonやPHPに依存できない環境であること。Java以外は一生コードを見ないですむなら見たくないという個人的な偏見と趣味とRubyとPerl(これも使いたくはない)はサーバで使える環境にあるので、選択肢はこれらのどっちかですな。
ただCGIなどでページをDynamicにページを生成するとCGI自身のメンテがかったるいので、WikiWiki Cloneは却下で、結局今のところはStaticなページ構造にして置いた方がよいかもと個人的に思うので、XML文書を書いてXSLTでXHTMLに変換するのがよいかなと思っている。最終的な目標はサーバにXMLファイルをいっぱい置いておいて、半動的生成を目指そうかと思うわけだが、しばらくはXMLで書いて、makeでStaticに作ってしまえと言う感じである。
XMLで適当に文書を書くと自分で作ったXML文法(XMLボキャブラリというのかな)を忘れてしまうと言う問題があり編集の便利さを追求するためにも、僕の場合は必ず文書型定義(DTD)を書く必要がある。ただ_DTD自身がXMLじゃないやん_とか_いまさらDTDなんて勉強しても仕方ないやん_ということで、何かしらのSchemerを勉強せねばと言うことになったわけだ。こういう用途でThe World Wide Web Consortium (W3C)御謹製のXML Schemaを使うほど暇人でもないので、Relaxを勉強かと思ったのである。いろいろ調べているうちに、Relax NGのページやTutorialを眺めていると、こっちの方がえらく簡単ということで_勉強する気になった。_(ようやく表題の話になった。)
ということで、いったんどういう事を書いているのか再分析して、Relax NGパターンを書き下して、DTDを生成してみようと思う。

今年もみなさまよろしく。

ここを読んでいるみなさん、昨年は本当にお世話になりました。ありがとうございました。今年もよろしくお願いします。ということで、「一年の計は元旦にあり」とのことなので、今年はどういう戦いを展開するか、今年の戦術・戦略を主要な分野別にまとめておこう。(今年は喪中のため、年頭の挨拶はこの辺で)

2003年の展望

はじめに、概況

2003年の活動分野における戦術・戦略に関する展望を分野別に述べることにしよう。昨日の文章をアレンジして書いているので似たような展開だが、去年の延長線上にある訳だから。
経済的な状況に関しては今後も流動的。抜本的に良くするには転職するしかないと踏んでいるが、めんどくさすぎるので、どうするのかよく分からない。まぁ将来のことも考えて行かねばならないし、そろそろ貯金とかもしなければと思わないでもない。別に何か当てがある訳ではないのだが。
最近体調をことに壊し気味なのと太り気味(おそらくストレスから来るものと思うが)で、食生活を改善せねば、どうしようもないな。とりあえず5kg程度は痩せないとなぁ。着る服が無くなってしまう。と言うことで、注意することとして、最近壊れ気味な精神状態も何とかせねばなぁ。

今日で2002年もおしまい

今年は、こないだ2001年もおしまいなんて記事を書いた気がするなぁと思わなくて、実にいろんな事があってやけに昔に書いた気がするのである。でも、気が付くともう今年もおしまい。今年お世話になった方々はいっぱいいて名前を挙げきれないが、今年1年本当にありがとうございました。来年もよろしくお願いします。
ということで、大晦日と言うこともあって、行く年に思いをはせて、今年はどういう戦いの1年だったか、今年の戦術・戦略とその戦いの成果を主要な分野別にまとめておこう。(と、ほぼ去年と同じ文章にしてみた。断じて_手抜きではない。_)

2002年の総括

はじめに、概況

2002年の活動分野における戦術・戦略に関する概況を分野別に述べることにしよう。
今年は、会社の状況が思わしくなく、経済的には惨憺たるものだった。当初、上期中は良化しそうにないと思っていたが、4月以降は給与カットでさらに拍車がかかった状況。。質素倹約に励まねばと思ったが、思った以上に出費が多く、収支的に±0で済んでいるところが素晴らしいところ。とはいえ、そろそろ貯金とかもしなければと思わないでもなく、将来について多少考えねばと思う今日この頃である。
最近体調をことに壊し気味なのと太り気味(おそらくストレスから来るものと思うが)で、食生活を改善しなければならないが、どうしようもないな。注意することとして、最近壊れ気味な精神状態も何とかせねばなぁ。
今年の大きな事件は、7月に父を亡くしたこと。最後に父を見た時には、すっかり老けたなぁと思わないでもなかったが、かなり元気だっただけにあと何年も生きていそうな感じだったが、突然亡くなってしまった。人生の儚さを感じた1年でもあり、いろいろな方々にお世話になった1年でもある。ありがとうございました。また父が亡くなる1週間前に父に会う機会をくれた石川君にどれだけのありがたいと思ったか分かりません。本当にありがとう。

TLUC月例勉強会

今日は、TLUCの月例勉強会であった。案内の通り最近の月例勉強会はWeb関連、特にHTML文書をかけるようになろうと言うのを目標に草の根活動を行っている。ただ書けるだけではつまらないというか、勉強する価値もないので、W3C的に正しいHTML(Strict DTD)を書けるようになると言うのが目標だ。この企画は今回講師をしていただいた高橋 克伸氏と続けてきている話である。
今回は新しい参加者が何人かいて、こういう活動を続けてきてよかったかなぁと思ったのだが、次また来ていただけるかどうかは、僕らの力量次第かな。
あんまり難しい話をしていないつもりだし、高橋さんにしても僕にしても相談しにくい人ではないと思うので、ホームページを書きたいけど一人で勉強するのには敷居が高いなと思う人は、1月末にも続きをするので、話を聞きに来てくれると良いなぁ。

ようやく復帰か…

3日寝込んでようやく良くなった気がする。さすがに明日あたりから動かないとさすがに鈍ってしまう。とはいえ、明日1日会社に行くとまたまたお休みなんだねぇ。
それにしても、一人暮らしをしていて一番しんどいのはやっぱり風邪を引いた時だな。油断していると何食か食べ損なうからなぁ。まぁ気ままなSingle Lifeとの引き替えでなのではあるが。

100円で買える物

Newsweek 日本語版の今号の記事「竹中ショックが日本を救う」から。海外誌っておおむね竹中さんの評価がよいのよね。まぁ実体が伴えば僕も良いと思うんだけども。(その結果僕の会社が無くなってもね。)
話を元に戻そう。記事のなかで_「今の日本で100円で買える物」と言う話があったが、今の日本では100円でジュースも買えないんだよね。で、買うことができる物は、「ちょっとしたお菓子」と「大企業の1株」_と。これにはさすがに笑ってしまった。確かにそうだわ。(1株レベルでは買えないけど、価値はそんなもんよね。) うちの親会社の株価もだんだん100円に近づいてきたので、ちょっと考えるところではあるなぁ。と、しみじみ。

僕がJavaを積極的に使わない理由

今日はなんだか議論になってしまったので、一応日記にも書いておこうと思う。今の時点では僕はJavaを開発言語に使っても良いくらいの完成度になってきていると思っているので、以下の議論はだいぶんどうでも良くなっているのだが、何個かの理由があってまだJavaを開発用の言語に選択する気はありません。
僕はJavaに熱狂があった時代(Alpha版からBeta版の時代)を知っていて、そのあとに大きく失望したので使っていない訳だが、大ざっぱに言えば以下の項目に集約される。
仕様の策定がオープンでない
最近は解消された気はするが、仕様の策定がSunで行われていた頃は、信頼に足るコンパイラ供給ベンダがSunだけという感じだった。自分が使うツールの提供元がただの民間企業1社しかないというのは、あまりに脆弱だと思う。いまはThe Java Community Processである程度読みとれるし、コンパイラベンダも複数になったのでまぁいいかと思うのだが。
開発ツールの提供
当時JDKは、SolarisとWindows版しかなかった気がする。当時僕の主要な環境はLinuxだったので、採用すらできなかった。(BSDユーザーもMacユーザーも悔しかっただろう。)
国際化周りの対処の遅れ
JDK1.2でほぼ解決された問題と考えているが、やっぱ母国語が陽に使えないのは痛い。Unicodeをがんがん使うのは良いが、Unicodeを編集できるエディタが当時なかったこと、処理する対象は非Unicodeな文書で、Unicode周りの問題(正規化とか言うんだっけか)があってどうもねぇと思っている訳だ。
動作が遅い
これはJITコンパイラのおかげで解決を見たと言っていいだろう。(同じアルゴリズムでC++とほぼ同じくらいだから問題なかろう。)
僕は過去も今も「オープンソース」側の人なので、プログラムを書くのに最も重要なのは_「プログラムを書く自由」_だと思っている。僕はあくまで職業プログラマではないので、プログラムを書くことはこの上ない楽しみであり喜びであるべきなのだ。それゆえに上記の用件で最も大切だと思っているのは、言語仕様のオープン性とコンパイラの提供が永続的であることである。その条件を満たせない限り、使ってみようとなかなか思い立てないのである。
ただ今となっては時代遅れな意見も散見している気もするので、ぼちぼちJavaを個人的なプログラムの開発に使えるよう準備を整えて良いかと思っている。なにせXML周りはJavaがないと立ちゆかなくなってきているので切実なところであろうか。僕の中のJavaの不運は、_必要な物が必要な時に提供されなかったこと_につきる。(それで仕事する気が失せるんだもの。) 逆にLinuxは使いたい時に使える形で登場したのね。(こっちもかなり偶然性が強い。) まぁ時の運とはこういう物だろうな。
僕のなかでJavaの残りの問題は、C++におけるtemplateがないことくらい。これはJava GenericsがJDK1.5で実現すれば解決される。僕自身はライブラリ設計者ではないので、Genericな型を持つclassを設計することはないのだが、Collection classを使っていると、Collectionから要素を取り出すのに_型キャストが必要_と言うことと、_意図しない型の要素を追加できること_が気になるわけだ。Java Genericにはそれなりの期待をしている訳だ。
議論については、幾ばくかつきあうので、僕にJavaを使わせたい人は建設的なご意見をください。

NHKの放送受信料

さすがに払う気がなくなる程度の請求が来た。(まぁ3年くらい払ってないから) うちのTVですが、NHK総合だけやたら映りが悪いんだよねぇ。3年くらい前から。ということで、NHKにお金を払う気にはなれないです。何とかしてくれたら払っても良いけど、過去にさかのぼってと言うのは勘弁して欲しいなぁ。

高橋 征義・後藤 裕蔵 / たのしいRuby

Rubyの入門書はないものかと探し求めて、最近発売された本書を購入。(購入は28日) ざっと中身を見た感じでは、必要なことが十分親切な内容でまとまっていると言う印象。なかなか良い本だと思う。
わかりやすいOOPの本はこんな感じにまとまるのかなぁと思ったりした。同じようにJavaで書けないものかな。僕はなんだか書けそうな気はするけども。良い入門書の基本は詰め込みすぎず、次へのステップの足がかりを示すことが重要で、何でもかんでも詰め込んではならない。その辺の扱いが下手なJavaの入門書は多いがAppletとかGUIとか見た目に走りたがる傾向があるせいだろうなぁ。(その点Rubyの出発点は、Unix的なプログラミングだものねぇ。)
ということで、ネタ本にしよう。この本で足りなかったら、もうまつもとさんの「オブジェクト指向スクリプト言語 Ruby」を読めばいいのだから。