K.Maebashi's BBS

あら、私のネタ振りから別スレッドに。 前橋さん> 自分自身がオブジェクト指向から入った人、またはそういう人を身近にたくさん 前橋さん> 見てきた人の経験を聞いてみたいです。 サンプルが少なくて申し訳ないですが、友人に 1 人、Java から本格的にプログラミングを始めた人がおります。 それ以前も C 言語を触ったことがあるのですが、"Hello, World." 程度でした。 私>「プログラミングは Java が初めて」という人ならこういう経験をしなくて済むかもしれません。 私> 何しろ邪魔する前知識が無いですから。 実はこれ、その友人のことなんです。 今度彼と会う機会があるので、もっと詳しくインタビューしてみますね。

> これですが、辞書攻撃を、Webで稼動中の掲示板に対して行うことを想定して > いますでしょうか。それとも、既にテーブル内容が流出していることを > 前提に、辞書攻撃でパスワードを解析しよう、というお話でしょうか。 テーブル内容が流出していることを前提にしています。 > 後者だとすると、テーブルが流出した時点でsaltはだだ漏れです。 そうです。 > これは、ひとつのパスワードがばれても、同じハッシュになっている他の > パスワードが芋づる式にばれることはない、ということでしょうか? 違います。辞書攻撃に必要な計算量が増えるという意味です。 > 同時間で、ほぼ同数のパスワードが抜かれてしまいそうに思う > のですが。 salt があると、探索空間が salt のビット数分広がるため、 辞書攻撃に要する時間が長くなります。以下のページにも、 同様な示唆があります。 http://www.itmedia.co.jp/enterprise/0307/24/epn09.html http://www.microsoft.com/japan/msdn/library/ja/f_and_m/html/vxconprotectingpasswordcredentials.asp データベース中には複数のMD5化されたパスワードが存在する わけですが、salt がないと、単一の辞書を使って、全ての パスワードに対する試行を行うことができます。これに対し、 salt があると、2 の salt のビット数乗 の辞書が必要になる わけです。 > 別の場所に置いてあるだけ"秘密"の方がまだマシかも。 これを気にするのであれば、salt とプログラム埋め込みのsecret の両方を使うのが良いと思います。どちらか片方だけであれば、 salt の方を選ぶのが良い習慣だと思います。

すみません、風呂の中で考えてたらちょっとわからなくなりました。 >今のやり方だと、仮に異なるユーザが同一のパス >ワードを利用していた場合、その事実を管理者は >知ることができるわけですが、salt を使えばその >心配もありません。 これはその通りだと思います。また、クラッカーにD/Bを継続的に監視されて いる場合、いろいろなパスワードで書き込んでみることで、パスワードを 推測することもできることになります。 >また、仮に "秘密" や salt が洩れた場合に、辞書 >攻撃への耐性が若干高くなります。(salt があると、 >同じ辞書は一つのメッセージにしか使えないため、 >探索空間が広くなる) これですが、辞書攻撃を、Webで稼動中の掲示板に対して行うことを想定して いますでしょうか。それとも、既にテーブル内容が流出していることを 前提に、辞書攻撃でパスワードを解析しよう、というお話でしょうか。 前者だとすると、"秘密"やsaltが漏れていようがいまいが関係なさそうですし (そもそもレンタルサーバ業者にプロセス止められそうですが)、 後者だとすると、テーブルが流出した時点でsaltはだだ漏れです。 別の場所に置いてあるだけ"秘密"の方がまだマシかも。 >同じ辞書は一つのメッセージにしか使えないため、 >探索空間が広くなる) これは、ひとつのパスワードがばれても、同じハッシュになっている他の パスワードが芋づる式にばれることはない、ということでしょうか? しかし、実際問題こんな掲示板の投稿が消されてもさしたる実害はないわけで、 問題は「お金が絡むようなところと共通のパスワードを使う人がいたケース」だと 思っています。 そんなユーザは投稿ごとにパスワードを変えたりしそうにないですし(そんな ユーザに限らずともそうなんじゃないかと思いますが)、同一ハンドルの人は 1回しか調べない、程度のことで、同時間で、ほぼ同数のパスワードが抜かれて しまいそうに思うのですが。 どちらが安全か、という問題以前に、まず私の認識は合ってますでしょうか?

