K.Maebashi's BBS

>> これだけの分量に対して、この程度の量の間違いって言うのは >> 私のプログラムのソースコードとバグの比率と比べて >> かなりいいと思いますが。 >いやあ、プログラムのテストと同じで、現状で見つかっているポカの数が >本当のポカの数を反映しているとは限らないわけでして。 >現状のチェックがぬるいだけで、これから増えるかもしれません。 こういう場合、チェック項目が何個もあるんでしょうけど、 それを自動化できないのはプログラマとしては歯がゆい感じしません? ところで、索引とかは何かのツールで自動生成してると思うので、 第2版では直っている、もしくは自動的に直ってしまうかもしれませんが 一つ間違いを見つけました... 索引(INDEX)中の「副作用」の項目を調べると97ページと書いてありますが 実際には副作用の記述は97ページにはなくて98ページにあるようです。 どうしてこういうことが発生するのかしら?ツールにバグがあるのかな? ツールで索引作成後に文章を書き足したのでしょうか? あ、「プロシージャ」は98ページとなっていますが、99ページにあるようですね。 ずれている場所を細かく調べると、どの文章を書き足したかわかる仕組み?(^^)/

> これだけの分量に対して、この程度の量の間違いって言うのは > 私のプログラムのソースコードとバグの比率と比べて > かなりいいと思いますが。 いやあ、プログラムのテストと同じで、現状で見つかっているポカの数が 本当のポカの数を反映しているとは限らないわけでして。 現状のチェックがぬるいだけで、これから増えるかもしれません。 もちろんそうならないことを祈ってますけれど。

>> ! = >>となっているように見えます ... >編集さんに確認メールを出しておきました。 　回答が来ました。 　結論から言うと、「!が全角になっていた」そうです。 　本文中で感嘆符として使う「!」は、私はいつも半角で書いていますが、 編集の際に全角に統一するらしく、その際、置換しすぎたそうです。 　本多さんご指摘の図を含め、第2刷にギリギリ間に合ったそうです。 　取り急ぎ、ご報告まで。

>　この週末は風邪引いて寝込んでまして、反応が遅れましてすみません。 ご自愛くださいませ。 >　正誤表の方ですが、ちょうど増刷がかかり、通しチェックをしていたので、 >それで見つけたポカと合わせてページを作成しました。 これだけの分量に対して、この程度の量の間違いって言うのは 私のプログラムのソースコードとバグの比率と比べて かなりいいと思いますが。 #まぁ、それは比較対照が悪すぎとも言いますが...(^^;)。 なにしろ、書物の世界はプログラムと違って コンパイラが構文チェックしてくれませんから ほとんど机上デバッグですもんね。

>センスオブプログラミングの95ページに掲載されてる否定演算子(名前うろ覚え) > != >ですが、間にスペースが入って > ! = >となっているように見えます ご指摘ありがとうございます。 確かにそう見えます。私自身、「心の隅にひっかかってた」状態でした。 ただ、 ・私から編集さんに原稿を出すときは、当然電子入稿(テキストファイル)である ・私が出した元原稿では、そんなところにスペースはない ・編集さんのところでわざわざそんなところをいじることはないだろう という判断で、フォントの都合か何かかと思っていました。 でも、別ページを見ると、もっと詰まっているところもありますよね。 編集さんに確認メールを出しておきました。

センスオブプログラミングの95ページに掲載されてる否定演算子(名前うろ覚え) != ですが、間にスペースが入って ! = となっているように見えます

>初めまして。koicと申します。 はじめまして。 >スレ違いでしたらすみません。 とんでもないです。スレッドタイトルそのままです。あああ。 >「センス・オブ・プログラミング!」のページに書かれているISBNが「Java謎+落とし穴徹底解明」のISBNになっております。 修正しました。重ね重ねポカしてましてすみません(_o_)

>P66の繰り上がり計算回路の「OR回路」の記号がAND回路で書かれています。 　ご指摘ありがとうございます。 　この週末は風邪引いて寝込んでまして、反応が遅れましてすみません。 　正誤表の方ですが、ちょうど増刷がかかり、通しチェックをしていたので、 それで見つけたポカと合わせてページを作成しました。 　…が、本多さんのご指摘は、気付いてすぐ編集さんにメールを入れたのですが、 たぶん第2刷に間に合っていないと思います。残念。

