D-7 <altijd in beweging>

Day to day life of a Perl/Go/C/C++/whatever hacker. May include anything from tech, food, and family.

タグ:golang

先日もお知らせしたように、「みんなのGo言語」という本の執筆に参加しました。発売日は9/9ですが、一部書店では先行販売されているようです。



そして今日著者用の分が届きました。やったぜ!

DSC_0920


内容についてのレビューは kaoriyaさんのものが良いかと思います。是非そちらもご覧下さい。

 個人的にはやはり気になったのは自分が描いたパラパラ漫画。やっぱりやっちゃうよね。もう少しカットを足せばよかったとも思うが、まぁプロじゃないので許してください!


是非手にとって読んでみてくださいね!
あと10月22日発売のWeb+DB Press (vol 95)にもGoの並行処理についての記事を19ページほど書きましたので、そちらも発売されたら是非ごらください〜

    このエントリーをはてなブックマークに追加 mixiチェック

「あ〜、インタプリタ言語飽きた。コンパイルしてぇ」と思っていたところ見つけたGo。あれから4年ほど経ちます。

gophercolor


当初 「mattn さんという超絶変態ハッカーが使ってるなぁ」くらいの印象でした。そして触り始めてからも「なんだこれ、オブジェクトじゃないの…?」「interface {}って… え、あとから自動的に紐尽くの…?」「なにこれ、ポインタレシーバーとby valueレシーバーで意味違うの…?」などなど色々と自ら真っ先に罠にかかり、穴にはまりまくって「この言語大丈夫か」と皆さんもそう思っていたかもしれませんし、僕もそう思っていたことがありました。

その後、自分が罠にはまるごとにあちこちで発表したりもし、pecoという思いがけないヒットを書いてしまったり、とにかく大量のGoコードを書き続けていくうちに…

Go言語は僕にとって既に無くてはならない存在になってしまいました。だって、コード書きやすいし、速いし、良いことづくめなんだもの。

そんなところで「本書くんだけど参加しない?」というお声がかかったのでめいっぱい手を上げて1章書かせてもらいました。それがこのほど予約開始になりました。(書影がまだないのが残念…)


Perlを10何年書いてからのGoで、なるほど、これは… という点は何個かあったのでどれをネタにしようか迷ったのですが、今回僕は"reflect"という黒魔術を採り上げさせてもらいました。

reflect芸人


やはりPerlと来たら黒魔術でしょう。Goでは基本必要のないツールですが、必要になったらこれ以外方法がない、というreflect。いくつかのライブラリを書く際にはまりまくったその結果を共有させてもらったので、是非皆さんには僕のテツを踏まないでいただきたいと思います。

P.S. 今回以下のようなものも描かせてもらいました。どこで使われるかな?



 
    このエントリーをはてなブックマークに追加 mixiチェック

moznion.hatenadiary.com


別にDocker使ったっていいんだけど、こっちでもできますよ、ってことで、Dockerもシェルスクリプトも使わない方法の説明。元記事を読んでわかるのは:

1. makeを使ってる
2. GOOS/GOARCHを設定してクロスコンパイルしている(gox等を使っていない)
3. Dockerであげた同一イメージ上で全てのクロスコンパイル結果を吐いている

ということなので、であれば別にローカルの環境でクロスコンパイルしても何の差もなさそう。別の環境をたててクロスコンパイルしたい場合もあるが、それは例えば cgoを使っている os.User 関連のコードをコンパイルするとか、そういう時だしその場合はそれぞれのプラットフォームごとに別のホスト上でコンパイルする必要がある。それをする必要がないなら go 1.5 以降であればもうGOOS/GOARCHを設定するだけで充分。

makeはプラットフォームごとの出力を作るなんてお手の物で、pecoではMakefile内でまず以下のように明示的に現環境でのGOOS/GOARCHを定義して、

peco-make-vars


必要な変数を与えてやれば適当なプラットフォーム用のバイナリを吐いてくれるルールを作ってる

peco-build-rule-main

このルールだけであとはこれを対象GOOS/GOARCHに対して実行するだけ。手動で実行したかったら "make build GOOS=darwin GOARCH=amd64"とかするだけ。でももちろんそんなことを手動で実行したくなりので、それを内包したルールを何個か作る。

以下ではループを使ってもいいんだけど、僕の「なんかまちがったのを設定した場合エラーになってほしい」というこだわりから全て別ルールにしてる

