今の勤務先で新たに
技術ブログ立ち上げることになり、過去のライター経験を買われて編集長やることに。
まあ編集長と言っても、実質は自分で記事書かないとならないので、体の良いライティング業の押し付けとも言いますがｗｗｗ
そんなわけで今後技術系の記事はこっちじゃなくて会社ブログの方に書くことが多くなると思います。
とりあえず会社のエンジニアのケツ叩いて記事書かせないと。
毎度毎度のSolrネタ。
「Solrでは後方一致のワイルドカード検索（例えば「*test」みたいなやつ）はできない」っていうのがこれまでの常識で、実際昔のバージョンではそーゆー検索するとエラーになるし、そのためにSolrにはわざわざ擬似的に後方一致検索をするための
ReverseWildcardFilterってFilterもあるくらいだったのに、今手元のSolr 4.2.1（QueryParserはdefaultのまま）で何の気なしに後方一致のクエリ投げてみたらあっさり通ってしまった。
SolrのWikiからリンク貼られてる
QueryParser.classic見ても「Note: You cannot use a * or ? symbol as the first character of a search.」って書かれてるのに…と思って調べてみたら、現行のLuceneの
WildcardQueryクラスでは「In order to prevent extremely slow WildcardQueries, a Wildcard term should not start with the wildcard *」って書き方になっていて、どうやら後方一致は「プログラム的には使えるけど、速度的に不利だから使わないほうが良い」扱いに昇格した模様。
現実的に後方一致を必要とする局面は自分の場合あまりないんだけど、とりあえず「エラーになって使えない」のと「使えるけど遅い」では大きな違いなので、一応メモ。
毎年恒例
コンピュータ将棋世界選手権の決勝最終局で、優勝候補筆頭の
GPS将棋が
Bonanza相手に時間切れ負けを食らった件。
なんか関連ブログ読んでると、194手目の7八銀打（これで先手玉の詰みが一旦なくなった）を疑問視している人が多いけど（実際ここで7六銀なら詰みだったらしい）、この対局でのGPS将棋の
探索木読んでると、実際にはその前から既におかしい。
この件あまり疑問視している人がいないのが不思議だったんだけど、今日になってぐぐってみたら
・
第２３回コンピュータ将棋選手権決勝！（kurageのメモ）
のようにちゃんと疑問視している人がいて一安心した。
そもそも184手目の8七角不成(!)って手が常識的にあり得ない手なわけで。将棋の世界で香・桂・銀の3つの駒は「不成じゃないと効きがない」場所が出てくるんで「あえて成らない」選択肢が有効なんだけど、角って駒は「成って不利になることがない」駒なんで、よほどの素人でもない限り「成らない」選択肢を取る意味が無い。
んで
この局面の探索木見てみると…、なんと「8七角不成」を意味する「7687KA」を読んでる探索木が出てこないんですね。
常識的な「8七角成」（7687UM）の方は探索木に入っているし、そもそもこれ見ると「7八歩」（0078FU）で評価点が「-29988」（＝ほぼGPS将棋の勝ち）と読んでるのに、なぜ探索木に出てきてすらいない手を指したのか。おそらくは何らかのバグなんでしょうが…。
考えてみれば前回Bonanzaが優勝した2006年の選手権って、自分がマイナビの記者として木更津まで取材に行った選手権で、自分のライターとしての事実上最後の仕事だったんですよね（あくまで現時点で。今後ライター業再開の可能性がないとは言わないので）。そのBonanzaがこーゆー形で2度目の優勝というのはちょっと感慨深いものが。
相も変わらずSolr 1.4→4.2系への移行で悪戦苦闘中。
コンパイルが通って喜んでたら、その後の設定のところでいろいろハマったのでメモその2。
◯schema.xml
Solr 3.6以降では、「termPositions="true"」かつ「termOffsets="true"」で、明示的に「termVectors="true"」が指定されていないフィールドにデータをaddしようとするとエラーになる模様。このためそれ以前のVer.からの移行の際にはschema.xmlの修正が必要。
◯solrconfig.xml
一番変更があるのがここ。
・luceneMatchVersionが必須。
・indexDefaultsとmainIndexがなくなりindexConfigに事実上統合される。これも修正しないとエラー。
・ResponseWriter系のクラスがorg.apache.solr.request.*→org.apache.solr.response.*に軒並み移動。なのでこのへんのクラスをqueryResponseWriterで呼んでいる場合は要修正。
・Update時のrequestHandlerが、今までXMLUpdateRequestHandler・BinaryUpdateRequestHandler等に分かれていたのが統合されて、solr.UpdateRequestHandlerで全て賄えるようになった模様（Content-Type:ヘッダでデータ形式を判断して振り分けるらしい）。Solr 4.2レベルではまだ修正の必要はないけど、一応起動時とかにwarningが出るんで修正しといたほうがよさげ。
◯その他
データ投入後のcommit・optimizeで、パラメータにsoftCommitが追加されたのはまあいいとして、問題は
パラメータにwaitFlushが入っているとエラーになる点。
これ今回のシステムで使ってるsolr-php-client（
http://code.google.com/p/solr-php-client/）の最新版（svnからtrunkを取ってきた）でもまだ未対策なんで、手でコードを修正する必要があった。
あとSolrのstats関係を取るAPIが「/solr/[コア名]/admin/stats.jsp」から「/solr/[コア名]/admin/mbeans?stats=true」に変更になってる。ここもhealthcheck関係で使ってるんで、移行先調べるのに手間取った。
今んとここの対応で一応動いている状態だけど、本格的にテストしだすとまだ他にも出てくるんだろうなぁ…。
新しい勤務先で早速Solr 1.4系→4.x系の移行を担当することになり、既存環境でSolrのTokenizer・CharFilterなどを独自開発している部分があるのを移行作業中。そこでちょっとハマった部分があるのでメモ。
Solr 4.0以降ではTokenizerFactory・CharFilterFactoryあたりのクラスがSolr側からLucene側に移っていて、import元をorg.apache.solr.analysis.*からorg.apache.lucene.analysis.util.*に変更しないといけない（詳しくは
こことか
こことかに解説あり）。
ただ実際のところ、それだけでは話が済まないわけで、今回はとりあえず以下の様な修正が必要だった。
◯CharFilter関係
・BaseCharFilterの継承元がorg.apache.lucene.analysis.charfilter.BaseCharFilterに変更
・Factoryクラスのcreate()に渡される引数がCharStreamクラスではなくReaderクラスに変更
◯Tokenizer関係
・super.reset() が引数を取らないもののみになった
既存コードでReaderクラスを引数で渡していたのを削除
◯Similarity関係
・org.apache.lucene.search.Similarity がなくなって org.apache.lucene.search.similarities.* に移行
既存のSimilarityクラスを継承しているコードについては、TFIDFSimilarityクラスを継承する形に変更するのが良さげ
その場合でもLengthNorm()の引数変更、scorePayload()の追加などの対応が必要
◯その他
・TermAttributeがなくなってCharTermAttributeに移行
その関係でmethodの修正が必要（setTermBuffer() → append()、termBuffer() → buffer() など）
これでとりあえずコンパイルは通ってSolrも起動するようにはなったが、Solrの管理画面からAnalyzeを試すと意図した結果が返ってこないので、これから調整。