初めまして。koicと申します。 スレ違いでしたらすみません。 「センス・オブ・プログラミング!」のページに書かれているISBNが「Java謎+落とし穴徹底解明」のISBNになっております。

P66の繰り上がり計算回路の「OR回路」の記号がAND回路で書かれています。

こんばんは。 > それはそう思います。でもそれはお互い様であるわけで、 > プロジェクトに入ったら、「郷に従え」とは思います。 同意します。 そういうわけで私は新規作成の場合は自分のスタイルで打って コンパイル通ったら括弧の位置を直したりしてます(^-^;) 追加の場合は直してる時間がもったいないので 最初から規約に従ってコーディングしますね。 > 関数の最初のレベルはインデントしない、という規約もあった これってちょっと誤認識しそう(^-^;) 最近は4タブでエディタ横幅が広いのでネストを展開したり、 内部関数化して切り離すほうが現実的かもしれないですね。 # 実はまだ8タブ規約のプロジェクトも健在してます。 そういえば昔は変数宣言だけはインデントしないところは多かったような。 int main(void) { char hoge; int piyo; /*--- 以下略 ---*/ } 処理がどこから始まるかがパッと見で判らないからなんでしょうけど、 私はあまり好きになれませんでした。 > 組み込みとかでもまた話は違うとは思います。 私も組み込みは経験がないので何とも言えなかったり・・・ メモリを節約するなら共用体も有効かも！？ # サーバ系だと怒られそうですが。 グローバル変数は今の時代なら「クラス内static変数にすれば十分」とか 色々な選択ができるので議論が広がりそうですね。 ちなみに未だに残っている80文字制限ですが、 「telnetでシェルスクリプトなどを覗くクライアントがいて折り返すと大激怒される」 という理由のあって渋々やっているプロジェクトがありました。 # もちろん彼らはコードが読めないのですが・・・

>あとスタイルは長年の経験で手が憶えたとおりに打ってしまうので、 >それを変えるのが嫌というのも原因かもしれませんね。実際、変えるの難しいですし。 それはそう思います。でもそれはお互い様であるわけで、 プロジェクトに入ったら、「郷に従え」とは思います。 きっと違う誰かが保守するわけですからね。 ただ、聞いた話ですが、 int main(void) { printf("hello\n"); if (a==0) { printf("world.\n"); } } みたいな感じで、関数の最初のレベルはインデントしない、という 規約もあったそうです。確かに関数の切れ目はコメントなどでわかるから 無駄にインデントを深くしないためには合理的なのかもしれませんが… でも、あんまり一般的じゃない規約はちょっと勘弁してほしい、とも思ったり。 >私もここ何年かで読み手主体で名前をつけるようになりました。（WinAPIの影響かも） WinAPIやJavaのおかげで、最近の世代では長い名前が当たり前になっているかも しれませんね。今あれを本に書くのはちょっと時代遅れだったかも。 >グローバル変数はゲーム系だと良く利用しますし、 >「オープン系ではこう」「でもゲーム系はこう」なんて限定したほうが良いのかな、と思ってます。 組み込みとかでもまた話は違うとは思います。経験がないのであまり語れませんが。 実行環境にメモリがなくても、開発環境のコンパイラが賢ければ、(インライン関数とかで) カバーできる部分もあるのではないか、と思いますが…　Cだと苦しいですかね。

丁度いいタイミングで「ソースを読む」ことに関連するサイトを発見(^-^;) ソースコードを読むための技術 　　http://i.loveruby.net/ja/misc/readingcode.html 引用元： 　　http://d.hatena.ne.jp/oooooooo/20041109#p2 　　→言われてみると確かに、と思いました。 　　　私は他人のソースを読むのは好きです。