peco-build-rules


あとはこれを依存対象としたルールを作れば勝手に全部ビルドされる。以下の場合は"make all"とすれば全てのバイナリが作成される。もちろん一個だけ実行したい場合は"make build-darwin-amd64"とかを実行してもいい

peco-build-all

こちらからは以上です
    このエントリーをはてなブックマークに追加 mixiチェック

kubernetesを使い始めている。かなり良いのだが、それまでの非kubernetesの世界で使っていたconsulとconsul-templateに依存する形で動的な設定変更をしていて、それが常々不満だった。もちろんロードバランスしちゃえばよいようなものはkubernetesのServiceにしてしまってそこにアクセスするようにしちゃえば手間いらずなんだけど、memcachedとかが意外にこのパターンにはまらんなーと思って困っていた。そこで ちょっと手の空いた時にTwitterで以下のようにつぶやいたところ


すぐに返事が返ってきた


お、それくさい!と思った物の、これどこにもドキュメントがないんだよね!そういうわけでとりあえず適当にクラスタを立ち上げてみて遊んでみようと思うのだが、あれこれどうやってGoogle Cloud Platform上で認証とかするんだ… 

ここから僕のyak shavingな旅が始まります。
 続きを読む
    このエントリーをはてなブックマークに追加 mixiチェック

ちょうど本業のほうでDBへのアクセスが遅い?んだかなんだかでREST APIがタイムアウトしている事象に出会っていたのでよっしゃとgo-sql-proxyを使おうと思ったのだけど、まずこのままだと実行時間とかが計測できない… ということに気づいて色々考えた結果PRを送る事にした。送ったら光速でマージされた。

今度から NewTraceProxyでプロキシを作れば Open/Exec/Queryに関しては所要時間が出力されるようになります。mysqlなら以下のような感じ:

driverName := "mysql"
if traceEnabled {
    driverName = "mysql-trace"
    sql.Register(driverName, proxy.NewTraceProxy(&mysql.MySQLDriver{}, logger))
}
db, err := sql.Open(driverName, dsn)
...

出力はこんな感じ:

tracer_test.go:27: Open (54.116µs)
tracer_test.go:27: Exec: CREATE TABLE t1 (id INTEGER PRIMARY KEY); args = [] (44.535µs)
tracer_test.go:41: Query: SELECT id FROM t1 WHERE id = ?; args = [1] (1.828µs)

わーい、これでボトルネック探すの捗るぞー!… と思っていたら、元々のNewTraceProxyのシグネチャが

func NewTraceProxy(d driver.Driver, o Outputter) *Proxy

で、これだと自前のloggerを受け付けてくれない!
type MyLogger struct { *log.Logger }
とかでも駄目だ!ということでインターフェースを定義してOutputメソッドを実装してればなんでもいいようにしておいたPRを送って取り込んでもらった。これで使えるようになった。YATTA!(けど、デプロイはこれからなのでまだなにか後で追加するかも…)

どちらのPRも光速でマージしてもらって大分たすかった。ありがとうございます。
    このエントリーをはてなブックマークに追加 mixiチェック

grpcをさらっと触ってみた。僕の個人的な結論から言うと、小規模なシステムにはいれるメリットあんまりないけど、複数チームでわりとバラバラに開発をしてるけど同じRPCを叩く必要があり、なおかつそれなりのトラフィックがあるなら有効そう。

他の言語の事は知らん。とりあえずGoでさわる。github.com/grpc/grpc-commonをチェックアウトして、サーバーとクライアントを起動する。ドキュメント読んでるとProtocol Buffersの話とかでてくるけど、動かしたいだけなら全部忘れてよし。

$ cd go/greeter_server
$ go run main.go
$ cd go/greeter_client
$ go run main.go

これだけだと一回RPCが走るだけでつまらないので、client側を変えて100 goroutineでぼちぼちたっぷりのコールをするようにする変更した部分はこんな感じ。ローカルホストにサーバーもクライアントもある状態なので正直正しい計測ではない事はまず言っておく。その前提で ざっくり10000 jobs/sec。HTTP2のオーバーヘッドを含めてだいたいそんなものなのでまぁ悪くないな、って感じ。

と、ツイートしたら"net/rpcと比べてどう?"って聞かれたのでほぼ同じプログラムをnet/rpcで作ったところ、約25K jobs/secいけた。 というわけで生スピードでは負けてしまったが、プロトコルの複雑さの差分と、goのhttp2がついこの間作られたばかりであまり最適化されていない、というのがほとんどの原因だと正直思ってる。

