春山 征吾のくけー

https://www.unixuser.org/~haruyama/blog/ に移転しました http://wiki.livedoor.jp/haruyama_seigo/d/FrontPage @haruyama タイトルが思いつかないときはそのときかかってた曲をタイトルにしています.

2012年02月

ICPAのエージェントからまたLinkedInで接触されたので厚生労働省の需給調整事業関係業務担当窓口に電話してみた

ICPA という職業紹介事業者 (厚生労働大臣許可番号:13- ユ-300680) のエージェントから, 10月にmixiに転職後確認できただけで10回以上の接触を受けている.

職場に電話

  • 2011/10/初旬
  • 2011/11/初旬

GitHub

  • 2012/1/6
  • 2012/1/31

LinkedIn

  • 2011/10/19
  • 2011/11/17
  • 2012/1/23
  • 2012/2/12
  • 2012/2/28

Twitter

  • 2012/1/12

昨日(2/28)に LinkedInで接触されたので 厚生労働省:需給調整事業関係業務担当窓口一覧 の東京 需給調整事業第一課 に電話した.

担当者から電話を折り返してもらって, 複数のエージェントから繰り返し接触を受けて迷惑している事情を説明したが, 明確に法律に違反しているわけではないので具体的な指導や対応は難しいのではないかという担当者の口振りだった. 今後調査をするか否かについて連絡してくれるとのこと. 担当者は LinkedIn を知らなかった. Twitter, Facebook は知っていた.

2012/02/27 エクストリームスポーツ・あんちべ とは

2012/02/27 エクストリームスポーツ・あんちべ とは @AntiBayes 氏にからむ競技である. 特に競技者が酒を飲んだ状態で行なうと(競技者にとって)面白いことで知られている.

mixi での SICP読書会に @AntiBayes 氏がいらっしゃった. 読書会後の反省会で思うぞんぶんリアル エクストリームスポーツ・あんちべ を行なった. 今後も継続的にいらっしゃるとのことで楽しみである.

2012/02/25 自宅で作業 2012/02/26 サッカー敗北

2012/02/25 前述の通りサッカーが中止になったので自宅で作業した.

2012/02/26 サッカー 1-2 (1-1, 0-1) で敗北. 文京区民大会決勝トーナメントは1回戦で敗退となった. 悪いグラウンドコンディションの中, 特にチームとしてサッカーが機能しなかった. 終了間際にミスから1点取られてしまった.

#TokyoNLP にいけなかったから Clojure で IME作った. 徳永本のコードの移植だけどな!

今週のはじめごろはTokyoNLPに行くつもりで, 補欠だったがくり上がりそうな順番で申し込みをしていました.

しかし, 所属サッカーチームから人足らないから来てと言われ, 足らないならしょうがないなとTokyoNLPはキャンセルしました.

で今日は雨でサッカー中止です.

むしゃくしゃしたので Clojure で IME を作りました.

日本語入力を支える技術 ―変わり続けるコンピュータと言葉の世界 のサンプルコードの移植です. 学習や変換精度の部分は作っていません. Clojure もまだまだよく知らないので適当です.

2012/02/24 立食の懇親会で箸が必要な食事を出す奴は敵

2012/02/24 会社でただ飯が食えたので野菜とパンを食いまくる. 立食の懇親会で箸が必要な食事を出す奴は敵だ.

Solrでのlucene-gosenの辞書の扱いについて確認した.

  • 辞書の更新
    • multicore を有効にしている環境ならば RELOAD で更新を反映できる
    • multicore が無効な環境だと再起動しかない?
      • @johtani さんによると solr.xml があれば可能だそうです.
      • solr.xml がなくても RELOAD できる. core名として collection1 を指定すればよい.
      • org.apache.solr.core.CoreContainer で solr.xml がない場合に example/solr/solr.xml と同じデータを load している.
  • 辞書のレプリケーション
    • conf 直下からの相対パスではだめだった. 直下に置けば大丈夫
    • 辞書だけの更新ではレプリケーションされない. インデックスの更新が必要
    • レプリケーションされれば slave で辞書の更新が反映される.

2012/02/23 4/4(水)のShibuya.XSS テクニカルトーク♯1で話します