>　「中括弧の位置論争」なんかはもう純粋に好みの問題でしかない そうですね。 あとスタイルは長年の経験で手が憶えたとおりに打ってしまうので、 それを変えるのが嫌というのも原因かもしれませんね。実際、変えるの難しいですし。 （変数名、関数名のつけ方にも言えますね） だから私は自分のスタイルでコーディングして、 必要最低限（要は目立ちそうなところだけ）だけ規約どおりに直してます。 >　私は、本にも書いたとおり、「読むとき」の方が重要だと考えているので >あのような記述になりましたが、異なる立場はもちろんあって良いわけで、 私もここ何年かで読み手主体で名前をつけるようになりました。（WinAPIの影響かも） 下手に省略しないので命名も意外と楽ですし、統一が取りやすい感じがします。 逆にcreateをcrtなんて略されると私は思い出すのが面倒だなと最近思ったり・・・ >立場が変われば「変数なんて1文字でいいよね」とか「グローバル変数マンセー」が >正解になることもあるかもしれません。 変数一文字は「y = a * x + b」など明らかに意味が読み取れるなら問題ないでしょうね。 ただ、数学得意な方がこぞってこれをやってしまうと 普通のプログラマが演算ライブラリを弄るのにひと苦労かも(^-^;) グローバル変数はゲーム系だと良く利用しますし、 「オープン系ではこう」「でもゲーム系はこう」なんて限定したほうが良いのかな、と思ってます。

>さっき、X-Wordのサンプルコード(Windows版)をダウンロードしてビビりました。 >xword_ver1.0\maebashi\book\kotsu\xword_ver1.0\src_dos\com\kmaebashi\xword >なんか、一般向けに配布するにしちゃ、やけに階層が深くないですか?(^^;) すみません、単純に、圧縮する際のミスでした。修正しました。 報告ありがとうございました。 ログを見ると、30人ほどの方が既にダウンロードされていたようです。 確認不足でご迷惑をおかけいたしました。

さっき、X-Wordのサンプルコード(Windows版)をダウンロードしてビビりました。 xword_ver1.0\maebashi\book\kotsu\xword_ver1.0\src_dos\com\kmaebashi\xword なんか、一般向けに配布するにしちゃ、やけに階層が深くないですか?(^^;) (kmaebashiという名前のフォルダが2度現れて、階層がループしてるのかと疑いました) 今後、配布するコードを格納するためのフォルダとかを熟慮した結果こうなった...ということかしら? まだ、この本を手に入れてないんですけど、 「普通は、これくらい深い階層で開発するべきなんだ」とか書いてあったりして?

　お買い上げいただきありがとうございます。 >スタイルについては「なぜ相手がそうしているのか」を理解する気があれば、 >話は大荒れになったりしないんだろうといつも思いますけどね(^-^;) ># もしかして雑記はこのための布石とか？ 　そうかもしれません (^^; 　雑記帳の方には、 | 最終的に「好み」や「優先度」の問題に落ち着くようなことは結論は出ませんけど 　と書きましたが、スタイルに関する宗教戦争にもこういう面はあると思います。 　リンク集にも入れている「「いんちき」心理学研究所」の編集後記のページで、 こんな記述があります。 http://2shin.net/neko/ | コップに水が半分あって、「もう半分しかない」と解釈するか | 「まだ半分もある」と解釈するかでどちらが正しいかを議論して | どれだけ意味があるのか。 　「中括弧の位置論争」なんかはもう純粋に好みの問題でしかないと思いますが、 たとえば変数名をどれくらいの長さにするのか、ということであれば、 ソースを「書くとき」と「読むとき」のどちらに重点を置くかで 正しい対応が変わってきます。 　私は、本にも書いたとおり、「読むとき」の方が重要だと考えているので あのような記述になりましたが、異なる立場はもちろんあって良いわけで、 立場が変われば「変数なんて1文字でいいよね」とか「グローバル変数マンセー」が 正解になることもあるかもしれません。

昔のエディタのアルゴリズム（ポインタを逆向きに繋ぎかえる）とかが 掲載されていたので興味を持って買いました。 # 恥ずかしながらその辺り知らなかったもので・・・ かなり現場寄りの要点が書かれていますね。 私も「あー、そうなんだよ。」なんて思いながら読み進めてました。 # 私もこれくらい的確な説明で指導できればなぁ(T_T) スタイルについては「なぜ相手がそうしているのか」を理解する気があれば、 話は大荒れになったりしないんだろうといつも思いますけどね(^-^;) # もしかして雑記はこのための布石とか？