この辺りの厳密な値はちゃんとサーバー立てて検証すべきだし、他の言語でも試すべきなので本当に雑談程度の認識にしておいてください。

それより、やはり方法論としてProtocol Buffersでプロトコルを定義してそれを複数言語用に自動生成できるのが強みかなーと思ってる。JSON Schema的な。あっちの大陸とこっちの大陸で作業してるチームがサーバー・クライアントのコードのひな形を簡単に生成して作業を始められるのは強いのではないだろうか。このコード生成をgoから試すにはgithub.com/google/protobufを入れた上でgithub.com/golang/protobuf/protoc-gen-go を入れる必要があるので注意。

以上、さわってみたエントリでした。
    このエントリーをはてなブックマークに追加 mixiチェック

godepというツールをpecomigemogrepに便利に使わせてもらってたんだけど、このたびカスタムなgoスクリプト(goだとスクリプトじゃないと言われそうだけど、スクリプトとしか言い様が無い)を書いてgodepを卒業しました。

 なんでこうしたかというとgodepの-copy=falseというオプションが使えなくなり、基本的に依存関係のライブラリもこちらのレポジトリに入れないといけない形になったから。いや、入れても良いけどさ… う〜ん。毎日ビルドして出荷してるわけじゃないし、それなのにレポジトリをcloneした時に依存関係も全部落とすのはなああああ、ということで、もう全部自前で書きました。

別にシェルスクリプトでもよかったんだけど、goのプロジェクトだし…ってことで全部goで書いて、wercker.ymlからこんな感じで呼び出すようにした

それだけ。あとで「なんであんなことしてるの?」って聞かれた時用に書いておく。
    このエントリーをはてなブックマークに追加 mixiチェック

今回の勉強会、自分的にも久しぶりに出る勉強会でもあるんだけど、なんと当方多分初めてPerl以外の話を(まともに)公でしてきました。資料は… YAPC後で上げます! 

追記: ustの録画があるようです。最初の10分間は僕が主催者とだべってるだけなので飛ばしてください。あと残念ながら会場からの質問が聞こえないですが、まぁわかる…はず

今回はYAPC::Asia Tokyo 2014で話すネタの前哨戦という事で「そもそも俺の話したいネタに需要はあるのか?」とか「この内容でわかってもらえるのか?」とかを調べる意味合いもかねて話してきました。結果的には自分が喋りたい事を聞きたい人も一定数いることはわかったので大変よかった。

質疑応答を絡めた発表をやりたい!と思ってたんだけど、俺の今までのYAPCでの8年にわたる経験だと日本では誰も質問というか、発声をしないからそのまま始めたんじゃ質問は期待できないと思って、今回は冒頭に自己紹介をした後 まずまっさきに発声練習をしてもらった。本当はもう少し長めの文章を言って欲しかったんだけど、残念ながらそんな余裕がなかったので「Go大好き〜!」と叫んでもらいました。効果があったような気がするんだけど、どうだろうな。笑点の公開収録とかで前説の人いなかったらちゃんと拍手できなかったわーって俺いつも思ってたから効いたと思いたいw

 まぁその成果がでたのかどうかはわからないけど、かなり質問が来てちょっと時間オーバーしたくらいだったので意図としてはばっちりだった。時間制限の厳しいYAPCで同じテクニックを使うかどうかはまだちょっとわからない。

まぁともあれ自分的には手応えあったし、改善点とかも色々あったのですがすがしい感じで終えられました。尾藤さんありがとうございました!


あと今回僕の話に関してよかった・わるかった、どっちでもいいのでなんなりと感想があったらブログ等に書いていただけると大変ありがたいです。Twitterにあがっているもの以上のつっこんだ意見とか聞きたい!よろしくお願いいたします。 
    このエントリーをはてなブックマークに追加 mixiチェック

さきほどちょろっとアップデートが入ったpeco v0.2.2をリリースしましたChangeログ)。

で、ついでに昨日mattnさんがpecoについてツイートしてたので流れてしまう前にまとめておく


続きを読む
    このエントリーをはてなブックマークに追加 mixiチェック

pecoのv0.1.0をリリースしてから今日で丸一ヶ月がすぎました。今日という日にちょうどGitHubでのスターも1000を超え、大変うれしい次第です。ちなみに昨日の夜840くらいだったのにそれから200弱ものスターがついた。これぞまさにTJのロックスター効果:



「percolをインストールするのにpythonの事調べるのだるい」というだけのところからmattn氏の悪魔のささやきを真に受けて始まったこのプロジェクトですが、まぁ何がよかったのかこの程度の注目を集められるレベルに到達できて大変うれしいです。自分もこのコードを書いててようやくgo-stf-serverでメタメタだった部分が少しずつ昇華できている気がしているし、クロスコンパイル部分も完全自動化できたりと技術的な学びの意味でもやってよかったと思えるプロジェクトになりました。

v0.2.1では 複数のアクションをまとめて1キーからディスパッチできるようになる機能などが同梱される予定です。

機能的にはだんだん落ち着き始めているので、もし何かあったらイッシューに書いてください(日本語でいいんですよ!)。これからも皆様の意見、PRをお待ちしております! 
    このエントリーをはてなブックマークに追加 mixiチェック

先週 @k0kubunさんがpecoで複数キーの入力シーケンスに対してアクションを起こす(例:C-x, C-cで終了する、みたいなの)PRをしてくれたのでそれをマージした。pecoには楽しいお兄さんが色々コントリビュートしてくれているので、そのPRを見た瞬間にこんなコメントが

おお、いいですね、ということで実装してみようとしたところ… うっ… 設定ファイルから読み込んで動的に作る無名関数からレキシカルな変数へのスイッチングしてて、これをプログラム内部から他に作る方法がねぇ!w 設定ファイルからはできるのに!w むきー!

ということでその後、基本的な設計構造を変えないでその辺りを奇麗にできる方法は ないかと一日くらい費やした。が、やはりうまくいかない。薄々気づいていたけどこれFSMとかの出番だよな… 一から実装面倒くせぇなーと、つぶやいたらすぐ返信が:


うほ!goでahocorasickの実装があるwwww ありがとうございます!全部ぱくります!

コードを眺めているとトップレベルではstringに対しての実装で、 中身はruneに対してノードを返すみたいな事になってるので、これまぁ用はstring = []rune として考えられるので、キーシーケンス= []キー で代用できるね、って分かったのでガツガツ変更。といっても検索キーとか、ちょっと再起的に使うためにinterfaceを足した程度で、基本は何も変えていない。

そんなこんなで最初にpecoを書き始めてから一番大きいPRをマージして、キー入力周りがそれまでのコードと一変した。コードを提示してもらったおかげで任意の長さのキーシーケンスを特定のコマンドを高速かつ分かりやすい形で検索+ディスパッチできるようになった。

これも含めて先ほどpeco v0.2.0としてリリースした。このリリースはかなりの数の変更が入っているので、pecoヘビーユーザーには嬉しい機能が結構あると思う。是非お試し有れ!

本日の教訓:この一つ前の記事もパクリの話だったけど、こういう汎用的な方法論についての助言はどんどん受け入れるべきだし、コードもがんがん再利用してやればいいと思う。

プログラムを書く作業は孤独だけど、わからない事は「分からない!どこから始めるか教えて!」って聞けば誰でもヒントをくれるので人に頼る事を恐れないほうが良い(ただし、そこから先は自己責任でちゃんと勉強しましょうね)。そういえばgo-xslate書いた時もgfxに「これ、どこのサイト読むとxslateで使ってるVMのモデルの概要わかるの?」って聞いたな。

年を取れば取るほど経験値はたまっていくけど、それと同時に自分の知らない事が世界にはまだまだあるのがわかる。もちろんそれらを全部吸収できればベストなんだけど、脳にも限界があるので他人に聞く事によって自分の知らない事を素早く正しく補完できるのであればそれを活用できるようにつながりを作ったり、素直に質問できるようにしていくのが老いてゆくエンジニアの進む正しい道な気がする。おすすめです。
    このエントリーをはてなブックマークに追加 mixiチェック

pecoでは何個か前のリリースからバイナリビルドをリリースの成果物として登録するようにしている。これのおかげでpecoはそもそもの存在理由である「2014年だしこういうツールはバイナリ一個置いておくだけで動いてほしい!」というをより簡単に実現できている。


で、その実装方法。基本motemenさんのスクリプトにmattnさんがツッコミを入れたりしてるのを見ながら「よし!パクろう!」と思ってパクったんだけど、一つだけpecoでは意図的に変えたところがあって、それはboxの選定のところ。

