2009-08-01
プル型ダウンキャストとプッシュ型ダウンキャスト
２種類あることに今気づいた。これが分かると、なぜIDが必要かが分かってくると思う。
このうち、プル型ダウンキャストはやばいが、プッシュ型は許される。
例えば、プッシュ型というのはString.valueOf(10)みたいなこと。これはダウンキャストではないけど、ダウンキャスト対象をプッシュして、それからStringを返してもらってきている。自分が必要なのはストリングなのでこれはおk
だが、逆に、これはやばい。
Node n = (Node)tree.getRoot();
これはプル型ということになる。引き出してからダウンキャストするのはよくなくて、押し込めてから中でダウンキャストをカプセル化出来ればよい。
ダウンキャストのカプセル化はマーチン本にも書いてあるリファクタリング。ダウンキャストっていうのは、これより、渡した情報をなんか別のものに変換してから教えてくださいというものだということが分かる。
IDが必要なのは、IDをプッシュして情報を引き出すから。実物がいろんなところを放浪して、それをダウンキャストしたりするのはあまりに美しくない。
（追記）
わけわからん。
なんか微妙にインターフェイスが汚れてきた感が否めない。
もう一回見直そう。
ミスっても1時間やそこらで戻れると思うけど、意味不明な設計を拡張するのはマゾの仕事だ。おれはマゾではない。
今日は、テーブルを木に変換するクラスを作った。これは有益なクラスだ。なぜならば、多くのデータはテーブル型だからだ。クラスタリングをサポートするということだ。条件を記述して、それをぶちこむ！頭の良い人は条件を計算機的に生成すればいい。そういうことも可能だ。
次のステップはテーブル型そのものの可視化だ。idを持ってそれを参照しながらという設計は悪くはないと思う。理由は、分割された領域で同じものを同じというのには、すべての領域が依存出来るだけ安定した記号が必要だからだ。確かに、テーブル自体は安定しているけど、だからと言って、テーブルのデータが直接、プログラム中を泳ぐという設計はかなり意味不明な気がする。突き詰めると、どのクラスも結局そのデータに依存してはいるし、それに依存しないことなんて考えられないけど、取得したものを飛び回らせるというのはよく分からんがおかしい。理由は分からん。この理由を今考えている。
分かりにくいというのはあると思うが、idを記号にしてしまうと、常にデータテーブルに依存するという悲しい形になる。これがいいわけがないんだけど、それでもしょうがないという気持ちはある。つまり、テーブルがほとんどグローバルデータになってるということ。
分からん。直感的に悪い設計には見えないし、良いと思ったからこうしたわけだけど、今は少し疑問に感じ始めている。
テストを通した。
class TestCondition_1 implements BranchingCondition{ IDataTable _data; public TestCondition_1(IDataTable data) { // TODO Auto-generated constructor stub _data = data; } @Override public int getGroupID(int candidate, List<Integer> allCandidate) { // TODO Auto-generated method stub int groupID = 0; if(_data.getData(candidate).getData("name").equals("A")){ groupID = 0; } if(_data.getData(candidate).getData("name").equals("B")){ groupID = 0; } if(_data.getData(candidate).getData("name").equals("C")){ groupID = 1; } return groupID; } } public class TreeFromTableTest { @Test public void 分岐をテスト_1(){ NodeTable t = new NodeTable(); Map<String, String> m1 = new LinkedHashMap<String, String>(); m1.put("name", "A"); Map<String, String> m2 = new LinkedHashMap<String, String>(); m2.put("name", "B"); Map<String, String> m3 = new LinkedHashMap<String, String>(); m3.put("name", "C"); t.setData(0, new ImmutableProperty(m1)); t.setData(1, new ImmutableProperty(m2)); t.setData(2, new ImmutableProperty(m3)); assertEquals(3, t.getNodes().size()); Node<BranchingCondition> conditionalTree = new Node<BranchingCondition>(new TestCondition_1(t)); conditionalTree.addChild(new Node<BranchingCondition>(new NullBranchingCondition())); conditionalTree.addChild(new Node<BranchingCondition>(new NullBranchingCondition())); TreeFromTable treeFromTable = new TreeFromTable(t, conditionalTree); Node<Integer> root = treeFromTable.getRoot(); INode<Integer> branch_0 = root.getChildren().get(0); assertEquals(0, (int)((Node<Integer>)branch_0.getChildren().get(0)).getItem()); assertEquals(1, (int)((Node<Integer>)branch_0.getChildren().get(1)).getItem()); INode<Integer> branch_1 = root.getChildren().get(1); assertEquals(2, (int)((Node<Integer>)branch_1.getChildren().get(0)).getItem()); } }
テストする気ないけど、テーブルと分岐条件から木を生成するクラスを作ってみた＾＾
テーブルデータから、木を生成するっていうのは、結構なジョブで、おれは、テーブルに加えて、分岐条件を書いた木によってテーブルから木を作るという発想にした。結構、ライブラリ作成って楽しい。ただし、テストする気は今のところ、ない。
public interface BranchingCondition { /** * Node<BranchingCondition>における子ノードの数と, * このメソッドで取得しうる分岐の数は同じでかつ, * 0からはじめてください. * * @param candidate * @param allCandidate * @return */ public int getGroupID(int candidate, List<Integer> allCandidate); }
public class TreeFromTable { Node<Integer> _root; int _maxIndexInTable; TreeFromTable(ITable table, Node<BranchingCondition> conditionTreeRoot){ _maxIndexInTable = Collections.max(table.getNodes()); _root = getNextBranch(); branchingAll(_root, table.getNodes(), conditionTreeRoot); } public Node<Integer> getRoot(){ return _root; } Node<Integer> getNextBranch(){ return new Node<Integer>(_maxIndexInTable++); } void branchingAll(Node<Integer> rootNode, List<Integer> givenLine, Node<BranchingCondition> conditionNode){ // 葉ノードだったら, // もう分岐がないので, // 全部ノードをつけてしまう. if(conditionNode.getChildren().isEmpty()){ for(int id : givenLine){ Node<Integer> child = new Node<Integer>(id); rootNode.addChild(child); } return; } List<List<Integer>> branchingResult = branching(givenLine, conditionNode); for(int childIndex=0; childIndex < branchingResult.size(); childIndex++){ Node<Integer> child = getNextBranch(); rootNode.addChild(child); Node<BranchingCondition> condChild = (Node<BranchingCondition>) conditionNode.getChildren().get(childIndex); branchingAll(child, branchingResult.get(childIndex), condChild); } } List<List<Integer>> branching(List<Integer> givenLine, Node<BranchingCondition> conditionNode){ List<List<Integer>> groups = new ArrayList<List<Integer>>(); for(int i=0; i<conditionNode.getChildren().size(); i++){ groups.add(i, new ArrayList<Integer>()); } for(int id : givenLine){ int groupID = conditionNode.getItem().getGroupID(id, givenLine); groups.get(groupID).add(id); } return groups; } }
あと、木からテーブルを吐くという方法もめっちゃ再設計になったけど、３０分くらい書けてやり方を変形させた。何かおかしいという匂いは感じていた。２つのことをやっているような気がしていたが、それを分離した。
設計に疑問を感じてきた。
引き返すなら今だ。
データをListでもつかid=>Dataのテーブルで持つかという些細な違い。
前者なら、常にcastでいいけど、後者なら、毎回テーブルに依存する上にハッシュ値計算が入る。
値がとびとびならば、テーブルの方がメモリ効率がよい（例えばListでadd(1000000000000000, obj)とやると一発でメモリ消し飛ぶ）。
大体、idに依存すると、intでは足りませんというときにIDクラスでラップしときゃよかったとなるが、生のデータが飛び交ってくれたら、それはかなり楽だ。全体として、idに依存するのは悪くないが、もしかしたら、生のデータに依存するのは良くないかも知れない。
ただ、生のデータに依存して悪くなるケースが思い浮かばないというのも事実だ。
（追記）
テーブルでデータを持つということにして、ノードにリンクを貼る場合、おれにはノードがidを持ってるという前提しか思い浮かばない。
さて、castとテーブル参照ってどのくらいスピードが違うのか、ってことになってくるな、これは。
アジャイル的な開発手法
拡張は小さく。
拡張の前には本気でリファクタリングを。
今、リファクタリング中。特に、クラスの位置とか、moveしまくってる。Eclipseがなければ不可能だと思う。Eclipseがなかったら、たぶんもう30歳くらいになってる。
最小のインターフェイス
気に入っている。外部に公開するインターフェイスは一種類であるべきだ。
だが、この選定方法が難しい。
David Archuleta - With You‐ニコニコ動画(ββ)
アチュレタ聴いて考えよう。このレベルになってくると、一つ一つの決定が命取りになる可能性がある。本当によくなると分からなければやりたくない。生成系は結構使われてるんだよ。
土日は仕事どきだ。
おれはコーディングする時、ぶつぶついう。
何か独り言を言わないと、開発出来ない。企業にとって、どんなに優秀であってもいらない子なのは自覚している。だから、企業に就職したくないのだ。他人とも関わりたくないし、おれは自分の世界だけで閉じていたい。必要ならばアクセスするから、こちらに話しかけないで欲しい。依存性の循環は悪だ。
さて、リファクタリングをした。自分的に、わざと妥協している面もある。例えば、処理とデータを本当なら同じプロジェクトに入れていいのだけど、データがコアなので、それにつきまとう処理が多く、だから、わざと分離して、わかりやすくしているという感じだ。しょうもない抽象データならまだしも、ソフトウェアの中でコアとなる抽象型に関する処理は一つのプロジェクトとして独立させるだけの価値がある。
今、私は、
public interface ITreeTable extends ITable { public List<NodeLink> getNodeLinks(); } public interface ITable { public List<Integer> getNodes(); }
このように、抽象を分離した。抽象の階層を作ってしまうことは必ずしもよくない。それは知っている。継承には問題があり、それは順序を入れ替えられないことだ。
だが、順序を入れ替える気がないのであれば、継承は悪くない。例えば、おれは他に、
public interface IDataTable { public ImmutableProperty getData(int id); }
こういう抽象ももっている。idに対してデータを吐くという抽象だ。データベースを想像してもらえばいい。おれは、これについて、ITableを継承してITableWithDataを作り、その上でITreeTableWithDataを作るのはかなり危険だと考える。そると、ITreeTableという、ツリーを表現しただけの抽象がどこかに消えてしまう。
これは、「どこにデータという概念を入れるかどうか入れ替われるようにしたいから継承がダメだ」という例だ。データがあるかないかというのは、付加的な抽象であり、ツリーとは切り離すべきだ。
データ構造などは継承しても構わないが、違う分野の話をまぜると、その抽象は一般的に装飾なので、まずくなる。ピュアに保ちたいという思いがある。
（追記）
リファクタリングによる継承階層の作成はうまくいくことが多いが、非リファクタリングによるそれは、失敗することが多いと思う。最初から継承階層を作り込むと、大抵の場合は失敗する。それはウォータフォールの失敗にも似ている。ボトムアップ、リファクタリング、これなのだ。無意味にリスクを背負い込んではいけない。巨大なソフトウェアは個人では作れないなどと思いこんではいけない。ソフトウェアは積み重ねだ。
カズムを狙って研究室にやってきた。
ほんの30分の雨止みを狙って、研究室に来た。結果として、傘をささなくてよくて、研究室についた瞬間に雨がざーっと降り出した。我々は我々のカンを信じることで、雨に濡れることを避けることに成功した。
さて、おれは思うのだ。
デフォルトがあるのであれば、デフォルト以外の値をコンストラクタで入れる必要がない。
というルールを決めるとどうだろうか。
デフォルト値というのは、簡単にいうと、ユーザ値が必ずしも必須ではないという意味だ。
では、必須な場合はどういう場合であろうか。
1. バグってしまう。
2. 落ちてしまう。
などだろう。例えば、ネットワークの設定が個別に必要なのは明らかなのにデフォルト値を組み込んでおいてもしゃーない。anyway, この問題は少し置いといて、テーブル可視化の方の開発を進めることにする。問題は、開発しながら考える。開発しながら考えることには意味がある。コードが書けないやつはくそったれだ。ビッチだ。
２ちゃんねる可視化によっておもしろいことが分かるかも知れません。
例えば
YouTube - KYOKYO - ZONE OF RAPISTS
可能性としてですが、本人の書き込みなどが分かってしまう可能性があります。
（追記）
見たけど、アヌビス分からんから全く分からなかった。
せめてエヴァくらいならね。
サブリミっぽい感じで文字がパンパン出てきて理解出来ないから＾＾；ま、見ずに感じろってことなのかな。
レイプか、レイプだけはダメだ。男の責務は女を守ることだ。
雨は・・・ダメだ。
おれの中で、少し階層構造から離れて、テーブルデータの可視化をしたいという思いがある。
階層型はテーブルの行にリンクをつけたものと考える、おれの中では。だから、まずはテーブルの方からさっと枠組みを作って、利用出来るものを階層型の方で利用する方が良いと思う。また、テーブルデータを階層型にクラスタリングによって変形するという手法も実装したいと思っている。
なので、早急に研究室に行って実装を始めたいのだが、雨や雷がひどいので、研究室に行けないのだ。まじで京大なんか来るんじゃなかった。
え・・・これ・・・京大じゃないの？
【宮崎】哲学の授業なのに「カレーの作り方」のリポートで単位認定-都城工業高等専門学校の男性教授★３
都市伝説かも分からんけど、カレーの作り方書いて出せば通るみたいな話があった気がします。
おれはふつうに書いて出したけどね。おれって、意外にマジメなんだよ。
衣装ではない。おれはそもそもこいつが日本代表ということが許せない。
ミス・ユニバースの“過激すぎる衣装”、抗議殺到でデザイン変更（Copyright 2009 SANKEI DIGITAL INC.）（産経新聞） - Yahoo!ニュース
まず、日本は、ミスユニに代表を派遣すべきではない。ミスユニは所詮、欧米基準の美しさの祭典だ。結局のところ、「欧米で評価を受けそうな日本人」ということが基準になっている。これはどういうことかというと、「白人になれなかった哀れな日本人」という意味だ。
日本には日本の美がある。それは日本で閉じて入ればいい。セックスする時に息を吸う外人には理解出来ない美しさがある。艶やかさがある。それは、日本の中で守ればいい。
結局、こいつにしても美しいは美しいが、果たして、プエルトリコだのイタリアだのアルゼンチンだのの超絶美女に比べるとどうかというと、遺伝子的に絶対に勝てませんと断言出来る。つまり、最初から本質的に勝てないことが保証されている。森なんとかとか、ふざけんあ。明らかにくららさまの方が上だった。
その上、「日本の奥ゆかしさを表現したい」だとか笑わせる。欧米基準の女を選んでおいて、「日本にもちゃんと欧米に通用する女がいるんだお」という主張をしているのに、なぜ、日本固有の奥ゆかしさに回帰しようとするのかが矛盾にしか思えない。日本にも、欧米に通用する美女がいることは確かさし、この宮坂もすごいスタイルをしているが、それでも外人の美女には勝てない。少なくとも、シャラポワの方が上だ。遺伝子的に無理。
だから、こんなくだらない祭典にはまず、代表を派遣しないという決断をすべきだ。知花くらら以外は全員カスだ。あの方は本気で美しいが、他のはただのビッチだろう。今回だって、ふざけた衣装で、全くもって、狂ってるとしか思えない。ゲイシャとか、ニンジャとか、ハラキリの世界だ。そういう外人が日本に持っているであろう印象に媚びてるだけ。日本人女性がこの祭典で優勝することには意味がない。もし、美しい女性がいて、私は世界一美しいのよ！というのであれば、まずイタリアの国籍をとってあげなさい。そして、イタリアの予選を勝ち抜いてから世界大会に出てください。日本からミスユニに代表を派遣する必要はありません。この宮坂がイタリアの予選を勝ち残ることは絶対にありません。第１０次予選敗退です。本当にありがとうございました。
くそがっ！！！
たわごとから続いてこのブログシリーズでは再三に渡って論理の重要性を説いてきたはずなのに、お前らには全然分かってもらえていないのか。
おれは、無力だ。
論理の重要性を常に意識しろ。堅牢な論理構造には価値がある。文系を雇うな。彼らは論理が分からない。優れた理系のみが雇われて、他は全員奴隷でいい。論理が分からないやつは、環境を汚すだけだから、優れた理系の奴隷として生きればいい。おれなどは超天才だから、１万人くらいニートを与えられて自由に駒として使えてもいいくらいだ。無能なやつが自分の意志で動いてくれることほど悪いものはない。優秀な人間の足を引っ張るバカにはははと笑っていられるおれではない。
おれが会社を作るとしたら、採用試験では知能指数の検査を行う。知能指数が低いやつは大抵の場合、まともな論理が構成出来ない。もちろん、文系は論外だ。文系の世界には論理というものが存在しない。
お前らには、論理の重要性を分かってもらいたい。それが、おれの願いだ。
英語は論理に制約を与えた良い言語です。
以下の英文を見て欲しい。これを理解出来るやつは、日本人だ。ネイティブは理解出来ない。
I think he do not love her.
正しくは、
I do not think he loves her.
だ。これならネイティブが理解出来る。池沼文というのは上のような論理で書かれた文であることが多い。こういう文を読んだとき、おれはその筆者を殺したくなる。生きている意味はない。
分かりやすい論理構造には２通りのマナーがあるとおれは考える。
- 否定はなるべく外で否定する。
- 早い段階で、事象を絞り込む。
後者は、プログラミング言語的にいうと、ガード文のことだ。ガードで落とせば、事象を早く絞り込める。
そして、前者というのはプログラミング言語的にいうと、else文が読みにくいことと等価だ。おれには、not分岐に入った文章が続く意味がよく分からない。これでは、条件をtrue, false, false, trueと追うことになる。悲惨だ。デバグ不可能、最適化不可能。うんこコード。書いたやつは死んで詫びるべき。
elseは使ってはいけない。ifを使って、いらない条件を省く。
正しい英語はまず、「おれは考えない！」ということを言っている。これによって、その後に来る文はtrueの文だと確定出来る。he loves herがtrueであることをおれが考えるのはfalseだ！と言っているのだ。外側に否定を持ってきているから読みやすい。まず、最初に考えない！という言葉で、おれが考えているという事象を落としている。
対して、前者の文は、thinkがtrueなのだから、その後に続く文の論理が確定出来ない。つまり肯定文か否定文か分からない。結果として否定文でしたが、この文はI think he loves herという形にもなりえた。もし、最初に否定を置くことをルールづけていたら、I thinkの段階で、もし次に彼が彼女を愛しているかいないかという文が続くとすれば、１００％、「愛している」側に絞り込める。
プログラミングの論理が分かっていれば、池沼論理を書いてしまうことはない。
なぜ、分かりやすい文と分かりにくい文があるのか、おれはこれについて非常に多くの規則を知っている。そもそもが文に対して敏感だし、コードの可読性というものと、一般的な文章の可読性には共通する部分が多いのだ。池沼文系の文は大抵の場合、分かりにくい。なぜか。それは彼らが論理を学んでいないからだ。おれは、良いコードが書けないやつに良い文章が書けるはずがないという考えを持っている。文章が意味を持つことは当たり前だ。しかし、それは小学生で学ぶことであり、大人の文というのは可読性が高くなければならないのだ。
作法を学び、可読性の高い文を書こう。論文の書き方や、文章の書き方と言った本に色々書いてあるから、これから卒論を書くやつはちゃんと読めよ。クズみたいな文章を他人に読ませる下衆じみた真似はするな。そういうやつはさっさと死ね。
池沼文を発見
・ン・ク・キ・逾?(・オ・ノ・?)トエター - link page FSWikiLite Ver
股間に違和感がない高さ以上には上げないようにして下さい。
おれはこれを見た時、何が言いたいのか分からなかった。全く。
理由は簡単な、否定文が多すぎる。論理が複雑すぎる。
この文はこうリファクタリングすればいい。
股間に違和感のないサドル高さにしてください。
なぜ、上の文がやばいかというのは、これはcode completeを読めば分かる。これは簡単にいえば、
boolean isNotLeaf();
みたいなメソッドを定義しているということだ。一般的にbooleanというのは、「ポジティブな名前をつける」という方が良いのだ。
これで言いたいのは、
ということだけだ。だから、「上げないでくれ」と、否定側を消す意味がない。十分に下げてくれ、と言えばいいだけだ。これの方がポジティブな意味だから、わかりやすい。また、往々にして、否定形を用いると論理を誤りやすい。例えば、小さいの否定が大きいになったりする。答えは、小さくはない、だ。
お前らに気をつけて欲しいのは、常に、論理値にはポジティブな名前をつけるということだ。人間はまず、ポジティブ側から考える。常にプラスを基準として、マイナス側を考える。マイナスを基準にする人はいない。だからプラス側の情報として提供した方がわかりやすいのだ。
また、もっと言ってしまうと、池沼文の方は、文意が一意に決定出来ない。例えば、上の文をこうすればどうか。
股間に違和感のある高さ以上には上げないようにして下さい。
上の文はこれと同じことだ。ある高さ以上は違和感があるので、やめてくれ、と言ってる。つまり、池沼文は論理を履き違えたのだ。原因は、
「ない高さ以上」というところにある。
ない以上とは何だろうか。この人は、サドルの高さを上から下げていくことを前提にしているのだ。上から下げていって、ある点では違和感がなくなる。だからそれ以上にはしてはいけないと言っているのだ。はぁ？意味が分からない。
以上と言ってるのだから、軸は上向きにとらなければいけない。だから、下から上に軸をとらなければいけない。だから、「ある以上」が正解だ。おれには、サドルが高いと違和感が出るという予備知識があるからこうやって理解出来ないこともないが、それでも理解するのに１分はかかった。本来なら、コンパイルエラーが出る。
きたあああああああああああああああああああああああああ
体重67.5
彼女が近づいてきたああああああああああああああああああああああああ
65になったら彼女出来る。あと、ざっと20000kcalだ。
これはいける。野村を攻めまくればいい。攻めて攻めて攻めて、攻めまくれば、きっと道は開ける。
世界でもっとも優れた開発者に、そして世界でもっとも優れたサイクリストになりたい。別府よりおれが劣ってるはずがない。どう見てもあいつはスポーツという顔じゃない。
きたああああああああああああああああああ
テストのないレガシーコードを排除せよ！！！
Amazon.co.jp： レガシーコード改善ガイド (Object Oriented SELECTION): マイケル・C・フェザーズ, ウル&
良いコードには価値があると知っている人間は好きだ。
逆に、悪いコードにも悪いなりの価値があると思っている人間は殺す。
悪いコードには価値がない。ゴミ以下だ。環境汚染だ。おれたちはテストを書き、リファクタリングを繰り返して、コードをクリーンにしていかなければならない。裏マーチンのクリーンコードを読まないとダメだ。ソフトウェアを書く人間も読む人間も人間だということを忘れてはいけない。
8月になってしまった。
8月といえば、以前は海にいったりしたものかも分からんが、今年の夏はずっと研究室にこもって、ひんやりとした部屋で自律神経がおかしくなりながら、プログラミングをしているだろう。おれには達成したいジョブがある。そのために、海は必要ない。必要ないものは排除すべきだ。
おれが彼女欲しいといっているのは、自律神経のためだ。プログラミングをすると確かに、自律神経がおかしいと感じる瞬間がやってくる。断っておくと、おれの研究室スペースはかなり歪みない空間であり、いくらプログラミングを肩などが凝ることはない。かなり快適空間なのだ。おれが使っていないときは、ネカフェとして提供したいくらいだ。
確かなことは、恋人の存在というのは、精神的な安定をもたらすということだ。これは、人間、いや動物としての本能レベルに備わったプロパティなのだと思うのだが、異性と付き合うと確かに精神的な安定がもたらせられる。例えば、おれたち喪男たちは、コンビニでおつりをもらう際に手が触れるだけで、ドキっとするのだ。ひとカラをすると言って、カラオケにいってぞんざいに扱われたとしても、その女性店員との間のコミュニケーションの間に、何か安心感を得るのだ。
動物にはオスとメスしかいない。だから、これらが近づくことによって、特別な効果が得られると考えるのは当たり前のことだ。
だから、自分のソフトウェアのために恋人が欲しいといっているのだ。確かなことは、おれがこの２ヶ月、ソフトウェアに没頭した結果得られるのは、巨大なソフトウェアと、荒んだ精神だということだ。きっと目は虚ろになって、一日中ぶつぶつと独り言をいうようになる。恋人がいれば、この荒びは軽減出来るという予測を立てている。
おれに彼女が出来ないはいくつもある。しかし、おれはどれも自分から解決する気にはなれない。とにかく彼女が欲しいのだ。
夏休み限定でおれの彼女になりたい女性は、メールくだしあ＾＾
なんていうか、どんな強い勇者でも、魔王と戦うとなれば、むっちりした脚の武道家と、ロリめがねの賢者と、ツンデレのお姫様が必要だということなんだ。おれは、きっと魔王と戦おうをしている。そしておれは、一人で魔王と戦えるほど強くはないのだ。負けることはないと思うが、バックアップなしでは、傷ついてボロボロになってしまう。女性ホルモンを好む。
おれはあやふやなことが大嫌いだ。
で、一体てめえは何が言いたいんだ、と言いたいことが多すぎる。
言いたいことを列挙するくせをつけろ。
まず、言いたいことを列挙して、それらについて説明しろ。優先度の高い順番からだ。話を一生懸命に聞いてくれるのはお前の親だけだ。一般的な他人は、お前の話など聞きたくもない。早く話が終われと思ってる。だから優先度の高い順番から、さくさくと話を進める。
おれが大嫌いな発表方法がある。それは、最初に目次を見せて、区切りごとに目次のフォーカスが変わっていくというものだ。これは、逃げだ。
何が大事で、何が大事でないか分かっていないから、常にフォーカスが当たっているものが大事なのだと言いつづけて、結局ごまかしているにすぎない。だから、おれはこういう発表を見たときは、一切耳を貸さないことにしている。全項目が優先度マックスなわけがない。大事なことだけを話して、あとは聴衆の想像力にお任せする。発表というのは、講義ではないのだ。発表と講義の境界が分かっていないやつが多すぎる。これすなわち、ゴミ。
それなりに大きなものをいくつかの部分に凝集度高く分解するというのは、非常に大事なジョブだ。聴衆は一つのインパクトある主張を、１つの流れの中に見出そうとする。おれなどは、もっとも言いたいことだけが聞きたくて枝葉のことは理解の邪魔になるから言わないで欲しいとすら思っている。凝集度が下がることを嫌っているのだ。枝葉をいえば、幹が隠れてしまう。
そして、このジョブは大抵の人間には出来ないものだと思っている。理由は簡単だ。コードを見れば分かる。大抵の人間のコードは凝集度が非常に悪い。関数としてまとめるという行為について凝集度を理解していない場合、それはむしろ意味不明な関数になるとすらいえる。凝集度の低い関数はゴミだ。
だから、コードを見る限り、多くの、９９％以上の人間は、いや、研究者は、凝集度というものを理解していない。結果として、多くのことを構造的に話すことが出来ない。それは、聴衆に不快感を与えて、かつ、自分の人生も損なう。同じグループだ、というあやふやな定義は良くない。感覚というのを排除して、機械的に何もかも行う。このレイヤーではそれがいい。感覚を用いるのは、もっと上のレイヤー、可視化レイヤーの話だ。ソフトウェアに、感覚の入り込む余地なんてありえるはずがない。常に機械的に作業が出来ること、それが一番なのだ。それが難しいから、世界中の優秀な開発者たちが悩んでいるのだ。そうだ、バカなやつは悩まなくていいから楽だよな！ということが言いたい。バカならば、真相は見えない。分かったふりが出来る。分かっていないといことが分からない。深い海すらも、浅瀬にしか見えない。
おれには、ソフトウェア開発はマリアナ海峡より深い海に見える。一生を捧げるに不足しないジョブだ。囲碁なども、深い海だったが、あまりに人間的なので、頭に来た。対戦相手が人間だということは、おれにとって不快以外何ものでもない。なぜ、おれが人間とコミュニケーションをとらなければいけないのか。
ソフトウェアの相手はソフトウェアであり、自分だ。おれより優秀な開発者以外とは仕事をしたくないし、しない。低能はちんこ切って死ねばいい。
あぁ、セックスしたい。
クラス最適化問題
おれは、昨日ベッドに横になりながら、考えた。なぜスタンプ結合はよくないのだろうか。なぜ、適切なクラス設計と不適切なクラス設計があるのだろうか。凝集度とは何だろうか。
あやふやすぎる！おれには到底受け入れることが出来ないんだぜ、この池沼が！！！おれは、厳密な定義がないとイライラする。定義なしで話す文系を殺したくなる。彼らの言葉には説得力がない。理工学系以外はダメだ。
そこで、おれは考えた。プログラムとは関数の塊である。どんな関数も関数によってカプセル化出来る。
ここで、関数について、これがベクトルか何かだと仮定して、ポジションを仮定する。プログラム全体のi番目の関数のポジションをp(i)と定義する。
そして、関数の距離を定義する。関数の距離は、いくつか定義法があると思うが、パフォーマンス的には最適化時の変換ステップ数とか、これはいくつか定義法があると思う。ここでは距離とだけ定義する。i番目とj番目の距離をlen(i, j)とする。
すると、ベストなクラスというのはフィールドを２個、A番目とB番目に持っていて、関数をいくつか持っているとすると、全体で関数がN個があるとして、あるクラスが最適であるというのは、
みたいな感じの関数のset(i)を見つけ出すことだ。
スタンプ結合がよくない理由というのは、ステップ数を距離にしないで、意味をポジションや距離にすればいい。意味距離が離れたものを組み合わせてはいけない。つまり、同じクラスにあるメソッドはほとんどが意味ポジション的に同じ、それぞれの意味距離がほぼ０でなければいけません、と言ってるに過ぎない。これが、凝集度の正体だということが出来る。
意味距離が近いものを集めれば、それぞれをひとまとまりにすることが出来る。結果として、ひとまとまりになったもの同士の関係を考えればいい。ここで一階層上の意味ポジションを定義して、距離を定義すればよい。
ということに違いないと閃いてみたが、本当のところはよく分からない。
おれは基本的に、クラスの状態が変化するということが許せない。クラスは不変であるべきだと思っている。だが、その基準が分からない。これによって、何かが分かるかも知れない。今日はこの線で、思考の海に潜り込んでみるのだ。
人とコミュニケーションをとることが不快なのに彼女が欲しい
矛盾してませんか・・・