顎≠The Stig

やたら長いドメイン

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

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 制御を参照）、あまり役に立たない情報かもしれませんが。

1年ぶりの投稿

あまりにブログ放置しまくってたのでたまに自分のメモ書き。

なんかケータイで知り合いがはまってる「UTOPIA」の新バージョン「UTOPIA2」が出て、運営会社が違うとかいうんでちょっと気になって調べたら、なんかいろいろ妙なことになってるみたい。

＃以下の情報はあくまで個人的なちらしの裏です。情報の真偽については一切責任持ちませんので自己責任でよろしく。

まず運営会社だけど、とりあえず

・セルプロモート株式会社
・株式会社デクー
・ソーシャルゲームファクトリー株式会社
・株式会社パネポ

の4社の住所と代表者（社長）名が全部一緒。このうちセルプロモートとソーシャルゲームファクトリーについては求人広告で「セルプロモート株式会社から、ソーシャルゲームの開発に力を入れるため分社化され、設立された企業」って言い切ってるので、関連会社であることは確定。

これだけでも状況証拠としては十分なんだけど、これらの会社がやってるサービスのドメインをwhoisで調べてくと、なぜか「panepo.jp」ドメインの所有者が「セルメディア株式会社」になってる。実際ぐぐってみたら会社概要とかまだサイト上に残ってて、セルメディア→パネポで何らかのつながりがあることもほぼ確実。

さらに「セルプロモート セルメディア」でぐぐると、リンク先をたどった結果株式会社ランダムにたどりつく。TOPページの下の方を見ると、平成18年4月に関連会社として「セルメディア株式会社」を設立したと書いてある。リンク先のドメイン名は「cellmedia.co.jp」なんだけど、これはさっきの「panepo.jp」ドメインの公開連絡窓口と一緒なんで、ランダム→セルメディアも確実。

んでダメ押しに、セルプロモートの稼ぎ頭のはずのUTOPIAが使ってる「utpa.jp」って、whois上は「セルメディア株式会社」の所有だという…。これでセルプロモートとセルメディアもつながる。セルプロモートとデクーの直接のつながりがまだ発見できてないけど、さっきも書いたとおり住所と社長名が一緒な上、この2社はなんと福岡の開発拠点まで住所が一致するので、関係がないってことはまず考えにくい。

あとbl0g.jpについてなんかにもいろいろ情報がまとまってて、ここによれば「bl0g.jp」なんてドメインも出てくるけど、これは既に手放したあとみたいなので今回は省略。

つか関連会社なら関連会社って堂々と名乗ればいいのに、なぜかそれを伏せたようなビジネス展開してるのが気になるわけで。まあそのへんは各社の勝手といえば勝手ですが、なんか気になる。

地震と自粛

東北地方太平洋沖地震では私も会社で死にかけましたが（オフィスの自分の席の目の前にロッカーが倒れてきたりとか）、おかげさまで無事でございます。

んで地震以後の様々な自粛問題について昨日あたりからネットで議論になっているようですが、個人的見解をちょっとだけ。

まず東北・関東エリアについては、ある程度の自粛はやむを得ないのではと思います。
なんせ人を集めるイベント等については、まず計画停電との絡みでイベントで消費する電力等の問題がありますし、交通機関がまともに動くかどうかわからない状況では「人の移動を伴う行動」はなかなか推奨しがたいところ。実際先週末は、津波警報がまだ発令中にも関わらず、横浜港の埠頭のすぐそばでイベントを強行する主催者もいたぐらいなので（このイベントの出演者の一人に知り合いがいたので、まじめに心配だった）、自粛要請はやっぱり必要かと。
また消費活動についても、現実的に流通の動きが元に戻るまでにはまだしばらく時間がかかりそうなので（実際家や会社の近所でも、セブンイレブン系の店舗は通常通り弁当とかが入荷しているのに対し、弁当工場が被害を受けたローソンは当然弁当系が皆無だし、ミニストップはカップラーメン系の入荷がさっぱりない）、買占めに走る人々に自制を呼びかける意味でも自粛の呼びかけは必要かと。何しろ今回はマクドナルドですら「材料が入荷しない」って理由で販売品目制限やってましたからねぇ。
節電目的で営業時間短縮する店舗も多いですが、一方でパチンコ業界みたいに、都の組合が営業自粛要請してるのにそれを無視して通常営業する店舗が続出しているところもあるので、自粛要請がないともっとひどいことになると思うとある程度の自粛に同意せざるを得ません。

ただそれ以外のエリアについては「今までどおりの日常を送ることが重要」という意見に同意します。他のエリアがいつもどおりの日常を送り、きちんと物資の生産・消費活動を継続してくれてこそ、被災地は復旧活動に集中できるので。

おそらく今回の最大の問題というか、ネット上で論争になった原因は、twitterにしろmixiにしろ「被害を受けた人々とそうでない人々の情報が混在してしまう」ことなんでしょうな。
被害を受けた側からすれば、タイムライン上に被害を受けていないエリアからの日常的なつぶやきが混じると「この非常時にそんなこといちいちつぶやくな」と文句言いたくなるのはわかりますし、逆の立場からは「なんで俺たちが被災地につきあわなきゃならないんだ」となるでしょうし。
アメーバやモバゲーなんかでも、ゲーム中で開催中のイベントについて「携帯電話網が輻輳している状況では、ゲームへのアクセス自体が困難なんだから、イベントは全て中止すべし」という人がいる一方で「もう有料アイテム買ってしまってるから中止されると困る」という人もいて、掲示板なんかで論争やってます。
何しろ地域ごとにサービスが分かれているわけではないので、運営側としてはどうにも対応しにくいところです。twitterならハッシュタグって手がありますが、それだけでは完全には問題を解消できないですし。同一サービス上で「被災者向け」と「そうでない人々向け」のサービスを分離できる仕組みがうまく作れないもんか、なかなか悩ましいところです。