[book][keiba]WIN5本

的中させまくりの著者が教えるWIN5の馬券の買い方。

門外不出! 投票データから分かった! WIN5の鋭い買い方

門外不出! 投票データから分かった! WIN5の鋭い買い方

同じ手法が、この本にも紹介されてる。

事例で出てくるのがが1993年のサンタアニタ競馬場のピックシックス配当。20年前のアメリカの競馬本に日本のWIN5と同じ話が出てくるのが面白い。

競馬探究の先端モード

競馬探究の先端モード


好きなところを引用。

つまり、ピック・シックスを予想するのは、通常の一つのレースを予想する行為とは異なると言うことだ。

(中略)

だが、こういった確固たる自信はピック・シックスでは致命的な欠点になってしまう。自分が選んだ馬が絶対に負けないと思っても思い描いたとおりになるのは稀だし、ずば抜けて強い馬に逆らって対抗できる馬を取り上げても、勝てるのはたまにしかない。

この後に出てくる話も面白い。ピックシックスのうち5つを的中させた6レース目で12万ドルを取り逃したときの話。

分からないことに対してどうやって決断してどうやって責任を取るのかっていう。むずかしい。濃淡つけて開き直るしかないんだけど、それだけだと開き直れない。もうこうなると、精神論を完全に排除した戦術論なんてありえない。仕事もそうかもしんない。いかにデスマを死なずにやりすごしつつ真剣に仕事するか、みたいな。

どうやって決断するかっていうフォームの参考には須田さんの本、精神論っぽい話としてベイヤーみたいな感じ。あわせてどうぞ。あわせないと耐え難い苦痛を伴う敗北を味わったときに対処できないよ。

オブジェクト指向入門第二版 方法論・実践

