ロングマン第4版入手
数か月前にアマゾンに注文していたロングマンがようやく到着。なんかアマゾンって早い時は早いけど、遅い時は、とことん遅いね。付属のソフトが使いものにならないというのは聞いていたので、速攻でEPWINGに変換。ありふれたmanyをひいてみる…
--- 引用(テキトー翻訳) ---
manyは主に疑問文と否定文で使用され、それ以外の場合にはa lot ofやplenty ofを使用する。ただし、正式な文章ではmanyを使用しても良い。またtoo、so、asの後に続く場合にも使用して良い。manyの後にandを続けたり、副詞の前にmanyを置いてはいけない。
--- 引用終り ---
ひぇ〜、そんなにいろいろとルールがあったんですか。奥が深いなぁ、こういうのを指摘してくれるスペルチェッカみたいなソフトは無いもんだろうか。
NetBeans 5.5のJavaDoc生成
NetBeans 5.5のJavaDoc生成では、結構新しいオプションを使っているので(-sourceとか)、Java Platform Managerで、1.3.1 VMとか指定していると、サポートされていないオプションというエラーで終了してしまう。
とりあえず、javadocだけ最新のものを使うようにするには、build.xmlの最後に、
<property name="platforms.IBM_Classic_VM_1.3.1.javadoc" value="d:/jdk1.5.0_06/bin/javadoc"/>
などと指定してやればいいようだ。真ん中の"IBM_Classic_VM_1.3.1"の部分は、Java Platform Managerで指定している名前で、空白は"_"になる模様。このようにすれば、コンパイルには1.3.1を使って、javadocだけ5.0で生成できる。しかしNetBeansのAntスクリプトは本当に良く考えられているなぁ。
電車の中は、なぜか集中できる。
久しぶりにオフィスに行ってきた。電車の中で、PC拡げて作業をすると妙にはかどるのは、なぜなんだろう。行き詰まったら山手線に乗って作業するか… でも多分乗ってる時間が限られているから、集中できるんだろうな。
[備忘録] 見えないフィールドにアクセス。
ユニットテストの時に、外からは直接見えないフィールドにアクセスする。
@SuppressWarnings("unchecked")
<T> T getField(Class cls, Object thisObj, String fieldName, Class<T> fieldClass)
throws NoSuchFieldException, IllegalAccessException
{
Field field = cls.getDeclaredField(fieldName);
field.setAccessible(true);
return (T)field.get(thisObj); // unchecked warning
}
例えばFilterInputStreamの"in"フィールド(protected)を覗く。
FilterInputStream fis = new BufferedInputStream(new ByteArrayInputStream(new byte[0])); InputStream in = getField(FilterInputStream.class, fis, "in", InputStream.class);
雨の日の猫は寝てばかり。
昨日で仕事の区切りがついてやること無いので、今日は休み。どこかに行こうかと思ったけど、あいにくの天気なので、NetBeans 5.5を一日中いじりまわしていた。るいもはずっと机の上の猫ベッドでおやすみ。
NetBeans 5.5のUML
なんだか本格的で、UMLをあまり真剣に勉強していない自分には、よく分からないものもあったり。
アグリゲーションとコンポジションにナビガブル(Navigable)というのがあるが、どうもナビガブルの方は、直接ソースコードの特定のメンバに結びつくようだ。でも、今のところ、1:多にすると配列固定みたいでコレクションにはできない模様。
Tomcat 5.5が生成するクラスファイルは不正
要約すると、「クラスファイルの中のsourcefile_indexで示されるソースファイル名には、ディレクトリとか絶対パスなどの情報を持ってはいけないとJavaクラス仕様4.7.7で規定されているが、Tomcat 5.5がJSPから生成するクラスファイルは、これを守っていない。Tomcat 5.0までは大丈夫みたいだ」
実際にjavapで見ると"org.apache.jsp.WEB_002dINF.jsp.components.globalheader_jsp"などと表示されるらしい。本来なら"globalheader_jsp.java"にならないといけない。
ってことはTomcat 5.5って、自分でクラスファイルを生成しているんだろうか。てっきりプラットフォーム側の機能を使用しているものとばかり…
画像ビューア
RAWも読めるし、いい感じ(なんか、たまに固まるけど)。ずいぶんと速いものだなと思ったら、Exifの中にサムネールが入っているのか。カメラでのプレビューはこれを使っているのだな。そりゃそうか。そうじゃなきゃ、あんな速さで表示できるわけないし。
NetBeans 5.5でJUnitがエラーになる。
なんかorg.w3c.dom.Nodeが無いとか言われる。なんでだろう。とりあえず、antのlibの下の全ファイルをLibrary Managerで登録して、プロジェクトの設定のLibrariesのところに追加してみたら、動くようになった。
[備忘録] NetBeansでアスペクトのコンパイル
build.xmlの一番最後に以下を追加(Library Managerでaspectj-1.5.0-rtと、aspectj-1.5.0-toolsを設定しておくこと)。aspectのソースは、aspectの下にあることを仮定。
毎回iajcが流れて重いので、*.ajが新しい時だけコンパイルするように変更。
<target name="-post-compile">
<taskdef resource="org/aspectj/tools/ant/taskdefs/aspectjTaskdefs.properties"
classpath="${libs.aspectj-1.5.0-tools.classpath}"/>
<uptodate property="aspect.uptodate">
<srcfiles dir="aspect" includes="**/*.aj"/>
<mapper type="glob" from="*.aj" to="../build/classes/*.class"/>
</uptodate>
<antcall target="compile-aspect"/>
</target>
<target name="compile-aspect" unless="aspect.uptodate">
<iajc srcdir="aspect" destDir="build/classes"
classpath="build/classes;${libs.aspectj-1.5.0-rt.classpath}"/>
</target>
[備忘録] NetBeansのライブラリ設定
Tools -> Library Managerで登録する。
こうすると、build.xmlの中からは、${libs.xxx.classpath}でアクセスできる。xxxはライブラリ名。この例なら、${libs.aspectj-1.5.0-rt.classpath}になる。
AspectJとアノテーション
AspectJ5でアノテーション使うと、アスペクトがきれいに書けるし、call(@Foo * *(..))みたいにして、@Fooがついたところにだけweaveとかできるので、かなり便利っぽいのだけど、結局5.0でしか動かなくなってしまう。サーバーサイドでは、あと数年は昔のスタイルで書くしかないのかな...
NetBeans 5.5 Preview
UMLが使えるということだったので、ちょっと落としてみた。インストールとかはサクっと省略。 起動直後の状態でタスクマネージャを見ると87MBくらい。
まずは普通にJava Applicationのプロジェクトを作成。FooインターフェースとBarクラスを作成。
で、どうやってUMLするのか、さんざん悩んだ挙句、どうやらUMLプロジェクトを作らないといけないらしいことに気付く。
プロジェクトの新規作成を選ぶと、UMLというカテゴリが。そこから"Java-Platform Model by Reverse-Engineering a Java Project"を選ぶ。
既存のプロジェクトを選んでねと表示されるので、Choose Java Projectというボタンを押して、最初に作ったプロジェクトを指定。
リバースエンジニアリングされて、最初に作っておいたFooとBarが無事、モデルとして表示された。
Diagramsというところを右クリックして、ダイアグラム作成に進む。今回はクラス図を選択。
クラス図ができたので、ダブルクリックして開く。

