行ってきた。申し込みでは個人参加と称して所属を書かなかったが、受付で「名刺をいただけますか」と言われたので観念して渡してきた。そういうもんなんだろう。というか名刺はバラまくためのものなので全然構わない。会社の仕事で来たわけぢゃないけど。
感想をブログとか日記とかで書いてください、と言われたので書いておきます。拾ってください。＞藤本さん
もうレポート上がってる。早っ。…あ、MeCabの発表資料の7ページ、間違ったままになってます。
MeCab
- 工藤さんは写真ほどワイルドな感じではなかった
- MeCabはライフワーク
- 形態素解析は学問だが、MeCabのやっていることはpureに工学
- 分かち書き、活用語処理、品詞の同定。3つ合わせて初めて「形態素解析」
- 最も自然な単語列を探す処理。辞書を引き、曖昧性を解消する。解消のためには基準の定義が必要。
- 辞書引き
- ハッシュで引いてくるのでは、文章の冒頭から(文章の長さ)2回の辞書引きが発生するため、DBは(形態素解析の)辞書としては使えない
- TRIE(トライ)…ツリー構造の辞書を文字列先端から辿っていくだけなので高速
- Double-Array TRIE方式…二つの行列でTRIE構造を表現。TRIE実装の中では最も高速に動作
- プレゼンに誤記発見。その場で修正（わら
- 曖昧性の解消
- ヒューリスティック法では曖昧性を解消できない
- 最小コスト法…連接と生起のコストを辞書に載せておく
- Viterbiアルゴリズム…一つの単語へ至るpathのうち、コストの高いものは捨てていく
- コストの決定方法
- 歴史
- 設計方針
- 辞書とシステムの分離。MeCabは日本語を知らない。ソースを「名詞」とかでgrepしても何も出ません
- コスト、文字種、品詞、すべて外部定義
- 辞書はバイナリ化。高速な分辞書はChaSenよりはるかに大きいが、昨今の情勢では富豪的使いかたでいいと思っている
- 前処理、後処理でできることはやらない（という方針はまさにこの日mecab-usersに来た質問の答えとして工藤さんが書いていた）。代わりにAPIとバインディングを充実。C++、Java、Perl、Python、Ruby、C#から使える。
- 解析器にしかできないことを提供する。N-Best解、制約付き解析、ソフト分かち書き（形態素分割と文字単位分割の重み付け）
- 意外な使いかた
- mecab-skkserv
- AJAX IME
- ローマ字→ひらがな変換
- 文字コード変換
- MeCabの辞書書式
- dic.csv。単語、左文脈ID、右文脈ID、生起コスト、素性列
- matrix.def。ID、ID、連接コスト
- 辞書を工夫すると特殊な入力方式を実現できるかも
- T9風予測入力。携帯の数字キーから単語に変換。241→クドウ。
- 子音入力。dmdkry→ダメだこりゃ。会場から"kwsk"というリクエスト。2ちゃん語かよ！ちなみに「カワサキ」とか出てた
smapspam filterは文章をMeCabで単語に分解して、別のspam DBを引いている。辞書の2度引き。MeCab辞書の素性列にスコアを入れれば、MeCabだけでspam判定できる。- 質疑応答
- 動的に辞書を更新することは？→まだできない。ニーズとしてはかな漢字変換など、ユーザー入力を辞書にフィードバックする場合か。spam filterはある程度まとめてbatch処理でやれるだろうと思っている
- knokさん
- バグの指摘→0.90で直っているはず。
- TODOのEndian依存解決はいつごろ。Debianパケジをarchitectureごとに辞書バイナリ作ったら、さすがに（サイズでかすぎて）怒られた。今はインストール後辞書作成するようにしているが…→速度が犠牲になるのでやる気なし。
- フナキさん
- MeCabのゴールは→言語に依存しないフレームワークを提供すること。これを元にみなさんいろんなアプリを作ってください。使ってくれればそれがゴールかな。辞書を作ってみて。
- 個人的な感想
- 解析手法、辞書の使いかた、使われかた、などなど、説明はとてもわかりやすかった。というか分かった気になれた。ありがとうございます。
- 設計方針には非常に共感できた。その方向でよろしく（←えらそうに言うな
- MeCab単体のspam filterは面白そう。mecab、ruby-mecab、bsfilterというブリッジで使っているが、MeCabだけで済めばこれはきっとめちゃくちゃ早いよ。たぶん世界最速？
- knokさんのDebianパケジの話も参考になりました。Vine Linuxの場合は実質動作するarchitectureは現在ix86とppcだけなわけだが、もしかしてPreReq: mecabなmecab-ipadic.noarch.rpmとかできるのかも。ちょっとトライしてみようかな？
Nagios+SNMPでサーバ群監視
すまん。眠いので明日書きます。いかん、一日たったらもう記憶が揮発し始めている…orz
- GREEのサーバの監視をどうやっているか、という話
- Linuxサーバ70台。90%がDebian、残りはRedHat。SNSとキャリアのサービスを稼働している。
- LAMP+Postfix
- 以前の監視方法
- 問題点
- サーバダウンは検知できない
- 全ての監視は困難
- メンテナンス時に監視を止めて、終了後に監視再開し忘れるリスク
- 単一故障から大量のAlertメールが来るため、どれが深刻なのか、どの程度深刻なのか判断できない
- ケータイ代が月に2万円
- 方針
- 目的を明確に。障害見地と正常確認をメインに
- 知りたい情報と知らせる情報の区別
- 運用ルール、対応マニュアルの整備
- オープンソースのものを使う
- 随時見直す
- 動作実績、柔軟性、拡張性でNagios
- Nagios→キューに貯める→定期的にチェック→MailMan
- チェックの内容
- 重複しているAlertをまとめる
- Nagiosサーバを多重化しているので、Slave側のメールを削除
- MasterがコケたらSlaveのメールが削除されずに発信される
- Alertレベルに応じた送り先の変更
- Nagiosプラグイン
- コマンドライン
- 出力は一行
- 終了ステータス：0(OK)〜2(Critical)、3(Unknown)
- 障害発生からメール発信まで5分→改善したい
- 質問
- 対応中にメールが来るのを止めているか？→キューチェック間隔を長めに変更して対応している
- 感想
- まだまだ改善の余地がありそうな気配
- でも70台を監視するという目的と基本的に自力で構築したということを考えると、よくできていると思う
- オープンソースでここまでできる、というかもっとできそう
- 通知手段がメールというのはなんか他にないのか。ケータイが生命線というのはちょっと？
全体的な感想
- 藤本さんは噂通り腰のひくーい人だった。もっと偉そうにしていていいのにと思った。
- 会場は天井式プロジェクタが2台あったり、電源があちこちに落ちていたり（わら）してすごかった。しかし部屋の形がヘン。というかこれは2部屋ぶち抜いて使ってますね？
- 非常に盛況で、前回はあったらしい机が全然なかった。それはかまわないけど、スクリーンには正対させてほしかった。スピーカーも斜めから喋る方が緊張しないでいいんじゃないでしょうか。
- やっぱりこういう場に来るとメモ用にノートPCほしい。手書きはしんどい。プレゼンに集中できなくなるし、あとでこういう風に書き写すのも非常にめんどい。まあ後日サマリとか配布資料が上がってくるのでメモなんか取らんで話聞け、という主張もあるかとは思うが、例えば「ライフワーク」とかソースをgrepとかknokさんのDebian話とかはたぶんそういうところには載らないし、自分でメモ取らないと自分の理解にならない。
- これが無料というのはすごい。無料だから盛会なのか、時間帯がいいのか、スピーカーが偉大なのかはよく分からない。たぶん全部なのだろう。でも個人的には、これくらい内容があれば1000円くらい払ってもいいと思った。場所代プラス講師の飲み代位にはなるのでは？
- 次回がほんとに高橋さんのRuby on Railsになったら、また参加させて頂きます。がんばって下さい＞藤本さん
