K.Maebashi's BBS

皆様初めまして、ＨＮ「けろ助」と申します。 職業プログラマ歴３年と９ヶ月のまだまだへっぽこです。 前橋さんのファン歴（？）は「Java 謎＋落とし穴」発刊以来ですから丸３年くらいでしょうか。 で、いきなりですが質問なのです。 本格的なアプリケーションを作る場合、「ソースを書いてコンパイルする」だけではなく、「リリース用のファ イルセット (実行モジュールや設定ファイル等の集合) を作成する」という作業も必要になってくると思います。 そして世間一般ではこの作業を「ビルド」と言い習わしているようです (正確な定義は良く認識できていません。 コンパイル～リリース用ファイルセット作成までの、一連の作業を「ビルド」と言っている場合もあれば、個別 の作業行為を「ビルド」と言っている場合もあるからです)。 ビルドを効率的、柔軟に行えるようにするには、makefile (make)、build.xml (ant) の記述ノウハウはもちろ んのこと、ディレクトリ構成等も慎重に考えて設計しなくてはならないように思います。 プログラマにとってデータ構造やアルゴリズムと同程度に重要な話題に思えるのですが、参考になる書籍やサイ トが見つからずに困っております。 ビルドツールの使い方そのものについては充分な情報が得られるのですが…。 ビルドについて詳細に取り上げている書籍、もしくはサイトをご存知の方、ご教授願います。 特に Java＋ant に向いた情報を必要としています。 「自分は大抵こんな構成で作ってる」「このオープンソースの設計が参考になる」「そんなものはプログラマの 基本教養じゃ。この青二才め」等、何でも構いません。 よろしくお願いします。 個人的には、前橋さんに「本格的なアプリケーションの構築技法」の本を出していただきたいな…と思っていた りするのですが。