まだ、中はからっぽなので、ここにModelからBarとFooをドラッグアンドドロップしてみる。
試しにパレットから"Implementation"を選んでFooとBarをつなげてみた。

Barのソースみ見てみると、

おぉ、ちゃんとソースも自動的に変わってますな。
今度はソースの方を手で修正してセーブ。

ダイアグラムの方に戻ってみると、

おぉ、ちゃんとダイアグラムも更新されてる!
すごいな、最近NetBeansは元気いいね! 試しにしばらく使ってみよう。
locale
nekopさんとこのコメント読んでいて気づいたのだけど、localeって発音記号みる限りは日本語的には「ロカール」か「ロウカル」だね。誰が「ロケール」なんて変な読みを広めたんだろう。SUNのAPI仕様書でもロケールだ。
不要なthis、super
あぁ、そうか。何でやたらめったらと必要も無いのにthisやsuper付けるんだろうかと思ったら、IDEでthis.まで打つと候補が出るからか。と思ったらsuper.では何も出ないようだけど、これは何で付けたがるんだろう。やっぱり継承を全く理解していないのだろうか。
Vistaに乗り換える理由
9番はちょっと欲しいかも。あとはいらない。これってやっぱりレイオジーのあれかなぁ。Notesの敵はExchangeなんかじゃなくてVistaなんじゃない?
しかし父が同じなのに敵っていうのもドラマのようで面白い。
カバレッジ・レポートに騙されないために
カバレッジツールの怖いところは、数字が一人歩きする事かな。100%と出てるからって、あらゆる条件がテストされているわけじゃ無いわけで。あの数値は変に分かり易くて怖すぎる。
そういえば、昔、引数に自動的にやたらめったら値をつっこんで(Stringだったらnullとか""とか)、事前条件を探り出すテストツールがあったけど、あれって今はどうなってるんだろう...
XP HomeはVistaリリース後2年の命
XP HomeはVistaリリース後2年の命。安易に機能だけみてHomeエディションを買うと痛い目に会うな。
そろそろOSの売り切りはやめたらどうだろう。売り切りだからOSベンダは次々と新製品を出さないと儲からない。使用料制にはできないのかな。
年間5000円くらいで、Windows2000サポートし続けてくれないかなぁ。Vistaとかいらないよ。3Dデスクトップとか3日で飽きそうだし。Windows2000と同じリソースで動くならともかく...
定数定義
やっている本人はきっと大まじめだとは思うのだけど、ハタから見てるとギャグにしか見えないんだよなぁ。
public static final String STR_40 = "40"; public static final String STR_SIXTY = "60"; public static final int INT_ZERO = 0; public static final int INT_ONE = 1; public static final String STR_ZORE = "0";
スペルミスまであるし。しかし、以下のようなのは意味があるわけで、
public static final BigDecimal BIGDECIMAL_ZERO = new BigDecimal("0");
いや定数定義ひとつとっても、ちゃんとやるのは難しい...
コピペできないエディタとか
コードインスペクションって、作業的にはつらいものではないけど、精神的には結構くるかも。な〜んか、だんだん心が荒んでくるんだよね。そのうち集中できなくなってきて、具にもつかない妄想が。持ち上がる。
- コピペできないエディタとかあったら使わせたい(移動は可能)。
- それか、コピペは完了に10秒待たされるとか。
- 毎回ダイヤログボックスが出て「コピペやめますか? プログラマやめますか?」と表示される、マウスでボタンを押さないと進めないとか。もちろんボタンからはフォーカスを外しておく。とか。
ifとelseに全く同じ処理が書かれているバグを発見するディテクタがFindBugsにはあって、まぁ、これは多分プロジェクトでまともなソースコード管理システムが使えないような状況で、ソースコードに更新履歴とかを埋め込まざるを得なくて、大量の更新タグで騒然としているようなソースだと起きるかもね。くらいにしか考えていなかった。FindBugs本でもそんな例を挙げている。
しかし現実は全然違った。まっさらの綺麗なソースで、ifとelseを合わせたって10行程度なのに、ifとelseが全く一緒。別にインデントが違うわけでもなく、まさに単にコピペしただけという感じ。それも結構あちこちに見つかる。インタビューしてみたい。いったいどうしたら、そういうコードを書くに至るのか。そのシナリオを知りたい。まさか「同じだからコピペしよう」なのかなぁ。「同じだからif文を取り払おう」と考えない理由は何なんだろうか。そんなに手間が変わるとも思えないんだけど。
「変数を宣言する」というコメント
//変数を宣言する
int rst = 0;
なんか、こういう書いちゃいけないお手本のようなのが見つかるとあきれるを通り越して感動すら覚えるのだけど、結局こういうのはコーディング規約の副作用というものなのだろうな。「コメント比率xx%以上」みたいな機械的なルールを作れば、こういう百害あって一利なしのコメントが増殖する。「総行数、xx以下」みたいなルールを作れば、?演算子でやたらめったら一行に押し込んだ条件文が氾濫する。ルールを作った側は、良いコメントが増えるだろうとか、メソッドやクラスの分割が進むだろうとか期待するんだろうけど、どうも自分の経験上、実際のところはそういう方向には99%行かない事が分かってきた。
トキソプラズマに感染すると洗脳される??
Yahoo ニュースから(ネタ元:スラド)
「健康なネズミは猫がマーキングした場所を避けるが、トキソプラズマに感染したネズミは、その場所に向かっていく」
トキソプラズマは、健康な人なら免疫で押さえ込まれるので、大きな問題にならず、多くの人が感染したままなのだそうだ(国によって感染率は違うらしい)。人間も性格とか変わっちゃうのかな。
池上梅園
まだ、早かったかも二分咲きくらいかな。多分1-2週間後くらいがいいんじゃないかな。その分すいていたし今日は暖かかったので、よしとしよう。