便乗して・・・ Javaを教えるほうにC言語などを知らないで育った方が 一体どれくらいいるのかも知りたいかも。 （あくまで参考として）

まったく違う話題にシフトします。件名とスレッド変えました。 >「プログラミングは Java が初めて」という人ならこういう経験をしなくて済むかもしれません。 >何しろ邪魔する前知識が無いですから。 「Cなどの言語を知っている人は、今までの知識が邪魔をしてオブジェクト指向の習得が 難しいけど、最初からオブジェクト指向を覚えるのなら簡単だ」 とたまに聞きますけど、これはどの程度事実なんでしょうか。 たまに、上の言葉の後ろに「なにしろオブジェクト指向は自然だから～」というのが 続いたりすると、どうも眉に唾をつけたくなります。私の場合。 古い知識が邪魔をするという傾向はもちろんありますが(FORTRAN屋やCOBOL屋が設計した Cプログラムにどれほど泣かされたことか)、じゃあまったくの初心者がJavaから 入門したとして、最初に動かすプログラムがhello, world. だったら、結局のところ 手続き指向→オブジェクト指向の流れで習得することになるように思います。 Javaの場合、hello, world.といってもアプレットから入るんでしょうか。 その場合、#include <stdio.h>なんかとは比べ物にならないくらい「とりあえず こう書いとけ」的な記述が増えてしまいますが、まあ、それは「いずれ分かる」と 言っておけばよいでしょう。 んで、ただブラウザにhello, world.と表示されるだけのプログラムから 順次発展していく場合、どの辺で「オブジェクト指向」を意識することになるんでしょうか。 クラスがアプレットしかなければ、メソッドも単なる関数ですし、インスタンスフィールドは グローバル変数と同じです。 GUIのボタンを作ったりするところは、「決まり文句」としか思ってもらえない気も するんですが、こういうところから、だんだんオブジェクト指向になじんでいったり するのかな。 私自身はBASICから入ったクチですし、新人にJavaを教えたことは何度となくありますが うちの会社では新人はまずCの研修を受けてくるので、「オブジェクト指向から入門」 した人の観察例が私にはほとんどありません。 自分自身がオブジェクト指向から入った人、またはそういう人を身近にたくさん 見てきた人の経験を聞いてみたいです。

>つまり、"秘密" はソース埋め込みにせず、メッ >セージごとに乱数で生成することにし、salt 自体も >message表に記録しておくわけです。 毎度ながらご指摘ありがとうございます。 掲示板のパスワードとしてどこまでの仕様が必要であるかはさておき、 この記事を読んで「パスワードの暗号化はこうすれば万全なんだ」と思ってしまう人が いるとまずいので、取り急ぎ注釈をつけました。

PHPとMySQLで掲示板を作る / 削除 / 削除系ソース の hash_user_password() ですが、"秘密" は、 UNIX パスワードなどで使われている salt の やり方にするのはどうですか？ つまり、"秘密" はソース埋め込みにせず、メッ セージごとに乱数で生成することにし、salt 自体も message表に記録しておくわけです。 今のやり方だと、仮に異なるユーザが同一のパス ワードを利用していた場合、その事実を管理者は 知ることができるわけですが、salt を使えばその 心配もありません。 また、仮に "秘密" や salt が洩れた場合に、辞書 攻撃への耐性が若干高くなります。(salt があると、 同じ辞書は一つのメッセージにしか使えないため、 探索空間が広くなる)

