引用します。 - @m_seki の
以前、初版をメモしましたが、これは第二版の方のメモです。初版にも同じ文面があったと思うけど。 ほとんどのプログラマはプログラム・テストということばの定義をあやまっており、それがプログラム・テストの貧困さの要因のひとつとなっているということがある。 「テストとは、エラーがないことをしめしていく過程である」とか、「テストの目的は、プログラムが意図された機能どおりに正しく動いてくれることをしめすことである」とか、「テストとは、プログラムが思い通りに動くことの確信を作っていく過程である」などである。これらの定義は、テストについての正反対の定義だといってもいい。 「第2章 プログラム・テストの心理学と経済学」だけでも、読むとお得です。以前、第2章だけ音読するという新人向け教育をやりました。初版も第2版も、西那須野図書館にあります。買わなくても西那須野駅のそばまでくれば読めるので、音読するといいよ。
計算量的な問題って - @m_seki の
具体的な問題がおきてから考えた方が良い気がしてきた。 RindaのTupleSpaceの検索はO(n)です。テンプレートにあんな形のパターンを許しているので、素朴に書くことにしたから。パターンマッチングの規則を単純なワイルドカードと値だけに限定しておけば良かったな。 で、検索がO(n)で問題になるケースってどういうときなのかしら。 タプルがたーくさんあって、takeする人が少なくて、狙った一つを取り出したい、っていうようなシチュエーションかなあ。そうなるのはどういうときだろ。サービス間の協調に使うとすると、たいてい、タプルのwriteとtakeの収支は合っている（合うことで協調する）と思う（甘いかな?）。 ほら、たくさんタプルを入れて取り出そうとすると遅いだろう！っていうのはわかるけど、どういうときそうなるんだっけ。TupleSpaceはデータベースの代わりにはならないものだって、啓蒙（言
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