>「「センス・オブ・プログラミング!」のページに戻る」ためのリンクが >「「Java謎+落とし穴徹底解明」のページに戻る」となってますよー(^.-) うわ、ご指摘ありがとうございます。修正しました。 >コピペしたでしょ? 図星です。 この本の中に、「コピペすると後で必ず後悔するよ」ってことが書いてあるのですが、 まさに身をもってそれを実践してしまいました(_o_)

どうでもいいことですが、例題プログラム「X-Word」のページの一番下にある 「「センス・オブ・プログラミング!」のページに戻る」ためのリンクが 「「Java謎+落とし穴徹底解明」のページに戻る」となってますよー(^.-)

>いつも楽しく読ませていただいております。 どうもです。 >なぜなら、面倒臭い作業をしなければならない状況ほど、「思考停止」というのは人を楽 >にしてくれるからです（人間の生理というのはそういうものなんだそうです）。 ええと、プログラマのような「面倒なことを回避できる仕事」ならともかく、 回避できない仕事の人は思考停止もある程度しょうがない、ということでしょうか? うーん、仕事上のことであればそうかもしれませんが、それ以外のことについては どうでしょうか。職種が全てに影響を与えるほど、みんな心血絞って仕事してる わけじゃない気がするんですが。 あと、雑記で書いた「進化論と創造論」のような話なら、それこそ日常生活を 送るには関係ない話です。「神様が創ったんだよ」を丸呑みするよりは、 「おら知らね」の方がずっと誠実な態度だと思えるんですよね。

いつも楽しく読ませていただいております。 で、雑記の「宗教な話」を読んだ感想としては、仰ることには全面的に賛成ですけれども、 「面倒臭いことからは可能な限り逃げるのがプログラマの美徳」と仰る（ぱ）さんらしい 見解だとも思いました。 なぜなら、面倒臭い作業をしなければならない状況ほど、「思考停止」というのは人を楽 にしてくれるからです（人間の生理というのはそういうものなんだそうです）。 ちなみに、私はプログラマとは全く畑の違う職業に就いておりますが、やはり面倒臭い作 業から逃げることが許されない職業です。 もちろん、職業だけで人の思考が規定されるわけでもありませんし、私自身も（ぱ）さん の仰るとおり、思考停止に陥らないよう努力したいものですけど、それでも世の中からは 思考停止な人が消えることはないんでしょうね。

ええと、投稿者により削除された投稿にレスするのもアレかもしれませんが。 昨年は、2月の健康診断に向けて11月末(って30日だから実質12月からですな)から 断酒を始めたわけですが、会社が変わったせいで、健康診断の時期が変わってしまいました。 どうも5月頃らしいです。 「俺はいつ断酒をはじめたらいいんだろ」と同僚に言ったら、 「今から始めればいいのでは」と言われてしまいました。もっともです。

>前橋信者未満な前橋ファン、かつ半人前プログラマな僕としては、これは >是非読みたいです！ ありがとうございます (_o_) >先日の「宗教な話」を深読みすると、論争を巻き起こしそうな内容ってこと >なのでしょうか？期待しています！ そういう面が全くないとは言いませんが、そんなにはないだろう、と 書いた本人は思っていますです。 もちろん既刊の3冊も、そうだと思っています(きっぱり)

前橋信者未満な前橋ファン、かつ半人前プログラマな僕としては、これは 是非読みたいです！ 仕事帰りにさっそく書店に寄ってみます。（って、仕事中に書き込んでますが。。） 先日の「宗教な話」を深読みすると、論争を巻き起こしそうな内容ってこと なのでしょうか？期待しています！

　や、まとまらない話にご意見いただきありがとうございます。 > しょせん日本人が「私は Free Software Foundation 信者である」とか「彼は qmail 信者だから」 >といったところで、葬式のときには仏教に頼る、という程度の意味しか持たないのではないかと思うのです。 　これなんですが、伝統宗教以外の世界で「○○信者」と言ったらそれはけなし言葉だろう、 つまり自分から「○○信者」と名乗ることはあるまい、ということを雑記帳には書いた のですが、書きながら、いやFSF信者だけは「自称」するかもしれない、と思ってました。 いやそのなんとなく。 > Gnu/Linux 遣いが PostgreSQL を使ったり、qmail 信者の人が DNS サーバは BIND だったり。 　正しい姿勢だと思います。所詮は道具なので。 > ...で、そこが日本人の良いところだと思うのです。 　これはつくづくそう思います。 　葬式仏教にはそれなりの存在意義があるし、初詣だって仲間とわいわい行けば楽しい でしょうし。