オブジェクト指向入門 第2版 方法論・実践 (IT Architects' Archiveクラシックモダン・コンピューティング)

オブジェクト指向入門 第2版 方法論・実践 (IT Architects' Archiveクラシックモダン・コンピューティング)

具体的な方法論っぽい話は、きっとこのあと出た書籍もあるし、そっちをよんでもそんなに大差ないのかと勝手に判断して読み飛ばした。

  • 第19章 方法論について
  • 第28章 ソフトウェア構築過程

あたりがメタな話題で、おもしろい。

  • シームレス性
  • 遡行可能性

設計作業から実装作業へ移るときの変換が軽いことと、実装作業から設計作業に戻ることが容易であること。

なんだよなあ。やっぱり。で、上巻で議論されてるソフトウェアの品質のある部分が満たせる。そのためのオブジェクト指向のそれぞれの要素と実装と方法論。

おもしろい。

知識と進化論

知識が進化論なのだという仮説。

どの辺が進化論的か。

  • ものが伝達されるとき、そのままでは伝達されず、一部異なった形で伝達される(伝達エラー)
  • ものに、優位・劣等という固定的な位置づけはなく、特定の状況下に適応できなかったものは死滅し、適応できたものは生存する
  • 伝達エラーと状況の変化が同時並行で繰り返し発生する

仕事上のルールなんかは、放っておけば実行されなくなる。

進化論的な公理/原理を知識にあてはめられるのであれば何か違う原則が作れる?

  • 近親交配の効果と問題と利用
  • 生存ルールの加工

考えたら、具体的な世界に戻ってこないとな。

このへん読むと面白いかな?重い400ページっぽいけど。

客観的知識―進化論的アプローチ

客観的知識―進化論的アプローチ

その前にずーっと読んでない福岡伸一かなあ。

引っ越しを前に積読が増える。

デブサミ2012 #devsumi

先週はデブサミに行った。

本を2冊購入。

100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊

100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊

この本のせいでウィッシュリストの本が増えた。困った。honz.jpは頑張ってスルーしているけど、これはスルーできない。

Jenkins

Jenkins

買って、さらっと読んで、人に聞かれたときにはこたえられるようにしておく。マーケティング的に必要。

検索と発見のためのデザイン

検索と発見のためのデザイン ―エクスペリエンスの未来へ

検索と発見のためのデザイン ―エクスペリエンスの未来へ

検索と題してはいるけど、なんだか検索を前提としていない雰囲気の本。

検索というのは発見のための1つのユースケース(もしくは実現方法)であるという主旨が最初の方にくる。発見ではなくナレッジマネジメント(!)の一部であるというところまで行くあたりが、この本が技術要素としての「検索」をメインに扱っていないことを表している。

後半に登場するパターンは参考にならないことももちろんないが、どちらかというとそういう思考フレームワーク的な、手順を踏まえて検索を考える向きにとても面白い。検索をよくするということは、発見やその体験をよくするということであって、検索という形だけじゃなくてもっと別なところも見ないといけない、というあたりはとても納得感がある。

検索というものをより良くするには、専門分野の垣根を越えたコラボレーションが必要だし、自分たちが思い描いている障壁を突破しないとね。

自由に考えるというより、きちんと筋道立てて考えているんだと思った。もしくは筋道立てて伝えてくれている。


どんなにセンスが必要な話であっても、本にまとまるときちんと目的からはじめてくれる。うれしいです。


以下はこの本と連動した(?)サイト。
Search Patterns

ファイルをtikaで解析してSolrのインデックスに入れるDataImportHandlerの設定

Solr 3.1からTikaEntityProcessorというDataImportHandler用のProcessorがついたけど、これをDataSourceや他のProcessorとどう組み合わせて良いかがさっぱりわからない。

ぐぐりつつ試してみて、あるディレクトリ以下のファイルを全て取り込むのは多分これで良いという結論になった。

data-config.xml

<dataConfig>
    <dataSource type="BinFileDataSource" name="bin"/>
    <document>
        <entity name="file" processor="FileListEntityProcessor"
                baseDir="/path/to/targetdir"
                fileName=".*"
                recursive="true"
                rootEntity="false"
                dataSource="null">
              <entity name="tika" processor="TikaEntityProcessor"
                      dataSource="bin"
                      url="${file.fileAbsolutePath}"
                      format="text"
                      transformer="LogTransformer"
                      logTemplate="file: ${file.fileAbsolutePath} processed"
                      logLevel="info"
                      onError="skip"
              >
                   <field name="Author" meta="true" column="author"/>
                   <field name="title" meta="true"  column="title"/>
                   <field name="text"               column="text" />
              </entity>
        </entity>
    </document>
</dataConfig>

TikaEntityProcessorはDataSourceのサブクラスがdataSourceになってないといけない。なのでBinFileDataSourceが必要。で、BinFileDataSourceはファイルの絶対パスが必要なのでFileListEntityProcessorからもらう。

FileListEntityProcessorはあるディレクトリの下にあるファイルを一つ一つ処理する感じ。正規表現でファイルをexcludeすることもできる。

  1. FileListEntityProcessorでファイルパスのリストを作る
  2. 一つずつTikaEntityProcessorで処理する
    1. FileListEntityProcessorで作ったファイルのパスを受け取る
    2. BinFileDataSourceにパスを渡す
    3. InputStreamになったデータを処理してスキーマに合わせて突っ込む

このFileListEntityProcessorとの組み合わせがあんまり情報ないんですよ。。。

対応するschema.xml(の一部)

 <fields>
   <field name="title" type="string" indexed="true" stored="true"/>
   <field name="author" type="string" indexed="true" stored="true" />
   <field name="text" type="text" indexed="true" stored="true" />
   
 </fields>

スキーマはこんな感じ。多分他にも増やせばTikaが抽出できるメタデータをもっと入れられるんだと思うけど、そこまで調べられていない。


やってみると、Tikaで処理できない旨のエラーが結構おきる。処理できなかったときには、特別なログに吐くなどしてエンドユーザに知らせたいんだけど、今のところSolrが普通通りログに吐くことしかできない。onErrorで好きな処理を指定することができなくて、abortするかそのドキュメントをskipするかしかできない。