motemenさんのgolang-goxc box自体に基本何も問題がないのだけど、pecoで色々やっているうちにgo1.3がリリースされたのにこのボックスを使っているといつまでもgo1.2.1だった(今はもう違うかもしれない)。まぁ当たり前ですよね。そこは他人の褌で相撲を取ろうとしている俺が文句言うところではない。

ただやっぱりバイナリのサイズが小さくなったり、多少パフォーマンス改善も見られている1.3系を使いたいと思いが募ったのと「これから先もきっとこういう事があるだろうし、そういうことがあるごとに文句を言わないといけないのか?」という思いがあり、pecoにはpeco専用のビルドボックスを作る事にした。それがこちら。もちろんgo1.3とgoxcを入れているところ以外はたいした事してない。

たいしたことはしてないんだけど、よくよく考えればライブラリとかではなくpecoのようにエンドユーザーに直接届くプログラムに関してはあまり自分が制御できていない環境に依存するのもどうかなーと思ったのでもうボックスから作る事にしてしまった。これなら自分がやりたいタイミングでgo1.4が出たらgo1.4にすることもできるし、goxcの特定のバージョンが欲しい、とかにも対応できる。

あとはmotemenさんの元記事と一緒。タグ打ってgit pushすれば勝手にファイルがあがってくる。おっさんは何もする必要がありません。大変すばらしい。また時間のある時にはhomebrewのレシピも自動的に作成しようとは思ってるけどそこまで至っていない。ともあれ、自動化はすばらしい。





ちなみに、drone.ioも一応登録はしてあって、こっちでもリリースとかできるかやってみたんだけど失敗して、ただただコンパイルして成果物を残しているだけ(基本前のやつは上書き)。あんまり必要じゃないけど、別の環境でコンパイルするとたまにバグが見つかったりもするので悪くはないと思ってる。まぁそのうち消すかも。
    このエントリーをはてなブックマークに追加 mixiチェック

tl;dr;
続きを読む
    このエントリーをはてなブックマークに追加 mixiチェック

これは笑ってしまった。The Open Source Report Cardという、githubのデータを持ってきて色々統計情報を見せてくれるサイトがあるんだけど、ここで今日とうとう「Exceptional Regexer」とか、そういうPerl Monger系の名称から「High Caliber Gopher」みたいな名称になって、さらによくみると「one of the 5% most active Go users」(6/18現在)だったのでツイートしたら、
GoプロジェクトにとてもゆかりのあるDave Cheneyさんからこんなツイートが…

よくみると彼は上位9%という位置だったw まぁGithubに対するコミット数とかだからそれ以外のところはカウントされないのでしょうがないw 彼がgithubにもっとコミットするようになったら一瞬で抜かされるだろうなー こういうのを"15 minutes of fame"とかいいますねw
    このエントリーをはてなブックマークに追加 mixiチェック

pecoそのものについてはここで読むよりREADMEを見た方が早いです

今月の初めくらいにpercolという便利なものがあるという話を聞き、「ほう、使おうかな」と思ったら普段あまり使い慣れていないpython製ツールでまるでcpanmを使うのがいやなPerlに慣れていない人のような反応で「まぁ必須アイテムじゃないし…」と思って諦めかけたところ


とか言われ「そこまでいいツールなのかなー」と思ったけど、使ったことないし、まずはツールがどういうものなのかをわかるためにGoで実装する事にした(はい、本当にこういう順番です)。
続きを読む
    このエントリーをはてなブックマークに追加 mixiチェック

(以下はgo 1.2.x時点での話です。将来的に仕様がかわるかどうかはわかりません)

これを読んでいて、こういうの気にしてない人多いんだろうなーと思って、書いてみます。元のポストはdeferの挙動について語っているように見受けられるけれども、これは要は複数スレッドで実行されるコードについて、プログラム終了時に同期とか取りたくない、という話だと思ったので、このポストのdeferを正しく動かすには…というところからどういう形でgoroutine同士で同期を取る方法があるのか、一例を書き出していきます。

TL;DR;

goでいくらgoroutineが気軽にかけるからと言って、複数スレッドで処理が行われているので同期はキチンとやらないとダメですよ。

続きを読む
    このエントリーをはてなブックマークに追加 mixiチェック

なんかごく一部に補足されているので、念のため軽く説明しておきます。