>皆様初めまして、ＨＮ「けろ助」と申します。 はじめまして。 >ビルドを効率的、柔軟に行えるようにするには、makefile (make)、build.xml (ant) の記述ノウハウはもちろ >んのこと、ディレクトリ構成等も慎重に考えて設計しなくてはならないように思います。 いやあ、このあたりは、最近はかなり「若い奴にお任せ」してる部分が大きいので、 私がこの方面に詳しいかというとそんなことはないと思います (^^; 詳しくないなりに思うところを書きますが、こういうのはアプリケーションと 環境により千差万別なわけですが、実はプログラマが仕事で書くプログラムの 95%は特定顧客からの受注アプリケーションだという現実があって(※1)、 その場合、特に相手がUNIXワークステーションだったりすると環境はかなり 限定できますから、「ディレクトリまるごとtarで固めてインストール先で展開。 パスは全て絶対指定」みたいなやり方でもなんとかなっちゃう、という面はあると 思います。 Windows環境ではさすがにそういうのは避けるべきかと思いますが(PCはきっと 他のことにも使うので)、業務用の特注アプリケーションだと、Cドライブにしか インストールできなくてもさほど問題にはならなかったりします。 一般に配布するのでどこでも動くようにしたい、と考え出すと、途端に難しく なりますよね。Cの場合、かつては#ifdef __SOLARIS__ とか書いてましたが これはひどいということでautoconfみたいなのが出てきましたけどconfig.hに 頼ってたらテストが大変(というか不可能)という状況には変わりなく、 結局は、(Javaが本質的にそうであるように)最初からどこでも動くように書くのが 正しいのでしょう。 # そういう意味で、typedef int int32_t; みたいなのは、少なくともアプリケーション # プログラムとしては、方向性が間違ってると思う。 Javaではそういうところは改善されているはずが、Webアプリ構築のために アプリケーションサーバを導入すると移植性なんかどっか行っちゃったりしますし、 JDKのバージョンに泣かされることもあります。 「Tigerはいつになったら仕事で使えるんだろう?」 「あと数年は無理じゃないですかねえ」 という会話を、まさに今日、同僚としてました。 >ビルドについて詳細に取り上げている書籍、もしくはサイトをご存知の方、ご教授願います。 これは私も知りたいです。詳しい方、よろしくお願いいたします。 ※1「魔法のおなべ」より http://cruel.org/freeware/magicpot.html

あけまして おめでとうございます。 少し趣旨の異なる質問ですが ># そういう意味で、typedef int int32_t; みたいなのは、少なくともアプリケーション ># プログラムとしては、方向性が間違ってると思う。 この方向性が間違っていると言うのは, どういうことを意味してるのでしょう? int32_tみたいな型を利用するのは、けっこう便利だと思うのですが。 一般のアプリではビット数なんか気にしないで作らんとあかんって言うことでしょうか? でも、ファイルフォーマットとかでやっぱりビット数って重要になりそうですが。 私は特殊なソフトウエアを作ってる場合が多いので、あれですけど、 色々な環境からハードウエアを直に叩く様なアプリケーションを 作っていて、そういう時整数型のビット数とかは非常に重要になっていたりしますが。 >>ビルドについて詳細に取り上げている書籍、もしくはサイトをご存知の方、ご教授願います。 >これは私も知りたいです。詳しい方、よろしくお願いいたします。 Javaはよくわかりませんが、私はX関係とかで一般に公開されている かなり熟練されている人たちが作ったと思われるプログラムの ディレクトリ構造とかを真似してみたりしてます。 まぁ、新規に作り始めることが少ないので、 既にある環境で何も考えずに やってることがほとんどですが。 なんつうか、頭を使わない私なのでした。

件名を変えました。 >># そういう意味で、typedef int int32_t; みたいなのは、少なくともアプリケーション >># プログラムとしては、方向性が間違ってると思う。 … > 一般のアプリではビット数なんか気にしないで作らんとあかんって言うことでしょうか? まあ、簡単に言ってしまえばそういうことです。 > でも、ファイルフォーマットとかでやっぱりビット数って重要になりそうですが。 ファイルにデータを吐き出したいのなら結局バイト列まで面倒を見なければ いけないでしょう。int32_tを、32bitだからってそのままファイルに吐いてたら、 バイトオーダーの問題さえ解決できません。まあ、バイトオーダー(とか負の数の 表現方法とか)が同じ環境に限り移植性が高い、というだけでもメリットは もちろんあるので、全面的に否定はしませんが。 コンピュータの世界では、実に色々な概念が階層的に構成されていて、 ハードに近い「低レベルな」概念を、より抽象的な概念で隠す、という層の 積み重ねになっています。が、typedef int int32_t; は、より低レベルな階層を 剥き出しにする方向の定義になっている。これじゃあ向きが反対です。 その意味で、私は、Javaな人が、「Javaでは、Cなんかと違い、intとかの データ型のサイズがきちんと規定されているから良い」という主張が理解できません。 「intは最低限いくつからいくつまでの数を表現できる」という規定があれば (本来は)十分じゃないでしょうか。実際、Cの規格ではそれは保証していますし。 # intが3万ちょっとであふれるのは嫌だ、ということなら、「俺のプログラムは # intが32ビット以上の環境だけを対象とする」と言ってもよいでしょう。 2147483647に1足すと-2147483648になる、なんてことを仕様で保証しても、 「どの環境でも同じようにバグる」ことが保証できるだけでしょう。 現実問題としては「どの環境でも同じようにバグる」と助かるのは確かですが、 そういう意味で利便を図るなら、実行時エラーにする(できる)ほうが 筋が通ってますよね(C#のように)。 > 私は特殊なソフトウエアを作ってる場合が多いので、あれですけど、 > 色々な環境からハードウエアを直に叩く様なアプリケーションを > 作っていて、そういう時整数型のビット数とかは非常に重要になっていたりしますが。 もちろんそういう低レベルな階層を意識しなければならないケースでは、 ビット数を意識する必要があると思います。それでもできるだけ階層化して、 下の方に押し込めたいところですが。

>> 私は特殊なソフトウエアを作ってる場合が多いので、あれですけど、 >> 色々な環境からハードウエアを直に叩く様なアプリケーションを >> 作っていて、そういう時整数型のビット数とかは非常に重要になっていたりしますが。 >もちろんそういう低レベルな階層を意識しなければならないケースでは、 >ビット数を意識する必要があると思います。それでもできるだけ階層化して、 >下の方に押し込めたいところですが。 私の感覚が特殊な状況にあったようですね。 私の作るアプリケーションが いわゆるICデバイスを生で扱うためのもので、 最上位...つまりユーザインターフェイスにまでビット数やら 各ビットの01情報が見えないといけないという「超特殊」なモノ... 私が特殊な環境のプログラムばかり作っているってことを忘れてました(^^;) しかも、私の環境がWindows⇔UNIXという移植性は(あまり)考える必要がないので バイトオーダと言うことも考えから抜け落ちてました。 そうですねぇ。一般の例えばワープロとかで、使うintが何bitか なんて概念が残ってる必要はないですよねぇ。

一応、念のため確認です。 int32_t を生で使うのがアレなのは賛成ですが、 typedef int32_t CustomerID; のようにして int ではなく CustomerID を使うってのは OK なんですよね？ あと、int32_t は既に C言語標準に含まれているので、 基本的にはアプリケーションで定義する必要はないわけ ですが、int32_t の定義されてない古い処理系上で、 上の CustomerID のような typedef を行うために、 アプリケーションで「typedef int int32_t;」するのも OK なんですよね？

ISO C99はすっかり頭から抜け落ちていたので、今調べなおしました (^^; >int32_t を生で使うのがアレなのは賛成ですが、 >typedef int32_t CustomerID; のようにして >int ではなく CustomerID を使うってのは OK >なんですよね？ 私の主張は「低レベルな概念をわざわざアプリケーションにばらなくな」 ということなので、CustomerIDを使うのであれば問題ないと思います。 ただ、ISO C99を前提にするのなら、CustomerIDなら、int_least32_tの 方が移植性が高そうには思います。 が、「どの環境でも同じようにバグって欲しい」とか、 「バイトオーダーがある程度限定されてもよいから生データでやりとりしたい」 とかの状況も当然あるとは思います。移植性という点ではどちらもなんとも 中途半端だと思いますが、全面否定はできません。 >int32_t の定義されてない古い処理系上で、 >上の CustomerID のような typedef を行うために、 >アプリケーションで「typedef int int32_t;」するのも >OK なんですよね？ 上のような意図なので、これもOKですね。 いつもながら軽率な表現ですみません(ご指摘ありがとうございます(_o_)) 意図としてはそのあたりだとご理解くださいませ。

前橋さん、本多さん、レスありがとうございます。 レスが大変遅れまして申し訳ありません (雑事に追われた挙句風邪で４日間も寝込んでて…日頃の行い？)。 こちらでお二人にまとめてレスしようと思います。 前橋さん> いやあ、このあたりは、最近はかなり「若い奴にお任せ」してる部分が大きいので、 前橋さん> 私がこの方面に詳しいかというとそんなことはないと思います (^^; ガーン。そうなのですか…。 前橋さん> 詳しくないなりに思うところを書きますが、こういうのはアプリケーションと 前橋さん> 環境により千差万別なわけですが、実はプログラマが仕事で書くプログラムの 前橋さん> 95%は特定顧客からの受注アプリケーションだという現実があって(※1)、 前橋さん> その場合、特に相手がUNIXワークステーションだったりすると環境はかなり 前橋さん> 限定できますから、「ディレクトリまるごとtarで固めてインストール先で展開。 前橋さん> パスは全て絶対指定」みたいなやり方でもなんとかなっちゃう、という面はあると 前橋さん> 思います。 前橋さん> Windows環境ではさすがにそういうのは避けるべきかと思いますが(PCはきっと 前橋さん> 他のことにも使うので)、業務用の特注アプリケーションだと、Cドライブにしか 前橋さん> インストールできなくてもさほど問題にはならなかったりします。 これが、「『とりあえず動けばいいや』的な作りでも何とかなる場合も多い」という意味でしたら同意です。 例えば、実行モジュールと設定ファイルが同一ディレクトリに置く、なんてことはマトモなアプリケーションで ならやってはいけないことだと思いますが、動かそうと思えば動くわけですし…。 前橋さん> 一般に配布するのでどこでも動くようにしたい、と考え出すと、途端に難しく 前橋さん> なりますよね。Cの場合、かつては#ifdef __SOLARIS__ とか書いてましたが 前橋さん> これはひどいということでautoconfみたいなのが出てきましたけどconfig.hに 前橋さん> 頼ってたらテストが大変(というか不可能)という状況には変わりなく、 前橋さん> 結局は、(Javaが本質的にそうであるように)最初からどこでも動くように書くのが 前橋さん> 正しいのでしょう。 私もそう思います。 だからこそ、Java を使用したアプリケーションの構築には、デザインパターンのように一定のセオリーや経験 則の蓄積があるはずだ、と思っていたのです。 が、お話を聞く限りそういう類のものは無いようですね…。 本多さん> Javaはよくわかりませんが、私はX関係とかで一般に公開されている 本多さん> かなり熟練されている人たちが作ったと思われるプログラムの 本多さん> ディレクトリ構造とかを真似してみたりしてます。 こういうノウハウは、まだ誰もドキュメントとして体系的にまとめてはいないのでしょうね。 X 関係ですか…へっぽこな私には厳しそうだ…。 …と、ここまで考えて、「アプリケーションの構成法を一般的な形に体系化するのは実は無理があるのではない か」と思えるようになってきました。 設定ファイルの読み込み方ひとつ取っても、C だと設定ファイルに記述された値を環境変数に代入し、シェル上 でコマンドに引数として渡すのが普通 (らしい) です。 が、Java には、Java 実行環境内からのみ参照できる環境変数もどきの「プロパティ」というものがありますか ら、設定ファイルの値はプログラム内から読み込むというのが普通 (らしい) です。 パスの指定にしても、C ならカレントディレクトリからの相対指定が可能なのに、Java は基底ディレクトリか らの相対指定しかできませんし…。 Make と Ant では、もう基本にある考え方そのものが違うという気がします。 でもなぁ…せめて個別のビルドツールについて、その設計思想を解説した本やサイトくらいあっても良さそうな ものだとやっぱり思うのですよ。

>レスが大変遅れまして申し訳ありません (雑事に追われた挙句風邪で４日間も寝込んでて…日頃の行い？)。 おや。お大事に。 >これが、「『とりあえず動けばいいや』的な作りでも何とかなる場合も多い」という意味でしたら同意です。 >だからこそ、Java を使用したアプリケーションの構築には、デザインパターンのように一定のセオリーや経験 >則の蓄積があるはずだ、と思っていたのです。 ディレクトリ階層ということなら、JavaによるWebアプリケーションなら、 J2EEによる規定がありますよね。 その他のアプリケーションだと、confとかetcとかdocとか、よく使うディレクトリ名は ありますが… きっちり規定されたルールというと… どうでしょうか。 Cに関しては、GNUプロジェクトには規約がありますが、configureを前提にされると 辛い、ていうか嫌。 http://www.sra.co.jp/wingnut/standards-j_toc.html#Managing%20Releases >が、Java には、Java 実行環境内からのみ参照できる環境変数もどきの「プロパティ」というものがありますか >ら、設定ファイルの値はプログラム内から読み込むというのが普通 (らしい) です。 プロパティファイルは読みにくいので、今ならXMLの方がよく使われている 気がします。

名前しか知りませんが、Mavenてそーゆーのには役に立たないんでしょーか?

前橋さん、iWA さん、早速のレスありがとうございます。 またぞろ風邪がぶり返してきそうです… (鼻水と咳が止まらない…) 何でだろ。 前橋さん> ディレクトリ階層ということなら、JavaによるWebアプリケーションなら、 前橋さん> J2EEによる規定がありますよね。 前橋さん> その他のアプリケーションだと、confとかetcとかdocとか、よく使うディレクトリ名は 前橋さん> ありますが… きっちり規定されたルールというと… どうでしょうか。 そうですねぇ…、J2EE は、役割 (ロール) を含め、かなりきっちりとした規定があるようですが、「Web アプ リに限定したからこそ」という印象が、私にはあるのです。 J2EE はやたら敷居が高いので本をパラパラと読んだだけでの感想ですが…。 前橋さん> プロパティファイルは読みにくいので、今ならXMLの方がよく使われている気がします。 なるほど。Properties クラスの名前空間は階層的ではないですし、そちらが主流なのは良く解ります。 質問の件に限らず、ずっと思っていたことがありまして、今回改めてそれを確認した思いがします。 それは、「言語にせよ、ツールにせよ、その設計思想を体得しないことには充分に力を引き出せない」というこ とです。 言語やツールの成長を初期から追いかけるか、時間と労力を割いて慣れ親しむかしないといけないのでしょうね。 個人的には、作者にその辺りの説明責任があると思うのですが…。 私の場合、C + Make という環境でいたのですが、同じ UNIX 発祥とはいえ、Java + Ant では考え方が随分違う のでかなり面食らいました。 Win + VB から移行するよりは楽なのでしょうけど。 iWA さん> 名前しか知りませんが、Mavenてそーゆーのには役に立たないんでしょーか? さっそく調べてみました。プロジェクト管理ツールだそうですね。 [Jakarta Project のページ] http://www.ingrid.org/jajakarta/turbine/jp/turbine/maven/index.html [Maven を取り上げているサイト・1] http://www.02.246.ne.jp/~torutk/index.html [Maven を取り上げているサイト・2] http://www-6.ibm.com/jp/developerworks/java/030613/j_j-maven.html Eclipse にすら挫折した (手を出すには時期尚早だと感じた) 私ですので、今すぐ Maven を活用できる訳では ないのですが、Maven が持つ「プロジェクトの標準ディレクトリ構成」はかなり参考になりました。 自分でグジグジ環境をいじってたらこのレベルに辿りつくのに半年じゃ効かんですわ…。 レスを下さった皆様、どうもありがとうございました。 Java に関しては完全に独学 (周りに使える人がいない…) で、暗中模索の状態が続いていたのですが、何だか 少し光が差してきたような気がします。

>またぞろ風邪がぶり返してきそうです… (鼻水と咳が止まらない…) 何でだろ。 無理されないように。ゆっくり休んでください。 >そうですねぇ…、J2EE は、役割 (ロール) を含め、かなりきっちりとした規定があるようですが、「Web アプ >リに限定したからこそ」という印象が、私にはあるのです。 あのディレクトリ構成は実際「Web アプリに限定したからこそ」だと思います。 ていうか私はあれを最初に見たとき、こんなことをフレームワークで決めて欲しくない、 と思いました。が、ユーザとしては無限の自由度を欲しがりますが、それがかえって 混乱を招くこともあるわけで、あれはあれでよいのかもしれません。 Cが、もし最初から、インデントがいわゆる「K&Rスタイル」になっていないものを コンパイラのレベルで文法エラーで弾いていたら、スタイルにまつわる宗教戦争は 発生しなかったわけで。 # でも、そういうことをツールの設計者がガチガチに決めてしまうと、なんか # 普及しなさそう、という気もします。 > 名前しか知りませんが、Mavenてそーゆーのには役に立たないんでしょーか? これは私も知りませんでした(Jakartaもなんか多すぎ)。勉強しておきます。

お世話になっております、けろ助でございます。 お陰様で風邪も良くなりまして、また勉強に励んでおります。 > あのディレクトリ構成は実際「Web アプリに限定したからこそ」だと思います。 > ていうか私はあれを最初に見たとき、こんなことをフレームワークで決めて欲しくない、 > と思いました。が、ユーザとしては無限の自由度を欲しがりますが、それがかえって > 混乱を招くこともあるわけで、あれはあれでよいのかもしれません。 つたない考えなのですが、これって「『今対象としている問題の領域』をどこに限定し、いかにモデル化する か」というテーマに帰着していくんだと思うんですね。 オブジェクト指向設計の用語では「ドメイン」と呼ぶそうですが。 ドメインの決定とモデル化を上手く行うことが、結局のところ良い設計となる…ということになるのでしょう。 「アルゴリズムとデータ構造」といった、割と枯れたテーマなら、ノウハウや経験則の蓄積も豊富で体系的にま とめられた書籍を気軽に入手して勉強できる程の環境にあると思いますが、上に挙げたテーマは「まだこなれて ないジャンル」であるだけにまだ模索状態なような気がします。 そんな中で、J2EE は一定の成果を上げることができた、と。 今のところ、私はそんな解釈をしています。 > Cが、もし最初から、インデントがいわゆる「K&Rスタイル」になっていないものを > コンパイラのレベルで文法エラーで弾いていたら、スタイルにまつわる宗教戦争は > 発生しなかったわけで。 > # でも、そういうことをツールの設計者がガチガチに決めてしまうと、なんか > # 普及しなさそう、という気もします。 ええ。そういう意味なら、C 言語は、上手いことユーザーのニーズに (今も) マッチした言語ですね。 制限と自由のさじ加減が非常にバランスが良い言語だと思ってます (除：宣言構文)。 「C 言語ポインタ完全制覇」を最初に読んだ時は「殴るんなら James Gosling より Dennis Ritchie だろ」と 思っていた私ですが、Java を本格的に書き始めた今では考えが全く逆ですから (汗)。 で、ツールの制限の話なのですが、実は私、色々な所で悪口を聞く COBOL を嫌いになれません。 COBOL の持つ記述上の制約は、「誰でも、それなりに実用に耐えうるソースを書ける」と信じられていた時代な らではのものだからです。 # 実は私、前の会社でホスト系言語 (COBOL、PLI/I、JCL …等々) の解析プログラムをメンテしてました。 # COBOL はソース記述開始位置等に非常な制約がある言語です。 # また、今では「変態言語」の名は Perl が欲しいままにしていますが、私ならその称号を PL/I に与えたい。 話それました。すみません。 要は、「『作者の設定した自由と制約』が時代やユーザーのニーズとどれだけマッチしているか」、が一番重要 な事項になのだろう、と思った、ということです。 流行る言語なり、ツールなりは、時代に見出されただけであって、後々まで残る方法論とはまた別なのだ、って 事なんです。 前向きに考えるなら「今からでもソフトウェア工学の根本的進歩を目の当たりにできる」と思えるでしょうし、 後ろ向きに考えるなら「なんだ、ソフトウェア工学ってこの程度なのか…」と思える混沌とした時代なのかな…。

>お陰様で風邪も良くなりまして、また勉強に励んでおります。 　ええと、ご無理されませんように。 >そんな中で、J2EE は一定の成果を上げることができた、と。 　EJBなんか本当に必要なのか? という声はなくもないですが。 　ただ、EJBを使おうが使うまいが、Webアプリケーションでは、何らかの「型」を決めて アプリケーションを開発する傾向はあります。Strutsなどは「型」を提供してくれますし、 たいていプロジェクトごとにさらに細かい型を決めます。 　実際、それで生産性は上がりますし、品質もある程度均一化できると思うのですが、 考えてみれば、「どこ見ても同じようなパターンで書いてある」というのは、 「同じことを複数の箇所に書いてはいけない原則」に反するのではないかと 思うこともあります。 　アスペクト指向ってのはそのへんをどうにかしようという発想なのだと思うのですが、 私はちゃんと追えてません。 >で、ツールの制限の話なのですが、実は私、色々な所で悪口を聞く COBOL を嫌いになれません。 >COBOL の持つ記述上の制約は、「誰でも、それなりに実用に耐えうるソースを書ける」と信じられていた時代な >らではのものだからです。 　すみません、私はCOBOLはやったことないです(入門書をみた程度)。 「誰が書いても似たようなコードになる」という話はよく聞きますけれど。 　一時期、TeXに凝っていた頃、「マクロでどうにでも化ける言語ってすごいじゃん」と 思ってしまったことがありますが、読むほうからするとむしろたまったもんじゃ ないんですよね。C++は、演算子のオーバロードで結構いかようにも化けますが、 おかげで、読む方は、そのクラスの仕様がわからなければ手が出せない。 たとえば文字列のクラスがあったとして、それが実体として扱われるのか参照として 扱われるのかはC++の文法からだけではわからないわけです。 # STLのstringの話をしているわけではないですからね。念のため。 　その点、Javaなら参照しかないので迷いようがない。こういうのは結構重要かなあ、 とも思ったりしてます。 　ちなみに、そういう発想にはおそらく真っ向から反するのがこちら。 「簡潔さは力なり」 http://www.shiro.dreamhost.com/scheme/trans/power-j.html