Canon EOS 20D EF70-200mmIS@200.00mm F4.0 100 1/200秒 Flash on

Canon EOS 20D EF70-200mmIS@110.00mm F4.0 100 1/400秒

Canon EOS 20D EF70-200mmIS@125.00mm 1/1250秒 F5.6

Canon EOS 20D EF70-200mmIS@200.00mm 1/400秒 F4.0 Flash on

Canon EOS 20D EF70-200mmIS@125.00mm 1/1000秒 F4.0

Canon EOS 20D EF70-200mmIS@125.00mm 1/1000秒 F4.0

Canon EOS 20D EF70-200mmIS@125.00mm 1/640秒 F4.0 Flash on

Canon EOS 20D EF70-200mmIS@200.00mm 1/500秒 F4.0 Flash on

Canon EOS 20D EF70-200mmIS@200.00mm 1/800秒 F4.0

Canon EOS 20D EF70-200mmIS@173.00mm 1/200秒 F4.0 Flash on

Canon EOS 20D EF70-200mmIS@200.00mm 1/1600秒 F4.0

Canon EOS 20D EF70-200mmIS@195.00mm 1/800秒 F4.0

Canon EOS 20D EF-S10-22mm@12.00mm 1/160秒 F9.0

Canon EOS 20D EF70-200mmIS@160.00mm 1/1000秒 F4.0 Flash on