2012/02/23 Shibuya.XSS テクニカルトーク#1 : ATND で15分話します. ネタは以下の中ないしそれ以外からひねり出す予定.

  1. Cryptography Engineering からひっぱってくる. ハッシュ関数に対する攻撃とハッシュ関数の正しい使い方とか. 地味だがまともな話になる.
  2. ECナビを辞めた理由. いい話ができるが自分の身が危険になるかもしれない.
  3. パスワードの話. 賞味期限が切れてる気がする
  4. mixi の中の話. セキュリティ業務もやってはいるが普段は検索とテキストマイニングとSICPが主業務なのでいい話ができなさそう.
  5. Issue 19 - lucene-gosen - String which repeats "くよ" (about 20 times and over) consumes much execution time and memory. LT ならばいいネタだが15分はきびしい. もう LT は埋まったようだ.
  6. SSH の話. 面白いかは別にして10年以上見ているのでネタはたくさんある.

2012/02/22 Anuenue 0.7.0 リリース

2012/02/22 anuenue-wrapper 0.7.0 リリース.

  • HTTPでの更新時に一時ファイルを作成していたのをやめました.
  • 最大同時HTTPリクエスト数のデフォルトをマスターの数の2倍から3倍にし, またこの係数をJavaのpropertyで調整できるようにしました. 手元でやったところ 8倍までは問題なかったです(ただし, 更新時間は速くはなりますが完全には反比例しなかったです).

簡単にSolrを利用する上で実装したい機能は実装しました. 今後はSolr や lucene-gosen の更新への追従や整理をします.

Solr4 がリリースされ SolrCloud がふつうに使える状態となったら, SolrCloud を利用する別のものを作るつもりです.

2012/02/21 1つのSolrに10億文書

2012/02/21 Mixiボイスのマイニングのために, 1つのSolrに10億文書つっこんでマイニングできるようにした. 11月終わりからのデータをためていって昨日10億を越えた.

全文書に対して1日区切りのdateのファセットを新規に取ると1分くらいかかる. マイニング用途としては問題ない. 検索で絞ればもっと速い.

Scalaで書いた 自作のフィルタ で形容詞/名詞/動詞をフィルタしている. また, 分析には Perl や Clojure を利用している.

Solrの仕組み的には21億文書までいけるが, ディスク側の制限があるのでそこまではやらない.

2012/02/19 サッカー引き分け 2012/02/20 SICP読書会2章開始

2012/02/19 文京区区民大会は引き分け. 2点取られて2点取り返したという試合だった. 2失点ともからんでしまって残念. 来週からは決勝トーナメント.

2012/02/20 SICP読書会2章開始した. そろそろ発表が一周する. そして反省した. 反省会の参加者も増えてきた. もっとつまみを用意しなければならない.

今日はちょっとした楽しい知らせができそうな予感.

2012/02/18 Clojureのio処理と例外

2012/02/18 ClojureのIO処理はJavaのクラスを用いてすることになる.

本体(src/clj/clojure/java/io.clj at 1538d809db22346987075b7f91d37addd33e1afd from clojure/clojure - GitHub) や clojure-contrib の IO処理を見ると

(make-reader (make-input-stream x opts) opts)

という感じのコードがある. なお, make-input-stream 中では例外処理はしていない. Java風の疑似コードで書くと以下の感じになる.

reader = new Reader(new InputStream(x))

このとき, finally 節で reader が null でない場合に close していたとしても,

InputStream インスタンスの生成に成功して Reader

インスタンスの生成に失敗すると, InputStream のインスタンスがリークしてしまう.

ので Java では通常, Reader や Stream のインスタンスは別々の変数に保持して finally

節で 別々に close する. close で 例外が出ることもあるので

IOUtils.closeQueity() を利用することが多い.

clojure の java.io などにはリソースリークしうる問題があるようにみえる.

with-open マクロは, bindings Vector の逆順に close していく. bindings

の数だけ入れ子の try-finally に展開されるので closeQuietly 的な効果があり

正しく使えば問題ない. しかし,

(make-reader (make-input-stream x opts) opts)

的コードでは make-reader でできた reader だけ with-open

してもリークの可能性がある.

私の勘違いでなければ, clojure での IO処理は with-open

を用いて自前でやったほうがよい.

QRコード
QRコード
  • ライブドアブログ