私も横からすんません。 norge さんは「プログラミング自体初めての人」と「オブジェクト指向は初めての人」を一緒くたにしちゃって るんだと思うんですけど。推測ですが。 まぁ、「Java (オブジェクト指向言語) を学ぶ前に、C 言語 (手続き指向言語) で得た知識は一度きれいに忘れ てください」って入門書もあったりしますし、私も読んだことがあります。 そういうやり方も、アリかなぁとは思うのですが。一応書けるようにはなるし。 でもですねぇ…、Java で得た知識と C 言語で得た知識がきれいに結びつかないのは苦痛でした。 入門書を読み、サンプルをグジグジいじくっては、覚えているだけで 3 回は挫折してしまいました。 とにかく、自分が何をやっているのかを、感覚としてさっぱり捕まえられなかった。 # こういう感覚はプログラマとして「まっとう」だと思ってます。 # 挫折しといてナンですが…。 「プログラミングは Java が初めて」という人ならこういう経験をしなくて済むかもしれません。 何しろ邪魔する前知識が無いですから。 かと言って、C 言語経験者を「古い知識に縛られたロートル」だとも思いません。 低レベルな概念と高レベルな概念がきれいに結びついた知識体系を獲得した時、飛躍的に応用が利くようになる からです (ちょっと大げさかな…)。 # アセンブラ上がりの高級言語プログラマであれば、また違ったセンスや発想を持っているように思います。 知識というのは、互いに結び付けられて意識下で体系化されてこそ意味を持ちうるわけで、その結びつきを強化 したり手繰り寄せたりしないと、新しい知識や発想に行き着けないと思ってます。私。 あれ、これ、前橋さんの意見の要約にしかなってないかも…。

>プログラムを始めたばかりのものです。 >Perlで作成する事になりました。 >PDFを表示する仕様があります。 >どの様にすればよいかわかりません。 >教えて頂ければありがたいです。 私はPerlにもPDFにも詳しくないですが… PerlとPDFをキーワードに、Googleで検索しました(日本語限定)。 http://www.google.co.jp/search?hl=ja&q=Perl+PDF&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=lang_ja 1件目がこれ。 http://www.warpstream.co.jp/package_pdfserver.html?afl=cgirescue1 商品のようです。 お金を出すのが嫌なら、2件目がこれ。 http://hp1.jonex.ne.jp/~nakajima.yasushi/ PDFJというモジュールがあるようです。 PDFJでGoogleすると、結構有名なようですね。 ただ、ざっと見て、ライセンスの規定がよくわかりませんが… また、1件目のページの中に >PDFLibなどのライブラリで作成することはできますが、 とありますから、PDFLibとPerlでGoogleするのも手です。これも商品のようですが。

>>そこらへんどうなんですか？ > >いずれ分かる 　これだけではあんまりなのでちょっと書き足しときますか。 　根拠も挙げず、イカれたレコードか何かのように、「いずれ分かる」と言い続ける だけなら、バカにでもできるわけです。 　まあ、それでもnorgeさんの最初の投稿には、 >Ｃの#include<stdio.h>がいい例じゃないすかね と書いてあったから、私はこれを 「Cの#include <stdio.h>は『とりあえずこう書いとけ』と言われても理解できたでしょ? 　だからクラスを書くことについても、同様に『とりあえずこう書いとけ』と 　言ってもいずれ理解できるのではないか」 という意味だと解釈しました。つまり「#include <stdio.h>」が、 「とりあえずこう書いとけ」と教えればよいというnorgeさんの主張の根拠であると 解釈したわけです。 そう解釈した上で、反論を書きました。[253]はわかりにくかったようなので、 [255]で改めて説明しています。それでもまだわかりにくかったとか、 再反論があるとか、あるいは最初の私の解釈が間違っていたとかなら拝聴いたしますが、 norgeさんはあいかわらず >そのうち分かるからとりあえずそうしときなさい と繰り返すばかり。だから、 >対話する気がないのなら、掲示板なんぞに出てこないで、自分でWebページでも >立てて好きなことを言っていればいいでしょう。 と言っているのです。 それからね、 >>でも、「クラスを作る」のケースでは、すぐにわかる見返りがないでしょう。 >いずれ分かる んで、こんなクラスを書かせるわけ? > class Car { > 　private int mileage > 　public Car(int mil) { > 　　this.mileage = mil; > 　} > 　//引数：ガソリン注入 > 　public int run (int gas) { > 　　return (gas * this.mileage); > 　} > } 「先生! 書けました」 「ではjavacでコンパイルしてください」 「Car.classってファイルができたんですけど、これってなんですか?」 「いずれ分かる」 ( ﾟдﾟ)ﾎﾟｶｰﾝ そもそもこのCarクラスってのは、いったい何をするためのプログラム(の一部?) なんですかね? 何をするためのクラスでもない、というのなら、私が 「疑り深い～」で批判している「犬」や「猫」のクラスと同じです。 私は「疑り深い～」において「犬」「猫」でクラスを説明することを批判して いますが、それを批判したいのなら、そう書けばいい。もちろん根拠を挙げた上で。 ついでに書いといきますと、句読点の使い方の変な文章は、ﾃﾞﾑﾊﾟに見えますぜ。

