2008年1月22日

データを全てファイル名に！？

カテゴリー: [ソフトウェア] [プログラミング]

スラドで見つけたんで、知っている人も多いでしょうけど。

スラッシュドット ジャパン | データをすべてファイル名扱いにして高速検索を実現?
HOWS「ISSEI（イッセイ）」：ITpro

既存のRDBの限界を超える、高速検索が出来るようにデータの全てをファイル名に入れる事にした検索技術を作ったというものです。OSの機能で高速検索できると主張しているわけですが。

最初は、何か利点になるポイントがあるんだと思って読んでいったんですが...
つっこみどころが満載で、どこからつっこんでいいやら困ってしまいます。ジョーク記事かと思いました。

すくなくとも、解説を読む限りはつっこみどころ満載です。
世の中、解説だけがでたらめということはあるので。（これがそれだけの話とは正直思えないですが）

とりあえず、他の人たちもつっこんでいるように、「ストップウオッチ片手に高速化を追求」というところは、つっこんでおかないといけないでしょうね。なぜストップウオッチ…

OSの基本機能であるファイル名の検索機能を用いることで、ハードディスク内のファイル本体にアクセスせず高速に検索できるのが特徴だ

HOWS「ISSEI（イッセイ）」：ITpro

ファイル名の情報も、ハードディスク上にあると思うのは私の勘違いなのでしょうか？
なにか、ファイル名を取ってくるのは、どんなときでも高速であるという思いこみがあるような気がします。

そもそもファイル検索機能というのが何をさすのか、よくわからないのですが、Windowsのファイル検索のことなんでしょうか。
あれだって高速化するには、インデックスつけたりするわけでDBと同じ事なんですが。
つまり、結局、Windowsのファイル検索は速いよ、ということですか。

検索対象は、このファイル名の集合体。この方法によって、ハードディスクに保存されているファイル本体にアクセスすることなく、メモリーにキャッシュされたファイル名群を検索することで高速化を図っている。

なるほど。メモリに持っておくから速いんですね。
でも、ファイル名としてデータを保存するから速いんではなかったんでしたっけ？
結局、ファイル検索ってなに…？キャッシュとは普通のディスクキャッシュのことなんでしょうか？
それこそ、単にOSの機能では？

従来のDBは、

「ファイルの入出力にかかる時間がボトルネックで、検索速度が上がらないとの問題を抱えていた」
というんですが、そこから、なぜ、ファイルの中身を読まずにファイル名だけ読めばよいという発想に至るのかよくわかりません。ファイル作成や、ファイル名の取得はボトルネックにならないと思ったのでしょうか？
そもそも、そのボトルネックはどうやって調べたんでしょうか。（ストップウオッチ？）

次はOSメーカーと共同開発し、ISSEIをOSの標準機能として盛り込みたい。最終的にはISSEI専用チップをメーカーと開発するのが目標だ

OSの機能をそのまま借りるのが利点だという主張なのに、なぜ専用チップですか。
これは、他と比べて、非常にわかりやすいつっこみどころですね。

このままつっこみ続けると、全文引用してしまいそうなのでこの辺で。
「ゼロベースで発想」したそうですが、どういう意味でゼロだったのか…

ファイル名にプログラムから利用される何らかの情報を持たせるということは、普通にあります。有効な場面もあるでしょう。
でも、そういうのは、62進数で全部のデータをファイル名に入れるとか言う話とは違う話ですし、新技術とか言うものではありません。

とにかく、この技術がたとえ本当に速かったとしても、すごいのはMicrosoftなわけです。
ファイルシステム、ファイル検索といった、「既存のDB」を使っているだけなのですから。

書くべきか迷いましたが、あんまりな話なので書かずにいられなかったです。
なんというか、トホホな話です…

追記：
改めて、何に違和感があるのか考えてみると、引っかかっているのは単に技術的に変とかいうことではないんですよね。
自分はそこに着目しがちですが、記事だけでは詳細まではわかりませんし。
まあ、記事の書き方自体がなにか変なのは確かですが…
用途は限られるでしょうけど、ファイル検索機能に検索させるということ自体は、（もしかしたら）状況によっては意味があるかもしれない。
（Google Desktop Searchとかの方がいい気はしますが）
でも、新技術とか、既存のDB技術と一線を画すとか、革新的とかいう話じゃない。（一番大事なところが借り物）
そこのところに引っかかるんでしょう。

投稿者 shingo : 01:16 | コメント (2) | トラックバック

2007年12月 1日

apacheでコメント・TBスパム対策

カテゴリー: [blog] [プログラミング]

blogの更新をさぼっていても、スパムは休んではくれないようです…

迷惑コメント・トラックバックがMovable Typeのデータベースに大量にたまっていきます。
（フィルタされたものは分類され未公開にはなりますが、DBにいったん入ります）
フィルタされてればいい方で、フィルタを通過して公開されてしまうものもかなり多いわけです。
アクセスのけっこうな割合がスパムなのは確実で、United Statesがアクセス数トップです。

Movable Type の SpamLookup プラグインでDNSBLをつかってフィルタ出来るんですが、もうブラックリスト入っていたら、Movable Typeに渡す前にフィルタしたくなってきました。
そうするとDBに入らないので、万が一誤検出した場合に回復する手段がないわけですが、どうせコメントはほとんどないし、とりあえず問題ないでしょう。

DNSBLを参照して、その結果を元にapacheに403を返させる方法がないかと調べてみたら、やっぱりそういうモジュールを作っている人がいるんですよね。

mod_setenvdnsbl : Apache module (nesitive thinking)|

早速インストールして、設定してみました。
インストールは、Makefileの先頭のAPXSのところを環境に合わせて書き換えて、make && make install するだけです。

設定はこんな感じです。 

<Directory ...>
      <FilesMatch "mt-(tb|comments)\.cgi">
          SetEnvIfDNSBL remote_addr zen.spamhaus.org spammer
          SetEnvIfDNSBL remote_addr bsb.spamlookup.net spammer
      </FilesMatch>
      ...
      Order allow,deny
      Allow from all
      Deny from env=spammer
</Directory>

しかし、apacheでMT/WPのスパム対策 DNSBLのmod_setenvifdnsblを使ってみる (blog@browncat.org) でも指摘されているように、複数のDNSBLを指定すると、最初のものしか見に行きません。

apacheのモジュールなんて作ったことありませんが、ソースを読んでみました。
まあ、apacheのAPIを知らないんで、最初はさっぱりだったわけですが、結局わかったのは、SetEnvIfDNSBLの最初の引数が同じだと、複数の設定を内部的にひとまとめにするための処理があるということでした。
mod_setenvdnsbl.cの217-255行目あたりです。

この設定の場合、remote_addr という行が複数あるので、これらをひとまとめにしようとします。
が、内部のデータ構造にはDNSBLは一つの設定ごとに一つだけしか用意されていませんので、最初のDNSBLのドメインしか残らないわけです。
単純にこの処理を省いてやるだけで要求通り動くようになりました。

本来は、１つのDNSBLへのリクエストを１回にするための処理なのかなと予想したのですが、それにしては、データ構造がそれらしくないんですよね。

こんなわけで、最近Javaばかりだったんですが、久しぶりにC言語をさわりました。

これをやって収穫があったとすれば、DNSBLのクエリの仕組みを初めて知ったことですね。
恥ずかしながら、今まで知りませんでした。プロトコルがDNSだから、DNSBLだったとは。
確かにクエリも軽いし、プログラムも書きやすいですね。
あとは、apacheのモジュールの作り方がなんとなく見えたことですかね。