しょせん日本人が「私は Free Software Foundation 信者である」とか「彼は qmail 信者だから」 といったところで、葬式のときには仏教に頼る、という程度の意味しか持たないのではないかと思うのです。 Gnu/Linux 遣いが PostgreSQL を使ったり、qmail 信者の人が DNS サーバは BIND だったり。 「信者」という言葉の意味、英語の「洗礼を受けた人」よりもだいぶ軽いんじゃないですかね。 ...で、そこが日本人の良いところだと思うのです。 -- yaemon

>>b)KeywordとPKeywordの区別はつけられるのか、という気がしますし、 >タグ検索のような事ができると聞いた事が有ります。例えばKeywordで検索すると >＜Keyword＞＜／Keyword＞の属性をメタファイルからチョイスし（複数ある場合もあります） XMLから特定の要素を抜き出したいのであれば、DOMなりSAXなり使えばよいと思います。 ただ、私が「KeywordとPKeywordの区別はつけられるのか」と書いているのは、 「PKeywordはそもそも不要では?」ということです。 既に例示されているA, Bでは、AがBへのリンクを持つだけでなく、BもAへの リンクを持つことになるのでは? つまりPKeywordは不要で、 単純に「共通のKeywordを含むメタデータへリンクする」ということに なるのではないかと思うわけです。 >>c)LOMだと、他のリソースを参照する場合はRelationという要素を使うようですし。 >LOMのRelationは，他のコンテンツ（LOMではない）を関係付ける記述です。また おっと、これは私が誤解していました。失礼しました。 >何か良い正規化の仕方は，あるでしょうか？ >>a)メタデータクラスとキーワードクラスができて、 >>b)メタデータクラスはキーワードクラスを0..*で集約していて、 >>c)キーワードクラスは、そのキーワードにより関連するメタデータへの >>　参照を保持するようにする。 ここのところ、修正します。あるキーワードから、そのキーワードにより 関連するメタデータは複数ありますよね。 >>または、LOMの構造を意識するなら、 >> >>a)メタデータクラスとキーワードクラスとリレーションクラスができて、 >>b)メタデータクラスはキーワードクラスを0..*で集約していて、 >>c)メタデータクラスはリレーションクラスも0..*で集約していて、 >>d)リレーションクラスは、そのメタデータと、何らかの要因(必ずしもそれは >>　キーワードの一致でなくてもよい)で関係するメタデータへの参照を >>　保持するようにする。 >これも勉強します。「0..*で集約」の意味が解っていないという寂しさ・・ 正直、この件に関する限り、特にOO用語を使う必要はないように思います。