>他の掲示板にＤ言語って書いたら、そんなのねーよって言われた。 　で? 　対話をする気もなく、言いたいことを一方的に書き散らすだけなら、掲示板なんぞに 出てこないでください。

他の掲示板にＤ言語って書いたら、そんなのねーよって言われた。

プログラムを始めたばかりのものです。 Perlで作成する事になりました。 PDFを表示する仕様があります。 どの様にすればよいかわかりません。 教えて頂ければありがたいです。

横槍失礼します。 プログラミングセンスを上達させるには、ある種の悟り体験というか、 「あー、そういうことなのか！」っていう感動を覚える体験が必要なんだと 思います。 norgeさんがおっしゃるように、本当にセンスのある奴は放っておいても、 そういった悟りを開くのかもしれないですけど。 「そのうちわかる」的教え方では、僕のようなその他大勢のへっぽこ コード書きは、感動を覚える前に挫折していってしまうのが目に見えています。 そういったへっぽこであっても、ある程度はセンスを磨くことのできる教え方 ってものもあるはずです。 前橋さんの本やこのサイトのドキュメントは、まさに「それだ」と感じます。 導入部分で、感動の一端が垣間見れるように導いてあげるのが、一番良い教え方 だと思うのですが。

D言語万歳

>いずれ分かると言っても納得してもらえないのか、 >ちゃんと最初に説明しないといずれもクソも分からないのか、 … >そこらへんどうなんですか？ いずれ分かる