スパム対策？そういえばそれもありました(^^;

結局、ブラックリストだけでは駄目なので、キーワードベースのフィルタにキーワードを追加して、厳しめにしてみました。
DBには入りますが、スパムが公開されてしまうことは防げます。結局これが一番効いたような…

投稿者 shingo : 19:31 | トラックバック

2006年12月15日

JScriptにはまる

カテゴリー: [プログラミング]

今週，仕事ではまったお話．．．

JavaScriptというより，JScripｔの話です．つまり，IEのせい．

いつも，Webアプリケーションの開発では，まずFirefoxを使って動作確認します．
デバッグ環境が充実していて，圧倒的に開発しやすいですから．
でも，IEで動かないのは困るわけで，ある程度の段階になったら，IEでもテストするわけです．
そこでたいていはまるわけで．今回のもそんな問題です．

prototype.jsのForm.serializeをつかって，formの内容をparameter1=value1&parameter2=value2...のようにシリアライズしてたんですが．
なぜだか，IEにしたとたん，input要素を全部無視して，select要素しか拾わなくなってしまいました．

いろいろ原因を考え，可能性を削っていってもさっぱりわからない．
らちがあかないので，prototype.js を読んで，中で何をしているのか調べました．
結局，問題になるのは単に以下ようなコードでした．

elements = $('フォームの名前').getElementsByTagName('input')

これが，
elements = $('フォームの名前').getElementsByTagName('select')

だと，問題ないのに，inputにしたとたん返ってくるものがおかしくなる．
具体的には，elements.length が [object] になってしまうのです．なぜ，numberじゃないの？

探し始めるノードを変えて，どんどん子の要素に降りていくと，うまくいく場合もある．
formの内側でtableを使っていたので，まさか，それが原因かとも考えますが，調べてもそんな話は出てこない．
生成するHTMLをいろいろ変えてみるとか，試行錯誤するも全く現象は変わらず．

そこで，問題のelementsとelements.lengthのプロパティを全部列挙してみました．
そうしたら，elements.length の中身が，どう見てもDOMの要素にしか見えない．．．
elementsのプロパティもよーくみて，原因が判明．

inputタグのname属性の名前が，そのままelementsのプロパティになっているじゃないの．．．
そして，そのプロパティの値はinput要素．
そこで気がついたのが，そういや，lengthって名前のinput要素があったなあ，ということ．

lengthという名前のinput要素に，本来長さを表すはずのlengthプロパティが上書きされてたみたいです．

まあ，何が言いたいかと言えば，もっと早く気づけよ俺，ふざけるなJScript，ということなんですが．
ふとした拍子に名前が衝突し，それも黙って上書きしてしまうという仕様，いいのかよ．
もしかしたら，この話は常識なのかもしれませんけど．

こんな事にずいぶん時間をとられてしまった日でした．

投稿者 shingo : 23:59 | コメント (0) | トラックバック

2006年7月21日

Becky用のベイズ理論ベースの学習型スパムフィルタが登場

カテゴリー: [ソフトウェア] [ニュース] [プログラミング]

Becky! Internet Mail にベイズ理論ベースの学習型スパムフィルタを追加するプラグインが出てきました．

窓の杜 - 【NEWS】「Becky!」に“ベイズ理論”を用いた学習型のスパムメールフィルターを追加

Beckyのプラグインで，この種のフィルタは，私が欲しいと思った数年前には無かったので，自分で作ってずっと使っています．公開はしてませんが．
誰かが作るだろうから，いつか出てくると思っていましたが，ついにでてきましたね．

私の作ったフィルタは，形態素解析にmecab，データベースにBerkeley DB，文字コード変換にICU(International Components for Unicode)と，外部ライブラリやプログラムをいろいろ使っています．その上，STL実装にSTLportを使ってみたりしてますので，依存するDLLはさらに増えてます．
ちゃんとインストーラを作らないとお世辞にもインストールしやすいとは言えず，配布できたものではありません．

また，初期状態では何も学習していないので役に立ちません．なので，あらかじめ，スパムのサンプルを持たない人には全く使えなかったりします．かといって，私宛のメールの断片を含んだ，スパムメールとクリーンメールのデータベースを標準添付するわけにもいきません．
公開するなら，最初からある程度フィルタ出来るだけの学習データが必要です．

というわけで，ちょっとは公開することも考えましたが，公開するのがあまりにも面倒なので，やめました．
そのかわり，自分好みに作り込んでます．
性能は他と比較してみたことは無いのでよくわかりませんが，まあ，使えているので良しとしています．

Beckyユーザのスパムフィルタの選択肢はそんなに無かったと思うので，選択肢が広がったのは良いことです．

追記）
どうやら少し前から，ベイズフィルタのBecky!のプラグインはあったようです．いやあ，自分で作って満足してたから，全く知らなかった(^^;

投稿者 shingo : 23:49 | コメント (2) | トラックバック

2006年7月10日

夢の原因

カテゴリー: [プログラミング]

先日，JavaScriptのプログラムで問題を抱えていたら，JavaScriptのデバッグをしている夢を見たという話を書きましたが，現実の方の問題が解決しました．

結局，JavaScriptは原因ではありませんでした．
サーバから取ってきたHTMLを，div要素に流し込むだけの事だったんですが，なぜかエラーが出て動かない．エラーメッセージを表示してみても，"System error"と出るだけで，全く情報量がありません．
なんですか，System errorって(^^;

原因は，HTTPレスポンスヘッダのContent-typeのcharsetが間違っていただけでした．"utf-8"と書くべきところが，"utf8"になってました．Firefoxは適当に何とかしてくれたけど，IEはそうでなかったんでしょう．
しかし，エンコードが間違っているレスポンスを受信して，それをinnerHTMLに入れると，System errorなんていうエラーになるとは想像もつきませんでした．

結局，'-'（ハイフン）１文字に，何時間も悩まされていたわけです．
なんだかなあ．．．．

まさに悪夢ですね．

投稿者 shingo : 23:46 | コメント (0) | トラックバック

2006年4月 3日

文字化け

カテゴリー: [ネットワーク] [プログラミング]

今まで，DeAGOSTINIの「週間スタートレック」を買っていたんですが，引っ越して本屋によるのが面倒になったので，定期購読にすることに．
その定期購読の申し込みシステムですが，注文確認のページにこんな注意書きが．

このページをプリントアウトしてお申し込みのお控えとして保管してください。 ※後ほど同じ内容のお申し込みの確認をEメールでもお知らせいたしますが、メールの文字が環境により文字化けが生じることがございます。（hotmaiをご使用の方から多くご報告を頂いております。）その際は、このページのプリントアウトをご参照ください。

で，私はhotmailじゃないんですが，見事に文字化けしてました．
よく見てみると，EUC-JPの本文なのに，ヘッダには，

Content-Type: text/plain; charset=ISO-2022-JP

環境なんて関係なく，化けるに決まってる．．．というか，化けない方がよほどおかしい．
メッセージを見ると，苦情がたくさん来ていると思われるが，気づいてないのね．．．

投稿者 shingo : 23:16 | コメント (0) | トラックバック

2006年2月25日

XindiceとXalan

カテゴリー: [プログラミング]

ここのところ，Xindiceをいじっていますが，あれ，どうも受け付けるXPathと受け付けないXPathがある模様．
コア関数をろくすっぽ認識しようとしないので，1.0 から，1.1b4に変えてみました．
ところが，その過程でやたらとはまりました．

まず，Xindiceとはrpc(CORBAだったかな？)で通信しているのですが，どうも呼び出し側で（も）XPathの解釈をしているようです．
最新版のxalanをつっこんでおいたら，クエリーを出したとたん，NoSuchMethodError になりました．

どうも，Xindiceに含まれるXMLDB APIは，Xalanのorg.apache.xpath.compiler.Compiler に依存しているようです．そのコンストラクタの引数が違うので，NoSuchMethodError になってました．2.7.0から変わったようで，2.6.x 以前
このクラスは，「**For advanced use only**」 ということなので，こういうインタフェースが変わるような内部のクラスに依存しているのは，あんまりよろしくないような気がします．

あと，Xindice 1.1b4 は，Webアプリケーションとして動作するようになっていますが，私が作っているのもWebアプリケーションです．同じサーブレット・コンテナに入れておくと，ロードの順番が決められません．サーブレットがロードされたときにデータベースに接続に行くような作りでは動きませんでした．

[追記]　同じ事で悩んでいる人はやっぱりいたようで．．．
'Incompatible change in xalan-java [Fwd: [GUMP@brutus]: Project xml-xindice' - MARC

古いコンストラクタを削除してしまうXalanが悪いのか，そんなコンストラクタに依存しているXindiceが悪いのか．．．

投稿者 shingo : 14:54 | コメント (0) | トラックバック

2006年1月13日

コードいぢり

カテゴリー: [プログラミング] [日常]

公聴会が終わったので，ちょっとコードをいじってみることに．
いつも使っているJavaじゃなくて，久しぶりにC++をいじってみました．

ずっと使っているジャンクメールフィルタのデータベースをBerkeley DBに置き換えてみました．

今まで，普通のテキストファイルをデータベースにしていたんですが，最初にすべてメモリに読み込んで，終了時にすべてファイルに書き出すようになっていたので，やはりいろいろ不都合がありました．
長時間起動しっぱなしにしたあと終了すると，おおかたページアウトされしまったメモリを読んでファイルに保存しようとするので，ものすごく遅くなります．サイズが大きいから，起動も遅くなってきたし．

BDBの使い方がよく分からなかったり，ゴミデータを書き込んでしまってデータベースが壊れたり，いろいろはまりましたが，久しぶりに，明け方まで集中してコードを書いてました．
時間的には，１日半くらいでできました．

何度か手を付けようとして，ずっとそのままでしたが，頭を占めていたものが１つ減ったので，一気に集中して仕上げることができました．

こうやって作りたいもの作っていられる時間はいいですね．

投稿者 shingo : 02:51 | コメント (1) | トラックバック

2005年12月26日

お節介なQuickTime

カテゴリー: [プログラミング]

珍しくコマンドラインから，Javaを使っていたら．．．
なぜか，javaのプログラムが起動しない．

原因：QuickTimeのインストーラが，CLASSPATH環境変数を書き換えていた

こっそり，いつのまにかやってくれるものだから，気づかなくて困ります．
そもそも，何でCLASSPATHを書き換える必要があるのでしょう．世の中にはPATHを上書きしてくれるインストーラもあるらしい．

ちなみに，CLASSPATHを設定すると全体に影響して混乱の元だから，私はCLASSPATH環境変数は使わないようにしています．Eclipseを使っていれば，必要もないし．

そういえば，QuickTimeにセキュリティホールが見つかったという話があったっけ．

投稿者 shingo : 15:29 | コメント (0) | トラックバック

2005年11月28日

これからのプロセッサの話

カテゴリー: [プログラミング] [情報技術]

学位論文審査で頭がいっぱいでblogを放置してました．というより，そればっかりやっていると，ネタがなかったんですが．
そうしたら，アクセス数が半分に＾＾；

さて，本題に．
先週の金曜日，大学に東芝セミコンダクターの斉藤光男氏が，Cellプロセッサ関係の講演に来ました．
何となく，その場の流れで聞きに行くことに．

主に，プロセッサの歴史と，Cellへ至る道についての話でした．
もちろん，もっぱらハードウェアの話でしたが，後ろの方でちょっとだけふれたソフトウェアの開発環境に興味を持ちました．ポイントは先祖帰りだそうです．

Cellは，制御用のプロセッサ(PPE)１つと，８つのSPEを１チップにした，非対称マルチコアです．
ですから，それぞれのプロセッサに上手に仕事を割り振る必要があります．
そして，これは人がやるようです．人が動作を客観的に判断できるように，SPEがどれだけ仕事をしているか，ブランチミス，バスを流れるデータ量，すべてを見ることが出来るようになっているということでした．
とにかく，隠蔽して透過的にするのではなく，見せるようになっています．見て，人が調整するわけです．

実際の開発環境を知っているわけではないので，実際どのくらい大変なのかは何ともいえないところですが，こういう話を聞いていると，やはりソフトウェア開発は大変なんだろうなあと思います．Cellをよく知った上で，使いこなす必要がありますから．

でも，こういう問題はCellだけの問題ではないでしょう．これから，マルチコアが当たり前になっていくでしょうから．ＰＣにのるプロセッサは対称マルチコアですから，Cellのような大変さはないかもしれませんが，それでも，いままでと同じ方法では速くなりません．
マルチスレッドにして，徹底して非同期で作らないといけないでしょうね．

サーバ・アプリケーションは，マルチスレッドが当たり前になっていますから，このままでもいいんでしょうけど，クライアント側は普通そういう作りになっていませんから，作り方を変える必要があるでしょう．

そもそも，私は，クライアントがマルチコアになっても，あんまり意味がないと思っているですけど．あっても，２つくらいでいいでしょう．どうせ，プロセッサ設計上の限界が来ているので，コアを増やすしかないという話なわけですから．
クライアントで動いているアプリケーションで，どのくらいマルチコアの効果があるんでしょうね．
一部のマルチメディア関係のアプリケーションには意味があることでしょうけど．

投稿者 shingo : 18:24 | コメント (1) | トラックバック

2005年10月 1日

.NET Compact Framework と P/Invoke

カテゴリー: [プログラミング]

.NET Compact Framework で仕事してますが，いろいろやっかいな事が多くてまいっています．

P/Invoke(Platform Invoke)は，.NETから，DLLにあるアンマネージ関数（いわゆるネイティブな関数）を呼び出す仕組み（のよう）ですが，.NET Compact FrameworkのP/Invoke は制限が強く，Windows CEのAPIを呼び出すのに一苦労です．

基本的な型は自動的にマーシャリングされますが，構造体（特に文字配列を含む構造体）などは，その対象になりません．そういう構造体を引数に持つ関数を呼び出す場合，マーシャリングを手書きしてやらないといけません．

では，どうするのか．byte配列を作って，そこに構造体に必要な情報を頭から順番に詰め込むのです．．．
byte配列で無くても，他にも方法はあるようですが，自分でメモリを確保して，そこに詰め込むという点においては大して変わりません．それができるように，それを補助するためのクラスが用意されています．文字列を，エンコーディングに従って，バイト列にしたり，バイト列をコピーしたりするものです．

で，WindowsのAPIの呼び出しには，構造体が多用されています．もちろん文字配列を含むものも多いわけです．一つAPIを呼び出せるようにするために，膨大なコードを必要とします．
引数が簡単なAPIならいいんですけどね．

構造体のメモリ上の並びは，.NET Frameworkと違って必ず書いた順番になりますから，かえって楽ですし，メンバの型がマーシャリングの対象になる型だけなら，特に考えることはないようなんですが，理想条件ばかりじゃないですから．

まあ，プラットフォームをまたぐ呼び出しが面倒なのは理解できますが，ちょっと面倒というか，ごちゃごちゃしすぎている感じです．プラットフォームをまたぐ複雑さが，コードに直接出てきてしまう感じですね．その割には，制限のためにそもそも呼び出せないAPIもあるんですよね．

投稿者 shingo : 22:27 | コメント (0) | トラックバック

2005年9月28日

C#.NET

カテゴリー: [プログラミング]

唐突に，C#.NET を使う羽目になりました．それも，スマートデバイス（PDA等）向けの，.NET Compact Framework です．

まず，スマートデバイス向けのアプリケーションを作る必要があって，Visual Studio .NET 2003 では，.スマートデバイス用だと，NET Compact Framework 上のアプリケーションしか作れないので，.NETの利用が確定．そして，.NET Compact Framework では，Visual Basic か，C# しか使えないので，どちらかに限定されました．
さらに，.NET Compact Frameworkから，ネイティブのAPIを呼ぶ必要があったのですが，それにはC#が必要になるということで，こうなりました．（でも，そもそも，そのAPIが無いかもしれないということがわかってきて，ちょっとまずい状況．．．）

C#なんて，しばらく書くことは無いだろうと思ってましたが，予想が外れました．

どうも，.NET Framework というか，C#の思想というか，この何とも言えない泥臭さが，なかなか慣れませんね．中途半端というか無理矢理というか．．．うまい言葉が見つかりませんが．

投稿者 shingo : 23:55 | コメント (0) | トラックバック

2005年8月23日

バグ？

カテゴリー: [プログラミング]

昨日，Eclipse 3.0.1 と JDK 1.4.2_03 でプログラムを書いていたとき，変な現象に遭遇しました．

Object[] array = new ...;
for(int i=0; i < **; ++i){
    ...
}
for(int i=0; i < array.length; ++i){
    array[i] ...
}

本来のコードとはいろいろ違いますが，こんな感じで，forを２つ連続で使っている部分があって，２番目のループで配列にアクセスしていたのですが，ここで，ArrayIndexOutOfBoundsException が起きました．しかし，配列の長さ以上にループしないわけですから，逆立ちしたって配列をオーバーすることは無いはずです．
わけが分からなかったのですが，なんとなく，２番目のforループの'i' を'j'に変えたら，動くようになりました．
しかし，何がどうなって，２番目のforの条件を無視して突っ走ったのか．

コンパイラが悪いのか，Eclipseのデバッガの関係なのか，さっぱりわかりません．
本当は，ちょっと調べてみようかと思ったんですが，再現できません．
再現したからといって，原因が分かるわけではないですが．

再現しないこということは，たまたま何か条件がそろっただけなんでしょう．

まあ，人が作った物ですから，たまには変なことも起きますか．

投稿者 shingo : 18:08 | コメント (0) | トラックバック

2005年7月22日

MDA

カテゴリー: [プログラミング] [情報技術]

私の専門は，ソフトウェア工学，コンポーネントベースのソフトウェア開発なわけですが．．．

最近，MDA(Model Driven Architecture)，モデル駆動アーキテクチャの話を聞くことが多くなりました．
どうも実用段階に入り始めているようで，興味があったので，これについて一度書いてみたいと思っていました．

MDAのツールは非常に高価（数百万）ですし，少々大がかりな仕組みなわけで，私が触れる機会はありません．UMLで記述したモデルから，プラットフォームごとに自動でソフトウェアが生成できるという話なわけですが，私は正直，その実用性については半信半疑でした．

ただ，最近，MDAを研究していてツールをさわったことのある人の話を聞いたのですが，ちょっと考えが変わりました．かなりツールとしてちゃんとしたもので，モデルを与えるだけで，かなりのものを作ってくれるようです．

そもそも，私が半信半疑だったのは，その需要が理解できなかったからなのですが，ビジネスロジックが非常に長期間にわたりほとんど変化しない業種では，需要があるようです．
つまり，ソフトウェアの寿命が，それを支えるプラットフォームより遙かに長く，ビジネスロジックは変わらないのに，そのうちプラットフォームを維持することができなくなり，ソフトウェアを新しいプラットフォーム向けに作り直さなければならない状況になる場合です．
そういう場合でも，新しいプラットフォーム向けのモデル変換が用意できていれば，移植しなくてもすみます．確かに，そういう業種・分野では，十分需要のある話なのかもしれないと思うようになりました．

とはいうものの，やはり，どんなアプリケーションにも適応可能だとは思いません．

あと，どの程度のプラットフォームの組み合わせに対してモデル変換が提供されるのかとか，結局モデル変換の種類に依存するだけじゃないかとか，MDAというプラットフォームに依存するだけなんじゃないかとか，いろいろ疑問はあるのですが．
よりメタなところで記述しておく意味は理解できますけどね．

ただ，思うのは，MDAを使えるような人間は，十分な知識を持った人間だけだということです．高価なツールが必要でも，少人数のきちんとした知識を持った人間さえいれば，人件費の削減になるということなんでしょうけど．

結局，使う人間の知識・能力の問題になっている気がします．MDAに限らず，そうなっています．
これは，どんなに技術が進んでも，いや，技術が進めば進むほど，それを扱う人間に知識を要求するということでしょうね．

最近，足りないのは技術じゃなくて，それを使う人じゃないかと思ったりします．

投稿者 shingo : 20:25 | コメント (0) | トラックバック

2005年7月21日

凝り性

カテゴリー: [プログラミング] [研究]

ずいぶんさぼってしまいました．
まあ，いろいろやることが多くて，そういうときに限って，代わり映えのない毎日でネタ切れだったわけですが．

もっぱら，研究のためのソフトウェア開発だったわけですが，どうも私は凝り性ですね．研究上，凝らないといけないことには，もちろん凝ります．でも，そうでないものにも凝ってしまいます．

本当は７月頭には論文を書き始めるつもりだったのですが，作っただけではなかなか論文にはなりません．論文を書くため，その開発したソフトウェアに必要なデータを用意し，使ってみようとしたところ，いろいろと問題が．作り込みが甘いという，実用上，品質上の問題もありますが，研究の目的上，重要な部分の機能不足も見つかったりして，結局ずるずるといじっているわけです．
やらなくなくてはならないことが，次々出てくるわけで．さっきも一つ見つけたばかりです．
で，いじっていると，結局凝ってしまうわけですね．それを結構楽しんでいたりして．．．

まあ，これくらいそろえば論文は書けるのではないかと思います．というか，いったん切らないといつまでも論文にならないわけです．結局，研究の成果はコードじゃなくて論文なわけで．まあ，この辺が私の性格と合ってないような気がします．
論文を書くのも嫌いじゃないのですが，あえて言えば比較の問題ですかね．

投稿者 shingo : 23:28 | コメント (0) | トラックバック

2005年6月18日

fooとbar

カテゴリー: [プログラミング]

scp を Java から使いたかったので，Jsch という pure Java の SSH2 実装のライブラリを使おうとしてました．でも，Jsch には，これといってドキュメントはついていません．ただ，example コードがあるので，それを見れば使い方は，だいたいわかります．変なドキュメントよりはよほど有用です．（ドキュメントもほしいけど）

ただ，やはり一覧でAPIを確認したいので，javadoc はほしいわけです．もちろん，ソースがあるので，javadoc を生成することはできます．
でも，Javadoc コメントはないので，あまりまともなドキュメントになりません．もちろん，クラス名や，メソッド名，パラメータ名を見れば，理解の助けにはなります．
ちゃんと，名前が付いてさえいれば．．．

というのも，いくつかの重要なメソッドの引数の名前が，foo, bar とかになっていたのです．もちろん，ソースコードも foo や bar の羅列です．
おかげで，見ただけではパラメータに何を渡すべきかもわかりませんし，何をするメソッドかもわかりにくくなります．
example コードか，ソースコード自体を追っかけて，そのメソッドの使い方を探るしかありませんでした．

何でこんな名前になっているのか．普通わかりやすい名前にすると思うんですけどね．

投稿者 shingo : 03:48 | コメント (0) | トラックバック

2005年6月 3日

EclipseとCVSとダイナミックDNS

カテゴリー: [プログラミング]

自宅のサーバにCVSリポジトリをおいて，Eclipseからアクセスしたりしているのですが，Eclipseを長期間起動しっぱなしにしていると，そのうち，次のようなエラーが出るようになって，CVSリポジトリに全くアクセスできなくなってしまうことが，気になっていました．

認証エラー: com.jcraft.jsch.JSchException: Session.connect: java.net.ConnectException: 
Connection timed out: connect

でも，再起動すると直るのです．
ところが，ふと，実際にどこにつなぎに行っているのか調べてみたら，接続先が全然違うIPアドレスになっていました．サーバはダイナミックDNSなわけですが，そのIPアドレスは，古いIPアドレスでした．

どうも，名前解決の結果をずっとキャッシュしてしまっているようです．

どうしてこんな作りになっているんだろうと思いつつ，ダイナミックDNSみたいなものを使うのいけないのか，そもそもEclipseを動かしっぱなしにしているのがいけないのか，と思っていました．

しかし，どうも，Javaのライブラリ自体がキャッシュしているようです．それも，DNSレコードのTTLを無視して，無期限にキャッシュするようです．

Java's Secret DNS Cache

しっかり読んだわけではないですが，このblogを書いた人はJavaのDNS Cacheに苦労させられたらしく，ちょっと怒ってるようですね．
EclipseのCVS機能がやっているのではなく，Java自体がやっているとすると，あちこちに影響するわけで，知らないと問題の元でしょうね．

試してませんが，この動作は，プロパティを定義することで変えられるようです．

Networking properties from java.sun.com

例えば，JVM起動時に -Dsun.net.inetaddr.ttl=0 の様な引数を渡します．

このデフォルト値が，-1 (cache forever) になっているので，無限にキャッシュしてしまうようです．DNSレコードのTTLを参照するようにさせることはできないらしく，固定の時間を指定する事しかできないようですね．

でも，やっぱりデフォルトが -1 というのは痛いと思います．

投稿者 shingo : 23:28 | コメント (0) | トラックバック

2005年6月 1日

Groovy のオペレータ・オーバーロード

カテゴリー: [プログラミング]

Groovy では，クラスにあらかじめ決められたメソッドを実装することで，オペレータ・オーバーロード (operator overload) ができますが，最近，一番くだらない原因で，一番時間をとられたのが，このGroovyのオペレータ・オーバーロードです．

研究で Groovy を使っているのですが，<= とか < とかの比較演算子をオーバーロードしたくて，ここの解説の通り，compareTo というメソッドを実装したのですが，何度やっても，比較演算子が使えません．

例外が発生するのですが，その例外というのが，NullPointerException
おかげで原因がさっぱり分かりません．やっぱり，Groovy のエラーメッセージは，まだまだ不親切なんですよね．

いろいろと試行錯誤を繰り返して，何時間もこれにかかりっきりになっていました．半日以上使ったような気がします．

で，結局，単に，compareTo というメソッドを作るだけではなくて，java.lang.Comparable インタフェースを実装する必要があるようなのです．分かってしまえば，非常に単純で，当たり前といえば，当たり前ですが．
てっきり，他の演算子と同じように，リフレクションでメソッドを探すのかと思っていたので，気づきもしなかったです．．．
気づかなかったのは，私だけですかね．もしかしたらそうなのかも (^^;
でも，これは上の解説のページに書いてないですから．他のところを読めば載っていたのかな．

こういうのに引っかかって，原因がくだらないと，ほんとへこみます．特にやることが多いときは．

投稿者 shingo : 00:52 | コメント (0) | トラックバック

2005年5月11日

JRCSのとほほなバグ

カテゴリー: [プログラミング]

研究というか，研究室の他の研究への協力の成り行きで開発を手伝った，実験レポート提出システムに拙作のWebアプリケーションフレームワークが使われています．そこには，拙作のWikiエンジンも乗っています．

このWikiエンジンは，変更履歴をとるために，内部でRCS(Revision Control System) を使っていますが，RCSのアーカイブ操作のために，JRCSというライブラリを使っています．JRCSは，Javaから，RCSアーカイブを読み書きするためのライブラリです．
JRCSは，一度は，Apache Jakarta Project の sandbox のプロジェクトでしたが，今はまた，Jakarta Project からはずれているようです．

今は，ここで手に入ります．

http://www.suigeneris.org/kb/display/JRCS

ちなみに，日本語が通らないので，１カ所いじりました．

このシステムは，実験として，実際に使われているのですが，最近，特定のレポートを提出すると，RCSアーカイブの解釈中に落ちるようになってしまいました．
調べたところ，RCSアーカイブを出力する部分がおかしいのです．RCSでは，テキストを'@'で囲みます．テキスト自体に'@'が含まれていると，'@@'のようにエスケープします．ところが，そのレポートに使われている最後の'@'は，エスケープされないのです．

もうメンテナンスされていない感じなので，自分で直しました．

ただ，それがなんというか，とほほなバグだったんです．問題の，'@' を処理する部分です．

org.apache.commons.jrcs.rcs.Archive

    static public String quoteString(String s)
    {
        //!!! use org.apache.commons.jrcs.RegExp here !!!
        StringBuffer result = new StringBuffer(s);
        for (int i = 0; i < s.length(); i++)
        {
            if (result.charAt(i) == '@')
            {
                result.insert(i++, '@');
            }
        }
        result.insert(0, '@');
        result.append('@');
        return new String(result);
    }

StringBufｆer に入れて，先頭から順番に見ていって， '@'を見つけたら，'@'を挿入するわけですが．．．
赤いところにご注目．文字列はだんだんのびていくのに，もともとの文字列の長さしかループしてません．
これじゃ，'@'がいくつかあると，後ろのほうの'@'を取りこぼします．

正しくはこうです．

    static public String quoteString(String s)
    {
        //!!! use org.apache.commons.jrcs.RegExp here !!!
        StringBuffer result = new StringBuffer(s);
        for (int i = 0; i < result.length(); i++)
        {
            if (result.charAt(i) == '@')
            {
                result.insert(i++, '@');
            }
        }
        result.insert(0, '@');
        result.append('@');
        return new String(result);
    }

まあ，こういうバグを入れてしまう気持ちは分かる気もします．そして，この手のバグを一度入れてしまうと，再現する入力に出会わない限り，見つからないのもよくわかります．
これを見ても，最初はちょっと気づきませんでした．
でも，やっぱり，なんだかなあ，と思うわけです．
このコードのコメントにあるように，正規表現を使った方が良かったような気がします．

しばらく，何でRCSアーカイブが壊れるんだろうと思っていたのですが，まさかこんなバグとは（＾＾；

ところで，こういうのやってると研究が進まないんですけど．．．（＾＾；

投稿者 shingo : 15:29 | コメント (0) | トラックバック

2005年4月 9日

rngom

カテゴリー: [プログラミング]

研究上の都合で， RELAX NG で書かれたスキーマを処理する必要が出てきたので，簡単に RELAX NG を扱えるライブラリでもないかと探したところ，rngom (Relax NG Object Model) というのがあったので，いじっていました．

しかし，ドキュメントが非常に少ない．
ベースが，Jing (RELAX NGの validator) だということなので，そちらのドキュメントも見たのですが，それでも余り多くはありません．
結局，ソースコードを読みながら，試行錯誤することになりました．

まず，User's Guide を見て，基本的な使い方は分かったのですが，思った通りにいきません．
いきなり，XMLSchema のデータ型を使うところでつまづきました．その辺は，「rngomでXMLSchemaのDatatypeLibraryを使う」こちらに書きました．

こんどは，読み込んだ object model の使い方が分からず，また少し悩みました．しかし，何で Visitor パターンだってことに，すぐに気がつかなかったんだろう．
やっぱり，頭がぼけているときにコードを書いてはいけませんね．

ここ数日は，これをずっとやってました．

余談ですが，これを調べているときに一つ分かったことがあります．
わたしは，RELAX NG を 「リラックスエヌジー」と読むのだと，ずっと思っていたんですが，本当は「リラクシング」と読むのだそうです．
うーん．ちょっと無理があるような気がしないでもない（＾＾；

投稿者 shingo : 01:33 | コメント (0) | トラックバック

2005年4月 6日

バグ

カテゴリー: [プログラミング]

ここしばらく悩まされていたバグが，実は，JRE自体のバグだったことが分かりました．

動かし続けていると，ファイルディスクリプタを食いつぶして，"Too many open files" になって，ファイルに抽象化されているあらゆるものが開けなくなってしまうという問題だったのですが，コードをどんなに修正しても直りませんでした．

結局，JRE自体にバグがあったわけです．SocketChennel を使ってソケットを作って，なおかつ，setSoTimeout() でタイムアウトを設定すると，close が効かなくなるバグでした．そのため，リソースリークしてしまいます．
例外も何もいっさいでないので，原因がさっぱり分かりませんでした．

Bug ID: 4726957 (so) Socket.close fails if timeout set on Socket created from SocketChannel

Bug ID: 4724030 (so) Async close of socket stream fails when timeout specified

使っているのは，1.4.2 系ですが，このバグは，まだ，fixされていないようです．ずいぶん昔からあるバグのようですが．．．

JavaのNIO(new I/O) 関係には，未修正のバグが他にもあるようです．

Bug ID: 4720952 (so) SocketChannel.socket().getInetAddress() returns null after close

最近，new I/O の機能を使っていろいろ作っているので，ちょっと気を付けないとまずいです（＾＾；

しかし，Java の new I/O にこんなに問題があるなんて，ちょっと思いませんでした．

通常，バグが出たときは自分のコードを疑うものです．よくテストされたコンポーネントを疑うより，書いたばかりの自分が書いたコードを疑う方が理にかなっています．ただ，ごらんの通り，たまにこれは裏切られるわけです．
もちろん，コードが手元にないので，一定上の検証ができないので，自分のコードを調べるしかないというのも理由です．
今回のように，長時間動かしてリソースを食いつぶさないと発覚しない，リソースリークがらみのバグだと，テストコードを書いても，なかなか再現しなかったりします．そもそも，何が原因なのか調べるだけで，一苦労です．

ソフトウェア部品の再利用は，これからも増えていくでしょうが，その一方でこの手の問題は増えていくでしょうね．バグの原因が見つからないことや，コンポーネント側に問題があることが分かるまで時間がかかることも，もちろん問題ですが，それよりも，バグが回避できなかった場合には，さらに致命的な問題となります．
研究で，ソフトウェア・コンポーネントをテーマにしているので，このあたりは，研究的にも興味あるところです．もっとも，こういう問題に技術的対処がどこまで有効かは分かりませんが．

そういえば，Javaをオープンソース化するべきか，するべきでないかという話題が，しばらく前からよく出ていますが，Sun Microsystems は Java の分裂を危惧して，一貫してオープンソースにはしないという態度です．
でも，いつまでも直らないバグがあったりすると，自分で直したい人もいるでしょうねえ．もっとも，オープンソース化してバグが減るかは分かりませんが．．．．

投稿者 shingo : 00:50 | コメント (0) | トラックバック

2005年3月28日

コード=ドキュメント

カテゴリー: [プログラミング]

私は，コードを読みやすく書くことを常に心がけます．最初はいい加減に書いても，必ず，徐々に整理していきます．どんなにドキュメントを詳しく書いても，結局，コードが一番正確で詳しいと思っているからです．

ドキュメントをいっさい用意しないで，コード読め，っていうのは，もちろん勘違いですが，コードよりも，いろいろなドキュメントを書く方に注力するのは，大事なところを間違えていると思います．
ちなみに，私が書くドキュメントというのは，Javadocのように自動生成されたドキュメントとその補足，ユーザ向けの使用方法などです．ソフトウェアの種類や，その設計の内容によっては，設計の概略についてドキュメントも書きます．ただ，設計について詳しく書けば書くほど，コードが変わったときに，ドキュメントを追従させるコストが発生するので，一定以上に詳しくは書きません．

ただ，こういうことを誤解を招かずに説明するのは非常に大変です．その点，この文章は，非常にわかりやすいです．
ソフトウェア系の人には有名な Fowler さんの文章の日本語訳です．

Martin Fowler's Bliki in Japanese - コードがドキュメントだ

無駄なドキュメントというのは，結局読まない（読まなくても問題ない）ドキュメントや，読んでも意味が分からないドキュメントですね．
あとは，古くなって最新コードと一致していないドキュメントなんかは，害の方が大きいです．
こういう無駄なドキュメントというのは，結構あるようです．

詳細な実装なんかはコードを読めばわかるのですから，ドキュメントには，コードを読んでもわからないような，設計の大枠とか，設計方針とか，そういうものを書いておくべきものだと思います．
コードがあれば，自動で生成できるものについて，手で詳細なドキュメントを書くのも変な話です．
もちろん，設計過程でいろいろと書くものは別です．ただ，私はこれは，ドキュメントと言うよりメモだと思っていますが．

どこかで読んだ記憶があるものの受け売りですが，昔は計算機の環境が貧弱で，ソースをドキュメントとして使えるほどわかりやすく書くことができなかったので，フローチャート等のドキュメントが必要だったが，今はそういうことはなく，コードと重複するものを書く必要はないわけです．

ちなみに，フローチャートは，名前の通り，流れ（フロー）をもろに書ける（流れしか書けない）ので，構造化プログラミング以前のものですから，もう捨てるべきもののはずですが，未だに使っているところがあるそうなのです．この話を聞いたときには，ちょっとびっくりしましたね．あんまり，詳しくは書けませんが．
それが役に立つのかと言えば，きっとそんなことはないのです．結構な残業代を使って書いているんだろうなあ，と思います．

投稿者 shingo : 20:28 | コメント (1) | トラックバック

2005年3月26日

Eclipseの欠点？

カテゴリー: [プログラミング]

この前，Eclipseについて，いろいろと書きましたが，今回は欠点についてです．

といっても，大したことではありません．普段は忘れていて，ほとんど文句などでないのですが，たまに思い出す重大な問題があります．
それは，重いことです．

もちろん，こればっかりはどうしようもないのですが．
それに，Javaのアプリケーションとしては軽い方ですし，そもそも速いＰＣなら，気になりません．
しかし，ノートＰＣで開発しているときは，本当に重いと思います．

今は，また実家に帰ってきているので，ノートＰＣで作業しているわけですが，Pentium III 800MHz メモリ 640MB の環境では，どうしてものろのろになります．メモリはめいっぱい積んでいるのですが，私の使い方だと，足りないようです．
まあ，私が普段から，マシンにかなり無理をかける使い方になれているというのもあるのですが．
このノートＰＣは，２年半くらい前のモデルですから，やはりいろいろと無理があるのでしょう．

もう一つ問題があります．これまた，Eclipseだけの問題ではなく，統合開発環境全般に言える問題です．それは，画面の広さ（解像度）を要求することです．

このノートＰＣは，1024x768 の解像度しかないので，左側にパッケージエクスプローラをおくと，かなりエディタが狭くなります．また，下にコンソールや，そのほかのビューをおくと，もう狭くて狭くてたまりません．
ですから，できるだけ広さを稼ごうと，エディタのフォントサイズは 8pt にしています．ただ，普通のフォントでは，8pt にするとつぶれてしまうので，つぶれにくいフォントとして，モトヤのフォントを使っています．
（ただ，どうしても判別しにくい文字があるのも事実ですが．．．）

普段は 20インチ，1600x1200 の液晶モニタでの開発ですので問題ないのですが，たまに狭い画面を使うと面倒です．ちなみに，20インチもあると，液晶なら，1600x1200 でもかなり小さい字まで判別できますので，さらにフォントを 8pt にして広さを稼いでいます．

やっぱり，今度ノートＰＣを買うときには，SXGA(1400x1050)の解像度にしたほうがよいかもしれません．

投稿者 shingo : 22:59 | コメント (0) | トラックバック

2005年2月26日

Ajax

カテゴリー: [プログラミング]

最近 Ajax (Asynchronous JavaScript + XML) というものを知りました．Webアプリケーションにおいて，ページをリロードすることなく，サーバと通信してページを更新できるものです．

"JavaScript to Java remote communication" という言葉が示すとおり，JavaScript から RPC(Remote Procedure Call) で，サーバ側のJavaプログラムと通信をするものです．
ですから，ページ全体をリロードする必要がありません．

これは，なかなか革新的な技術だと思います．まあ，Ajax自身は，既存技術の組み合わせであるのですが．
やり方自体は考えつくかもしれませんが，それが実際に使える仕様と実装にまとめられ，すでに使える物になっていることが重要です．
ちなみに，GMail もこれで実装されているそうです．

雑用があったので，まだ，きちんと調べていないのですが，おもしろそうです．
いろいろ問題点が指摘されつつも，Webアプリケーションは今後も廃れる様子がありません．インターネットを介してサービスを提供することが当たり前になっている以上，廃れるどころか増えるでしょう．
イントラネットなら，リッチクライアントもいいでしょうけど，インターネットだとそうもいかないですから．
これからの，Webアプリケーションのプレゼンテーション層，ユーザインタフェースを構築する手法が変わるかもしれませんね．

投稿者 shingo : 21:15 | コメント (0) | トラックバック

2005年2月21日

Eclipseの功罪

カテゴリー: [プログラミング]

まあ，あんまりネタが思いつかないので，このブログらしく技術ネタを一つ書いてみます．

私は最近Eclipseを使ってしかJavaのプログラムを書かないんですが，Eclipseを初心者に使わせるとよくないことがあるという意見をあちこちで聞くことがあります．
これについて本当にどうなのかというのは，検証できない話ですので，私の主観で書いてみようかと思います．

そもそも，Eclipse を使うとプログラミングが身に付かないという意見がなぜ出るか．
Eclipse は非常に便利です．では，なぜ便利中といえば，その一つはEclipseが，多くのことを内部で自動的に処理してくれるからです．つまり，その自動で処理されている知識が欠落するのではないかという懸念があるのだと思います．
コンパイルなんか，その代表格でしょう．

反論もあって，その一つに，今時プログラムを打ち込むのに紙テープを使ってないのと同じだというのもあります．まあ，コンパイルとかの知識は，紙テープほど古い物とは思えないので，ちょっと言い過ぎかとは思いますが．

私は，便利な物は使えばいいと言う人間なので，便利であることが問題であるとは思いません．また，苦労すると覚えるとも思えません．どちらかといえば，便利な方法を知らない方が怖いですね．
うちの大学のプログラミングの演習では，コマンドラインでgccを使わせるのですが，結局，gcc のコマンドをおまじない程度にしか認識していない人は多いです．
そのせいで，プログラムの実行直前には，必ずコンパイルするという行動をとる人がいました．つまり，自分が何しているのか全くわかってないのです．（何をしているか教えないのも悪いのですが）

Eclipse はバックグラウンドで勝手にコンパイルしてくれますが，じゃあ，手動でやったらわかるのかと言えば，そんなことはないでしょう．

Eclipse の便利な機能に，補完機能と，文法チェック機能があります．これをやると，コンパイルが通った喜びを初学者に感じてもらう事が出来ないという意見を見たことがありますが，そもそもそんなところで喜んでいることが間違いです．動かすことが目的なのであって，コンパイルなんて通って当たり前です．
ちなみに，Eclipse を使わせても，教えないと補完機能なんかは使い始めない人もいます．

コンパイルにしたって，操作を教えたり，それを繰り返させても意味が無く，その意味を教えないでしょう．意味が分かっていれば，計算機が出来ることはやらせておけばいいのです．
勉強する気のない人には，何を使わせても同じ事でしょう．会社何かだとそうもいってられないので，Eclipseはよくないとかいう話になるのかもしれませんが，使いたいと言う人にわざわざ使うなと言ったりすることもあるようですから，それはどうかなあと思います．

結論みたいになりますが，私の主観としては，Eclipse を初学者に使わせるのは全く問題ありません．実際に，私も研究室の学生には積極的に勧めています．
あと，これは，会社等の組織での話になりますが，ツールの種類に関わらず，きちんと指導することです．もちろん中身について．

それに，Eclipse を使うとコードの質が上がる訳ではありません．あれは，あくまで便利な道具ですから．
能力を上げるには，別の努力が必要で，その時間を確保するために，実際の作業をさぼったっていいと思います．というか，そうするべきです．ただでさえ，計算機というのはややこしいのですから．浮いた時間分だけ，どんどんコードを書いた方がよっぽどいいでしょう．
まあ，勉強として，試しにコマンドラインからやってみるというのも，少しは必要かもしれませんが．

ちなみに，私は最初からIDEでした．Microsoft Cを買う金が無くて，２万円くらいで手に入る Quick Cを使っていたからです．これは，MS-DOS上で動作しますが，立派にIDEです．
こればっかり使っていたので，コマンドラインからコンパイルする事なんて滅多にありませんでした．でも，別に知識を得る上で，何にも困ったことなんてありませんでしたけどね．
ちなみに，Javaでは，vim + javac, 秀丸 + ant, Eclipseと移ってきました．私は便利な道具があれば飛びつくので．

何？私では例が悪いと．まあ，ごもっともです（笑）

投稿者 shingo : 23:49 | コメント (0) | トラックバック

2005年2月19日

CLOSE_WAITがたまる

カテゴリー: [プログラミング]

今日（もう昨日か）は，ほとんど，ずっとデバッグでした．
さんざん悩ませてくれました．一応解決したようなので，メモ書きとして書いておくことにします．

Javaで書いた，あるTCP通信をするプログラムで，サーバ側にCLOSE_WAITの状態のTCP接続がたまり続けて，ファイルディスクリプタを食いつぶすというバグが見つかりました．長時間動かしていると，"Too Many Open Files" になって，何にもソケットの操作ができなくなり，お手上げになってしまいます．

いろいろと切断方法を変更してみても，CLOSE_WAIT な接続ができてしまいます．

結局，SocketのshutdownOutput() と shutdownInput() を呼び出すことで，回避できました．原因がはっきりしないのが，どうにも気にくわないんですが．shutdownOutput() が TCPの接続修了処理をやるみたいなので，それのおかげだと思うのですが．．．

しかし，今まで普通に close しても問題を起こしたことはなかったんですが，何がおかしかったんでしょうね．謎です．こういう，動いたけど理由が分からないというのが，最悪ですね．

投稿者 shingo : 01:41 | コメント (0) | トラックバック

2005年2月 9日

私のプログラムの作り方

カテゴリー: [プログラミング]

しばらく，研究のシステムの開発がなかなか進まなかったんですが，やっと今日あたりから進み始めました．設計以前に要求の詳細が決まらなかったので，全然書けなかったんです．設計の大枠が決まって，勢いがついてくるまで，どうしても時間がかかります．

私は，プログラムを書くとき，設計はしても，いわゆる設計図は書きません．頭を整理するために個条書きにして書き出したり，ちょっといたずらがきをするだけです．
私はもっぱらJavaを使うわけですが，Java の場合，interface を書いていけば，そのまんま詳細設計のようなものです．わざわざ，設計図を書く必要なんてありません．
机上で書いた設計図なんて，実際のコードを書くときは実装の都合で変わるわけで，丁寧に書くだけ時間の無駄です．実態（ソースコード）と食い違った設計図なんて，百害あって一理無しです．じゃあ，一致させればいいのかといえば，それはとてつもない労力でしょう．
# とかいって，大学生の時に，そういうツールを研究したことがありましたけど．あのころは違う考え方だったので．
前の指導教官には，よく設計図無しに書けるねと，しょっちゅういわれたものですが，確かに私はものぐさですが，いい加減だからこうしているわけじゃないです＾＾；
よほど大規模でない限り，すくなくとも最初に書く設計図は必要ないと思います．

設計をする人間と実装する人間は別である，ということがほとんど当たり前とされていますが，設計ができない人間が実装しても，設計者の意図を読めるわけもなく，実装できない人が設計図を書いても，実装しにくい設計ができるだけだと思います．じゃあ，両方できる人が，それぞれ役割分担すればよいかといえば，そんなのは無駄なわけです．

ちなみに，私はコメントもほとんど書きません．interface にJavadocコメントを書くだけです．どんどんコードを書き換えるのに，コメントも一緒に直すのは面倒この上ないからです．ただ，トリッキーなことをしているところには，その理由を書くことはありますけど．

いわゆる私の作り方は，最近の流行っぽくかっこよくいうと，アジャイル(agile)的な開発という奴に分類されるんでしょう．それを意識してますし．ただ，合理的だとは思っていますが，どこでも簡単に適応可能な方法とは思っていません．いろいろな意味で，人を選ぶ方法でしょう．規模も選ぶと思います．

ただ，こういうアジャイルは間違っていると思いますが．．．

＠IT：開発現場の天国と地獄（3）

この例は，プロジェクトが燃えちゃったから，アジャイルなやり方にせざるを得なかったというだけのような気がします．．． 確かに効率がいいですからね．プロジェクトが燃える→人が燃え尽きる→逃げる→会社が消えるって感じですか．私はいわゆる現場を経験していないので，こういうのは伝聞でしかないんですけどね．

ソフトウェア工学の歴史上，いろんなツールが作られてきましたが，結局プログラマがそれを使うのに必要な能力は，少なくなるどころか増えているように思います．結局，人が作っているわけなので．労力は減っても，知識は要求するんですよね（それでも，VisualBasic とかはある程度成功したと思います）．
結局，先進的方法ほど，知っている人にしか使えない，できないわけです．当たり前ですが．
人という条件が揃わないと，やっぱりだめなんですよね．

それにしても，エンジニアが足りないっていって，こんなに増やしたのは誰ですか（＾＾；
まあ，数は必要なんでしょうけど，結局，数だけの問題じゃないんですよね．

ソフトウェア開発を機械的作業に落とすことを目的に，ずっときているわけですが，適応範囲の広い機械化に関しては，できるところはしてしまったんでしょう．最近は，アプリケーションドメインに特化した自動化がほとんどだと思います．Executable UML のように，設計図を書くと「自動的に」実装ができるという技術(MDA=Model Driven Architecture)も，設計図という名のプログラムを書くことになるだけに思えます．まあ，私はMDAに関しては不勉強なんで，もっとすばらしいのかもしれませんが（＾＾；
個人的には，UMLは，実装の話を忘れてモデルに注力できるから役に立つのであって，実行できるほど詳細なモデルは，意味がないと思っているんですが．
ただ，どこまでできるようになるのか，興味がないわけではないです．

ソフトウェア工学も，いろんな流れがある中で，MDAのような流れと，アジャイルのような流れの 大きく２つに分かれているように思います．どういう風になっていくんでしょうね．単に，棲み分けをするだけになる気がしないでもないですが．私は，当面アジャイルの方でしょうけどね．

うーん．また長い．プログラムだけじゃなくて，文章も短く書く訓練をしないといけないかも．．．

投稿者 shingo : 00:49 | コメント (0) | トラックバック

2005年1月28日

「センス・オブ・プログラミング」／「Ｃプログラミング診断室」

カテゴリー: [プログラミング] [本]

研究室にあった本を適当にめくっていたら，おもしろそうな本を見つけました．
ちゃんと読んだわけではないですが．

扱っている範囲はやたら広いです．プログラムとは何かという話から，リソース管理などのOSの役割，モジュール化についてなどなど，いろいろなことを書いてあります．
ここに説明されている内容は，それぞれの専門書には，もちろん細かく解説されているような内容です．
深く知りたいなら，そういう専門書の方がよいでしょう．
しかし，プログラミングをする上で，さけては通れないことを，広く浅くふれています．
なかなか，最初は何が必要なのかすら分からなかったりするものですから，最低限のことを知るという意味で，初学者には，向いているような気がします．
また，ある程度かけるようになってきた人にも，是非読んでもらいたい本です．結構大事な事が書いてあったりします．

言語は特に固定せず，CやJavaを例に挙げて説明してあります．
「プログラミング言語」ではなく，「プログラミング」を取り上げた本です．

最近は増えてきているとはいえ，こういう一見分かりきっているけど明文化されていないものを，きちんと本にしているのは珍しいので，プログラムをこれから書くという人にも，プログラミング言語はかけても，ソフトウェアは作れないと言う人にも，是非勧めたいですね．

これを読んで思い出したのが，この本です．

「Ｃプログラミング診断室」

私が，高校生の時に買った本で，これを読んでから，コードの書き方が変わり，今までまともに動かすことができなかった，ある程度規模の大きいプログラムを動かすことができるようになりました．
いわゆる，言語は書けるがソフトウェアは書けないという状態を脱するのに，役に立った本です．

この本では，うまいコードの書き方が書いてあると言うより，実際に書かれた「とんでもない」コードを材料に，こんな書き方をするからうまく動かないんだということを，一つ一つ説明している本です．
単純に，読み物としてもおもしろいと思います．

言語はＣ言語ですし，環境もUNIX系の環境が主ですが，他の言語や，環境にも通じることが書かれています．
一部の内容は古くなっていて，最新の言語，環境やソフトウェア工学の事情とはちょっと違いますが，ほとんどは今でも通用する基本的なことです．Ｃ言語に特有のテクニックがけっこう多いので，そういうところは他の言語ではあまり役にたたないと思いますが．

この本は，初版の内容ですが，サイト上ですべてが公開されていますので，読んでみてください．本当は，買った方がいいんでしょうけど＾＾；

私が当時やたらと受けた部分のうち，一カ所を引用しておきます．

Ｃプログラミング診断室／珠玉の力作／サボリの美徳 より

ソースリストが長くなるほど、全体が見えにくくなり、取扱いの困難なソフトになっていきます。内容の理解度は、長さの２乗、３乗あるいはそれ以上のペースで悪くなります。短くできるものは短く書きましょう。キーボードを押すのも面倒だなと思いながらプログラミングしていても長くなって困るのですから、「がんがん書くぞ！」なんて頑張られたら困ってしまうのです。消す手間がかかるではありませんか。

投稿者 shingo : 02:40 | コメント (0) | トラックバック

2005年1月21日

怠け者と働き者

カテゴリー: [プログラミング] [情報技術]

おもしろい記事があったので紹介．
研究の結果を引用して，具体的な数字を出していて，説得力があります．


人材不足と慢性的残業の悪循環を断ち切る : Hotwired

こんな数字を出してこなくても，プログラマの能力差が２倍や３倍どころではなく，１０倍以上になることは，プログラマ同士なら気が付いています．仕事を見ていれば，だいたいわかります．
気が付いていないのは，給料を払っている側だけです（笑）
実際，現場でこれだけの差があるのです．

同期で，実際の開発に関わっている人間の話を，直接，間接的に聞くことがありますが，それはもうひどいものです．私は酒を基本的に飲みませんが，飲んでなければ聞けない話です．
できないプログラマというのは，文字通り「できない」のです．能力が低いとかいう以前の問題です．

私は，ソフトウェア開発の仕事をアルバイトとしてやってきました．
既存のプログラムの修正や機能追加を依頼されることが多かったのですが，中には，それはもうひどいコードがありました．動けばまだいい方で，動かなかったりします．ある操作をすると，「必ず」落ちるとか．．．問題外です．コードがデバッグできる状態ではないので，バグがとれなかったんでしょう．

使えないプログラマの何が問題かって，仕事量の絶対値ばっかり大きくて，実際はマイナスだということです．労働時間は長かったりするので，仕事をしているように見えますが，自分でバグを生産して，はまっているだけだったりします．
能力のあるプログラマは，それを探し出しては，せっせと削除することになるわけです．さらに，作り直さないとなりません．
ゴミの山を作った人間の生産量は，単に他人の労働時間を増やしているだけですから，マイナスです．そして，直す人の残業時間がまた増えるわけです．

生産性の高いプログラマと，低いプログラマの間の残業時間に特に差が生じませんから，時間給である以上，給料の差も生じません．下手をすれば逆転します．
そうすると使える人間から順番に逃げていきます．この辺のことは，上の記事に書いてある悪循環の図が，的確に説明しています．

上の記事でも少しふれていますが，この悪循環の輪は，大学などの教育現場にまで拡大しているように思えます．つまり，学生は将来金にならないことはやらないのです．
いろいろ自分で勉強している人間は，好きだからやっているにすぎません．
資格を取ると，少し「手当」がもらえるので，それはがんばります．しかし，その中身を理解し，仕事に反映させようという意欲からではありません．資格という看板が，金を生むからやっているだけです．正直，資格なんて持っているだけなら無意味です．

以前にも書きましたが，ソフトウェア開発の現場では，プログラマを歯車にしようと試みてきました．
ですから，個人の工夫なんていうのは邪魔なだけで，コーディングルールという名の枷をはめ，できるだけ生産性の低い人間のレベルにあわせて，コードを書かせようとするくらいです．
（コーディングルールが全く無意味だと言っているわけではないです．念のため）
そんなんでは，おもしろい仕事にはなりません．能力は評価されないどころか，発揮することすら許されなくなります．

金の話ばかりしてきましたが，魅力的な職場というのは，金だけではなく，「おもしろく」なければなりません．大金を渡して，毎日単調作業だけをやってくれといっても，普通発狂するでしょう．
正当な対価と知的満足．それらがないと，優秀な人間から順番に逃げていくのです．．．

こういう事を考えると，自分の今後の進路について，さらに悩むわけですが．．．

投稿者 shingo : 18:19 | コメント (2) | トラックバック

2005年1月18日

プログラミング言語としてのXML

カテゴリー: [プログラミング]

このあたりを読んで思ったこと．

Matzにっき　(2005-01-13)　「私はなぜXMLを愛していないか」
型なし言語XML : NDO::Weblog

ほとんど自分の考えを整理するためのメモ書きですので，無駄に長文で，まともな文章ではないですが，その辺はご勘弁を．

私も，XMLをプログラミング言語のように使う研究をやっていたので，それがどんなにややこしいことか，わかっているつもりです
より汎用的なことをやろうとしたとたん，おもいっきりはまりました．苦労した割には，そんなに自由にプログラムが書けるようにはなりません．

自分でやっておいていうのはなんですが，そもそも，プログラミング言語として使うのは，XMLの目的からはずれているわけです．
静的な要素を宣言的に記述する局面ではある程度有効ですが，もうちょっと書けないかな，と欲を出すと，もうだめです．
私は，アプローチを間違えたというか，変な欲を出してしまったと思っています．
全く別の書き方を選択するべきでした．

いろいろな議論で似たような話出てきますが，結局，大きく分けて，次の３つのXMLがあるわけです．

  1. マークアップ言語としてのXML
  2. データフォーマットとしてのXML
  3. プログラミング言語としてのXML

本来は，１．が目的でしょう．
しかし，ほとんどのXMLは，データフォーマットとしてのXMLのような気がします．
それも，通信用だったり，設定ファイルだったり，さらにはデータベースだったりすることさえあります．
そして，３番目として，プログラミング言語のような振る舞いをするようなものもあります．
（私が今作っているものもそれに近いです）

型のないXMLはだめだとか，冗長性は悪であるという議論は，主に２． or　３．の視点でXMLを評価した場合に出てくるものでしょう．

Matzにっき(2005-01-05)

こっちを読むとよりはっきりします．
JavaでXMLを使う場合，XMLに「頻繁に変更される要素」を切り出すような事をすることが多いです．
これが，XMLをスクリプト言語として使うという話になるんだと思います．
こういう用途が，そもそもスクリプト言語では問題にならないことなんだ，というのもわかります．

XMLは，データフォーマットや，プログラミングに使えそうに見えます．
ツールがそろっているので，なおのことそう思えます．
それで，実際そう考えた人たちがいろいろいじったので，さらにそれっぽくなっています．
それでも，Java と XML の間の隙間が，完全に埋まるわけではありません．

型をつければいいかといえば，そういう問題でもないでしょう．
動的な言語ならともかく，Javaのように強い静的な型を持つ言語では，それほど便利にはならない気がします．
そもそも，この問題は使い方の問題であって，XML自身が悪いわけではありません．
XMLを改良するべきであるという話ではないと思います．
単に，一つの記述方法で何でもやろうとしているところに問題があるのでしょう．

ただ，XMLは，そのいろいろなツールのおかげで，結構便利に使えますから，現実的な選択として，データフォーマットとしてXMLを使うのは十分ありえるわけです．
ツールのおかげで使えるようになっただけで，XML自身がそれに向いているわけではないのでしょうが．
まあ，その辺は気にしても仕方ないと思っています（笑）
XMLSchemaを使えば，validation もやってくれるので，データフォーマットとしてもそれなりに使えます．
しかし，結局 Java のコード側で，型に合わせてパースする必要があるのが問題というのは，理解できます．分散しますからね．
ですから，私の場合，JavaからXMLを使う場合は，RelaxNG と Relaxer を使っています．プリミティブな型なら，これで何とかなりますから．
RelaxNG は，XMLSchema と比べて，大げさでもありませんし，スキーマさえ書けば，コードは自動生成されます．
Relaxer もこれはこれで問題がないわけではないんですが．．．

また，Javaでスクリプト言語をやるなら，私は，素直に Groovy などのJava上で動作するスクリプト言語を使うべきだと思います．

いまいちすっきりしなくて，消化不良ですが，今回はこんなところで．

投稿者 shingo : 21:32 | コメント (0) | トラックバック

2005年1月11日

プログラマーとのつきあい方

カテゴリー: [プログラミング]

少し前に見つけた，ちょっとおもしろいページ

プログラマとつきあう

ゲーム業界の話が入っているので，少し違うところもあるでしょうが，おおむねこうなんでしょうね．

結局，直接向き合っているものと，顧客が見る成果物が全く別の姿をしているのが，ややこしい話なんで
すよね．
どうして，こんな「呪文」を書くと，ウィンドウが開くんだよとか．
一般人にとっては非常に似ていて，一方から一方に簡単に変更できそうなものが，コード上で見ると，大幅に違うものだったりします．通常の視点で見ている世界とは，距離感が違うというか，そんな感じです．

プログラムを書けば書くほど，計算機は馬鹿だと思います．馬鹿正直に自動化する機械なのです．
プログラミングとは，そのお馬鹿さんに，一から十まで教えてやって，膨大な仕事をやらせる仕事です．
というか，一から十までやらせるには，一から百まで教えてやらなけりゃ，動かないのが計算機です．

ソフトウェアを作るというのは，処理対象を様々な角度，様々なレイヤーで分析し，それを，すべて計算機が理解できる表現に変換し，再構築する作業で，誰にでもすぐにできるようになるものではありません．
基本的に人間が作ったものなので，訓練さえすれば誰でもできるようになるはずであるとは思っていますが，十分な訓練が必要です．運転免許みたいに，直感的なものではないのです．

そのような訓練の結果，プログラマは，一般人からちょっとずれた（笑）センスを身につけます．
その結果，世界を独自のロジックで観察し，機械の言葉で書き下す事ができるようになるわけですが，結局，一般人から見るとは，何やってんだかさっぱりわからん，ということになるわけです．
きっと，それが数多くの悲劇を生んできたのでしょう＾＾；；
ちなみに，そういうセンスを持つと，年末調整とかの書類をみて，情報処理の設計がおかしいとか思うようになります（実話）＾＾；

ソフトウェア工学は，いかにさぼってものを作るか考えてきたわけです．さぼるために多大な努力してきました．個人の訓練も同じで，さぼり方の訓練のようなものです．
もう一つの悲劇は，それがあまり理解されていないことです．
優秀な人ほど，早く正確に仕事を片づけられるわけですが，残業やってがんばっている人の方が，仕事をしているように見えてしまいます．見ている人には，プログラミングなんてわかりませんから．
たとえ，残業しながらバグを生産しているだけだとしてもです．

まあ，これは，ソフトウェア工学の歴史上の問題でもあって，ソフトウェア工学は，ソフトウェア開発を工場のラインのようなメタファで考えてきました．ですから，プログラマを均質な歯車として扱おうとしてきました．最初から個人の能力差なんて考慮していないともいえます．．
まあ，最近は必ずしもそうでもないようですが．

ものぐさにやらないと，プログラマなんて，心も体も参ってしまいます．
プログラミングは，あくまで頭脳労働であるべきです．
ものぐさにやっている人が，一番生産性が高いんだというのは，どうやったらわかってもらえるんでしょうねぇ．
熟練したプログラマは，徹底的にさぼります．まあ，一番いいのは人にやらせることです（笑）

ここまで駄文を読んでくれて，どうもありがとうございます＾＾；

投稿者 shingo : 22:43 | コメント (0) | トラックバック