はじめまして（ぱ）さん。有難うございます（＾0＾） ものすごい早い回答で嬉しいです。またご丁寧な説明有難うございます。 ならびに少々わかりづらい文面があったこと申し訳ありません。 プログラム初心者の私にとって，メタデータの関係付けプログラムを 作成するのは，色々と難解な所が有ります。・・（ToT) 頑張ります。 >a)あるデータについて、Keywordはひとつのような気はしませんし、 確かに複数ある場合があります。 >b)KeywordとPKeywordの区別はつけられるのか、という気がしますし、 タグ検索のような事ができると聞いた事が有ります。例えばKeywordで検索すると ＜Keyword＞＜／Keyword＞の属性をメタファイルからチョイスし（複数ある場合もあります） ただし聞いた事があるだけなので，実際にみた事はありません。仮に無かった場合は， JAVAプログラムでタグから属性見つけるプログラムを作成することは，できるできるでしょうか？出来たらいいんですけど・・・ >c)LOMだと、他のリソースを参照する場合はRelationという要素を使うようですし。 LOMのRelationは，他のコンテンツ（LOMではない）を関係付ける記述です。また そのコンテンツを，LOM作成者が知っている必要があります。 私がやろうとしている事は，メタデータ同士を関連付けるプログラムでござります。 メタデータAを登録すると⇒自動的に関連付ける という感じです。つまり他のオブジェクトを意識せずに関連付ける事が出来ます。 「属性を記述することで関係を持たせる」というコンセプトで考えています。 >ひとつのメタデータには複数のキーワードがあり、 >あるメタデータから、共通するKeywordを含む(全ての?)メタデータへの >参照を持ちたいのなら、テーブルを分けて正規化するのがセオリーの >ように思うんですが、どうでしょうか。 流石でございます。確かに今のDB構造では，ダメだと思っていました。 今どのように正規化するのかも検討しています。←実はDBについても初心者なので 　　　　　　　　　　　　　　　　　　　　　　本を抱えて勉強中です。 　　　　　　　　　　　　　　　　　　　　　　本は，SQLでござんす。。 何か良い正規化の仕方は，あるでしょうか？ Keyword属性 PKeyword属性 リンク先ID この3つは，複数ある場合があります。 >a)メタデータクラスとキーワードクラスができて、 >b)メタデータクラスはキーワードクラスを0..*で集約していて、 >c)キーワードクラスは、そのキーワードにより関連するメタデータへの >　参照を保持するようにする。 > >または、LOMの構造を意識するなら、 > >a)メタデータクラスとキーワードクラスとリレーションクラスができて、 >b)メタデータクラスはキーワードクラスを0..*で集約していて、 >c)メタデータクラスはリレーションクラスも0..*で集約していて、 >d)リレーションクラスは、そのメタデータと、何らかの要因(必ずしもそれは >　キーワードの一致でなくてもよい)で関係するメタデータへの参照を >　保持するようにする。 これも勉強します。「0..*で集約」の意味が解っていないという寂しさ・・ 知識が無く申し訳ないです。。。 以下にアドレス 3aeem029@keyaki.cc.u-tokai.ac.jp

>初めまして，ねこさんといいます。 ねこさんさん(でいいんでしょうか?) はじめまして。 >例 >Aというメタデータ内 >＜Keyword＞仲間＜／Keyword＞ >＜PKeyword＞学校＜／PKeyword＞ > >Bというメタデータ内（Aと同じく） >＜Keyword＞相性＜／Keyword＞ >＜PKeyword＞仲間＜／PKeyword＞ ええと、私はLOMについては今調べた知識しかありませんので、見当外れの ことを言ってましたらすみません。 このモデルには正直ちょっと違和感を感じます。 a)あるデータについて、Keywordはひとつのような気はしませんし、 b)KeywordとPKeywordの区別はつけられるのか、という気がしますし、 c)LOMだと、他のリソースを参照する場合はRelationという要素を使うようですし。 >AのKeyword属性とBのPKeyword属性が同じなので >AとBは関係しているようにしたいのです。 > >これをDBに記述すると >メタID　メタデータ名　Keyword属性　PKeyword属性　リンク先ID >　1　　　　　A　　　　　仲間　　　　　　学校　　　　　 2 >　2　　　　　B　　　　　相性　　　　　　仲間　　　　　 Keywordがひとつでよく、KeywordとPKeywordの区別があってよく、 ひとつのメタデータが参照するメタデータもひとつでよいのなら、 このテーブルでよいのでしょうが、それでよいのでしょうか? ひとつのメタデータには複数のキーワードがあり、 あるメタデータから、共通するKeywordを含む(全ての?)メタデータへの 参照を持ちたいのなら、テーブルを分けて正規化するのがセオリーの ように思うんですが、どうでしょうか。 >またこれを実現するための >オブジェクト指向が聞けるとすごく嬉しいです。 >（これを先に教えていただけると嬉しいです） 「オブジェクト指向が聞けると」というのはちょっとよくわかりませんが (^^; a)メタデータクラスとキーワードクラスができて、 b)メタデータクラスはキーワードクラスを0..*で集約していて、 c)キーワードクラスは、そのキーワードにより関連するメタデータへの 　参照を保持するようにする。 または、LOMの構造を意識するなら、 a)メタデータクラスとキーワードクラスとリレーションクラスができて、 b)メタデータクラスはキーワードクラスを0..*で集約していて、 c)メタデータクラスはリレーションクラスも0..*で集約していて、 d)リレーションクラスは、そのメタデータと、何らかの要因(必ずしもそれは 　キーワードの一致でなくてもよい)で関係するメタデータへの参照を 　保持するようにする。 ということになるのではないでしょうか。 ズレたこと言ってましたらすみません。