これ、ベストな方法だとは思っていないんだけど、最初にこれを書いた当時の考え方は以下の通り:

  1. これは自分の部署で初めて 本番に設置するgoアプリである
  2. 一次対応をする人は自分とは限らない
  3. 細かいコード内容の修正はともかく、明らかなバグっぽいものの修正(例:SQL文の変更)などを自分以外の人間が施した後にサーバーを簡単に再コンパイル+再起動するする方法がないと椅子が降ってくる事が容易に予想される
というところから、どうするのがベストか考えたのがきっかけ。以下、やった事の詳細。

続きを読む
    このエントリーをはてなブックマークに追加 mixiチェック

tl;dr: 別にPerl捨ててないです。Perl大好き。俺はLLはPerlでいい。でも別ドメインの事もやってもいいよね!

Rebuild.fmに限らず、公の場でYAPC/Perl以外の話をする事があるとは正直思っていなかったが、このたびRebuild.fm ep 42に置いて1時間Goについてしゃべりまくってきた。1時間ぶっつけ本番でしゃべりたい事はだいたいしゃべってきたのだけど、その後のフィードバック等もふまえてまとめておきたいと思ったのでこのエントリでまとめてみます

続きを読む
    このエントリーをはてなブックマークに追加 mixiチェック

このところ情熱を燃やしていた go-xslate プロジェクトですが、大分使えるようになってきたしかなりの処理速度も出るようになったしgo-nutsで宣伝もしたし、小さいプロジェクトで使い始めたし・・・ってことで 手軽に遊べる用に Go PlaygroundをぱくってGo-Xslate Playgroundってのを書いた。

外部テンプレートを使うWRAPPERやINCLUDEは使えないけど、それ以外の機能は一通り使えるはず。是非遊んでみて、問題がありそうだったら "Share"ボタンを押してpermalinkを作成の上、permalinkをissueにはりつけて教えてください。よろしくお願いいたします。

ちなみに書いたそばから mattnさんにぱくられたけど、自分もぱくってるし、ぱくられたのは良い物を書いたからなのでつまり全体的に大変よい。なおGo-Xslate Playground自体のソースはこちらにあります。なにか問題等ありましたら教えてくださいませ。
    このエントリーをはてなブックマークに追加 mixiチェック

golangでNgram処理をするためにgo-ngramを書きました。ngramによる類似文字列検索に関してはコードを読みながら逆算してこういうことか、という書き方をしたのでちょっと実装に自信はないのですが、まぁだいたい動くな、というところまでは確認しました。問題がありそうでしたら是非ご連絡ください。

使い方は以下の通り。まずただngramでトークナイズするならngram.NewTokenize()を使います。以下はいわゆるTrigramを使った例:

import (
"fmt"
"github.com/lestrrat/go-ngram"
)
func main() {
tok := ngram.NewTokenize(3, "ハローハローハロー") for _, token := range tok.Tokens() {
fmt.Printf("token = %s\n", token)
}

ちゃんと日本語も対応してます。

ユニークなトークンだけがほしい場合はTokenSet()を使ってください。
import (
"fmt"
"github.com/lestrrat/go-ngram"
)

func main () {
tok := ngram.NewTokenize(3, "ハローハローハロー")
set := tok.TokenSet() // see http://github.com/dackarep/golang-set
for x := range set.Iter() {
fmt.Printf("token = %s\n", x)
}
}

一応簡単なインメモリインデックスも作りました

import (
"fmt"
"github.com/lestrrat/go-ngram"
)

func main() {
index := ngram.NewIndex(3)
index.AddString(`....`) // 検索対象の文字列を登録しておく
....
matches := index.FindSimilarStrings(`ハロー`) // AddString()された物の中から`ハロー`に似ている文字列を持ってくる
for _, str := range matches {
fmt.Printf("matched %s\n", str)
}
}

これで登録されている文字列の中から似た単語を抽出できます。 デフォルト設定だと一個でもngramがマッチするとあたってしまいますが、SetMinScore()で閾値を設定することによって検索結果を絞り込めます。

さらに、一番良いマッチだけを持ってくる場合にはFindBestMatch()を使ってください。

あと自分で検索結果をフィルターする場合はIterateSimilar()を見てください。

ツッコミ、コメントお待ちしております。
    このエントリーをはてなブックマークに追加 mixiチェック
カテゴリー
記事検索
メッセージ

名前
メール
本文
アーカイブ

このページのトップヘ