Canon EOS 20D EF70-200mmIS@200.00mm 1/1600秒 F5.6

Canon EOS 20D EF70-200mmIS@125.00mm 1/640秒 F8.0
こうなるのか。
コンシューマソフトウェアは売る時代から、お金出して使ってもらう時代に移行しつつあるようだ。この流れに乗れないソフトウェアベンダはバタバタといきそうだ。
高いシェアを取れたPCベンダには、今よりは、もうちょっといい時代が来るかもね。
pingはピンか?
なんか「ピン」って発音するのがカコイイらしいが。発音記号見る限り日本語的には「ピング」だと思われる。
いや、ring、king、singをリン、キン、シンって発音するって言うなら、それはそれで潔いと思うけど。とは言うもののting、ding、ping、zingあたりの擬音語系はグを発音したくないという気持ちも分かるような気もする。
OpenOfficeで△が□になる。
OpenOfficeで△を入力して、Word形式で保存すると、□になってる。どうも英文フォントになってしまうみたいだ。
ここにバグ報告が見つかったが、ずっと直っていない模様...
Word開いて置換を使って、置換後の方に書式指定をつけてフォントにMS P ゴシックを指定...「置換しました」と出るけど、なぜか置換されていない。む〜、こっちはWordのバグか? しょうがないのでマクロで置き換え...
植民地支配的システム開発
安い労働力を海外で調達して物造りをする。実態は昔の植民地支配と大して変わらない。武力でおさえつけるか、金でおさえつけるかの違いだけだ。その根底には「プログラミングなんて単純作業、工業製品でそれなりにうまくいったから、うまくいかないわけがない」という考えがあるように思う。しかしプログラミングには単純なものも困難なものもある。困難な部分にきちんと金をかけて一流のエンジニアに作りこませ、単純部分だけを外に出せばいいのだけど、実際は丸投げがほとんどだろう。
それを指して「まったくSIerってやつは仕事を丸投げして利益ばかりをむさぼろうとする」という批判が良く聞かれるが、それはちょっと違うように思う。たぶん理由の大半はサブコンに「だっておたくの設計書の、フレームワークの出来が悪いから」と逃げを打たれるのを避けたいからだ。システムってやつは複雑で、なかなかきれいに切り分け出来ないから、協業するとすぐに責任範囲のなすりあいが起きる。それでモラルが下がって生産性と品質が下がるくらいなら、全部任せてハラをくくらせるか、全く任せない方がうまくいくのだ。
もちろんウォーターフォールにも責任の一端はある。触ってみた事も無い、これから作るシステムの要件をビシっと決め、水をもらさぬ仕様を最初に作る事を要求する。手戻りのリスクを減らすためは、上流品質をいかに上げるかが重要となり、結果、過度な上流偏重体質が生まれた。象徴的なのがコーディング作業部分に工場のベルトコンベアを当てはめる絵。なんでプログラミングと工場の大量生産とを結びつけるのかな〜。それも結構IT寄りの人間が、そんな絵を描いていたりする。
でもウォーターフォールって悪者扱いされるけど、植民地支配的システム開発には、最も適したやり方の1つじゃないかな。ホントに現場で植民地支配的システム開発やっている人、今のプロジェクト、例えばXPで回ると思いますか? 植民地が解放されない限りは、(修正)ウォーターフォール(例えば単体テストの自動化だけ取り入れるとか、開発をフェージングするとか)という選択しか無いように感じるのだ。
Eclipseでライブラリの指定
プロジェクトのライブラリ指定でAdd External JARを使うと、絶対パスが埋め込まれるので、Workspaceごと別のマシンに持っていくと移動先にも全く同じパスにライブラリが無いと、エラーになってしまう。
「自分のプロジェクトディレクトリ」というVariableでもありそうなものだが、どうも見つからない。ふと思いついてlibsという名前のSimple Projectを作って、その中にライブラリをインポートしてみる。ライブラリを使用したいプロジェクトのライブラリ指定ではAdd Jarsの方を指定してlibsプロジェクトの下のライブラリを指定。
これでWorkspaceを持ち歩けば、どこでもコンパイルできるようになった。多分Eclipse常用者には常識なんだろうが...























