顎≠The Stig

情報ネットワーク法学会・11/3メモ

ちょっと遅くなりましたが、情報ネットワーク法学会・第19回研究大会の11/3分のメモです。

午前の個別報告のところはあまりにも意味不明なメモなので省略して、午後の分科会の部分のみになってます。

こちらも個人的なメモなので内容は無保証です。あらかじめご理解いただいた上で個人の責任でご覧ください。

More

情報ネットワーク法学会・11/2メモ

ナビプラス技術ブログが事実上閉鎖になったので個人ブログのこちらを数年ぶりに復活させることに。

というわけで昨日の情報ネットワーク法学会・第19回研究大会の聴講メモ。

あくまで個人的なメモなので正確性に関しては無保証です。個人の責任でご覧ください。

※11/6追記：一部誤字脱字を修正しました。あと第4分科会で頻繁に出てくる「PPC」は「個人情報保護委員会」の意味です（Personal Information Protection Commissionの略）。

More

やたら長いドメイン

昨日電車に乗っていて、壁に貼ってあったオリーブオイルの広告を何気なく眺めていたら、プロモーションサイトのドメイン名が

watashitachinolifestylewoajiwau.jp

だったので思わず苦笑。なんぼなんでもドメイン名長過ぎますがなｗｗｗ
んで今日そのサイトを見てみたところ、どうも元々

tasteourlifestyle.com

というサイトを英語で展開していて、その日本語版として前記のサイトを開設したらしいことがわかる。「taste our lifestyle」を訳すと確かに「私達のライフスタイルを味わう」になるけど、だけどさぁ、あまりにも直訳過ぎない？
日本語版サイト自体はそんなに変な日本語表記もなくて割と普通の作りだし、そもそも東京メトロの交通広告出してる時点でどっか国内の代理店が噛んでることは容易に想像できるわけで、せめてもう少しドメイン名短くするとかできなかったのか疑問に思った次第で。

編集長

今の勤務先で新たに技術ブログ立ち上げることになり、過去のライター経験を買われて編集長やることに。
まあ編集長と言っても、実質は自分で記事書かないとならないので、体の良いライティング業の押し付けとも言いますがｗｗｗ

そんなわけで今後技術系の記事はこっちじゃなくて会社ブログの方に書くことが多くなると思います。
とりあえず会社のエンジニアのケツ叩いて記事書かせないと。

Solrの後方一致検索

毎度毎度の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 4.x系への移行メモその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 4.0以降のCharFilter周り

新しい勤務先で早速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を試すと意図した結果が返ってこないので、これから調整。

転職しました

3月に入りようやく情報がオープンに出来るようになったのでご報告。

このたび3/1付で、今まで在籍していた株式会社プログレートを退職して、ベリトランス株式会社に移ることになりました。

ただ実際に働くところはまた別でして。
元々ベリトランスに採用される段階で、籍はベリトランスになるものの実際に働くのは子会社のナビプラス株式会社になることははっきりしていたので、それは了解していたわけですが。
いざ3/1にナビプラス＠代官山に出社すると、この1月にナビプラスが同業他社の株式会社コトハコを買収した関係で、コトハコ側の業務を引き継ぐということでしばらくコトハコのオフィス＠秋葉原に常駐することになりました(^^;;

そんなわけで当分は秋葉原勤務という予想外の展開が…。
ま、4月までにはコトハコのオフィスを代官山に統合する予定なので、秋葉原にはそれほど長くいるわけではないんですけど。

.NET Framework 3.0以降でZIPを扱う方法

またまたほぼ1年ぶりの更新。

仕事上で.NET Framework上でZIPを扱う必要が出てきて、できれば追加のDLLとかなしで対応できないもんかと調べてたら、3.0以降限定になるもののこんなのを見つけた。

C# Use Zip Archives without External Libraries

ここの「ZipArchive」ってクラスが、MSのInternal Classである「MS.Internal.IO.Zip.ZipArchive」のwrapperとして働いてくれる。
ちなみに使用する場合にはVisual Studioの参照設定で「WindowsBase.dll」（ふつーの環境だと「C:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\WindowsBase.dll」とか）を追加しておく必要がある。

今回はZIPから中のファイルを抽出してテキストを読み出せればいいのであまり細かい機能は調べてないけど、ファイル一覧・展開・圧縮・削除等基本的なところは一通り対応してるみたいなので、結構おすすめかも。

ま、最新の4.5だと、何も考えずに「System.IO.Compression.ZipArchive」とかってクラスが追加されてたりするんで（詳しくはついに解禁！.NET で ZIP 制御を参照）、あまり役に立たない情報かもしれませんが。