なんか分かってないっつーか理解力がないっつーか。。 「なんでこんなことしなきゃいかんの？」 っていう人に対して 「とりあえずそうやっとけばいずれ分かる」 って言えばいい、って２回も言ったのにそれに対して何も返事が返ってきてない 下にコピーした返事らしきものがあるけど、ちゃんとした答えじゃない >でも、「クラスを作る」のケースでは、すぐにわかる見返りがないでしょう。 いずれ分かる >なにせCとかに慣れた人なら、staticメソッドの塊で何でも書いちゃうでしょうから。 最初は黙ってpublicとかいときなさい >だから、「なんでこんなことしなきゃいかんの?」という疑問に答える必要がある、 それもいずれ分かる いずれ分かると言っても納得してもらえないのか、 ちゃんと最初に説明しないといずれもクソも分からないのか、 単に意地で最初から説明したいのか、 そこらへんどうなんですか？ ちなみに例としてはこんなん class Car { 　private int mileage 　public Car(int mil) { 　　this.mileage = mil; 　} 　//引数：ガソリン注入 　public int run (int gas) { 　　return (gas * this.mileage); 　} }

で、結局何が言いたいんですか? >結局問題なのはマルチプルインスタンスによる、多様性、つまりコンストラクタ等で設定した値によって振る舞いが違うと >ならそれの超簡単版でも作ればいいんじゃないかな 具体的には? >>だから、「なんでこんなことしなきゃいかんの?」という疑問に答える必要がある >前も言った気がするけど、そのうち分かるからとりあえずそうしときなさい >じゃまずいっすかね で、それに対する私の意見は書いたわけで、さらに反論があるのなら書けばいいし、 ないのならそれでいい。あるいは私の言っていることが意味不明だというのなら それも、そう書けばいい。 >VC++のSDKとかいちいち全部説明してたら死ぬし VC++のSDKをいちいち全部説明しろ、と誰か言っていますか? 対話する気がないのなら、掲示板なんぞに出てこないで、自分でWebページでも 立てて好きなことを言っていればいいでしょう。

結局問題なのはマルチプルインスタンスによる、多様性、つまりコンストラクタ等で設定した値によって振る舞いが違うと ならそれの超簡単版でも作ればいいんじゃないかな >だから、「なんでこんなことしなきゃいかんの?」という疑問に答える必要がある 前も言った気がするけど、そのうち分かるからとりあえずそうしときなさい じゃまずいっすかね VC++のSDKとかいちいち全部説明してたら死ぬし やっぱ最初は「そのうち分かるからとりあえずこういう風にやっとけばいい」 これの一言に尽きると思う

で、結局何をおっしゃりたいんでしょうか? この部分にレスが付いたって事は、「疑り深い～」に対する反論や感想の類と 思っていいのかなあ。 >>いざインスタンスを作るときには、やっぱり「なんでこんなことしなきゃ >>いかんの?」という疑問を持つはずで、それには答えなきゃいかんと思うんですがねえ。 > >とりあえずそうしときなさい、いずれ分かるから >ってことじゃダメっすかね たとえば「hello, world.」を表示するときの#include <stdio.h>は、 「とりあえずそうしときなさい。ほら、hello, world.って表示されたでしょ」 と言えます。この例では、「とりあえずそうしとく」ことで、 hello, world.が表示されるという短期的な見返りがあるわけです。 でも、「クラスを作る」のケースでは、すぐにわかる見返りがないでしょう。 なにせCとかに慣れた人なら、staticメソッドの塊で何でも書いちゃうでしょうから。 だから、「なんでこんなことしなきゃいかんの?」という疑問に答える必要がある、 と私は考えています。

>いざインスタンスを作るときには、やっぱり「なんでこんなことしなきゃ >いかんの?」という疑問を持つはずで、それには答えなきゃいかんと思うんですがねえ。 とりあえずそうしときなさい、いずれ分かるから ってことじゃダメっすかね 実際オレがそうだったし それでも分からんやつは才能がないと諦めた方がいいんじゃないの

　件名付けました。 >ここで言っても仕方ない事かもしれないけど、理解するのはあとだと思う >あーだこーだ説明されるよりまず、こう書けばクラスが作れるっていう書き方が重要 >書き方覚えてあとから理解した方がいい >Ｃの#include<stdio.h>がいい例じゃないすかね 　いや、私はまったく同意するんですが(実際、体当たり学習～では、#include <stdio.h> について、そういうことを書いてるし)。 　唐突にこう言われても何がなんだかわからないんですが、いったい何を おっしゃりたいんでしょうか? 「疑り深い～」に対する反論なのかなあ。 ただ、これについて言えば、CプログラマにJava教えるとき、 なんでもstaticメソッドで書かせればすぐ理解できると思うけど、 いざインスタンスを作るときには、やっぱり「なんでこんなことしなきゃ いかんの?」という疑問を持つはずで、それには答えなきゃいかんと思うんですがねえ。

ここで言っても仕方ない事かもしれないけど、理解するのはあとだと思う あーだこーだ説明されるよりまず、こう書けばクラスが作れるっていう書き方が重要 書き方覚えてあとから理解した方がいい Ｃの#include<stdio.h>がいい例じゃないすかね

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

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

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

前橋さん、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 に関しては完全に独学 (周りに使える人がいない…) で、暗中模索の状態が続いていたのですが、何だか 少し光が差してきたような気がします。

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

>レスが大変遅れまして申し訳ありません (雑事に追われた挙句風邪で４日間も寝込んでて…日頃の行い？)。 おや。お大事に。 >これが、「『とりあえず動けばいいや』的な作りでも何とかなる場合も多い」という意味でしたら同意です。 >だからこそ、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の方がよく使われている 気がします。

前橋さん、本多さん、レスありがとうございます。 レスが大変遅れまして申し訳ありません (雑事に追われた挙句風邪で４日間も寝込んでて…日頃の行い？)。 こちらでお二人にまとめてレスしようと思います。 前橋さん> いやあ、このあたりは、最近はかなり「若い奴にお任せ」してる部分が大きいので、 前橋さん> 私がこの方面に詳しいかというとそんなことはないと思います (^^; ガーン。そうなのですか…。 前橋さん> 詳しくないなりに思うところを書きますが、こういうのはアプリケーションと 前橋さん> 環境により千差万別なわけですが、実はプログラマが仕事で書くプログラムの 前橋さん> 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 では、もう基本にある考え方そのものが違うという気がします。 でもなぁ…せめて個別のビルドツールについて、その設計思想を解説した本やサイトくらいあっても良さそうな ものだとやっぱり思うのですよ。